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>
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: 56e57cb6c0 (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>
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: 56e57cb6c0 (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>
This prevented C20 from successfully being muxed as GPIO.
Fixes: 56e57cb6c0 (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>
Fixes simple typos in the initial commit. There is no behavioural
change.
Fixes: 56e57cb6c0 (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>
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>
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>
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>
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>
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>
