Boundary between pinctrl and peripheral settings

[Heiko Stuebner]

Hi Linus,


thanks for taking the time of reading through that wall of text :-) .

Am Mittwoch, 10. August 2016, 15:32:59 CEST schrieb Linus Walleij:
> 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.

completely correct. Pin functions and electrical stuff (pull, drive strength, 
etc) can be set independently of them being actually used.


> Then the thing called "switch" is some kind of multiplexer,
> a second level pin controller.

More like a demultiplexer. The one uart signal is routed to one of the 4 
possible pins (which then need to also select the correct pin function to even 
receive that data).


> 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.

That being a demux is the main reason I'm unsure if this belongs to pinctrl, 
because it is independent from the actual pin control and the pinctrl 
subsystem so far always only seems to only handle signals coming from multiple 
sources but not deciding to which pin to send a signal.


> 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.

Rockchip socs have these syscon aggregations called "General Register Files", 
which contain a lot of different controllable knobs. Inside that area there 
are sub-blocks liky phy control-blocks and also the whole core pinctrl 
mechanisms (iomux, electrical settings).

The uart demuxer is part of the GRF_SOC_CONx registers which is essentially a 
dumping ground for dozens of single-bit settings, from ethernet controller 
settings to some special gic settings and that uart demuxer setting somewhere 
in between.

So while in the same io area, I'd still consider them separate.

Essentially this is some sort of stray bit controlling a demux of the uart 
signals.


Today I've also stumbled onto drivers/i2c/muxes which does provide (de-)muxing 
capabilities for i2c busses (use different i2c controllers for a set of i2c 
devices, but also route i2c signals to different outputs (similar to the uart 
problem at hand)).

So if it were an i2c bus on the rk3399 soc the mux control would probably go 
into the muxes part of i2c and probably nobody would think of bolting that 
onto a pinctrl :-) . 


Heiko