On Friday 26 February 2016 17:43:54 Carlo Caione wrote: > On Fri, Feb 26, 2016 at 5:00 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Friday 26 February 2016 16:34:59 Carlo Caione wrote: > >> 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? > > > > Would it be possible to split the pin controller driver into two drivers > > that each only access registers on one of the buses? Is that a split > > that makes sense from the point of view of that driver? > > AFAICT (I'm not the driver author) there is no a really strict reason > to have one single driver accessing registers on both buses. Of course > the driver has to be changed a bit. > Are you suggesting to have two different drivers with two different compatibles? Just an idea, but yes: if the register layout is different, then they would also need different compatible strings. This is mostly a question of how the hardware design really looks: are these two separate pin controllers that each are responsible for a clear subset of the pins? Arnd -- 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
