public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes
Date: Mon, 6 Jul 2015 23:45:00 +0200	[thread overview]
Message-ID: <201507062345.01029.marex@denx.de> (raw)
In-Reply-To: <1436217935.2658.8.camel@freescale.com>

On Monday, July 06, 2015 at 11:25:35 PM, Scott Wood wrote:
> On Fri, 2015-07-03 at 15:44 +0200, Marek Vasut wrote:
> > On Thursday, July 02, 2015 at 11:35:19 PM, Scott Wood wrote:
> > > On Thu, 2015-07-02 at 07:53 +0200, Marek Vasut wrote:
> > > > On Thursday, July 02, 2015 at 01:04:52 AM, Marcel Ziswiler wrote:
> > > > > From: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > > 
> > > > > Various U-Boot adoptions/extensions to MTD/NAND/UBI did not take
> > > > > buffer
> > > > > alignment into account which led to failures of the following form:
> > > > > 
> > > > > ERROR: v7_dcache_inval_range - start address is not aligned -
> > > > > 0x1f7f0108 ERROR: v7_dcache_inval_range - stop address is not
> > > > > aligned - 0x1f7f1108
> > > > > 
> > > > > Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> > > > 
> > > > What about using ALLOC_CACHE_ALIGN_BUFFER() and friends instead ? See
> > > > include/common.h for their definition, this is what those functions
> > > > are exactly for.
> > > 
> > > ALLOC_CACHE_ALIGN_BUFFER() is for statically allocating an aligned
> > > buffer.
> > 
> > You're confusing this with DEFINE_ALIGN_BUFFER, no ?
> 
> OK, not "statically", but on the stack.  It is not appropriate to turn
> dynamic allocations into stack allocations without considering how large
> the allocation can be.  It'd also be more intrusive a change than
> necessary, even if the sizes were small enough.

Fine.

> > > Dynamically allocating an aligned buffer is exactly what memalign() is
> > > for.
> > 
> > Isn't memalign()ed memory aligned only to the start address, while the
> > end address (and thus the length) is not aligned ?
> 
> The end address is aligned if the size passed to memalign is aligned. 
> Maybe add a wrapper that calls memalign() with the size rounded up to
> ARCH_DMA_MINALIGN?

I agree.

> >  This is what memalign(3) has
> > 
> > to say:
> > 
> > "
> > The function posix_memalign() allocates size bytes and places the
> > address of the allocated memory in *memptr.  The address of the
> > allo? cated memory will be a multiple of alignment, which must
> > be a power of two and a multiple of sizeof(void *).  If size is  0,
> > then  the value placed in *memptr is either NULL, or a unique pointer
> > value that can later be successfully passed to free(3).
> > 
> > The obsolete function memalign() allocates size bytes and returns a
> > pointer to the allocated memory.  The memory address will be a mul?
> > tiple of alignment, which must be a power of two.
> > "
> 
> posix_memalign() does not exist in U-Boot, and it's not clear to me why
> memalign() should be considered obsolete.  Is the difference just the
> ability to return -EINVAL?

The args are also totally different.

Best regards,
Marek Vasut

  reply	other threads:[~2015-07-06 21:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 23:04 [U-Boot] [PATCH 0/8] assortment of fixes/enhancements Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 1/8] fs/fs.c: read up to EOF when len would read past EOF Marcel Ziswiler
2015-07-02  5:46   ` Marek Vasut
2015-07-02  6:01     ` Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 2/8] net: asix: fix operation without eeprom Marcel Ziswiler
2015-07-02  5:50   ` Marek Vasut
2015-07-02  6:12     ` Marcel Ziswiler
2015-07-02 18:39       ` Marek Vasut
2015-07-08  3:55   ` Joe Hershberger
2015-07-08  6:39     ` Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 3/8] generic-board: allow showing custom board info Marcel Ziswiler
2015-07-03  3:27   ` Simon Glass
2015-07-01 23:04 ` [U-Boot] [PATCH 4/8] logos: add Toradex logo Marcel Ziswiler
2015-07-01 23:04 ` [U-Boot] [PATCH 5/8] colibri_vf: remove spurious new line Marcel Ziswiler
2015-07-02  5:52   ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 6/8] image-fdt.c: store returned error value Marcel Ziswiler
2015-07-02  5:52   ` Marek Vasut
2015-07-03  3:21     ` Simon Glass
2015-07-01 23:04 ` [U-Boot] [PATCH 7/8] mtd/nand/ubi: assortment of alignment fixes Marcel Ziswiler
2015-07-02  5:53   ` Marek Vasut
2015-07-02 21:35     ` Scott Wood
2015-07-03 13:44       ` Marek Vasut
2015-07-06 21:25         ` Scott Wood
2015-07-06 21:45           ` Marek Vasut [this message]
2015-07-06 21:50             ` Scott Wood
2015-07-06 21:57               ` Marek Vasut
2015-07-01 23:04 ` [U-Boot] [PATCH 8/8] tftp.c: fix CONFIG_TFTP_TSIZE for small files Marcel Ziswiler
2015-07-02  5:54   ` Marek Vasut

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=201507062345.01029.marex@denx.de \
    --to=marex@denx.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox