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: 7d29ed88ac ("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>
The ASPEED pinctrl driver implementations make heavy use of macros to
minimise tedium of implementation and maximise the chance that the
compiler will catch errors in defining signal and pin configurations.
While the goal of minimising errors is achieved, it is at the cost of
the complexity of the macros.
Document examples of the expanded form of pin declarations to
demonstrate the operation of the macros.
Cc: Johnny Huang <johnny_huang@aspeedtech.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20190628023838.15426-9-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
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>
