Interrupt handlers should be fast and not block other interrupts, so handling
the VERY slow SPI device communications should be done not directly by the
interrupt handler, but by a dedicated SPI task or thread. The interrupt
handler need only send a signal to the dedicated SPI task to awaken it and have
it perform SPI IO in either kernel or user space, depending on your needs. TS
has made it easy to create a high-priority user space task to do the SPI IO. I
don't know why you want a kernel space task, but if you look at the code in
sbus.c you will see how the memory mapping is done to gain access to the SPI
bus. Just don't mix multi-threaded sbus.c-based apps with your kernel space
routine unless you add pthread_mutex support to the sbuslock/unlock routines -
there can be no more than one user of the sbus at any given time. The sbus.c
code provided is NOT safe for multi-threaded apps.
HTH
--- In João Trindade <> wrote:
>
> Hi,
>
> I need to communicate via SPI whenever a hardware interruption occurs.
> I've done a module to handle the interruption and all is working there.
>
> The problem is how to do the SPI communication. The supplied sbus.c is
> user space and I need to do it through kernel space.
>
> Can anyone give me some hints on how to do SPI communication on a kernel
> module?
>
> Thanks
>
> --
> João Trindade <>
> Telephone: +351 93 561 39 10
> http://cnm.tagus.inesc-id.pt/joao+trindade
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|