On Wed, Aug 24, 2011 at 1:13 PM, Anton Staaf robot...@google.com wrote:
On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski majess1...@gmail.com
wrote:
On Wed, 24 Aug 2011 11:25:42 -0700
Anton Staaf robot...@google.com wrote:
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message caf6fiowhhqbvqwwprusb69s2mpfbtoiazxc8x56bkogjmzx...@mail.gmail.com
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
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
On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood scottw...@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
On Mon, Aug 29, 2011 at 1:35 PM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
caf6fiowhhqbvqwwprusb69s2mpfbtoiazxc8x56bkogjmzx...@mail.gmail.com you
wrote:
I would like to know, mainly for my education, why you do not want
alloca, but are OK with dynamic array sizing
On 08/29/2011 03:58 PM, Anton Staaf wrote:
On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood scottw...@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,
On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood scottw...@freescale.com wrote:
On 08/29/2011 03:58 PM, Anton Staaf wrote:
On Mon, Aug 29, 2011 at 1:47 PM, Scott Wood scottw...@freescale.com wrote:
On 08/29/2011 03:12 PM, Anton Staaf wrote:
1) Mikes's macro
#define DMA_ALIGN_SIZE(size) \
On 08/29/2011 04:54 PM, Anton Staaf wrote:
On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood scottw...@freescale.com 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
On Mon, Aug 29, 2011 at 3:03 PM, Scott Wood scottw...@freescale.com wrote:
On 08/29/2011 04:54 PM, Anton Staaf wrote:
On Mon, Aug 29, 2011 at 2:23 PM, Scott Wood scottw...@freescale.com wrote:
With the version in that patch I get the slightly different error:
initializer element is not
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 file scope, then yes,
On Mon, Aug 29, 2011 at 4:01 PM, Scott Wood scottw...@freescale.com 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
Hi,
On Tue, 23 Aug 2011 23:00:59 -0400
Mike Frysinger vap...@gentoo.org 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
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 - avoidable
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 tricks).
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.
On Wednesday, August 24, 2011 09:25:53 Wolfgang Denk wrote:
Lukasz Majewski wrote:
3. Mike's DMA_DECLARE_BUFFER(buffer type, variable name,
size in bytes)
solution looks OK for me, at least for the stack allocated data (e.g.
ext_csd).
However this proposed implementation has been NAK'ed
On Wed, Aug 24, 2011 at 6:25 AM, Wolfgang Denk w...@denx.de 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 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 bytes.
Dear Anton Staaf,
In message CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com
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
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com you
wrote:
4. get_dcache_line_size() can be simply defined as
#define get_dcache_line_size() CONFIG_SYS_CACHE_LINE_SIZE if
Dear Anton Staaf,
In message caf6fiowm6mezmmdr6+i8tgolg-en4tihtocaupbh0o7vqha...@mail.gmail.com
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
On Wed, 24 Aug 2011 11:25:42 -0700
Anton Staaf robot...@google.com wrote:
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
CAF6FioWBsjFa+QdFNHEQGO50eLoqZMc--Yt3-iYX6DWr=hc...@mail.gmail.com
you wrote:
4. get_dcache_line_size() can be
On Wed, Aug 24, 2011 at 12:04 PM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
caf6fiowm6mezmmdr6+i8tgolg-en4tihtocaupbh0o7vqha...@mail.gmail.com you
wrote:
No, it is definitely NOT needed for this purpose - we have been using
CONFIG_SYS_CACHE_LINE_SIZE for more than
On Wed, Aug 24, 2011 at 12:18 PM, Lukasz Majewski majess1...@gmail.com wrote:
On Wed, 24 Aug 2011 11:25:42 -0700
Anton Staaf robot...@google.com wrote:
On Wed, Aug 24, 2011 at 11:12 AM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
Hi Mike,
On Mon, 22 Aug 2011 12:08:42 -0400
Mike Frysinger vap...@gentoo.org 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
Hi Anton,
On Mon, 22 Aug 2011 11:57:57 -0700
Anton Staaf robot...@google.com 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
On Tue, Aug 23, 2011 at 2:19 AM, Lukasz Majewski l.majew...@samsung.com wrote:
Hi Anton,
On Mon, 22 Aug 2011 11:57:57 -0700
Anton Staaf robot...@google.com 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
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.
On Tue, Aug 23, 2011 at 10:30 AM, Mike Frysinger vap...@gentoo.org 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
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 allocated on
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 out small
On Tue, Aug 23, 2011 at 11:36 AM, Mike Frysinger vap...@gentoo.org 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
Dear Anton Staaf,
In message CAF6FioXeFQP2a0VaZOVOTmxPvJxF4=kamS18=2=p6tfnefw...@mail.gmail.com
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
On Tue, Aug 23, 2011 at 1:12 PM, Wolfgang Denk w...@denx.de wrote:
Dear Anton Staaf,
In message
CAF6FioXeFQP2a0VaZOVOTmxPvJxF4=kamS18=2=p6tfnefw...@mail.gmail.com you
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 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. But
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 something
On Tue, Aug 23, 2011 at 1:37 PM, Mike Frysinger vap...@gentoo.org 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
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 passing it the
On Tuesday, August 23, 2011 17:06:41 Anton Staaf wrote:
On Tue, Aug 23, 2011 at 1:37 PM, Mike Frysinger vap...@gentoo.org 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
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 passing it
On Tue, Aug 23, 2011 at 2:32 PM, Mike Frysinger vap...@gentoo.org 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
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 you
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 posted and you
Hi Mike,
On Fri, 19 Aug 2011 11:35:50 -0400
Mike Frysinger vap...@gentoo.org 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 =
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 Majewski
On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger vap...@gentoo.org 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
On Monday, August 22, 2011 06:42:06 PM Anton Staaf wrote:
On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger vap...@gentoo.org 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
On Monday, August 22, 2011 12:42:06 Anton Staaf wrote:
On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger vap...@gentoo.org 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
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
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 that
On Mon, Aug 22, 2011 at 11:31 AM, Mike Frysinger vap...@gentoo.org 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
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
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.
Hi Mike,
On Fri, 19 Aug 2011 09:57:10 -0400
Mike Frysinger vap...@gentoo.org 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
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
Please
55 matches
Mail list logo
