From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers
Date: Mon, 29 Aug 2011 16:23:08 -0500 [thread overview]
Message-ID: <4E5C033C.9090808@freescale.com> (raw)
In-Reply-To: <CAF6FioUMtaP25vzF-WhTQYf9kk4XE9qbaP0g-eTjbijk055veQ@mail.gmail.com>
On 08/29/2011 03:58 PM, Anton Staaf wrote:
> On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood <scottwood@freescale.com> wrote:
>> On 08/29/2011 03:12 PM, Anton Staaf wrote:
>>> 1) Mikes's macro
>>>
>>> #define DMA_ALIGN_SIZE(size) \
>>> (((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>>>
>>> #define DMA_DECLARE_BUFFER(type, name, size) \
>>> void __##name[DMA_ALIGN_SIZE(size * sizeof(type))]; \
>>> type * name = __##name & ~(CONFIG_SYS_CACHELINE_SIZE - 1));
>>>
>>> DMA_DECLARE_BUFFER(int, buffer, 100);
>>
>> This doesn't compile, and it tries to round the buffer down below its
>> starting point.
>
> You are correct. I wrote that one as a modification of mikes initial
> proposal. I should have caught the incorrect rounding when I did.
> The patch that Lukasz sent titled "dcache: Dcache line size aligned
> stack buffer allocation" has a correct implementation.
With the version in that patch I get the slightly different "error:
initializer element is not computable at load time". Seems like whether
you cast the address to (type *) or (void *) determines which error you
get. This is with GCC 4.5.1 (powerpc) and 4.6.0 (x86). Maybe it's
arch-dependent, based on available relocation types.
Also, shouldn't the array be of type "char" rather than "char *"?
How do you make the declaration static?
>> After fixing the more obvious issues, I get "error: initializer element
>> is not constant".
>
> I think this requires the use of -std=c99 or GCC extensions. More
> specifics can be found here:
> http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
-std=c99 doesn't help.
The problem isn't the array itself, it's the pointer initializer.
>> You could set the pointer at runtime, though, and remove some of the
>> macrification:
>>
>> #define DMA_ALIGN_SIZE(size) \
>> ((size) + CONFIG_SYS_CACHELINE_SIZE - 1)
>> #define DMA_ALIGN_ADDR(addr) \
>> (DMA_ALIGN_SIZE(addr) & (CONFIG_SYS_CACHELINE_SIZE - 1))
>>
>> int buffer_unaligned[DMA_ALIGN_SIZE(100)];
>> int *buffer;
>>
>> some_init_func()
>> {
>> buffer = (int *)(DMA_ALIGN_ADDR((uintptr_t)buffer_unaligned));
>> }
>
> :) This was one of my suggestions earlier on a different thread. It
> was rejected there, I believe because it makes things less clear.
So, the complex macro is bad because it obscures things, and this
version is bad because it doesn't? :-)
-Scott
next prev parent reply other threads:[~2011-08-29 21:23 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 9:25 [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers Lukasz Majewski
2011-08-19 13:57 ` Mike Frysinger
2011-08-19 15:28 ` Lukasz Majewski
2011-08-19 15:35 ` Mike Frysinger
2011-08-22 7:29 ` Lukasz Majewski
2011-08-22 16:08 ` Mike Frysinger
2011-08-22 16:42 ` Anton Staaf
2011-08-22 16:52 ` Marek Vasut
2011-08-22 17:17 ` Mike Frysinger
2011-08-22 18:15 ` Anton Staaf
2011-08-22 18:31 ` Mike Frysinger
2011-08-22 18:57 ` Anton Staaf
2011-08-23 9:19 ` Lukasz Majewski
2011-08-23 17:00 ` Anton Staaf
2011-08-23 17:30 ` Mike Frysinger
2011-08-23 18:12 ` Anton Staaf
2011-08-23 18:35 ` Mike Frysinger
2011-08-23 18:36 ` Mike Frysinger
2011-08-23 18:46 ` Anton Staaf
2011-08-23 20:12 ` Wolfgang Denk
2011-08-23 20:27 ` Anton Staaf
2011-08-23 20:37 ` Mike Frysinger
2011-08-23 21:06 ` Anton Staaf
2011-08-23 21:32 ` Mike Frysinger
2011-08-23 21:09 ` Wolfgang Denk
2011-08-23 21:32 ` Mike Frysinger
2011-08-23 21:48 ` Anton Staaf
2011-08-24 16:16 ` Mike Frysinger
2011-08-23 22:42 ` Wolfgang Denk
2011-08-24 3:00 ` Mike Frysinger
2011-08-24 10:07 ` Lukasz Majewski
2011-08-24 13:25 ` Wolfgang Denk
2011-08-24 14:31 ` Lukasz Majewski
2011-08-24 16:20 ` Mike Frysinger
2011-08-24 17:27 ` Anton Staaf
2011-08-24 18:06 ` Mike Frysinger
2011-08-24 18:12 ` Wolfgang Denk
2011-08-24 18:25 ` Anton Staaf
2011-08-24 19:04 ` Wolfgang Denk
2011-08-24 20:12 ` Anton Staaf
2011-08-24 19:18 ` Lukasz Majewski
2011-08-24 20:13 ` Anton Staaf
2011-08-29 20:12 ` Anton Staaf
2011-08-29 20:35 ` Wolfgang Denk
2011-08-29 21:08 ` Anton Staaf
2011-08-29 20:47 ` Scott Wood
2011-08-29 20:58 ` Anton Staaf
2011-08-29 21:23 ` Scott Wood [this message]
2011-08-29 21:54 ` Anton Staaf
2011-08-29 22:03 ` Scott Wood
2011-08-29 22:49 ` Anton Staaf
2011-08-29 23:01 ` Scott Wood
2011-08-29 23:05 ` Anton Staaf
2011-08-23 20:35 ` Mike Frysinger
2011-08-23 8:42 ` Lukasz Majewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E5C033C.9090808@freescale.com \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.