Dear Reinhard Meyer,
In message 4CB2D225.6020702@emk-elektronik.de you wrote:
After thinking alot about this: Preface: (for understanding of the issue)
Thanks!!
I see two possible solutions for that problem here:
- generally limit the number of blocks requested to 65535. The performance
penalty for that is insignificant. (65535 blocks are about 32 MiB) 2. limit it on a case by case basis by passing such limit like a host capability to the high level part.
Here I would (after much deliberation) favour version 1.
I agree. Implementing 2) is not worth the effort or the code. 32 MiB should be enough in most practical cases, and even for really big transfers it is a more than appropriate chunk size.
The second and more serious problem Lei Wen seems to have with his hardware is that DMA seems problematic (how so?) for more than 512 KiB.
Indeed. So far it is totally unclear to me what sort of restriction this actually is. If my interpretation is correct, than such DMA transfers should not cross 512 KiB memory boundaries, so the maximum transfer size is 512 KiB, but only when you start on a 512 KiB aligned address. Also my interpretation is that this is not actually a hard restriction, but only a convenience to avoid handling some DMA interrupt properly - in Linux. I wonder if this really applied to U-Boot at all, where we use polling instead.
I really don't see that we should pull such (unusual?) limitations into the high level part. I think the low level driver could issue several DMA transfers in that case.
Again I agree. thi is a low-level, controller specific detail, which should not affect any upper-layer code. It should be completely hidden in the controller specific driver code.
We need concensus here first before we can issue and comment patches.
I think both of us agree. We just need to convince Lei Wen...
Best regards,
Wolfgang Denk