Hi Shawn, did this topic get any final resolution - especially in terms of the pingrp.h header? As I'm currently preparing two board files (imx50 and imx6sl) this discussion made me unsure if using the pin-group definitions is still the preferred style. Thanks Heiko On Monday 13 January 2014 10:19:14 Shawn Guo wrote: > On Sun, Jan 12, 2014 at 09:21:19PM +0100, Arnd Bergmann wrote: > > I was under the impression that the generic pinctrl binding was designed > > in a way to let you assign labels to each possible (reasonable) > > configuration so you didn't have get to this level of detail at the > > driver. > > The generic part of pinctrl binding only covers the procedure how a > client device get its pinctrl state configuration from a pin controller > node. That's what we defined in bindings/pinctrl/pinctrl-bindings.txt > and implemented in pinctrl core. But the details of how a pinctrl state > configuration should be interpreted for a particular pin controller is > defined by individual pin controller binding like fsl,imx-pinctrl.txt, > and implemented in the pin controller driver like > drivers/pinctrl/pinctrl-imx.c. > > > I'm also surprised that you have to know multiple constants > > (mux register, input register, config register offsets) to select a > > particular pin. I would have expected that you could have one constant > > from which the driver is able to compute the other ones. > > That's what we do before. We define a constant in the binding and have > the driver to maintain these data and look up the data using the > constant. See commit below for imx6q example. > > d8fe357 pinctrl: pinctrl-imx: add imx6q pinctrl driver > > The biggest problem with that approach is we have huge data to maintain > in the driver because of the complexity and flexibility of IMX pin > controller design. And these data can not be init data. Check that big > array of struct imx_pin_reg in commit above for what I'm talking about. > So when we build a v7 kernel image for IMX, we will have such big array > for each of these SoCs, imx50, imx51, imx53, imx6sl, imx6dl, imx6q, and > more to come. > > That's why we went through the pain of breaking DT compatibility to move > all these data into device tree one year ago with the commit below. > > e164153 pinctrl: imx: move hard-coding data into device tree > > Now kernel gets released from the floating and we do not even need to > touch kernel to add these data when new SoC support is added. > > Shawn -- 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
