[U-Boot] [PATCH v4 18/23] ARM: Implement non-cached memory support

[Albert ARIBAUD]

Hello Simon,

On Wed, 10 Dec 2014 08:03:29 -0700, Simon Glass <sjg at chromium.org>
wrote:
> Hi Albert,
> 
> On 9 December 2014 at 22:25, Simon Glass <sjg at chromium.org> wrote:
> > From: Thierry Reding <treding at nvidia.com>
> >
> > Implement an API that can be used by drivers to allocate memory from a
> > pool that is mapped uncached. This is useful if drivers would otherwise
> > need to do extensive cache maintenance (or explicitly maintaining the
> > cache isn't safe).
> >
> > The API is protected using the new CONFIG_SYS_NONCACHED_MEMORY setting.
> > Boards can set this to the size to be used for the non-cached area. The
> > area will typically be right below the malloc() area, but architectures
> > should take care of aligning the beginning and end of the area to honor
> > any mapping restrictions. Architectures must also ensure that mappings
> > established for this area do not overlap with the malloc() area (which
> > should remain cached for improved performance).
> >
> > While the API is currently only implemented for ARM v7, it should be
> > generic enough to allow other architectures to implement it as well.
> >
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> > Changes in v4: None
> > Changes in v3:
> > - Avoid build error with noncached_init() when the dcache is disabled
> >
> >  README                        | 19 +++++++++++++++++++
> >  arch/arm/include/asm/system.h |  5 +++++
> >  arch/arm/lib/cache.c          | 44 +++++++++++++++++++++++++++++++++++++++++++
> >  common/board_r.c              | 11 +++++++++++
> >  4 files changed, 79 insertions(+)
> 
> I think you have applied the other cache patches. Are you OK with this
> one? I would like to get this series applied very soon (after DM I2C)
> as it's been around since August.

This is delegated to Tom Warren in Patchwork. I'm delegating it to
myself and applying it; if Tom has applied it too, this should not
cause a major merge issue.

Amicalement,
-- 
Albert.