I also found that we having problems with MCP supply, so this is it! Thanks anish for your reply!
Cheers,2015-09-09 15:30 GMT-03:00 Daniel. <danielhilst@xxxxxxxxx>:
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. <danielhilst@xxxxxxxxx>:
> 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@xxxxxxxxx>:
>>
>>
>> On Tue, Sep 8, 2015 at 10:19 AM, Daniel. <danielhilst@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
>>> 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
Yoda Master
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
