Rahul,

On Tue, May 6, 2014 at 3:55 AM, Rahul Sharma [off-list ref] wrote:

quoted

+module_platform_driver(ec_i2c_tunnel_driver);

In peach-pit, tps65090 is connected to i2c tunnel which provides
regulators for lcd, led and hdmi. We need to make all regulators
available before platform devices get probed. Shall it be changed to
subsys_initcall like other i2c controllers ?

I wouldn't object it it being subsys_initcall, but I'd rather do it in
a separate patch series so we can have discussion about it and not
block this basic support from landing.  Specifically when I originally
submitted the "i2c arbitrator" for exynos5250-snow I had
subsys_initcall and was asked to change away from that.  See
<http://comments.gmane.org/gmane.linux.drivers.devicetree/30172>

The answer I got was that the rest of the system should handle the
regulator showing up late by using deferred probing.  That's not my
favorite mechanism since in this case it means that the LCD turns on
much later in the boot process, but it still can be workable.  Last I
checked DRM had a whole lot of work to do to handle deferred probing
well, though.  :(

Note also that there are other dependencies if we actually want to
make this work properly as a subsys_initcall.  Specifically:

* Last I checked you'd also need to move the pl330 driver to be
subsys_initcall.  That's actually a latent upstream bug since the SPI
driver uses subsys_initcall, has a dependency on pl330, and doesn't
check / defer probe if pl330 isn't ready.  I'd need to check if that
still happens and also whether upstream would accept a change to the
init ordering or would rather see the spi driver somehow detect this
and defer.

* You'll also need to adjust cros_ec_spi to init earlier to make
things actually work properly.


See <https://code.google.com/p/chromium/issues/detail?id=239659> for
the patches that changed initcall ordering locally in the Chromium OS
tree.


Since I'm really not interested in fighting a fight about the benefits
and alternatives to deferred probing, I'd be inclined to let someone
else drive this (especially if you can point to a use case where
deferred probing is causing a problem and can justify why fixing that
is too big of a burden).


-Doug