[okl4-developer] Synchronization in driver framework.

[Lukas HANEL]

Hi Geoffrey,

Geoffrey Lee wrote:
> Hi Lukas
> 
>>> 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.
>>>
>> I can vaguely see two solutions:
>>
>> One is to somehow flatten the initialization of the PWM driver, to be  
>> progressing after each interrupt.
> 
> Your "flattening" solution sounds good.  Note in native Linux in effect
> it is serialized anyway, since you rely on the interrupt handler 
> to do its job before you can proceed.  Hence, the approach here
> would be to initialize up to the certain point when you need
> to take the interrupt, then turn on interrupts on the card.
> The interrupt will then be raised.  Rather then doing a simple
> udelay() loop, spin on the status register of the card or similar
> to tell you when the interrupt has been generated.  You can then
> do whatever processing required, turn interrupts off again and proceed
> with further initialization.
> 
> 	-gl

I was following your approach for several days now and am not advancing 
as fast as I was wishing. To change the driver to use polling instead of 
interrupts turns out to be more difficult than I was thinking. It seems, 
that there are also some hardware issues making this especially tricky.

In fact, the driver code already disables and enables interrupts on its 
own. And it is doing this at many places with big macros. So I do not 
want to change this part.

I found one problem with the update of the masked interrupt status 
register. After the occurence of an interrupt the corresponding bit was 
masked by the driver. However, the status register still had this bit 
set. So my interrupt polling loop would see the status register not 
beeing zero and rerun the interrupt handler. Even disabling the bit 
directly via the interrupt clear register did not work. So I use masking 
in software, e.g. in my polling loop. Although I hacked around this 
problem, I fear that there might still be other problems of this nature 
on the horizon.

For instance, in such a polling loop it can take seconds for the 
interrupt to arrive, when in Linux startup the whole PWM initialization 
is done in a blink of the eye.

Also I was wondering, if polling is the future proof solution? Of 
course, these driver threads can and will be scheduled, so at least they 
are not blocking the whole system. But for power consumption isn't it a 
bad idea to use polling? So are you going to do some changes in this 
direction in the future? (When..?)

I was starting to think about other solutions to get a working LCD 
driver and I would like your opinion on the direction to take.

* continue debugging

* Use the Linux sources, but do not poll on interrupt status registers.
Instead, implement some "thread" management to simulate Linux behavior.
i.e. save context before udelay, then return. At the end of interrupt 
handler, continue setup function.

* Use another source package, which is much slimmer than the Linux code 
and already uses polling.

* Use the driver in a Linux VM. However I later on have to provide the 
vlcd interface.

thanks,
Lukas Hänel