On Mon, Aug 29, 2011 at 4:01 PM, Scott Wood wrote:
> On 08/29/2011 05:49 PM, Anton Staaf wrote:
> How do you make the declaration static?
you can't with this version of the macro. Are there cases where you
need the buffer to be static?
>>>
>>> I think you'd want it to be static
On 08/29/2011 05:49 PM, Anton Staaf wrote:
How do you make the declaration static?
>>>
>>> you can't with this version of the macro. Are there cases where you
>>> need the buffer to be static?
>>
>> I think you'd want it to be static more often than not.
>
> If the buffer is allocated at fil
On Mon, Aug 29, 2011 at 3:03 PM, Scott Wood wrote:
> On 08/29/2011 04:54 PM, Anton Staaf wrote:
>> On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood wrote:
>>> With the version in that patch I get the slightly different "error:
>>> initializer element is not computable at load time". Seems like whethe
On 08/29/2011 04:54 PM, Anton Staaf wrote:
> On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood wrote:
>> 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 *) determi
On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood wrote:
> On 08/29/2011 03:58 PM, Anton Staaf wrote:
>> On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood wrote:
>>> On 08/29/2011 03:12 PM, Anton Staaf wrote:
1) Mikes's macro
#define DMA_ALIGN_SIZE(size) \
(((size) + CONFIG_SYS_CAC
On 08/29/2011 03:58 PM, Anton Staaf wrote:
> On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood 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, na
On Mon, Aug 29, 2011 at 1:35 PM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> I would like to know, mainly for my education, why you do not want
>> alloca, but are OK with dynamic array sizing (as in the first solution
>> above). My understanding is that they pr
On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood 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(s
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 & ~
Dear Anton Staaf,
In message
you wrote:
>
> I would like to know, mainly for my education, why you do not want
> alloca, but are OK with dynamic array sizing (as in the first solution
> above). My understanding is that they pretty much equate to the same
> thing. What is it about alloca that i
On Wed, Aug 24, 2011 at 1:13 PM, Anton Staaf wrote:
> On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski
> wrote:
>> On Wed, 24 Aug 2011 11:25:42 -0700
>> Anton Staaf wrote:
>>
>>> On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk wrote:
>>> > Dear Anton Staaf,
>>> >
>>> > In message
>>> >
>>> >
On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski wrote:
> On Wed, 24 Aug 2011 11:25:42 -0700
> Anton Staaf wrote:
>
>> On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk wrote:
>> > Dear Anton Staaf,
>> >
>> > In message
>> >
>> > you wrote:
>> >>
>> >> >> 4. get_dcache_line_size() can be simply
On Wed, Aug 24, 2011 at 12:04 PM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> > No, it is definitely NOT needed for this purpose - we have been using
>> > CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so
>> > I don't really understand why w
On Wed, 24 Aug 2011 11:25:42 -0700
Anton Staaf wrote:
> On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk wrote:
> > Dear Anton Staaf,
> >
> > In message
> >
> > you wrote:
> >>
> >> >> 4. get_dcache_line_size() can be simply defined as
> >> >> #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE
Dear Anton Staaf,
In message
you wrote:
>
> > No, it is definitely NOT needed for this purpose - we have been using
> > CONFIG_SYS_CACHE_LINE_SIZE for more than a decade without problems, so
> > I don't really understand why we now would need a new function for
> > this?
>
> Ahh, I misunderstoo
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> >> 4. get_dcache_line_size() can be simply defined as
>> >> #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we
>> >> _really_ want to save a few bytes.
>> >
>> > Actually
Dear Anton Staaf,
In message
you wrote:
>
> >> 4. get_dcache_line_size() can be simply defined as
> >> #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we
> >> _really_ want to save a few bytes.
> >
> > Actually I fail to understand why we would ever need
> > get_dcache_line_size() i
On Wednesday, August 24, 2011 13:27:05 Anton Staaf wrote:
> On Wed, Aug 24, 2011 at 6:25 AM, Wolfgang Denk wrote:
> > Lukasz Majewski wrote:
> >> 4. get_dcache_line_size() can be simply defined as
> >> #define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if we
> >> _really_ want to save a few
On Wed, Aug 24, 2011 at 6:25 AM, Wolfgang Denk wrote:
> Dear Lukasz Majewski,
>
> In message <20110824120744.097ba2c5@lmajewski.digital.local> you wrote:
>>
>> After reading dcache related threads I'd like to sum them up:
>>
>> 1. alloca() -> not acceptable to u-boot mainline by Wolfgang. I agree
On Wednesday, August 24, 2011 09:25:53 Wolfgang Denk wrote:
> Lukasz Majewski wrote:
> > 3. Mike's DMA_DECLARE_BUFFER(, ,
> > )
> > solution looks OK for me, at least for the stack allocated data (e.g.
> > ext_csd).
> > However this proposed implementation has been NAK'ed by Wolfgang.
> >
> > I'm
On Tuesday, August 23, 2011 17:48:50 Anton Staaf wrote:
> I wasn't going to say it. :) How about something like this, which is
> very similar to what you had Mike, but doesn't define the array in the
> macro. It's a bit clearer what is going on, but also requires a bit
> more work at each use.
>
Hi Wolfgang,
> I think I'd like to see a macro that can be used like this:
>
> void *dma_buffer_pointer = DMA_BUFFER(size_in_bytes);
>
Frankly speaking I don't know any easy way to define buffer this way
in a macro (at least without digging deep enough to C preprocessor
programming trick
Dear Lukasz Majewski,
In message <20110824120744.097ba2c5@lmajewski.digital.local> you wrote:
>
> After reading dcache related threads I'd like to sum them up:
>
> 1. alloca() -> not acceptable to u-boot mainline by Wolfgang. I agree
> that alloca is NOT the way to go.
>
> 2. malloc/memalign ->
Hi,
On Tue, 23 Aug 2011 23:00:59 -0400
Mike Frysinger wrote:
> On Tuesday, August 23, 2011 18:42:46 Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> > > > Why cannot we define a macro that declares a (sufficiently
> > > > sized) buffer on the stack and provides and a pointer to a
> > > > (correc
On Tuesday, August 23, 2011 18:42:46 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > Why cannot we define a macro that declares a (sufficiently sized)
> > > buffer on the stack and provides and a pointer to a (correctly
> > > aligned) address in this buffer?
> >
> > isnt that what i already pos
Dear Mike Frysinger,
In message <201108231732.39791.vap...@gentoo.org> you wrote:
>
> > Why cannot we define a macro that declares a (sufficiently sized)
> > buffer on the stack and provides and a pointer to a (correctly
> > aligned) address in this buffer?
>
> isnt that what i already posted and
On Tue, Aug 23, 2011 at 2:32 PM, Mike Frysinger wrote:
> On Tuesday, August 23, 2011 17:09:37 Wolfgang Denk wrote:
>> Mike Frysinger wrote:
>> > On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
>> > > So then, to guide our efforts, what is a more suitable solution?
>> > > Would you prefer w
On Tuesday, August 23, 2011 17:09:37 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
> > > So then, to guide our efforts, what is a more suitable solution?
> > > Would you prefer we stick with the existing path of calling memalign
> > > and p
On Tuesday, August 23, 2011 17:06:41 Anton Staaf wrote:
> On Tue, Aug 23, 2011 at 1:37 PM, Mike Frysinger wrote:
> > On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
> >> So then, to guide our efforts, what is a more suitable solution?
> >> Would you prefer we stick with the existing path o
Dear Mike Frysinger,
In message <201108231637.05845.vap...@gentoo.org> you wrote:
>
> On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
> > So then, to guide our efforts, what is a more suitable solution?
> > Would you prefer we stick with the existing path of calling memalign
> > and passin
On Tue, Aug 23, 2011 at 1:37 PM, Mike Frysinger wrote:
> On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
>> So then, to guide our efforts, what is a more suitable solution?
>> Would you prefer we stick with the existing path of calling memalign
>> and passing it the cache size by directly
On Tuesday, August 23, 2011 16:27:26 Anton Staaf wrote:
> So then, to guide our efforts, what is a more suitable solution?
> Would you prefer we stick with the existing path of calling memalign
> and passing it the cache size by directly calling
> get_dcache_line_size? Or would you prefer somethin
On Tuesday, August 23, 2011 16:12:03 Wolfgang Denk wrote:
> Anton Staaf wrote:
> > > what about adding a new func like:
> > > #define dma_buffer_alloca(size)
> >
> > I generally avoid large allocations on the stack, they can confuse
> > virtual stack management and blow out small embedded stacks.
On Tue, Aug 23, 2011 at 1:12 PM, Wolfgang Denk wrote:
> Dear Anton Staaf,
>
> In message
> you
> wrote:
>>
>> > what about adding a new func like:
>> > #define dma_buffer_alloca(size)
>>
>> I generally avoid large allocations on the stack, they can confuse
>> virtual stack management and blow o
Dear Anton Staaf,
In message
you wrote:
>
> > what about adding a new func like:
> > #define dma_buffer_alloca(size)
>
> I generally avoid large allocations on the stack, they can confuse
> virtual stack management and blow out small embedded stacks. But
> neither of these are really a problem
On Tue, Aug 23, 2011 at 11:36 AM, Mike Frysinger wrote:
> On Tuesday, August 23, 2011 14:12:09 Anton Staaf wrote:
>> On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger wrote:
>> > what about adding a new func like:
>> > #define dma_buffer_alloca(size)
>>
>> I generally avoid large allocations on the
On Tuesday, August 23, 2011 14:12:09 Anton Staaf wrote:
> On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger wrote:
> > what about adding a new func like:
> > #define dma_buffer_alloca(size)
>
> I generally avoid large allocations on the stack, they can confuse
> virtual stack management and blow ou
On Tuesday, August 23, 2011 14:12:09 Anton Staaf wrote:
> On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger wrote:
> > On Tuesday, August 23, 2011 05:19:39 Lukasz Majewski wrote:
> >> On Mon, 22 Aug 2011 11:57:57 -0700 Anton Staaf wrote:
> >> > drivers/mmc/mmc.c: ext_csd in mmc_change_freq is alloca
On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger wrote:
> On Tuesday, August 23, 2011 05:19:39 Lukasz Majewski wrote:
>> On Mon, 22 Aug 2011 11:57:57 -0700 Anton Staaf wrote:
>> > drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stac
>> > drivers/mmc/mmc.c: scr and switch_status i
On Tuesday, August 23, 2011 05:19:39 Lukasz Majewski wrote:
> On Mon, 22 Aug 2011 11:57:57 -0700 Anton Staaf wrote:
> > drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stac
> > drivers/mmc/mmc.c: scr and switch_status in sd_change_freq are
> > allocated on the stack.
> > drivers/m
On Tue, Aug 23, 2011 at 2:19 AM, Lukasz Majewski wrote:
> Hi Anton,
>
> On Mon, 22 Aug 2011 11:57:57 -0700
> Anton Staaf wrote:
>
>> drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stac
>> drivers/mmc/mmc.c: scr and switch_status in sd_change_freq are
>> allocated on the stack.
Hi Anton,
On Mon, 22 Aug 2011 11:57:57 -0700
Anton Staaf wrote:
> drivers/mmc/mmc.c: ext_csd in mmc_change_freq is allocated on the stac
> drivers/mmc/mmc.c: scr and switch_status in sd_change_freq are
> allocated on the stack.
> drivers/mmc/mmc.c: ext_csd in mmc_startup is allocated on the stac
Hi Mike,
On Mon, 22 Aug 2011 12:08:42 -0400
Mike Frysinger wrote:
> On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
> > On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger wrote:
> > > On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
> > > > On Fri, 19 Aug 2011 09:57:10 -0400
On Mon, Aug 22, 2011 at 11:31 AM, Mike Frysinger wrote:
> On Monday, August 22, 2011 14:15:22 Anton Staaf wrote:
>
> please dont top post
Sorry about that.
>> Yes, this would be a much preferable approach. The only problem that
>> I encountered when attempting to do that in the Chromium U-Boot
On Monday, August 22, 2011 14:15:22 Anton Staaf wrote:
please dont top post
> Yes, this would be a much preferable approach. The only problem that
> I encountered when attempting to do that in the Chromium U-Boot was
> that there are exposed stand alone U-Boot API's that can pass in
> pointers t
Yes, this would be a much preferable approach. The only problem that
I encountered when attempting to do that in the Chromium U-Boot was
that there are exposed stand alone U-Boot API's that can pass in
pointers that make their way all the way down to the device driver.
Two solutions occurred to me
On Monday, August 22, 2011 12:42:06 Anton Staaf wrote:
> On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger wrote:
> > On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
> >> No tests performed yet. The goal of those patches is to preserve the
> >> MMC subsystem functionality when dcache is e
On Monday, August 22, 2011 06:42:06 PM Anton Staaf wrote:
> On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger wrote:
> > On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
> >> On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger wrote:
> >> > On Friday, August 19, 2011 11:28:18 Lukasz Majewski
On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger wrote:
> On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
>> On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger wrote:
>> > On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
>> > > On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger w
On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
> On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger wrote:
> > On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
> > > On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger wrote:
> > > > On Friday, August 19, 2011 05:25:13 Lukasz Maje
Hi Mike,
On Fri, 19 Aug 2011 11:35:50 -0400
Mike Frysinger wrote:
> On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
> > On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger wrote:
> > > On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
> > > > + cache_align_buf = memalign(
On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
> On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger wrote:
> > On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
> > > + cache_align_buf = memalign(get_dcache_line_size(),
> >
> > nowhere do i see get_dcache_line_size() defined
>
Hi Mike,
On Fri, 19 Aug 2011 09:57:10 -0400
Mike Frysinger wrote:
> On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
> > + cache_align_buf = memalign(get_dcache_line_size(),
>
> nowhere do i see get_dcache_line_size() defined
>
> also, what is the code size increase with your patch
On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
> + cache_align_buf = memalign(get_dcache_line_size(),
nowhere do i see get_dcache_line_size() defined
also, what is the code size increase with your patch ?
-mike
signature.asc
Description: This is a digitally signed message part.
MMC operations are performed on cache line size aligned buffers.
In the current MMC implementation it is allowed to pass buffer
with arbitrary alignment.
In this patch assumption has been made, that it is better to align the buffer
on the MMC framework boundary, than in a number of u-boot subsyste
55 matches
Mail list logo
