From mboxrd@z Thu Jan  1 00:00:00 1970
From: Allen Martin <amartin@nvidia.com>
Date: Tue, 23 Oct 2012 14:58:39 -0700
Subject: [U-Boot] [PATCH v3 1/3] USB: make usb_kbd obey USB DMA
 alignment requirements
In-Reply-To: <50871179.4060901@wwwdotorg.org>
References: <1351028274-30301-1-git-send-email-amartin@nvidia.com>
	<50871179.4060901@wwwdotorg.org>
Message-ID: <20121023215838.GG13201@badger>
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 Tue, Oct 23, 2012 at 02:51:53PM -0700, Stephen Warren wrote:
> On 10/23/2012 03:37 PM, Allen Martin wrote:
> > Change usb_kbd driver to obey alignment requirements for USB DMA on
> > the buffer used for data transfer.  This is necessary for
> > architectures that enable dcache and enable USB DMA.
> 
> > diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> 
> > +/*
> > + * This structure must be aligned to USB_DMA_MINALIGN to allow DMA to
> > + * buffer "new" below.
> > + */
> >  struct usb_kbd_pdata {
> > +	uint8_t		new[8];
> > +	uint8_t		old[8];
> 
> Oh, one more thought on this: Those fields should both be aligned, and
> their size be aligned too, at least to cache size. In particular, if we
> have HW write to new[], then invalidate the cache that contains new[]
> because it just did, we want to make sure that fields after new[] (i.e.
> old[], ...) don't get invalidate too, in case the cache contained stale
> data for those fields. That's one of the things that the (stack-based)
> ALLOC_CACHE_ALIGN_BUFFER handles. Perhaps make those two fields
> pointers, and point those at a memalign()-allocated blob, where the size
> of those blobs are something like ROUND_UP(USB_DMA_MINALIGN, 8)?
> 
> Sorry for forgetting about this before!

That's a good point.  We also don't want to touch old[] from the CPU
right after we just flushed new[] and dirty the cacheline again.  It
does seem like these should be dynamically allocated, then I can avoid
the memalign() on the whole structure and don't have to worry if a new
member gets added in front of new[] later.

-Allen
-- 
nvpublic