Boundary between pinctrl and peripheral settings

Fri May 19 02:13:17 PDT 2017

Hi David,

Am Donnerstag, 18. Mai 2017, 22:39:34 CEST schrieb David.Wu:
> The attached file is the list for (pin, pinfunc) and their own grf-setting.

thanks for collecting this wealth of information. 
One small thing, it seems like it is missing the pcie_clkreq_sel bit that
seems to switch the clkreq signal between gpio2-d2 and gpio4d0?

> If a pin-routing contains a few pins as gmac, need all the pins (pin, 
> pinfunc) to be configured correctly from DT, then the corresponding GRF 
> setting is configured.
> If configured grf-setting per pin, assuming that one of the pin's 
> pinfunc is wrong, it may cause pin-routing not to be effective or wrong.

I still think it should be enough to watch for one pin of a specifc group
to be set to its special pinmux function. If the pinmux setting is wrong
for that pin the ip block won't work correctly anyway (independent of
its inner-soc routing).

Our pinctrl groups also are defined on a global per-soc level
(rk3399.dtsi etc) and thus if they are really wrong, a lot of people will
complain anyway ;-) .

So for example just take 
uart2dbga_sin, uart2dbgb_sin, uart2dbgc_sin on rk3399
as pins to watch, some thing like

struct rk3399_pinrouting[] = {
	{
		/* uart2dbga */
		.bank = 4,
		.pin = 8,
		.func = 2,
		.route_offset = 0x0e21c,
		.route_val = (3 << (10+16)),
	}, {
		/* uart2dbgb */
		.bank = 4,
		.pin = 16,
		.func = 2,
		.route_offset = 0x0e21c,
		.route_val = (3 << (10+16) | 1 << 10),
	},
...
};

That way you can just hook it into the rockchip_set_mux function similar
to the recalc stuff, without to much trouble.

> So i think the smallest cell is a group, which contains the pins for the 
> pin-routing.

Though that creates more ABI between kernel and devicetree (pingroup
names), which will most likely bite us some time in the future. Also I'd
like to keep these dependencies as minimal as possible, as depending on
how much more funny inventions we accumulate, we might want to restructure
(or split) the driver at some later point - without breaking devicetrees.

Heiko

> 在 2017/5/18 16:48, Heiko Stübner 写道:
> > Hi Kever, David,
> >
> > Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
> >> Hi Heiko, Linus,
> >>      Is there any news to handle this kind of IOMUX?
> >
> > I was talking with David Wu about that a short while ago as well :-) .
> >
> > From what I've heared, in the future socs may be able to select that
> > routing themselfs based on the iomux and having had time to ponder
> > the whole issue for some time now, I do guess some sort of list would be
> > the least intrusive solution.
> >
> > It seems we're talking about only a handful of such routings per soc,
> > so I guess having the iomux setting check a list
> >
> > 	(pin, pinfunc) -> grf-setting for the pin-routing
> >
> > really is the least intrusive thing to do - as iomux settings really
> > aren't changed that often on a running device and adding more
> > stuff on top would just complicate everything.
> >
> >
> > Heiko
> >
> >
> >> Thanks,
> >> - Kever
> >>
> >> On 08/05/2016 07:36 AM, Heiko Stübner wrote:
> >>> Hi Linus,
> >>>
> >>>
> >>> on the rk3399 we found an interesting new feature and would like to get
> >>> some input from the pinctrl expert :-) , as Doug and me currently are of
> >>> differing opinions on where specific control elements belong.
> >>>
> >>>
> >>> 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?
> >>>
> >>> -----
> >>>
> >>> I hope to have presented the core issue above somewhat neutrally, below
> >>> are
> >>> my personal worries about doing that in pinctrl :-) .
> >>>
> >>>
> >>> Apart from it feeling "bolted-on" to me, I have two main worries with that
> >>> approach:
> >>> (1) Right now the unused pins are really unused on the same iomux, so when
> >>> flipping the switch it essentially does
> >>>
> >>>   uart-sout    unused
> >>>
> >>>    |(iomux2)    |(iomux2)
> >>>
> >>> +----------+ +----------+
> >>>
> >>> | gpio4_b0 | | gpio4_c0 |
> >>>
> >>> +----------+ +----------+
> >>>
> >>> going to
> >>>
> >>>   unused       uart-sout
> >>>
> >>>    |(iomux2)    |(iomux2)
> >>>
> >>> +----------+ +----------+
> >>>
> >>> | gpio4_b0 | | gpio4_c0 |
> >>>
> >>> +----------+ +----------+
> >>>
> >>> but nothing keeps designers from doing
> >>>
> >>>   uart-sout    special1
> >>>
> >>>    |(iomux2)    |(iomux2)
> >>>
> >>> +----------+ +----------+
> >>>
> >>> | gpio4_b0 | | gpio4_c0 |
> >>>
> >>> +----------+ +----------+
> >>>
> >>> going to
> >>>
> >>>   special2     uart-sout
> >>>
> >>>    |(iomux2)    |(iomux2)
> >>>
> >>> +----------+ +----------+
> >>>
> >>> | gpio4_b0 | | gpio4_c0 |
> >>>
> >>> +----------+ +----------+
> >>>
> >>> somewhere down the road, so relying on following the selected iomux feels
> >>> not future proof.
> >>>
> >>> (2) Looking at [0] we already have a similar case, where we configure the
> >>> pins for rgmii but still tell the gmac controller that it is supposed to
> >>> do
> >>> rgmii instead of rmii.
> >>>
> >>> Here the pinmux is the same for all pins, rmii just uses less pins when
> >>> compared to rgmii, so binding that to the pinmux isn't even possible.
> >>>
> >>> And doing it one way here and another way for the switch feels very
> >>> strange.
> >>>
> >>>
> >>> I hope this overly long mail was not to confusing and hope for some words
> >>> of wisdom ;-)
> >>>
> >>>
> >>> Big thanks
> >>> Heiko
> >>>
> >>>
> >>> [0]
> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/
> >>> arm/boot/dts/rk3288-miqi.dts#n139
> >>>
> >>>
> >>> _______________________________________________
> >>> Linux-rockchip mailing list
> >>> Linux-rockchip at lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> >
> >
> >
> >
> >
> 