On Mon, Dec 03, 2018 at 11:20:52AM +0100, Andrea Merello wrote: > Is there any way to get several transfer from the framework without > waiting to finish one to get the next even if they belongs to > different messages? You'd probably want to be starting at transfer() and completely ignoring the core message queue, trying to use the core queue and simultaneously offload it to hardware isn't going to end well. > We've seen that some drivers (e.g. spi-pxa2xx.c) do use > spi_get_next_queued_message() in order to snoop into next messages, > but AFAICT they just use it to get some hint about how to handle the > chip-select; it seems that they still wait for the framework to call > their transfer_one_message() to actually push it to the HW. Right, nothing tries to do the queue in the hardware. Very few controllers can do that in the first place and since many controllers have some rather interesting assumptions built in which require software overrides even for the most basic operation. > We tried to dig into the SPI framework, but we couldn't locate the > place where messages are actually popped out of the controller message list_del_init() in _pump_messages() - the message comes off the queue before we start processing it. > list.. Also we couldn't get the point of 'queue' list in struct > spi_message; the above comment didn't help us indeed.. What's it for? With the Linux list handling code we use the same struct for list heads and list entries, it's the link in the controller queue linked list for that message.
Attachment:
signature.asc
Description: PGP signature
