Boundary between pinctrl and peripheral settings

Boundary between pinctrl and peripheral settings

[Heiko Stübner]

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

Re: Boundary between pinctrl and peripheral settings

[Linus Walleij]

On Fri, Aug 5, 2016 at 1:36 AM, Heiko Stübner <heiko@sntech.de> wrote:

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

This is really complex to understand, sorry I might be getting it wrong.

It sounds like there is some kind of hierarchical pin control
going on here: there is a front end pin controller (to the
far right in the image) that can set up pins to different
functions and (I guess) also set up the electrical characteristics.
That is what I guess we could call a proper "pin controller"
as it controls the actual pin/pad/iocell.

Then the thing called "switch" is some kind of multiplexer,
a second level pin controller.

I suspect the proper abstraction is actually a hierarchichal
two-level pinmux, i.e. a driver only doing multiplexing
behind the driver doing full pin control.

I have no idea how to best abstract this :( maybe changes
in the pin control core is needed to let pin controllers use
other pin controllers hierarchically?

However if this is a one-off, it may fit better like a local tweak
in the pin controller for the system.

I would ask questions like if these things exist in different
IO spaces, like is there one block of iomem for each of
these three blocks: uart, switch, pin controller? In that case
what we want to achieve is probably three drivers talking
to each other.

If the registers are in any way mixed up they may sit better
as quirks to either the pin controller driver on the right
or the uart on the left.

Yours,
Linus Walleij

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

Re: Boundary between pinctrl and peripheral settings

[Heiko Stuebner]

Hi Linus,


thanks for taking the time of reading through that wall of text :-) .

Am Mittwoch, 10. August 2016, 15:32:59 CEST schrieb Linus Walleij:
> On Fri, Aug 5, 2016 at 1:36 AM, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> > 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?
> 
> This is really complex to understand, sorry I might be getting it wrong.
> 
> It sounds like there is some kind of hierarchical pin control
> going on here: there is a front end pin controller (to the
> far right in the image) that can set up pins to different
> functions and (I guess) also set up the electrical characteristics.
> That is what I guess we could call a proper "pin controller"
> as it controls the actual pin/pad/iocell.

completely correct. Pin functions and electrical stuff (pull, drive strength, 
etc) can be set independently of them being actually used.


> Then the thing called "switch" is some kind of multiplexer,
> a second level pin controller.

More like a demultiplexer. The one uart signal is routed to one of the 4 
possible pins (which then need to also select the correct pin function to even 
receive that data).


> I suspect the proper abstraction is actually a hierarchichal
> two-level pinmux, i.e. a driver only doing multiplexing
> behind the driver doing full pin control.

That being a demux is the main reason I'm unsure if this belongs to pinctrl, 
because it is independent from the actual pin control and the pinctrl 
subsystem so far always only seems to only handle signals coming from multiple 
sources but not deciding to which pin to send a signal.


> I have no idea how to best abstract this :( maybe changes
> in the pin control core is needed to let pin controllers use
> other pin controllers hierarchically?
> 
> However if this is a one-off, it may fit better like a local tweak
> in the pin controller for the system.
> 
> I would ask questions like if these things exist in different
> IO spaces, like is there one block of iomem for each of
> these three blocks: uart, switch, pin controller? In that case
> what we want to achieve is probably three drivers talking
> to each other.
>
> If the registers are in any way mixed up they may sit better
> as quirks to either the pin controller driver on the right
> or the uart on the left.

Rockchip socs have these syscon aggregations called "General Register Files", 
which contain a lot of different controllable knobs. Inside that area there 
are sub-blocks liky phy control-blocks and also the whole core pinctrl 
mechanisms (iomux, electrical settings).

The uart demuxer is part of the GRF_SOC_CONx registers which is essentially a 
dumping ground for dozens of single-bit settings, from ethernet controller 
settings to some special gic settings and that uart demuxer setting somewhere 
in between.

So while in the same io area, I'd still consider them separate.

Essentially this is some sort of stray bit controlling a demux of the uart 
signals.


Today I've also stumbled onto drivers/i2c/muxes which does provide (de-)muxing 
capabilities for i2c busses (use different i2c controllers for a set of i2c 
devices, but also route i2c signals to different outputs (similar to the uart 
problem at hand)).

So if it were an i2c bus on the rk3399 soc the mux control would probably go 
into the muxes part of i2c and probably nobody would think of bolting that 
onto a pinctrl :-) . 


Heiko

Re: Boundary between pinctrl and peripheral settings

[Kever Yang]

Hi Heiko, Linus,


     Is there any news to handle this kind of IOMUX?


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

Re: Boundary between pinctrl and peripheral settings

