Well, I am trying to pipeline DMAs - especially Writes then Reads.
As DMA does 32 bit only it works perfectly as long as the number of bytes are multiple of 4.
If not then I need to do Clear RX and TX - as the "DLEN" is not "honoured" in this case really from the FIFO perspective.
If I write 3 Bytes in DLEN and then do the DMA then after the DMA and transfer is finished there is still one byte min the FIFO
Even when I have "said": 3 bytes only.
An even simpler case would be writing a datablock to an SD card via SPI - first the addressing bytes (2 bytes if I remember correctly), then 512 bytes of data , then 2 bytes crc. so which could get done in 3 DMAs without any Copying, but due to all the issue I have to reset the FIFOS after the 1st and 3rd.
If I do a reset of the TX-FIFO, why does it require that CS goes up - that is not a logical requirement, so the datasheet should mention it. (but why does it not happen for the RX FIFO?)
Especially if you look at it that you _can_ reset the FIFOS and also enable TA. So if the above was not correct, then this should
not work either.
gsh wrote:There will be a period (of a few cycles...) between clearing the FIFOs and the new data becoming available (from the DMA) during this period the CS signal will go high...
And if resetting takes some time, then it should get mentioned in the Datasheet as a requirement (which it does not state).
Nor does it state that CS will/may go high for a few cycles (whatever cycles means in this context SPI Clock or cdif divided SPI Clock - I would guess the former) - and documenting this case is especially important, as it is VERY hard to detect such a "glitch" of maybe only 4ns CS high with hobbyist equipment - and then it may ONLY happen in 5% of all cases... And then not all devices might even detect such a thing.
Something else related to FIFO: I also found that if you reset your FIFO and at the same time set DMAEN and TA, then in some cases (I did not even measure the percentage) at some point the "clock" ticks are not shifted out, while MOSI for example does change during that time - which results in the RX-DMAs getting stuck waiting for the transfer to finish for the missing byte.
But if you Reset Fifos, set dlen and then set CS to the final "value" it works...
Also the datasheet should also state that ADCS is required for a DMA to work, not optional like described in the "DMA Cookbook".
And finally the DMEN is ONLY honored if the CB is the last one in the chain (cb.info=DMEN;cb.next=NULL;) otherwise no interrupt gets triggered.
In the end the whole DMA pipelined thing is (almost) working and it is reducing CPU utilization a lot compared to the polling or interrupt-driven interfaces that are implemented in the linux kernel now.
What I am asking is that someone updates the SOC datasheet and updates it - not every "bug" found is also documented in the elinux wiki page and other people may also fall into the same traps, which is totally unnecessary...
And that is what I am asking for:
- an updated datasheet with updates to everything that is not working as defined - the document is now almost 2 years old
- a way to report a HW-bug so that they can get documented in the datasheet at some point (or clarifications if someone dislikes to see it called "errata")
And I believe others will also benefit from this effort.