Initialisation sequencing.

Initialisation sequencing.

[Ian Molton]

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.

what is the correct solution? does one exist?

Re: Initialisation sequencing.

[Jamey Hicks]

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