Boundary between pinctrl and peripheral settings

[David.Wu]

Hi Heiko,

在 2017/5/19 17:13, Heiko Stuebner 写道:
> 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?

Yes, you are right. I miss the the pcie_clkreq_sel bit.

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

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