From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Tue, 01 Jul 2014 09:16:26 -0600
Subject: [U-Boot] [PATCH V2] usb: ci_udc: Allocate the qTD list directly
In-Reply-To: <201407011713.16627.marex@denx.de>
References: <1404172398-6522-1-git-send-email-marex@denx.de>
	<1404173061-6691-1-git-send-email-marex@denx.de>
	<53B2CDB5.5020803@wwwdotorg.org> <201407011713.16627.marex@denx.de>
Message-ID: <53B2D0CA.4060701@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

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...