Re: Boundary between pinctrl and peripheral settings

[Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>]

Hi David,

[I've dropped Linus Walleij, so we don't spam him with our discussions :-) .
 I've kept the list though, so people can read up on it if necessary ]

Am Montag, 22. Mai 2017, 21:58:00 CEST schrieb David.Wu:
> 在 2017/5/19 17:13, Heiko Stuebner 写道:
> >> 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.
> >
> The gmac_m1_sel is different, it need to configure both bit[10] and 
> bit[2] with value:1, used after optimization. The gmac_m1 after 
> optimization need to configure all pins iomux of gmac_m1 and tx pins 
> iomux of gmac_m0. The tx pins iomux of gmac_m0 is also required,so it is 
> conflict of gmac_m1 after optimization. Besides, we don't need to use 
> m1, because m1 's signal is bad, don't think about it, but
> gmac_m1 after optimization is obligatory.

I'm not sure I understand the paragraph above. Especially what is the
"optimization" thing.

But if I understand you correctly, that still leaves us with only 2 settings.
gmac-m0 and gmac-m1-optimized (or whatever we want to call it).

For gmac-m0 just hook it onto mac_rxd0, which is only used on m0;
just use any of the gmac-m1 pins for that gmac-m1-optimized state;
and as yo wrote just ignore the gmac-m1 state, as it is bad anyway.


Heiko


> >> 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@lists.infradead.org
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> > 
> > 
> 
> 
> 



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip