Please see the explanation for the 'flags' in Documentation/spi.txt within the patch.The list of main differences between David Brownell's SPI framework (A)
and my one (B):
- (A) uses more complicated structure of SPI message, that contains one
or more atomic transfers, and (B)
offers the only spi_msg that represents the atomic transfer on SPI bus.
The similar approach can be imple-
mented in (B), and actually is implemented. But my imp[ression is that
such enhancement may be added later..
I wouldn't have said that the message structure in (A) is more complex then (B). For example, in
(B) you have many flags which controls things like SPI mode which are not needed in every message.
Once the SPI controller has been setup for a particular slave device you don't need to constantly
send this information. In (B) how to do you handle SPI devices which require to send several messages with out releasing
their cs? There are/will be some devices which require this.
I bet the drivers that don't need neither threads not workqueue there's no need in async transfers as well. :)
- (A) uses workqueues to queue and handle SPI messages, and (B)
allocates the kernel thread to the same purpose.
Using workqueues is not very good solution in real-time environment; I
think that allocating and starting the separate thread will give us more predictable and stable results;
Where does (A) use a workqueue? (A) doesn't use a workqueue or thread and instead leaves it up to
the adapter driver how to handle the messages that it gets sent (which in the case of some drivers
will mean no thread or workqueue). (B) is _forcing_ a thread on the adapter which the adapter may
I'm afraid that you're not quite getting the whole concept. The concept is to provide thorough and stable solution.
- (A) has some assumptions on buffers that are passed down to spi
functions. If some controller driver (or bus driver
in terms of (B)) tries to perform DMA transfers, it must copy the
passed buffers to some memory allocated
using GFP_DMA flag and map it using dma_map_single. From the other
hand, (B) relies on callbacks provided by SPI device driver to allocate memory for DMA transfers, but keeps
ability to pass user-allocated buffers down
to SPI functions by specifying flags in SPI message. SPI message being
a fundamental essense looks better to me when it's as simple as possible. Especially when we don't lose any
flexibility which is exacly our case (buffers that are
allocated as well as message itself/provided by user, DMA-capable
But allocating and freeing buffer is a core kernel thing not a SPI thing. To me you are adding
more complexity then is needed and your saying this is keeping things simple?
Can you please elaborate on that?- (A) uses standartized way to provide CS information, and (B) relies on
functional drivers callbacks, which looks more
flexible to me.
I'm not sure what you mean here. You need to provide the cs numbers with SPI device in order for
the core to create the unique addres and entry in sysfs. However, (A) is not checking to see if the cs that a registering device wants to use is already in
use, this needs to be added, and the same is true for registering spi masters.