Re: [PATCH] Revert "spi: omap2-mcspi: convert to module_platform_driver"

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

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@iki.fi> 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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]