On 06-02-2024 17:32, Andy Shevchenko wrote:
On Tue, Feb 06, 2024 at 04:44:03PM +0100, Mike Looijmans wrote:
On 06-02-2024 16:09, Andy Shevchenko wrote:
On Tue, Feb 06, 2024 at 03:47:45PM +0100, Mike Looijmans wrote:
...
But it's up to you what to do with that.
Maybe Jonathan can advice something different.
The spinlock also protects the call to spi_async().
I don't get this. Locks usually protect the data and not the code.
Can you elaborate?
Either the DRDY or SPI completion handler will call spi_async(), the
lock assures that it's only called by one.
Usually the DRDY handler will call spi_async(). If the next DRDY arrives
before the spi_async transfer finishes, the SPI completion handler must
call spi_async() a.s.a.p. to also read the newly arrived sample. There's
no way to ask the chip whether there's data to read, so all the driver
can do is use the ISR to remember that DRDY did trigger.
The lock protects that the "busy" counter matches the actual pending
calls to spi_async, and also protects that only one handler will call
spi_async (and update the counter).
Maybe this picture helps:
DRDY ---+-----+-----+-----+-
SPI ------+------------+-+--
busy 00001100011111112211101
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@xxxxxxxx
W: www.topic.nl
