From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Sat, 21 Jul 2012 13:22:40 -0400 Subject: [U-Boot] [PATCH 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER In-Reply-To: <5009D2A9.3000706@ti.com> References: <1341716895-31089-1-git-send-email-marex@denx.de> <201207201747.47423.vapier@gentoo.org> <5009D2A9.3000706@ti.com> Message-ID: <201207211322.41728.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Friday 20 July 2012 17:50:33 Tom Rini wrote: > On 07/20/2012 02:47 PM, Mike Frysinger wrote: > > On Friday 20 July 2012 07:31:47 Marek Vasut wrote: > >> Dear Mike Frysinger, > >> > >>> On Saturday 07 July 2012 23:08:14 Marek Vasut wrote: > >>>> +/* DEFINE_CACHE_ALIGN_BUFFER() is similar to > >>>> ALLOC_CACHE_ALIGN_BUFFER, but it's purpose is to allow > >>>> allocating aligned buffers outside of function scope. Usage > >>>> of this macro shall be avoided or used with extreme care! */ > >>>> +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) + static > >>>> char __##name[roundup(size * sizeof(type), > >>>> ARCH_DMA_MINALIGN)] + __aligned(ARCH_DMA_MINALIGN); + > >>>> static type *name = (type *)__##name; > >>> > >>> how is this any different from doing: static __u8 foo[1234] > >>> __aligned(ARCH_DMA_MINALIGN); > >> > >> Does __aligned() align both start of the buffer downwards and end > >> of it upwards ? > > > > it guarantees the start is aligned. i don't believe it does any > > tail padding. > > > > that said, you've added just 1 consumer, but it uses in function > > scope, so i don't see why you had to define a new helper in the > > first place. the existing one would work fine shouldn't it ? > > The rough outline of the problems are: > - We need to have buffers that are multiple of cache size, for clearing. > - Today we know ehci-hcd had a problem. We also know other drivers / > layers have problems, but they aren't as readily breakable. > > That's why we put the macro in rather than a USB header. that wasn't the question. no one in the tree needs the new macro at all, regardless of what header it lives in. i guess the answer is that some code in the future (which hasn't been merged) might use it. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: