[PATCH 2/2] ARM: dts: meson: Adding hwrev syscon node

[Carlo Caione]

On Fri, Feb 19, 2016 at 1:54 PM, Arnd Bergmann <arnd at arndb.de> 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