On Tue, Oct 29, 2013 at 11:00 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Tue, Oct 29, 2013 at 7:32 AM, Markus Pargmann <mpa@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> >> Acked-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> >> Acked-by: Shawn Guo <shawn.guo@xxxxxxxxxx> >> --- >> 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@xxxxxxxxxxxxx> -- 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
