[okl4-developer] Synchronization in driver framework.

[Geoffrey Lee]

On Thu, Jul 03, 2008 at 05:08:01PM +0200, Lukas HANEL wrote:

Hi Lukas


>
> 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.

At this point what is unsure is why clearing the status on the 
hardware does not work.  If you have not done so already, I would
suggest manually acknolwedging the interrupt once you have
detected that an interrupt has been raised and handled that condition
with InterruptControl().

>
> 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 would agree that spinning unnecessarily is not good.  My understanding
of the Linux driver, however, effectively spins anyway, because you
rely on the interrupt handler to to change some state, which is 
checked at the end of the delay loop.  I am guessing if you find the
interrupt handler has not fired you need to spin again, since the
state has not changed as you desired.  Hence I think there might
be another issue with the driver which gets exposed due to the
conversion into the single threaded scheme?


>
> 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
>

Spawning new threads in drivers, while possible, is strongly discouraged.  
We would encourage people to adapt existing drivers to the OKL4
driver framework design.  I'm not quite sure how complex your driver
is but one option may be to instead of retrofitting driver into the
OKL4 driver framework, cherry-pick the bits that you require and
write a driver with design priciples that is compatible with the 
OKL4 driver framework.  Using a Linux VM to export your driver
is also possible.  Using this approach will require a different
set of infrastructure, e.g. stub driver, buffer management etc.

So far I am not sure is why the OKL4 driver takes so long 
to initialize that does essentially the functional equivalent
Remember that acking the interrupt in-place in the OKL4 scheme is
basically the same as asking the interrupt to ack it for you,
since you are blocked on the interrupt handler being run, and why
the hardware refuses to clear the necessary status bits for you to
continue.  Hence I think it would be good to do some further
investigation.  If it turns out that there is something that 
your hardware needs that the current framework cannot support,
we want to hear your feedback on how we can suit your hardware.

	-gl

> * 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
>

--