On Tue, 6 Feb 2024 18:38:29 +0100
Mike Looijmans <mike.looijmans@xxxxxxxx> wrote:
On 06-02-2024 17:32, Andy Shevchenko wrote:
On Tue, Feb 06, 2024 at 04:44:03PM +0100, Mike Looijmans wrote:Either the DRDY or SPI completion handler will call spi_async(), the
On 06-02-2024 16:09, Andy Shevchenko wrote:...
On Tue, Feb 06, 2024 at 03:47:45PM +0100, Mike Looijmans wrote:
I don't get this. Locks usually protect the data and not the code.But it's up to you what to do with that.The spinlock also protects the call to spi_async().
Maybe Jonathan can advice something different.
Can you elaborate?
lock assures that it's only called by one.
Arguably it's protecting the destination buffer of the spi_async()
call. We don't really care if we issue two reads (it's a waste
of time and we would store two sets of readings but meh), but we do
care about being sure that don't issue a second read into a buffer
that we are potentially simultaneously getting data back from.
There are comments where the release is to describe when it can
be safely unlocked.
I'm not super keen on this whole structure but I don't really have a better
idea. Who builds a device where you have no latched way of seeing
if there is new data? (some) Hardware folk love to assume they have a RTOS only
talking to their device and that no pulse signals will ever be missed.
We get to educate them when ever the opportunity arises :)