[okl4-developer] Synchronization in driver framework.

[Lukas HANEL]

Hi

Geoffrey Lee wrote:
> On Wed, Jun 25, 2008 at 11:54:17AM +0200, Lukas HANEL wrote:
> Hi Lukas
> 
>> I am porting a Linux driver to the okl4 driver framework. This driver 
>> uses udelay to wait for the device. More specifically, after some setup, 
>> the initialization function will enable the interrupt and then use 
>> udelay. The interrupt handler will then do some work and change some 
>> variables. After udelay, the init funtion checks this variables.
> 
> 
> Just to make sure that I am understanding you correctly, you 
> want to do some setup then call udelay(), and while it is doing 
> the udelay() loop the interrupt will fire and it will change some
> variables.  After the udelay() loop, it does some additional checks on 
> the variables that have been modified in the interrupt handler, right?
> 
That's about it. More precisely, the setup function is waiting for the 
operation to complete. Therefore it checks an entry in a datastructure. 
This entry will be updated by the interrupt handler.

In fact, all this is about the LCD/Backlight/PWM/I2C/GPIO driver server. 
The discussed problem appears in the I2C driver code. However, this 
drivers write/read functions are called several times in the 
initialization of the PWM driver.

> 
>> In a first compilation port, I "implemented" udelay with a "for" loop. 
>> However, I experience, the delay beeing over before the interrupt fires.
>>
>> So instead of a wait loop I would like to have the execution of 
>> device_enable_impl stalled at some point and to go on after the 
>> execution of device_interrupt_impl. What would be the best / easiest way 
>> to do?
> 
> 
> Drivers in the OKL4 driver framework are single threaded.  Hence, 
> the context in which initialize and call udelay is the same context
> that will be used to run your interrupt handler.  Hence, the udelay
> will always finish before the you get to run the interrupt handler.
> Can you let us know a bit more what you are trying to achieve 
> and why the Linux driver might be architected and programmed that way?
> We may be able to suggest an alternative solution that better fits into
> the OKL4 driver framework.
> 
Thanks for clearing that, I was already beginning to wonder, if it would 
not be that way.

I can vaguely see two solutions:

One is to somehow flatten the initialization of the PWM driver, to be 
progressing after each interrupt.

The other is to eventually use several driver servers, to have the 
interrupt handler of I2C in parallel with PWM initialization. - No, it 
would not work, because I2C would be occupied serving PWM request.

Glad to hear about an alternative solution.

Thanks,
Lukas Hänel