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 at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: RK322x & RK3399 & RK3328 COM_MUX_LIST.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 23287 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20170518/ac1d3d29/attachment-0001.xlsx>
