Re: Boundary between pinctrl and peripheral settings

["David.Wu" <david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 4777 bytes --]

Hi Heiko, Linux

The attached file is the list for (pin, pinfunc) and their own grf-setting.

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.

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

在 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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>
>
>

[-- Attachment #2: RK322x & RK3399 & RK3328 COM_MUX_LIST.xlsx --]
[-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 23287 bytes --]

[-- Attachment #3: Type: text/plain, Size: 200 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip