SPI operations on interrupt context!?

quoted

I also found that we having problems with MCP supply, so this is it! Thanks
anish for your reply!

Cheers,
- dhs

2015-09-09 15:30 GMT-03:00 Daniel. [off-list ref]:

I've checked the iomux configuration, there was some pins miss
configured. Anyway I'm still losing IRQs. But now I have some hints
from kernel. Now I see that I'm hitting this line:
https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L380
which traces to:

spi32766-72    [000] ....  1728.245798: mcp23s17_produce_complete:
mcp23s08: Error on SPI transfer, -115

From errno.h 115 means "operation in progress":

http://lxr.free-electrons.com/source/include/uapi/asm-generic/errno.h?v=3.10#L88

So I need to take a look from ecspi (imx6 spi controller) code/clock/rates
etc.

Cheers,
- dhs

2015-09-08 18:23 GMT-03:00 Daniel. [off-list ref]:
Even spi_async sleeps? I thought that spi_async wouldn't sleep :/

I have a board with an MCP23S17 gpio expander that is used as an
digital input. I need to notify my application every time that any
input status changes. The MCP triggers an interrupt every time that an
input changes, but, the application may not be able to poll the MCP at
the same rate that the input changes, so I used a circular queue at
MCP driver. I need to add input changes (readed from INTCAP) as soon
as they came, to be free to get new input changes as soon as possible.
I'm looking for 1ms resolution here, so, summarizing, I want to be
able to enqueue input changes at each 1ms.

The MCP works like this.

1 - Input changes (set IRQ flags)
2 - Raise IRQ
3 - IRS reads INTCAP (this clears IRQ flags)

Okay, ... I was enqueing on the threaded IRQ, but was losing events.
The "losing events" here means that I got two interrupts in a row,
with same INTCAP values, so I got input changes notification (IRS
called) with no input changes. I think that a new interrupt is being
raised before I read INTCAP so it got masked. The big question is: How
to read INTCAP as fast as possible?

This is why I tried spi_async in interrupt context. (mcp_hard_irq),
but I'm still losing events at 1ms resolution.

So, explaning the mess I did in the code :), first of all I've updated
the code, is still in the same link:
https://gist.github.com/gkos/4cce494e90518077084a

I've decided to use a producing/consuming aproach, since application
will never be abble to poll input status at same rate that it changes
I need to enqueue it. To do this I've created a new function inside
this module. mcp_getlast() should take the last element in queue, or
wait for next event if is empty, is my consumer, here it is:
https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L182
The procucer is the mcp23s17_produce_complete handler, it should
enqueue INTCAP and return. This is it!
https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L346
I've enabled tracing on my kernel (3.10.53 running on an i.MX6 quad).
At the trace file I got this lines:
        spi32766-72    [000] d...  2589.220910:
mcp23s17_produce_complete: mcp23s08: produced ffffff01
        spi32766-72    [000] d...  2589.222973:
mcp23s17_produce_complete: mcp23s08: produced ffffff00
        spi32766-72    [000] d...  2589.223235:
mcp23s17_produce_complete: mcp23s08: produced ffffff01
        spi32766-72    [000] d...  2589.226119:
mcp23s17_produce_complete: mcp23s08: produced ffffff00
        spi32766-72    [000] d...  2589.227631:
mcp23s17_produce_complete: mcp23s08: produced ffffff00
        spi32766-72    [000] d...  2589.227898:
mcp23s17_produce_complete: mcp23s08: produced ffffff01

There is possible see that INTCAP repeated (..ff00). This my problem!

Well, thanks anybody that readed that long, any ideia would be helpful

Best regards,

2015-09-08 16:30 GMT-03:00 anish singh [off-list ref]:

On Tue, Sep 8, 2015 at 10:19 AM, Daniel. [off-list ref] wrote:
Hi all,

I'm dealing with a SPI driver and I have a doubt. I need to read and
write
data to spi (registers and values) inside interrupt handler. I want to
know
if this pattern is safe or if I'll face problems with it.

AFAIK the spi calls sleep, so it is not safe.

This code is being added to gpio-mcp23s08.c driver to handle IRQ and
save
INTCAP at interruption time. INTCAP register keeps the input port
status at
interruption time. I want to capture this as fast as possible and put
it at
a circular queue. I write this code inspired by spi_sync function, but
using
spinlocks so it doesn't sleeps. But, these spin_(un)lock calls seems a
bad
ideia to me. Any better idea or guidelines?

Here is the code.

https://gist.github.com/gkos/4cce494e90518077084a#file-gpio-mcp23s08-c-L440
The functions are mcp23s17_read_irqsafe and
mcp23s17_read_irqsafe_complete
PS: The code is a little messed up (because I've been trying to
optimize
this INTCAP capturing by many means)
 What exactly you are trying to optimize you have not mentioned. I
looked at
the driver code
you pointed out in your mail and looks like they are using threaded irq
and
I am sure that you
understand that threaded irq can perform sleeping operations as it is
basically a kthread.

http://lxr.free-electrons.com/source/drivers/gpio/gpio-mcp23s08.c#L494
so
you can easily use
spinlock here. It is not interrupt context.

Generally if you are trying to optimize something in linux kernel you
should
be very clear about your goal.

Cheers
- dhs

--
"Do or do not. There is no try"
  Yoda Master

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--
"Do or do not. There is no try"
  Yoda Master

--
"Do or do not. There is no try"
  Yoda Master

-- 
*"Do or do not. There is no try"*
  *Yoda Master*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150909/499af4c3/attachment.html 

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help