>> But with all that said, I can do a single SPI_MESSAGE with 5 transfers
>> , 2 of which have CS_CHANGE only with DMA without any interrupts -
>> besides the final interrupt to trigger the wakeup of the
>> spi_message_pump thread.
>
> How exactly does this work in concrete terms? I'm particularly
> interested in how the /CS manipluation is done. The basic idea doesn't
> sound terribly different to things a lot of devices can do with driving
> the transfers from the IRQ handler (possibly hard IRQ handler) without
> waking the tasklet, I'd hope we can make this work as a special case of
> that.
>
Essentially what the DMA-looks like is :
* if clock_divider changed:
Write 4 byte to CS-register config resetting TX/RX
* Write 4 byte to CS-register config resetting TX/RX
* write 4 byte to LEN-register configuring length of the next transfer
* write 4 bytes to CS-register setting up the transfer via DMA (for the length
above)
* Write to DMA-RX-Controlblock the next "target" Controlblock for the RX-DMA
* Write to DMA-RX-Controlregister to start DMA reading the next control-block
* Add the following transfers in an inner loop
adding similar transfers to the RX/TX DMA queues until we are
reaching the end of xfers
or we reach a reconfigured xfer (Cs_change,delay_us)
speed_hz is slightly different - we need to do a look-ahead in that case
and abort as well
*Note here the TX queue stopps after the last transfer
- we continue on the RX DMA chain
* schedule some "idle" DMA cycles to RX queue to wait until the clock is
finished
* if delay_usec is reached schedule some more idle cycles to RX queue
* if cs_change write 4 bytes to CS-register resetting the "transfer flags
also add some idle cycles so that CS does stay high for half a clock cycle
* Write to DMA-TX-Controlblock the next "target" Controlblock for the TX-DMA
* Write to DMA-TX-Controlregister to start DMA reading the next control-block
* Create a transfer that keeps us informed which message, which transfer
and how many bytes we have transferred
* if not finished and there are more xfers go back to the first step
* last message gets the send IRQ flag as a final step
(if callback is set on the message)
So it is a bit complicated, but this is the way it works in principle and this
is why
I need some CPU cycles to set it up - and for some of those little more
complicated messages i need a total of about 60 control-blocks.
But - hey: it works!
And it is the reason why I am asking for a "prepared" SPI-message option
to reduce this kind of overhead and get down to "real" transfer costs that are
handled by HW...
I believe in most drivers, spi_messages are potentially "prerendered"
if speed is important and are not created and torn down every time.
Otherwise - setting up the spi message itself becomes very computationally
intensive...
So adding this additional call "spi_message_prepare" would come cheap...
>> As for the prepare_spi_message - I was asking for something different
>> than prepare_transfer_hardware (unless there is new code there in 3.12
>> that already includes that - or it is in a separate tree).
>
> You should be working against the latest development code, we're almost
> at the merge window for v3.13, the v3.12 code is about 3 months old at
> this point. Also bear in mind that this is open source, you can extend
> the frameworks if they don't do what you want.
That is a bit more effort for me - if the RPI came with upstream code already,
then it would be much easier, but it does not...
Device-tree came just before the RPI tree could get integrated, so I am left
somewhat behind, because my main project relies on things that are not
upstream and might take a long (RPI camera,...)
Still I want to get these things upstream, because I hope that it will
eventually happen...
So I will try to write this "spi_message_prepare interface" and provide a patch
for inclusion, so that it may filter down again to the RPI in due time...
Ciao,
Martin--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
