On Thu, 2012-08-02 at 17:54 -0600, Grant Likely wrote: > On Thu, Aug 2, 2012 at 5:08 PM, Aaro Koskinen <aaro.koskinen@xxxxxx> wrote: > > This reverts commit 9fdca9dfe093c76fe1ac1a09888ba9679d46996a. > > > > Changing omap2_mcspi_init() from subsys_initcall to device_initcall broke > > the display initialization on N900 when all the drivers are compiled > > built-in. Display subsystem drivers need a certain initialization order > > and having all of them initialize with device_initcall seems to be too > > fragile. Without this revert the display init fails and the boot hangs > > with the following messages: > > > > [ 1.260955] acx565akm spi1.2: invalid display ID > > [ 1.265899] panel-acx565akm display0: acx_panel_probe panel detect error > > [ 1.273071] omapdss CORE error: driver probe failed: -19 > > The dependencies are all messed up. The reverted commit is part of > fixing that and I don't really want to go backwards on it. How many > drivers are failing? Can you try modifying the failure path of those > drivers to return -EPROBE_DEFER and see if that helps? The description of 9fdca9dfe093c76fe1ac1a09888ba9679d46996a seems to be overly positive: "this will delete a few lines of code, no functional changes". But yes, the probe dependencies with omap's display are quite fragile. The probe order should be something like (from first to last): - omapdss, i2c, spi, etc. - panel drivers - omapfb I fear that if we'd use EPROBE_DEFER in a panel driver, it'll lead to omapfb missing the panel. And we can't use EPROBE_DEFER in omapfb, because there's no way to know if all the panel drivers are loaded or not. I think the only reliable way would be to manage the panels dynamically, so that omapfb will handle them no matter when they are added/removed. But that's not done by just changing a few lines... So, it's broken. One option, although hacky, would be to move all the spi probe stuff from acx565akm's probe to acx_panel_enable. That will be called by omapfb during late_initcall, at which point spi should be available. Well, I'll see how difficult the dynamic panel add/remove would be to implement. And probably even dynamic add would be enough for the start. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
