On Thu, 11 Jun 2009 11:23:57 +0800 Greg KH <greg@xxxxxxxxx> wrote: > On Thu, Jun 11, 2009 at 11:10:25AM +0800, Alek Du wrote: > > On Thu, 11 Jun 2009 10:54:35 +0800 > > Greg KH <greg@xxxxxxxxx> wrote: > > > > > On Wed, Jun 10, 2009 at 12:23:58PM +0800, Alek Du wrote: > > > > >From 9bab93441d0969fe5f16ad8c8d61737e9eff02ff Mon Sep 17 00:00:00 2001 > > > > From: Alek Du <alek.du@xxxxxxxxx> > > > > Date: Wed, 10 Jun 2009 11:53:59 +0800 > > > > Subject: [PATCH] EHCI: Make ehci_qh structure items all 32bit aligned > > > > > > > > Intel Moorestown platform EHCI controller has internal SRAM using for > > > > caching of QH/QTD pools, but this SRAM has the 32bit alignment access > > > > limit, all SRAM access must be 32bit aligned. This patch will change > > > > only a few not u32 items to u32. > > > > > > Why not just reorginize the fields to not need any padding and provide > > > the same functionality? Just increasing the field size does bloat > > > things a bit, right? > > > > > > thanks, > > > > > > greg k-h > > > > Greg, > > > > I guess reorganizing order is tricky? Can compiler grant that? > > Grant what? The C standard says that the order will always be what you > define, but it can add padding between fields if it wants to (unless you > explicitly say it should "pack" the structure). > So either way would waste some padding bytes. > > The qh is per EP, it won't waste much. I guess this way should be the > > simple way. If you look into drivers/usb/host/ehci.h, almost all data > > members are 32bits. > > Ok, I'll let David ack this then, if it's not really a big deal. > > I think you are going to run into lots of other problems though, if you > can't handle 32bit accesses on odd addresses very easily. > > Good luck, > OK. Thanks. Our EHCI controller are working perfectly. The alignment limitation only affects the descriptors that allocated in SRAM. The data payload buffer will keep in DDR. > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
