[PATCH v7] pinctrl: imx27: imx27 pincontrol driver

[Matt Sealey]

On Tue, Oct 29, 2013 at 11:00 AM, Linus Walleij
<linus.walleij at linaro.org> wrote:
> On Tue, Oct 29, 2013 at 7:32 AM, Markus Pargmann <mpa at pengutronix.de> wrote:
>
>> imx27 pincontrol driver using the imx1 core driver. The DT bindings are
>> similar to other imx pincontrol drivers.
>>
>> Signed-off-by: Markus Pargmann <mpa at pengutronix.de>
>> Acked-by: Sascha Hauer <s.hauer at pengutronix.de>
>> Acked-by: Shawn Guo <shawn.guo at linaro.org>
>> ---
>> Hi,
>>
>> another binding documentation update. The MUX_ID components are described more
>> detailed now.
>
> Patch tentatively applied unless someone has very fundamental
> issues with it, it stays in. I really want a full transfer of i.MX
> pin controllers to the subsystem, using device tree so we can
> get rid of the old i.MX cruft in arch/arm.

I think this is a rush-in patch. I actually read the manual last night
and found some serious weirdness.

The i.MX27 doesn't have a dedicated IOMUX controller so actually
having a whole separate node for it in the device tree - or even a
separate driver - makes very little sense. I understand pinctrl and
gpiolib are somewhat separated as software, but this is encoding a
Linuxism into the tree.

In fact, the binding will conflict with actual binding of the GPIO
(i.e. setting data, receiving interrupts) module since it's all one
register set, and the "fsl,imx27-iomuxc" compatible property does not
represent reality except to collect data in a different spot. There's
no reason for it except to cut the documentation and tree definition
in half, and have two nodes for Linux.

Would it be so bad to implement this as a regmap and have two drivers
access the same regmap on the Linux side? You don't need two nodes for
that, and the IOMUX definitions can live under the GPIO node. There is
NOTHING stopping two drivers on Linux matching the same compatible
property. Locking and coordination in software of a single IP block
used by two drivers shouldn't be arbitrated by the device tree.

Thanks,
Matt Sealey <neko at bakuhatsu.net>