On Mon, Mar 4, 2013 at 3:38 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Mon, 21 Jan 2013 14:22:56 +0100, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: >> The non-dt probing allowed passing the location via platform data from >> the beginning. So make up leeway for device tree probing. >> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > Linus, does this look like some thing that should be done using pinctrl? Hm it's a bit weird actually. Most platforms will have some cetral entity dealing with pin multiplexing, and often it is combined with either a system controller register range, or it's combined with a GPIO controller (which is more common). This is a new oddity: it's like multiplexing is distributed out among the peripherals on the EFM32, or atleast for this UART, so there is a register on the peripheral itself selecting where to route it. If all peripherals on the system follows this pattern, like if there is some such "location" register on each and every peripheral, ideally that should be centralized into some file like drivers/pinctrl/pinctrl-efm32.c but the thing is that then that driver needs to own a single register or even just part of a register in each peripheral device memory range. And that seems a bit complex to handle. But if the EFM32 is using device tree exclusively it's actually just an array of named <&ersand> references in the node for the pin controller, pointing to each peripheral with a mux register. So maybe that's not that bad after all. Still it might be a bit overzealous to request that each device ask a central entity to write one of its own registers. So it needs to buy you something - like for example if it is possible to completely screw up the muxing if different peripherals are muxed to the same pins. So it all depends, we need a birds-eye view of the system to determine this. I tried looking at the datasheet but couldn't figure it out. Uwe how does this work on EFM32? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
