kernel/linux.git/drivers/pinctrl/aspeed, branch v4.11.5

pinctrl: aspeed: g4: Fix mux configuration for GPIOs AA[4-7], AB[0-7]

2017-01-26T13:42:39+00:00

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 Signed-off-by: Linus Walleij

pinctrl: aspeed: Fix kerneldoc return descriptions

2016-12-28T00:23:10+00:00

Signed-off-by: Andrew Jeffery Acked-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g5: Add mux configuration for all pins

2016-12-28T00:21:23+00:00

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 Acked-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Linus Walleij

pinctrl: aspeed-g4: Add mux configuration for all pins

2016-12-27T22:17:23+00:00

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 Signed-off-by: Andrew Jeffery Acked-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Linus Walleij

pinctrl: aspeed: Read and write bits in LPC and GFX controllers

2016-12-27T22:15:32+00:00

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 Reviewed-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Linus Walleij

pinctrl-aspeed-g5: Never set SCU90[6]

2016-11-07T09:31:33+00:00

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 Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g5: Fix pin association of SPI1 function

2016-10-18T12:36:12+00:00

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 Reviewed-by: Joel Stanley Acked-by: Rob Herring Signed-off-by: Linus Walleij

pinctrl: aspeed-g5: Fix GPIOE1 typo

2016-10-18T12:36:11+00:00

This prevented C20 from successfully being muxed as GPIO. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed-g5: Fix names of GPID2 pins

2016-10-18T12:36:11+00:00

Fixes simple typos in the initial commit. There is no behavioural change. Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver) Reported-by: Xo Wang Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij

pinctrl: aspeed: "Not enabled" is a significant mux state

2016-10-18T12:36:10+00:00

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 Reviewed-by: Joel Stanley Signed-off-by: Linus Walleij