Boundary between pinctrl and peripheral settings
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
Quoted 11 lines · Heiko Stübner
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)
Quoted 6 lines
(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_bqgets 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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
A message that is not in the archive (sent off-list or not yet received): CACRpkdb=ju0i9x3rtRz0OvUkrsGBSBLymnzLqWNZ=WWJ6CKryQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
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:
Quoted 21 lines · Heiko Stübner
Quoted 12 lines
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)Quoted 7 lines
+-------+ +--------+ \-
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_bqgets selected or is that routing outside of pinctrl's scope?
Quoted 8 lines
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.
Quoted 2 lines
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).
Quoted 3 lines
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.
Quoted 13 lines
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.
Quoted 3 lines
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
Hi Heiko, Linus,
Is there any news to handle this kind of IOMUX?
Thanks,
- Kever
Quoted 103 lines · 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_bqgets 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 doesuart-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_______________________________________________
Linux-rockchip mailing list [email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
A message that is not in the archive (sent off-list or not yet received): 2f1d45cb-8869-94fc-98b1-952d0f12d343-TNX95d0MmH7DzftRWevZcw@public.gmane.org
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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
Quoted 122 lines
Thanks,
- KeverQuoted 118 lines · 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_bqgets 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 doesuart-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 [email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
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.
Quoted 16 lines · Heiko Stübner
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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
Quoted 137 lines
(pin, pinfunc) -> grf-setting for the pin-routingreally 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
Quoted 122 lines
Thanks,
- KeverQuoted 118 lines · 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_bqgets 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 doesuart-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 [email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list [email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
A message that is not in the archive (sent off-list or not yet received): a865024c-98d4-4349-6a33-e29fbc3cd7a7-TNX95d0MmH7DzftRWevZcw@public.gmane.org
Hi David,
Am Donnerstag, 18. Mai 2017, 22:39:34 CEST schrieb David.Wu:
Quoted 1 line
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?
Quoted 5 lines
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 takeuart2dbga_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.
Quoted 2 lines
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
Quoted 145 lines · Heiko Stübner
Quoted 144 lines
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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-routingreally 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
Quoted 118 lines
Thanks,
- KeverQuoted 114 lines · 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_bqgets 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 doesuart-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
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Heiko,
Quoted 8 lines · Heiko Stuebner
Hi David,
Am Donnerstag, 18. Mai 2017, 22:39:34 CEST schrieb David.Wu:
Quoted 1 line
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 thepcie_clkreq_selbit that seems to switch the clkreq signal between gpio2-d2 and gpio4d0?
Yes, you are right. I miss the the pcie_clkreq_sel bit.
Quoted 37 lines
Quoted 7 lines
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.dtsietc) and thus if they are really wrong, a lot of people will complain anyway ;-) .So for example just take
uart2dbga_sin,uart2dbgb_sin,uart2dbgc_sinon rk3399 as pins to watch, some thing likestruct 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), },
Quoted 6 lines
...
};That way you can just hook it into the
rockchip_set_muxfunction 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.
Quoted 4 lines
Quoted 3 lines
So i think the smallest cell is a group, which contains the pins for the pin-routing.
Quoted 170 lines
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
Quoted 155 lines · Heiko Stübner
Quoted 153 lines
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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-routingreally 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
Quoted 122 lines
Thanks,
- KeverQuoted 118 lines · 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_bqgets 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 doesuart-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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
A message that is not in the archive (sent off-list or not yet received): 97536e9f-7ad9-032b-d2dd-921f97464123-TNX95d0MmH7DzftRWevZcw@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:
Quoted 42 lines · Heiko Stuebner
Quoted 35 lines
Quoted 5 lines
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.dtsietc) and thus if they are really wrong, a lot of people will complain anyway ;-) .So for example just take
uart2dbga_sin,uart2dbgb_sin,uart2dbgc_sinon rk3399 as pins to watch, some thing likestruct 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), },Quoted 6 lines
...
};That way you can just hook it into the
rockchip_set_muxfunction similar to the recalc stuff, without to much trouble.
Quoted 7 lines
The
gmac_m1_selis different, it need to configure both bit[10] and bit[2] with value:1, used after optimization. Thegmac_m1after optimization need to configure all pins iomux ofgmac_m1and tx pins iomux ofgmac_m0. The tx pins iomux ofgmac_m0is also required,so it is conflict ofgmac_m1after optimization. Besides, we don't need to use m1, because m1 's signal is bad, don't think about it, butgmac_m1after 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
Quoted 158 lines
Quoted 158 lines
Quoted 2 lines
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
Quoted 145 lines · Heiko Stübner
Quoted 144 lines
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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-routingreally 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
Quoted 118 lines
Thanks,
- KeverQuoted 114 lines · 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_bqgets 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 doesuart-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
Quoted 18 lines
Quoted 15 lines
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi Heiko,
Quoted 60 lines · 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:
Quoted 42 lines · Heiko Stuebner
Quoted 35 lines
Quoted 5 lines
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.dtsietc) and thus if they are really wrong, a lot of people will complain anyway ;-) .So for example just take
uart2dbga_sin,uart2dbgb_sin,uart2dbgc_sinon rk3399 as pins to watch, some thing likestruct 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), },Quoted 6 lines
...
};That way you can just hook it into the
rockchip_set_muxfunction similar to the recalc stuff, without to much trouble.Quoted 7 lines
The
gmac_m1_selis different, it need to configure both bit[10] and bit[2] with value:1, used after optimization. Thegmac_m1after optimization need to configure all pins iomux ofgmac_m1and tx pins iomux ofgmac_m0. The tx pins iomux ofgmac_m0is also required,so it is conflict ofgmac_m1after optimization. Besides, we don't need to use m1, because m1 's signal is bad, don't think about it, butgmac_m1after optimization is obligatory.I'm not sure I understand the paragraph above. Especially what is the "optimization" thing.
Quoted 6 lines
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),
},
};Quoted 186 lines
Heiko
Quoted 176 lines
Quoted 173 lines
Quoted 2 lines
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
Quoted 155 lines · Heiko Stübner
Quoted 153 lines
Hi Kever, David,
Am Donnerstag, 18. Mai 2017, 16:21:09 CEST schrieb Kever Yang:
Quoted 2 lines
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-routingreally 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
Quoted 122 lines
Thanks,
- KeverQuoted 118 lines · 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_bqgets 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 doesuart-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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
_______________________________________________
Linux-rockchip mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
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.
Quoted 6 lines · 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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip
A message that is not in the archive (sent off-list or not yet received): d0ade22d-3e3d-6bf3-3a06-e85e74360147-TNX95d0MmH7DzftRWevZcw@public.gmane.org
Hi David,
Am Freitag, 21. Juli 2017, 14:33:00 CEST schrieb David.Wu:
Quoted 6 lines
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 :-) .
Quoted 2 lines
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
Quoted 10 lines · Heiko Stuebner
Quoted 6 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-rockchip