summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/aspeed/pinctrl-aspeed.c
AgeCommit message (Collapse)AuthorFilesLines
2023-01-31pinctrl: aspeed: Revert "Force to disable the function's signal"Joel Stanley1-1/+10
This reverts commit cf517fef601b9dde151f0afc27164d13bf1fd907. The commit cf517fef601b ("pinctrl: aspeed: Force to disable the function's signal") exposed a problem with fetching the regmap for reading the GFX register. The Romulus machine the device tree contains a gpio hog for GPIO S7. With the patch applied: Muxing pin 151 for GPIO Disabling signal VPOB9 for VPO aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to acquire regmap for IP block 1 aspeed-g5-pinctrl 1e6e2080.pinctrl: request() failed for pin 151 The code path is aspeed-gpio -> pinmux-g5 -> regmap -> clk, and the of_clock code returns an error as it doesn't have a valid struct clk_hw pointer. The regmap call happens because pinmux wants to check the GFX node (IP block 1) to query bits there. For reference, before the offending patch: Muxing pin 151 for GPIO Disabling signal VPOB9 for VPO Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Disabling signal VPOB9 for VPOOFF1 Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Disabling signal VPOB9 for VPOOFF2 Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000 Enabling signal GPIOS7 for GPIOS7 Muxed pin 151 as GPIOS7 gpio-943 (seq_cont): hogged as output/low We can't skip the clock check to allow pinmux to proceed, because the write to disable VPOB9 will try to set a bit in the GFX register space which will not stick when the IP is in reset. However, we do not want to enable the IP just so pinmux can do a disable-enable dance for the pin. For now, revert the offending patch while a correct solution is found. Fixes: cf517fef601b ("pinctrl: aspeed: Force to disable the function's signal") Link: https://github.com/openbmc/linux/issues/218 Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20230130220845.917985-1-joel@jms.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2023-01-27pinctrl: aspeed: Fix confusing types in return valueJoel Stanley1-1/+1
The function signature is int, but we return a bool. Instead return a negative errno as the kerneldoc suggests. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20230119231856.52014-1-joel@jms.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-10-24pinctrl: aspeed: Add missing header(s)Andy Shevchenko1-0/+1
Do not imply that some of the generic headers may be always included. Instead, include explicitly what we are direct user of. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Linus Walleij <linus.walleij@linaro.org>
2022-08-31pinctrl: aspeed: Force to disable the function's signalBilly Tsai1-10/+1
When the driver want to disable the signal of the function, it doesn't need to query the state of the mux function's signal on a pin. The condition below will miss the disable of the signal: Ball | Default | P0 Signal | P0 Expression | Other -----+---------+-----------+-----------------------------+---------- E21 GPIOG0 SD2CLK SCU4B4[16]=1 & SCU450[1]=1 GPIOG0 -----+---------+-----------+-----------------------------+---------- B22 GPIOG1 SD2CMD SCU4B4[17]=1 & SCU450[1]=1 GPIOG1 -----+---------+-----------+-----------------------------+---------- Assume the register status like below: SCU4B4[16] == 1 & SCU4B4[17] == 1 & SCU450[1]==1 After the driver set the Ball E21 to the GPIOG0: SCU4B4[16] == 0 & SCU4B4[17] == 1 & SCU450[1]==0 When the driver want to set the Ball B22 to the GPIOG1, the condition of the SD2CMD will be false causing SCU4B4[17] not to be cleared. Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20220818101839.28860-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-06-15pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()Haowen Bai1-2/+2
pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference. Signed-off-by: Haowen Bai <baihaowen@meizu.com> Link: https://lore.kernel.org/r/1650508019-22554-1-git-send-email-baihaowen@meizu.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-08-10pinctrl: aspeed: placate kernel-doc warningsRandy Dunlap1-2/+2
Eliminate kernel-doc warnings in drivers/pinctrl/aspeed by using proper kernel-doc notation. Fixes these kernel-doc warnings: drivers/pinctrl/aspeed/pinmux-aspeed.c:61: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Query the enabled or disabled state for a mux function's signal on a pin drivers/pinctrl/aspeed/pinctrl-aspeed.c:135: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Search for the signal expression needed to enable the pin's signal for the Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Aditya Srivastava <yashsri421@gmail.com> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: linux-aspeed@lists.ozlabs.org Cc: openbmc@lists.ozlabs.org Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-gpio@vger.kernel.org Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20210723034840.8752-1-rdunlap@infradead.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2021-05-19pinctrl: aspeed: Fix minor documentation errorSouptick Joarder1-1/+2
Kernel test robot throws below warning -> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c:2705: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2614: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/pinctrl/aspeed/pinctrl-aspeed.c:111: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/pinctrl/aspeed/pinmux-aspeed.c:24: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Fix minor documentation error. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/1619353584-8196-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-12-08pinctrl: aspeed: Fix GPIO requests on pass-through banksAndrew Jeffery1-6/+68
Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.") fixes access to GPIO banks T and U on the AST2600. Both banks contain input-only pins and the GPIO pin function is named GPITx and GPIUx respectively. Unfortunately the fix had a negative impact on GPIO banks D and E for the AST2400 and AST2500 where the GPIO pass-through functions take similar "GPI"-style names. The net effect on the older SoCs was that when the GPIO subsystem requested a pin in banks D or E be muxed for GPIO, they were instead muxed for pass-through mode. Mistakenly muxing pass-through mode e.g. breaks booting the host on IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI. Further exploit the names in the provided expression structure to differentiate pass-through from pin-specific GPIO modes. This follow-up fix gives the expected behaviour for the following tests: Witherspoon BMC (AST2500): 1. Power-on the Witherspoon host 2. Request GPIOD1 be muxed via /sys/class/gpio/export 3. Request GPIOE1 be muxed via /sys/class/gpio/export 4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through ("GPIE2" mode) via a pinctrl hog in the devicetree Rainier BMC (AST2600): 5. Request GPIT0 be muxed via /sys/class/gpio/export 6. Request GPIU0 be muxed via /sys/class/gpio/export Together the tests demonstrate that all three pieces of functionality (general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through mode via 4) operate as desired across old and new SoCs. Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Billy Tsai <billy_tsai@aspeedtech.com> Cc: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-11-05pinctrl: aspeed: Fix GPI only function problem.Billy Tsai1-3/+4
Some gpio pin at aspeed soc is input only and the prefix name of these pin is "GPI" only. This patch fine-tune the condition of GPIO check from "GPIO" to "GPI" and it will fix the usage error of banks D and E in the AST2400/AST2500 and banks T and U in the AST2600. Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs") Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20201030055450.29613-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-09-29pinctrl: aspeed: Use the right pinconf maskAndrew Jeffery1-1/+1
The Aspeed pinconf data structures are split into 'conf' and 'map' types, where the 'conf' struct defines which register and bitfield to manipulate, while the 'map' struct defines what value to write to the register and bitfield. Both structs have a mask member, and the wrong mask was being used to tell the regmap which bits to update. A todo is to look at whether we can remove the mask from the 'map' struct. Fixes: 5f52c853847f ("pinctrl: aspeed: Use masks to describe pinconf bitfields") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Johnny Huang <johnny_huang@aspeedtech.com> Link: https://lore.kernel.org/r/20200910025631.2996342-3-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-09-29pinctrl: aspeed: Format pinconf debug consistent with pinmuxAndrew Jeffery1-3/+3
When displaying which pinconf register and field is being touched, format the field mask so that it's consistent with the way the pinmux portion formats the mask. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200910025631.2996342-2-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2020-07-16pinctrl: aspeed: Improve debug outputAndrew Jeffery1-3/+22
We need to iterate over each pin in a group for a function and disable higher priority mux configurations on the pin before finally muxing the relevant function's signal. With the current debug output it is hard to track what register output is relevant to which operation, so break up the actions in the debug output by providing some more context. Before: [ 5.446656] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 37 (B26) for 1e780000.gpio:341 [ 5.447377] Want SCU414[0x00000020]=0x1, got 0x0 from 0x00000000 [ 5.447854] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000 [ 5.448340] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000 After: [ 5.298053] Muxing pin 37 for GPIO [ 5.298294] Disabling signal NRI4 for NRI4 [ 5.298593] Want SCU414[0x00000020]=0x1, got 0x0 from 0x00000000 [ 5.298983] Disabling signal RGMII4RXD1 for RGMII4 [ 5.299309] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000 [ 5.299694] Disabling signal RMII4RXD1 for RMII4 [ 5.300014] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000 [ 5.300396] Enabling signal GPIOE5 for GPIOE5 [ 5.300687] Muxed pin 37 as GPIOE5 Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20200701030039.2834418-1-joel@jms.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-13pinctrl: aspeed: Use masks to describe pinconf bitfieldsJohnny Huang1-6/+6
Since some of the AST2600 pinconf setting are not just single bit, modified aspeed_pin_config @bit to @mask and add @mask to aspeed_pin_config_map to support configuring multiple bits. Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com> [AJ: Tweak commit message] Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20191202061432.3996-7-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-12-13pinctrl: aspeed: Move aspeed_pin_config_map to separate source fileJohnny Huang1-33/+5
The AST2600 pinconf differs from the 2400 and 2500, aspeed_pin_config_map should define separately, and add @confmaps and @nconfmaps to aspeed_pinctrl_data structure for that change. Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20191202061432.3996-6-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-29pinctrl: aspeed-g5: Delay acquisition of regmapsAndrew Jeffery1-7/+5
While sorting out some devicetree issues I found that the pinctrl driver was failing to acquire its GFX regmap even though the phandle was present in the devicetree: [ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail Without access to the GFX regmap we fail to configure the mux for the VPO function: [ 1.548866] pinctrl core: add 1 pinctrl maps [ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO [ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display [ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display ... [ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display [ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display [ 1.563113] Muxing pin 144 for VPO [ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000 [ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back This turned out to be a simple problem of timing: The ASPEED pinctrl driver is probed during arch_initcall(), while GFX is processed much later. As such the GFX syscon is not yet registered during the pinctrl probe() and we get an -EPROBE_DEFER when we try to look it up, however we must not defer probing the pinctrl driver for the inability to mux some GFX-related functions. Switch to lazily grabbing the regmaps when they're first required by the mux configuration. This generates a bit of noise in the patch as we have to drop the `const` qualifier on arguments for several function prototypes, but has the benefit of working. I've smoke tested this for the ast2500-evb under qemu with a dummy graphics device. We now succeed in our attempts to configure the SoC's VPO pinmux function. Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-14Merge tag 'pinctrl-v5.3-1' of ↵Linus Torvalds1-209/+37
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "This is the bulk of pin control changes for the v5.3 kernel cycle: Core changes: - Device links can optionally be added between a pin control producer and its consumers. This will affect how the system power management is handled: a pin controller will not suspend before all of its consumers have been suspended. This was necessary for the ST Microelectronics STMFX expander and need to be tested on other systems as well: it makes sense to make this default in the long run. Right now it is opt-in per driver. - Drive strength can be specified in microamps. With decreases in silicon technology, milliamps isn't granular enough, let's make it possible to select drive strengths in microamps. Right now the Meson (AMlogic) driver needs this. New drivers: - New subdriver for the Tegra 194 SoC. - New subdriver for the Qualcomm SDM845. - New subdriver for the Qualcomm SM8150. - New subdriver for the Freescale i.MX8MN (Freescale is now a product line of NXP). - New subdriver for Marvell MV98DX1135. Driver improvements: - The Bitmain BM1880 driver now supports pin config in addition to muxing. - The Qualcomm drivers can now reserve some GPIOs as taken aside and not usable for users. This is used in ACPI systems to take out some GPIO lines used by the BIOS so that noone else (neither kernel nor userspace) will play with them by mistake and crash the machine. - A slew of refurbishing around the Aspeed drivers (board management controllers for servers) in preparation for the new Aspeed AST2600 SoC. - A slew of improvements over the SH PFC drivers as usual. - Misc cleanups and fixes" * tag 'pinctrl-v5.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (106 commits) pinctrl: aspeed: Strip moved macros and structs from private header pinctrl: aspeed: Fix missed include pinctrl: baytrail: Use GENMASK() consistently pinctrl: baytrail: Re-use data structures from pinctrl-intel.h pinctrl: baytrail: Use defined macro instead of magic in byt_get_gpio_mux() pinctrl: qcom: Add SM8150 pinctrl driver dt-bindings: pinctrl: qcom: Add SM8150 pinctrl binding dt-bindings: pinctrl: qcom: Document missing gpio nodes pinctrl: aspeed: Add implementation-related documentation pinctrl: aspeed: Split out pinmux from general pinctrl pinctrl: aspeed: Clarify comment about strapping W1C pinctrl: aspeed: Correct comment that is no longer true MAINTAINERS: Add entry for ASPEED pinctrl drivers dt-bindings: pinctrl: aspeed: Convert AST2500 bindings to json-schema dt-bindings: pinctrl: aspeed: Convert AST2400 bindings to json-schema dt-bindings: pinctrl: aspeed: Split bindings document in two pinctrl: qcom: Add irq_enable callback for msm gpio pinctrl: madera: Fixup SPDX headers pinctrl: qcom: sdm845: Fix CONFIG preprocessor guard pinctrl: tegra: Add bitmask support for parked bits ...
2019-07-03pinctrl: aspeed: Split out pinmux from general pinctrlAndrew Jeffery1-209/+37
ASPEED have completely rearranged the System Control Unit register layout with the AST2600. The existing code took advantage of the fact that the AST2400 and AST2500 had layouts that were similar enough to have little impact on the pinmux infrastructure (though there is a wart with read-modify-write vs write-1-clear semantics of the hardware strapping registers between the two). Given that any similarity has been thrown out with the AST2600, separate out the function applying an expression state to be driver-specific. With it, extract out the pinmux macro jungle to its own header and implementation so the pieces can be composed without dependency cycles. Cc: Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Link: https://lore.kernel.org/r/20190628023838.15426-8-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-07-03pinctrl: aspeed: Clarify comment about strapping W1CAndrew Jeffery1-1/+1
Writes of 1 to SCU7C clear set bits in SCU70, the hardware strapping register. The information was correct if you squinted while reading, but hopefully switching the order of the registers as listed conveys it better. Cc: Johnny Huang <johnny_huang@aspeedtech.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20190628023838.15426-7-andrew@aj.id.au Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Thomas Gleixner1-5/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-31pinctrl: remove unnecessary unlikely()Igor Stoppa1-1/+1
WARN_ON() already contains an unlikely(), so it's not necessary to wrap it into another. Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-06-28pinctrl: aspeed: Fix documentationJoel Stanley1-2/+2
Fixes these warnings: pinctrl-aspeed.c:112: warning: Function parameter or member 'map' not described in 'aspeed_sig_desc_eval' pinctrl-aspeed.c:112: warning: Excess function parameter 'regmap' description in 'aspeed_sig_desc_eval' Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-31pinctrl: aspeed: Rework strap register write logic for the AST2500Andrew Jeffery1-10/+16
Yong Li found that writes to the AST2500 strapping register were not properly supported by the Aspeed pinctrl core and provided a patch to rectify the problem. Several revisions of the patch were posted and ultimately v4 should have been applied, however some unfortunate liberal application of tags on my part lead to confusion between v3[1] and v4[2]. Generate the diff between v3 and v4 to apply as a fixup patch. [1] http://patchwork.ozlabs.org/patch/801662/ [2] http://patchwork.ozlabs.org/patch/802946/ Cc: Yong Li <sdliyong@gmail.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-08-22pinctrl: aspeed: Fix ast2500 strap register write logicYong Li1-2/+17
On AST2500, the hardware strap register(SCU70) only accepts write ‘1’, to clear it to ‘0’, must set bits(write ‘1’) to SCU7C Signed-off-by: Yong Li <sdliyong@gmail.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-24pinctrl: aspeed: Add core pinconf supportAndrew Jeffery1-0/+211
Several pinconf parameters have a fairly straight-forward mapping onto the Aspeed pin controller. These include management of pull-down bias, drive-strength, and some debounce configuration. Pin biasing largely is managed on a per-GPIO-bank basis, aside from the ADC and RMII/RGMII pins. As the bias configuration for each pin in a bank maps onto a single per-bank bit, configuration tables will be introduced to describe the ranges of pins and the supported pinconf parameter. The use of tables also helps with the sparse support of pinconf properties, and the fact that not all GPIO banks support biasing or drive-strength configuration. Further, as the pin controller uses a consistent approach for bias and drive strength configuration at the register level, a second table is defined for looking up the the bit-state required to enable or query the provided configuration. Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU. The test method was to set the appropriate bits via devmem and verify the result through the controller's pinconf-pins debugfs file. This simultaneously validates the get() path and half of the set() path. The remainder of the set() path was validated by configuring a handful of pins via the devicetree with the supported pinconf properties and verifying the appropriate registers were touched. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-03-14pinctrl: aspeed: Allow disabling Port D and Port E loopback modeRick Altherr1-2/+12
Port D and port E GPIO loopback modes are commonly enabled via hardware straps for use with front-panel buttons. When the BMC is powered off or fails to boot, the front-panel buttons are directly connected to the host chipset via the loopback to allow direct power-on and reset control. Once the BMC has booted, the loopback mode must be disabled for the BMC to take over control of host power-on and reset. Disabling these loopback modes requires writing to the hardware strap register which violates the current design of assuming the system designer chose the strap settings for a specific reason and they should be treated as read-only. Only the two bits of the strap register related to these loopback modes are allowed to be written and comments have been added to explain why. Signed-off-by: Rick Altherr <raltherr@google.com> Acked-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-28pinctrl: aspeed: Fix kerneldoc return descriptionsAndrew Jeffery1-6/+6
Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-28pinctrl: aspeed: Read and write bits in LPC and GFX controllersAndrew Jeffery1-61/+100
The System Control Unit IP block in the Aspeed SoCs is typically where the pinmux configuration is found, but not always. A number of pins depend on state in one of LPC Host Control (LHC) or SoC Display Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the means to adjust these as necessary. We use syscon to cast a regmap over the GFX and LPC blocks, which is used as an arbitration layer between the relevant driver and the pinctrl subsystem. The regmaps are then exposed to the SoC-specific pinctrl drivers by phandles in the devicetree, and are selected during a mux request by querying a new 'ip' member in struct aspeed_sig_desc. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-10-18pinctrl: aspeed: "Not enabled" is a significant mux stateAndrew Jeffery1-5/+7
Consider a scenario with one pin P that has two signals A and B, where A is defined to be higher priority than B: That is, if the mux IP is in a state that would consider both A and B to be active on P, then A will be the active signal. To instead configure B as the active signal we must configure the mux so that A is inactive. The mux state for signals can be described by logical operations on one or more bits from one or more registers (a "signal expression"), which in some cases leads to aliased mux states for a particular signal. Further, signals described by multi-bit bitfields often do not only need to record the states that would make them active (the "enable" expressions), but also the states that makes them inactive (the "disable" expressions). All of this combined leads to four possible states for a signal: 1. A signal is active with respect to an "enable" expression 2. A signal is not active with respect to an "enable" expression 3. A signal is inactive with respect to a "disable" expression 4. A signal is not inactive with respect to a "disable" expression In the case of P, if we are looking to activate B without explicitly having configured A it's enough to consider A inactive if all of A's "enable" signal expressions evaluate to "not active". If any evaluate to "active" then the corresponding "disable" states must be applied so it becomes inactive. For example, on the AST2400 the pins composing GPIO bank H provide signals ROMD8 through ROMD15 (high priority) and those for UART6 (low priority). The mux states for ROMD8 through ROMD15 are aliased, i.e. there are two mux states that result in the respective signals being configured: A. SCU90[6]=1 B. Strap[4,1:0]=100 Further, the second mux state is a 3-bit bitfield that explicitly defines the enabled state but the disabled state is implicit, i.e. if Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not considered active. This requires the mux function evaluation logic to use approach 2. above, however the existing code was using approach 3. The problem was brought to light on the Palmetto machines where the strap register value is 0x120ce416, and prevented GPIO requests in bank H from succeeding despite the hardware being in a position to allow them. Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-09-13pinctrl: aspeed: fix regmap error handlingArnd Bergmann1-3/+3
The newly added aspeed driver tries to check for a negative return value from a pinctrl function, but stores the intermediate value in a 'bool' variable, which cannot work: drivers/pinctrl/aspeed/pinctrl-aspeed.c: In function 'aspeed_sig_expr_set': drivers/pinctrl/aspeed/pinctrl-aspeed.c:192:11: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare] This slightly reworks the logic to use an explicit comparison with zero before assigning to the temporary variable. Reported-by: Colin King <colin.king@canonical.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-09-07pinctrl: Add core support for Aspeed SoCsAndrew Jeffery1-0/+498
The Aspeed SoCs typically provide more than 200 pins for GPIO and other functions. The signal enabled on a pin is determined on a priority basis, where a given pin can provide a number of different signal types. In addition to the priority levels, the Aspeed pin controllers describe the signal active on a pin by compound logical expressions involving multiple operators, registers and bits. Some difficulty arises as a pin's function bit masks for each priority level are frequently not the same (i.e. we cannot just flip a bit to change from a high to low priority signal), or even in the same register(s). Some configuration bits affect multiple pins, while in other cases the signals for a bus must each be enabled individually. Together, these features give rise to some complexity in the implementation. A more complete description of the complexities is provided in the associated header file. The patch doesn't implement pinctrl/pinmux/pinconf for any particular Aspeed SoC, rather it adds the framework for defining pinmux configurations. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-25 07:33:09 +0300