On 04/23/2013 08:34 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [130423 06:25]:
Hi
There are two public discussions now related to OMAP boot and drivers
initialization issues:
"Multiple issues with omap4 panda es in linux next"
http://www.spinics.net/lists/linux-omap/msg90241.html
"[BUG] omap: mfd/regulator: twl/core: init order"
http://www.spinics.net/lists/linux-omap/msg89980.html
In both cases there are pinctrl-single/I2C/MFD/Regulators initailization issue:
- regulators are not initialized because of twl,
- twl is not initialized because of I2C,
- I2C is not initialized because of pinctrl-single,
- pinctrl-single is initialized at mudule/device init time.
So, most everything will be shifted at late_initcall time.
This may cause boot delay (more over, it can broken initialization of drivers
which are not ready to use deferred probe mechanism yet, for example DSS).
Introduced pathes shift I2C and TWL iniialization to module/device init layer
instead of subsys init layer where initialization dependencies resolved
indirectly in drivers/Makefile now.
Grygorii Strashko (2):
i2c: omap: convert to module_platform_driver()
mfd: twl-core: convert to module_i2c_driver()
drivers/i2c/busses/i2c-omap.c | 14 +-------------
drivers/mfd/twl-core.c | 12 +-----------
2 files changed, 2 insertions(+), 24 deletions(-)
Thanks, I have few questions:
1. It seems that the real fix to the issues we're seeing
is to make the broken drivers to support -EPROBE_DEFER?
yes.
2. If so, can these be merged later on as clean-up?
if i understand Tomi correctly, he has problems with DSS updating to use
-EPROBE_DEFER, so this is rather fix than clean-up.
But need confirmation that it's true from him.
3. Can these two patches be merged separately without
breaking things?
I think, yes.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
