On Tuesday, July 01, 2014 at 05:16:26 PM, Stephen Warren wrote:
On 07/01/2014 09:13 AM, Marek Vasut wrote:
On Tuesday, July 01, 2014 at 05:03:17 PM, Stephen Warren wrote:
On 06/30/2014 06:04 PM, Marek Vasut wrote:
Instead of weird allocation of ci_drv->items_mem and then even weirder distribution of offsets in this memory area into ci_drv->items array, just allocate ci_drv->items as a big slab of aligned memory (replaces ci_drv->items_mem) and let ci_get_qtd() do the distribution of offsets in this memory area.
As I mentioned on IRC, this patch isn't correct.
The existing code ensures that each pair of QTDs are correctly aligned, hence the slight complexity. The new code only actively ensures that the first QTD is correctly aligned; the subsequent QTDs will only be correctly aligned if the sizeof the QTD structure is an exact multiple of the alignment requirements. In practice, it is on my system at least, but that may not be generally true.
It is on every system with 32b cachelines.
Sure.
On system with 64b cachelines, you won't be able to use one endpoint as both in and out, which I don't think is doable now either.
Yes, the 2nd QTD in each pair isn't correctly aligned at present for 64byte cachelines. I was thinking about sending a patch to fix that (perhaps theoretical) issue.
Ah bah, you're right.
Actually, I wonder if that's related to Jörg's issue at all; his system has the cache line size set to 64 even though that's incorrect, perhaps that influences the behaviour of the cache code...
My understanding of his test is that he uses u-boot-usb/master + this patch and there are not modifications to the CPU support code. If there are, then his test is useless of course.
With u-boot-usb/master + this patch , on MX28 there should be no problem.
Best regards, Marek Vasut