Boundary between pinctrl and peripheral settings
linus.walleij at linaro.org
Wed Aug 10 06:32:59 PDT 2016
On Fri, Aug 5, 2016 at 1:36 AM, Heiko Stübner <heiko at sntech.de> wrote:
> In a nutshell on the rk3399 some things like one specific uart can use
> multiple pins to output data, but control of that seems to be split. The
> actual pin config is identical for all pins - each needs to be configured to
> function 2, pulls set etc. Then somewhere between the pin io-cells and the
> uart it seems to have some sort of switch to decide to which pin to actually
> route the data.
> +-------+ +--------+ /- GPIO4_B1 (pinmux 2)
> | uart2 | -- | switch | --- GPIO4_C1 (pinmux 2)
> +-------+ +--------+ \- GPIO4_C4 (pinmux 2)
> (switch selects one of the 3 pins to actually output data to)
> So the question now is, should the pinctrl driver also flip that switch to
> the correct position itself when pin-function 2 of say gpio4_bq gets
> selected or is that routing outside of pinctrl's scope?
This is really complex to understand, sorry I might be getting it wrong.
It sounds like there is some kind of hierarchical pin control
going on here: there is a front end pin controller (to the
far right in the image) that can set up pins to different
functions and (I guess) also set up the electrical characteristics.
That is what I guess we could call a proper "pin controller"
as it controls the actual pin/pad/iocell.
Then the thing called "switch" is some kind of multiplexer,
a second level pin controller.
I suspect the proper abstraction is actually a hierarchichal
two-level pinmux, i.e. a driver only doing multiplexing
behind the driver doing full pin control.
I have no idea how to best abstract this :( maybe changes
in the pin control core is needed to let pin controllers use
other pin controllers hierarchically?
However if this is a one-off, it may fit better like a local tweak
in the pin controller for the system.
I would ask questions like if these things exist in different
IO spaces, like is there one block of iomem for each of
these three blocks: uart, switch, pin controller? In that case
what we want to achieve is probably three drivers talking
to each other.
If the registers are in any way mixed up they may sit better
as quirks to either the pin controller driver on the right
or the uart on the left.
More information about the Linux-rockchip