Hi Albert, On 18 December 2014 at 13:17, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Simon, > > On Wed, 10 Dec 2014 08:03:29 -0700, Simon Glass <s...@chromium.org> > wrote: >> Hi Albert, >> >> On 9 December 2014 at 22:25, Simon Glass <s...@chromium.org> wrote: >> > From: Thierry Reding <tred...@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 <tred...@nvidia.com> >> > Signed-off-by: Simon Glass <s...@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.
Agreed, sounds good, thanks. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
