[U-Boot] [PATCH v3 1/3] USB: make usb_kbd obey USB DMA alignment requirements

[Allen Martin <amartin@nvidia.com>]

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