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