Re: Initialisation sequencing.

[Jamey Hicks <jamey.hicks@hp.com>]

Ian Molton wrote:

> Hi.
>
> I have a problem. It affects both modular and non modular builds, and 
> I dont see an obviously correct solution.
>
> The problem is that I have a video chip which supports some GPIOs and 
> an LCD display.
>
> some LCD functions are controlled via the GPIOs, like backlighting.
>
> so the driver is split into a video driver which exports three GPIO 
> related functions, and a backlight driver which requires them to work. 
> Both are on the platform bus.
>
> the problem occurs when the backlight driver gets probed before the 
> video driver. it tries to access the GPIO functions, which try to 
> write to random locations as the memory hasnt been ioremap()ed by the 
> as yet unprobed video driver, and it all predictably falls over in a 
> gibbering heap.
>
> I cant spin at this point without deadlocking the video driver and 
> ending up never being able to call the gpio functions, for obvious 
> reasons.
>
> I've tried making the backlight driver a child of the video driver, 
> hoping the probe functions are called in 'bus order', ie. parents 
> first. This failed.
>
> I could make the backlight driver initialise late, but that seems like 
> a hack. scheduling work risks deadlock.
>
I think initialising the backlight driver after the core of the driver 
that implements the GPIO is the right thing.  The backlight_device 
framework includes a notifier chain so that the video driver can take 
the right action when the backlight driver is registered.  Using soc to 
split the chip driver into a core, backlight and video might be another 
option that lets you bring up the backlight driver before the video driver.

Jamey