* Haojian Zhuang <haojian.zhu...@gmail.com> [121018 19:54]: > On Fri, Oct 19, 2012 at 10:38 AM, Tony Lindgren <t...@atomide.com> wrote: > > * Haojian Zhuang <haojian.zhu...@gmail.com> [121018 19:17]: > >> On Fri, Oct 19, 2012 at 6:28 AM, Tony Lindgren <t...@atomide.com> wrote: > >> > > >> > Specifically could you decribe the cases where this issue happens? > >> > Also check if one of your client drivers has some early initcall > >> > that's no longer needed. > >> > >> Yes, the special case is PMIC. Most of PMIC are based on I2C/SPI bus. > >> It means that I2C/SPI bus driver should be initialized firstly. For > >> example, > >> we could find that PMIC mfd driver are initialized in subsys init call > >> level. > >> It means that pinctrl should be initialized earlier than I2C/SPI bus > >> driver. > >> Otherwise, pins of I2C bus may not be configured as I2C function since > >> pinctrl driver is module init call level. > > > > Hmm, the order in drivers/Makefile is already: > > > > pinctrl/ > > i2c/ > > > > Maybe check that your i2c drivers don't have non-standard initcalls? > > > > Also the i2c drivers may need to return -EPROBE_DEFER? > > > > Regards, > > > > Tony > > OK. I'll support -EPROBE_DEFER if failed to get pin from pinctrl system. > This solution could also resolve the issue.
OK good to hear. Regards, Tony _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss