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. <[email protected]>: > 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. <[email protected]>: > > 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 <[email protected]>: > >> > >> > >> On Tue, Sep 8, 2015 at 10:19 AM, Daniel. <[email protected]> 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 > >>> [email protected] > >>> 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*
_______________________________________________ Kernelnewbies mailing list [email protected] http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