[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

Re: Boundary between pinctrl and peripheral settings

[David.Wu]

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

Re: Boundary between pinctrl and peripheral settings

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


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

Re: 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@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

Re: Boundary between pinctrl and peripheral settings

[Heiko Stuebner]

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

Re: Boundary between pinctrl and peripheral settings

[David.Wu]

Hi Heiko,

在 2017/5/23 0:29, Heiko Stuebner 写道:
> 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.

Yes, Just use the gmac-m0 and gmac-m1-optimized two states.
Another aspect is I think per pin needs to traverse, and array element 
too much, want to improve route match rate.

How do you feel about the two points below:
1. add IOMUX_ROUTE type,that only per 8 pins need to traverse.
static struct rockchip_pin_bank rk3228_pin_banks[] = {
	PIN_BANK_IOMUX_FLAGS(0, 32, "gpio0", IOMUX_ROUTE, IOMUX_ROUTE, 0, 
IOMUX_ROUTE),
	PIN_BANK_IOMUX_FLAGS(1, 32, "gpio1", IOMUX_ROUTE, IOMUX_ROUTE, 
IOMUX_ROUTE, 0),
	PIN_BANK_IOMUX_FLAGS(2, 32, "gpio2", IOMUX_ROUTE, 0, 0, 0),
	PIN_BANK_IOMUX_FLAGS(3, 32, "gpio3", IOMUX_ROUTE, IOMUX_ROUTE, 
IOMUX_ROUTE, IOMUX_ROUTE),
};

2. add route mark for per bank, that only if current BIT(pin) & 
route_mask is ture, need to traverse.
static struct rockchip_pin_bank rk3228_pin_banks[] = {
	PIN_BANK_ROUTE_MASK(0, 32, "gpio0", 0x5c002002),
	......
	......
	......
};

static const struct rockchip_mux_route_data  rk3228_mux_route_data[] = {
	{
		/* pwm0-0 */
		.bank = 0,
		.pin = 26,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16),
	}, {
		/* pwm0-1 */
		.bank = 3,
		.pin = 21,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16) | BIT(0),
	},{
		/* pwm1-0 */
		.bank = 0,
		.pin = 27,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 1),
	}, {
		/* pwm1-1 */
		.bank = 0,
		.pin = 30,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 1) | BIT(1),
	},{
		/* pwm2-0 */
		.bank = 0,
		.pin = 28,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 2),
	}, {
		/* pwm2-1 */
		.bank = 1,
		.pin = 12,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 2) | BIT(2),
	},{
		/* pwm3-0 */
		.bank = 3,
		.pin = 26,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 3),
	}, {
		/* pwm3-1 */
		.bank = 1,
		.pin = 13,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 3) | BIT(3),
	},{
		/* sdio-0_d0 */
		.bank = 1,
		.pin = 1,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 4),
	}, {
		/* sdio-1_d0 */
		.bank = 3,
		.pin = 2,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 4) | BIT(4),
	},{
		/* spi-0_rx */
		.bank = 0,
		.pin = 13,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 5),
	}, {
		/* spi-1_rx */
		.bank = 0,
		.pin = 1,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 5) | BIT(5),
	},{
		/* emmc-0_cmd */
		.bank = 1,
		.pin = 22,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 7),
	}, {
		/* emmc-1_cmd */
		.bank = 2,
		.pin = 4,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 7) | BIT(7),
	},{
		/* uart2-0_rx */
		.bank = 1,
		.pin = 19,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 8),
	}, {
		/* uart2-1_rx */
		.bank = 1,
		.pin = 9,
		.func = 2,
		.route_offset = 0x50,
		.route_val = BIT(16 + 8) | BIT(8),
	},{
		/* uart1-0_rx */
		.bank = 1,
		.pin = 9,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 11),
	}, {
		/* uart1-1_rx */
		.bank = 3,
		.pin = 13,
		.func = 1,
		.route_offset = 0x50,
		.route_val = BIT(16 + 11) | BIT(11),
	},
};

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

Re: Boundary between pinctrl and peripheral settings

[David.Wu]

Hi Heiko,

Unfortunately, after the discussion with IC, we feel that we can not 
make hardware automatic switch;
The reason for this is that if you accidentally configure all of these 
configurations, the hardware doesn't know which one to choose, and then 
it's not good for our debug, because I don't know which option the 
current hardware is switching to.
So we still maintain the current way, but ask them to write more clearly 
and easily in the TRM file.

在 2017/5/23 0:29, Heiko Stuebner 写道:
> 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.


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

Re: Boundary between pinctrl and peripheral settings

[Heiko Stuebner]

Hi David,

Am Freitag, 21. Juli 2017, 14:33:00 CEST schrieb David.Wu:
> Unfortunately, after the discussion with IC, we feel that we can not 
> make hardware automatic switch;
> The reason for this is that if you accidentally configure all of these 
> configurations, the hardware doesn't know which one to choose, and then 
> it's not good for our debug, because I don't know which option the 
> current hardware is switching to.

I guess we can live with the routing solution, as it looks manageable :-) .

> So we still maintain the current way, but ask them to write more clearly 
> and easily in the TRM file.

Ok ... maybe also try to keep them from being overly creative with the
routing options (the rk3328 mac pins had these strange states, where
we were lucky that some of them were just not usable).


Heiko



> 在 2017/5/23 0:29, Heiko Stuebner 写道:
> > 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.
> 
> 
> 



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