summaryrefslogtreecommitdiff
path: root/drivers/pinctrl/aspeed
AgeCommit message (Collapse)Author
2017-04-24pinctrl: aspeed: g5: Add pinconf supportAndrew Jeffery
Testing for pinctrl-aspeed-g5 was performed on an AST2500EVB system, using the strategy outlined in the commit message for the change to the Aspeed pinctrl core. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-24pinctrl: aspeed: g4: Add pinconf supportAndrew Jeffery
Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto system, using the strategy outlined in the commit message for the change to the Aspeed pinctrl core. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-04-24pinctrl: aspeed: Add core pinconf supportAndrew Jeffery
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-04-11pinctrl: aspeed: Fix unused-const-variable warningsAndrew Jeffery
Three video input signals suffered from a search/replace failure in some copied code. 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 Altherr
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>
2017-01-26pinctrl: aspeed: g4: Fix mux configuration for GPIOs AA[4-7], AB[0-7]Andrew Jeffery
Incorrect video output configuration bits were being tested on pins in GPIO banks AA and AB for the ROM{8,16} mux functions. The ROM{8,16} functions are the highest priority for the relevant pins and also the default function, so we require the relevant video output configuration be disabled to mux GPIO functionality. As the wrong bits were being tested a GPIO export would succeed but leave the pin in an unresponsive state (i.e. value updates were ignored). This misbehaviour was discovered as part of extending the GPIO controller's support to cover banks Y, Z, AA, AB and AC (AC in the case of the g5 SoC). Fixes: 6d329f14a75f ("pinctrl: aspeed-g4: Add mux configuration for all pins") Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-28pinctrl: aspeed: Fix kerneldoc return descriptionsAndrew Jeffery
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-g5: Add mux configuration for all pinsAndrew Jeffery
The patch introducing the g5 pinctrl driver implemented a smattering of pins to flesh out the implementation of the core and provide bare-bones support for some OpenPOWER platforms and the AST2500 evaluation board. Now, update the bindings document to reflect the complete functionality and implement the necessary pin configuration tables in the driver. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-27pinctrl: aspeed-g4: Add mux configuration for all pinsAndrew Jeffery
The patch introducing the g4 pinctrl driver implemented a smattering of pins to flesh out the implementation of the core and provide bare-bones support for some OpenPOWER platforms. Now, update the bindings document to reflect the complete functionality and implement the necessary pin configuration tables in the driver. Cc: Timothy Pearson <tpearson@raptorengineering.com> Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-12-27pinctrl: aspeed: Read and write bits in LPC and GFX controllersAndrew Jeffery
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-11-07pinctrl-aspeed-g5: Never set SCU90[6]Andrew Jeffery
If a pin depending on bit 6 in SCU90 is requested for GPIO, the export will succeed but changes to the GPIO's value will not be accepted by the hardware. This is because the pinmux driver has misconfigured the SCU by writing 1 to the reserved bit. The description of SCU90[6] from the datasheet is 'Reserved, must keep at value ”0”'. The fix is to switch pinmux from the bit-flipping macro to explicitly configuring the .enable and .disable values to zero. The patch has been tested on an AST2500 EVB. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Uma Yadlapati <yadlapat@us.ibm.com> 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-10-18pinctrl: aspeed-g5: Fix pin association of SPI1 functionAndrew Jeffery
The SPI1 function was associated with the wrong pins: The functions that those pins provide is either an SPI debug or passthrough function coupled to SPI1. Make the SPI1 mux function configure the relevant pins and associate new SPI1DEBUG and SPI1PASSTHRU functions with the pins that were already defined. The notation used in the datasheet's multi-function pin table for the SoC is often creative: in this case the SYS* signals are enabled by a single bit, which is nothing unusual on its own, but in this case the bit was also participating in a multi-bit bitfield and therefore represented multiple functions. This fact was overlooked in the original patch. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) 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-g5: Fix GPIOE1 typoAndrew Jeffery
This prevented C20 from successfully being muxed as GPIO. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) 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-10-18pinctrl: aspeed-g5: Fix names of GPID2 pinsAndrew Jeffery
Fixes simple typos in the initial commit. There is no behavioural change. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Xo Wang <xow@google.com> 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-10-18pinctrl: aspeed: "Not enabled" is a significant mux stateAndrew Jeffery
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 Bergmann
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 pinctrl-aspeed-g5 driverAndrew Jeffery
A small subset of pins and functions are exposed. The selection of pins and functions is driven by the development of OpenBMC[1] on the AST2500 SoC, particularly around booting the IBM Witherspoon platform. [1] https://github.com/openbmc/docs 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-07pinctrl: Add pinctrl-aspeed-g4 driverAndrew Jeffery
A subset of the pins and functions are exposed. The selection of functions and pins is driven by the development of OpenBMC[1] on the AST2400 SoC, particularly around booting the OpenPOWER Palmetto development machine. [1] https://github.com/openbmc/docs 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-07pinctrl: Add core support for Aspeed SoCsAndrew Jeffery
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>