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. <danielhilst@gmail.com>:
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...
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. <danielhilst@gmail.com>:
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 <anish198519851985@gmail.com>:
On Tue, Sep 8, 2015 at 10:19 AM, Daniel. <danielhilst@gmail.com> 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@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*