Messages in this thread | | | Date | Mon, 13 Oct 2014 08:42:19 -0700 | From | Tony Lindgren <> | Subject | Re: [RFC PATCH] pinctrl: pinctrl-single.c: init pinctrl single at arch_initcall time |
| |
* He YunLei <heyunlei@huawei.com> [141011 02:03]: > On 2014/10/9 2:10, Tony Lindgren wrote: > >* He YunLei <heyunlei@huawei.com> [141007 18:43]: > >> > >>Thanks for your review and I am really appreciated it, but in our arm > >>platform, we haven't custom initcall levels for other drivers. Although > >>deferred probe helps other drivers to register well, we are also confused > >>for the issues of lots of pin request errors debug output while booting the > >>kernel. Besides, if the number is bigger than the limited number, whether > >>deferred probe can solve this problem. > > > >OK. Care to provide some examples where this happens on your > >platform? > > > >Note that we already have pinctrl very early in drivers/Makefile. > >What are the early users for pinctrl-single in your setup? > > > >Regards, > > > >Tony > > > >. > > > In our platform we use subsys_initcall in I2C, and fs_initcall in PMIC, Both > of them are early than pinctrl-single. Although they register well > with the aid of deferred probe, it's really confused us that pins request > deferred. Why can't we setup pinctrl-single earlier to reduce these > messages.
How about make the I2C controller just regular module_init?
We're planning to do that for omaps as soon as we have made omap3 DT only as we still have some board-*.c files.
Presumably your PMIC is also on I2C and you need the PMIC for regulators?
In that case you can just make the PMICinit normal module_init too.
Regards,
Tony
| |