On Fri, Feb 19, 2016 at 1:54 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: <cut> > This still really sounds like a mixed bag to me, which should better get represented > as a syscon node, except that there are also some more structured areas in > CBUS. > > Having just the registers between METAL_REVISION and HW_REV in a syscon > is clearly wrong, as that would include the pinctrl area that already has > a driver, but would not include some other parts that want the syscon. > > Maybe the best way is to make it compatible with both syscon and > simple-bus and put the other nodes underneath. That is still rather > ugly, but at least it works and can be extended. More on this topic. On the meson platforms (at least on the meson8 / meson8b) we have two buses: cbus and aobus. Since in cbus we have a bunch of scattered registers, Arnd suggested to make it compatible with both syscon and simple-bus. So my idea was actually to update the meson8b DTSI file adding the two buses to make it closer to the actual hardware. In the most simple cases moving the devices under the correct bus is a trivial operation since (of course) the same driver can be used when the device is attached to a different bus, like in the uart_AO case (http://lxr.free-electrons.com/source/arch/arm/boot/dts/meson8b.dtsi#L114). Unfortunately pinctrl is a different beast since it requires (http://lxr.free-electrons.com/source/drivers/pinctrl/meson/pinctrl-meson.c#L659) at least two subnodes: one accessing registers from aobus, and the other one from cbus. I know this is quite a peculiar case but I'm wondering what is the best way to approach this issue. 1) We could move only the pinctrl device outside both aobus and cbus but IMO this is ugly (at this point is probably better not having the two buses at all described in the DTS). 2) The second option is just to fix the driver so that the two subnodes are not strictly required. The problem with this second solution is that in the driver we still need to access some data (http://lxr.free-electrons.com/source/drivers/pinctrl/meson/pinctrl-meson8b.c#L873) that is specific to each bus. So we will end up having two different compatibles for the two buses (meson8b-pinctrl-aobus using data from 'ao-bank', and meson8b-pinctrl-cbus using data from 'banks'). 3) Another option is just to have the driver with a unique compatible poking the parent node (or just to another property) to determine on which bus it is so that it can use the correct bus-specific data. Any idea / feedback? -- Carlo Caione -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
