RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
Russell, > -Original Message- > From: Sin, David > Sent: Monday, August 02, 2010 9:55 AM > To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, > Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Molnar, Lajos; > Voultoury, Pierre; linux-arm-ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager > interface and implementation > > -Original Message- > From: Shilimkar, Santosh > Sent: Monday, August 02, 2010 9:53 AM > To: Sin, David; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, > Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Molnar, Lajos; > Voultoury, Pierre; linux-arm-ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager > interface and implementation > > > > > -Original Message- > > From: Sin, David > > Sent: Monday, August 02, 2010 8:20 PM > > To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard > > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, > Hari; Ohad Ben- > > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; > linux-arm- > > ker...@lists.infradead.org > > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > > implementation > > > > -Original Message- > > From: Shilimkar, Santosh > > Sent: Monday, August 02, 2010 9:45 AM > > To: Sin, David; Russell King - ARM Linux; Woodruff, Richard > > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, > Hari; Ohad Ben- > > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; > linux-arm- > > ker...@lists.infradead.org > > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > > implementation > > > < snip> > > > > > + m->pa = page_to_phys(m->pg); > > > > + > > > > + /* flush the cache entry for each page we allocate. */ > > > > + dmac_flush_range(page_address(m->pg), > > > > + page_address(m->pg) + > PAGE_SIZE); > > > > + outer_flush_range(m->pa, m->pa + PAGE_SIZE); > > > > > > NAK. This is an abuse of these interfaces, and is buggy > in any case. > > > > > > ARMv6 and ARMv7 CPUs speculatively prefetch memory, which > means that > > > there's no guarantee that if you flush the caches for a particular > > > range of virtual space, that it will stay flushed until you decide > > > to read it. So flushing the caches in some memory allocator can't > > > guarantee that when you eventually get around to using > the page that > > > there won't be cache lines associated with it. > > > > > > [dhs] Russell, thanks for reviewing this code. Do you have any > > interface > > > suggestions that you can share that would make this > proper? Ideally, I > > > would like to get physical pages without associated > virtual address, or > > > ones that are non-cached/non-bufferable. > > > > There is nothing called 'non-bufferable' any more David on ARMv6 and > > ARMv7. > > You can get non-cached memory using "dma_alloc_coherent" > > > > [dhs] Thanks, Santosh, for the clarification. I believe > > dma_alloc_coherent is quite limited, right? We need to be > able to cover > > potentially 128MB of physical memory for the TILER. BTW, > does GFP_DMA > > indicate that I don't want cached memory? > > > It's configurable. By default it's 2 MB pool. GFP_DMA doesn't give you > un-cacheable memory. > > [dhs] OK -- I will increase this and try to allocate this > way. Thank you. > > As Santosh suggests, I will increase the dma_alloc_coherent pool size to something that will accomdate TILER requirements. I believe this will work, as I'm only making 4k allocations per call, as opposed to one large contiguous allocation. However, I'd like to be able to use an API similar to alloc_page() that gives back device or strongly ordered memory so that we don't have to pre-allocate such a large amount at boot-up. Is this something that you're considering on your end for the near future? Thanks for working through this with us. Regards, -David-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
-Original Message- From: Shilimkar, Santosh Sent: Monday, August 02, 2010 9:53 AM To: Sin, David; Russell King - ARM Linux; Woodruff, Richard Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; linux-arm-ker...@lists.infradead.org Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation > -Original Message- > From: Sin, David > Sent: Monday, August 02, 2010 8:20 PM > To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben- > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; linux-arm- > ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > implementation > > -Original Message- > From: Shilimkar, Santosh > Sent: Monday, August 02, 2010 9:45 AM > To: Sin, David; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben- > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; linux-arm- > ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > implementation > < snip> > > > + m->pa = page_to_phys(m->pg); > > > + > > > + /* flush the cache entry for each page we allocate. */ > > > + dmac_flush_range(page_address(m->pg), > > > + page_address(m->pg) + PAGE_SIZE); > > > + outer_flush_range(m->pa, m->pa + PAGE_SIZE); > > > > NAK. This is an abuse of these interfaces, and is buggy in any case. > > > > ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that > > there's no guarantee that if you flush the caches for a particular > > range of virtual space, that it will stay flushed until you decide > > to read it. So flushing the caches in some memory allocator can't > > guarantee that when you eventually get around to using the page that > > there won't be cache lines associated with it. > > > > [dhs] Russell, thanks for reviewing this code. Do you have any > interface > > suggestions that you can share that would make this proper? Ideally, I > > would like to get physical pages without associated virtual address, or > > ones that are non-cached/non-bufferable. > > There is nothing called 'non-bufferable' any more David on ARMv6 and > ARMv7. > You can get non-cached memory using "dma_alloc_coherent" > > [dhs] Thanks, Santosh, for the clarification. I believe > dma_alloc_coherent is quite limited, right? We need to be able to cover > potentially 128MB of physical memory for the TILER. BTW, does GFP_DMA > indicate that I don't want cached memory? > It's configurable. By default it's 2 MB pool. GFP_DMA doesn't give you un-cacheable memory. [dhs] OK -- I will increase this and try to allocate this way. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
> -Original Message- > From: Sin, David > Sent: Monday, August 02, 2010 8:20 PM > To: Shilimkar, Santosh; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben- > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; linux-arm- > ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > implementation > > -Original Message- > From: Shilimkar, Santosh > Sent: Monday, August 02, 2010 9:45 AM > To: Sin, David; Russell King - ARM Linux; Woodruff, Richard > Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben- > Cohen; Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre; linux-arm- > ker...@lists.infradead.org > Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and > implementation > < snip> > > > + m->pa = page_to_phys(m->pg); > > > + > > > + /* flush the cache entry for each page we allocate. */ > > > + dmac_flush_range(page_address(m->pg), > > > + page_address(m->pg) + PAGE_SIZE); > > > + outer_flush_range(m->pa, m->pa + PAGE_SIZE); > > > > NAK. This is an abuse of these interfaces, and is buggy in any case. > > > > ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that > > there's no guarantee that if you flush the caches for a particular > > range of virtual space, that it will stay flushed until you decide > > to read it. So flushing the caches in some memory allocator can't > > guarantee that when you eventually get around to using the page that > > there won't be cache lines associated with it. > > > > [dhs] Russell, thanks for reviewing this code. Do you have any > interface > > suggestions that you can share that would make this proper? Ideally, I > > would like to get physical pages without associated virtual address, or > > ones that are non-cached/non-bufferable. > > There is nothing called 'non-bufferable' any more David on ARMv6 and > ARMv7. > You can get non-cached memory using "dma_alloc_coherent" > > [dhs] Thanks, Santosh, for the clarification. I believe > dma_alloc_coherent is quite limited, right? We need to be able to cover > potentially 128MB of physical memory for the TILER. BTW, does GFP_DMA > indicate that I don't want cached memory? > It's configurable. By default it's 2 MB pool. GFP_DMA doesn't give you un-cacheable memory. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
-Original Message-
From: Shilimkar, Santosh
Sent: Monday, August 02, 2010 9:45 AM
To: Sin, David; Russell King - ARM Linux; Woodruff, Richard
Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben-Cohen;
Hiremath, Vaibhav; Molnar, Lajos; Voultoury, Pierre;
linux-arm-ker...@lists.infradead.org
Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
implementation
> -Original Message-
> From: Sin, David
> Sent: Monday, August 02, 2010 8:11 PM
> To: Russell King - ARM Linux; Woodruff, Richard
> Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben-
> Cohen; Hiremath, Vaibhav; Shilimkar, Santosh; Molnar, Lajos; Voultoury,
> Pierre; linux-arm-ker...@lists.infradead.org
> Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> implementation
>
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, July 24, 2010 3:01 AM
> To: Sin, David
> Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
> Tony Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav;
> Shilimkar, Santosh; Molnar, Lajos
> Subject: Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> implementation
>
> On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
> > +/* allocate and flush a page */
> > +static struct mem *alloc_mem(void)
> > +{
> > + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> > + if (!m)
> > + return NULL;
> > +
> > + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> > + if (!m->pg) {
> > + kfree(m);
> > + return NULL;
> > + }
> > +
> > + m->pa = page_to_phys(m->pg);
> > +
> > + /* flush the cache entry for each page we allocate. */
> > + dmac_flush_range(page_address(m->pg),
> > + page_address(m->pg) + PAGE_SIZE);
> > + outer_flush_range(m->pa, m->pa + PAGE_SIZE);
>
> NAK. This is an abuse of these interfaces, and is buggy in any case.
>
> ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
> there's no guarantee that if you flush the caches for a particular
> range of virtual space, that it will stay flushed until you decide
> to read it. So flushing the caches in some memory allocator can't
> guarantee that when you eventually get around to using the page that
> there won't be cache lines associated with it.
>
> [dhs] Russell, thanks for reviewing this code. Do you have any interface
> suggestions that you can share that would make this proper? Ideally, I
> would like to get physical pages without associated virtual address, or
> ones that are non-cached/non-bufferable.
There is nothing called 'non-bufferable' any more David on ARMv6 and ARMv7.
You can get non-cached memory using "dma_alloc_coherent"
[dhs] Thanks, Santosh, for the clarification. I believe dma_alloc_coherent is
quite limited, right? We need to be able to cover potentially 128MB of
physical memory for the TILER. BTW, does GFP_DMA indicate that I don't want
cached memory?
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
> -Original Message-
> From: Sin, David
> Sent: Monday, August 02, 2010 8:11 PM
> To: Russell King - ARM Linux; Woodruff, Richard
> Cc: linux-omap@vger.kernel.org; Tony Lindgren; Kanigeri, Hari; Ohad Ben-
> Cohen; Hiremath, Vaibhav; Shilimkar, Santosh; Molnar, Lajos; Voultoury,
> Pierre; linux-arm-ker...@lists.infradead.org
> Subject: RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> implementation
>
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Saturday, July 24, 2010 3:01 AM
> To: Sin, David
> Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
> Tony Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav;
> Shilimkar, Santosh; Molnar, Lajos
> Subject: Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> implementation
>
> On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
> > +/* allocate and flush a page */
> > +static struct mem *alloc_mem(void)
> > +{
> > + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> > + if (!m)
> > + return NULL;
> > +
> > + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> > + if (!m->pg) {
> > + kfree(m);
> > + return NULL;
> > + }
> > +
> > + m->pa = page_to_phys(m->pg);
> > +
> > + /* flush the cache entry for each page we allocate. */
> > + dmac_flush_range(page_address(m->pg),
> > + page_address(m->pg) + PAGE_SIZE);
> > + outer_flush_range(m->pa, m->pa + PAGE_SIZE);
>
> NAK. This is an abuse of these interfaces, and is buggy in any case.
>
> ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
> there's no guarantee that if you flush the caches for a particular
> range of virtual space, that it will stay flushed until you decide
> to read it. So flushing the caches in some memory allocator can't
> guarantee that when you eventually get around to using the page that
> there won't be cache lines associated with it.
>
> [dhs] Russell, thanks for reviewing this code. Do you have any interface
> suggestions that you can share that would make this proper? Ideally, I
> would like to get physical pages without associated virtual address, or
> ones that are non-cached/non-bufferable.
There is nothing called 'non-bufferable' any more David on ARMv6 and ARMv7.
You can get non-cached memory using "dma_alloc_coherent"
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, July 24, 2010 3:01 AM
To: Sin, David
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Tony
Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar,
Santosh; Molnar, Lajos
Subject: Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
implementation
On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
> +/* allocate and flush a page */
> +static struct mem *alloc_mem(void)
> +{
> + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> + if (!m)
> + return NULL;
> +
> + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> + if (!m->pg) {
> + kfree(m);
> + return NULL;
> + }
> +
> + m->pa = page_to_phys(m->pg);
> +
> + /* flush the cache entry for each page we allocate. */
> + dmac_flush_range(page_address(m->pg),
> + page_address(m->pg) + PAGE_SIZE);
> + outer_flush_range(m->pa, m->pa + PAGE_SIZE);
NAK. This is an abuse of these interfaces, and is buggy in any case.
ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
there's no guarantee that if you flush the caches for a particular
range of virtual space, that it will stay flushed until you decide
to read it. So flushing the caches in some memory allocator can't
guarantee that when you eventually get around to using the page that
there won't be cache lines associated with it.
[dhs] Russell, thanks for reviewing this code. Do you have any interface
suggestions that you can share that would make this proper? Ideally, I would
like to get physical pages without associated virtual address, or ones that are
non-cached/non-bufferable.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
> -Original Message-
> From: Sin, David
> Sent: Saturday, July 24, 2010 4:52 AM
> To: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org;
> Tony Lindgren; Russell King
> Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
> Molnar, Lajos; Sin, David
> Subject: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
> implementation
>
> From: Lajos Molnar
>
> This patch defines the TILER Memory Manager (TMM) interface and
> provides implementation for a PAT-supporting TMM.
>
> Signed-off-by: Lajos Molnar
> Signed-off-by: David Sin
> ---
> drivers/media/video/tiler/tmm-pat.c | 274
> +++
> drivers/media/video/tiler/tmm.h | 109 ++
> 2 files changed, 383 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/tiler/tmm-pat.c
> create mode 100644 drivers/media/video/tiler/tmm.h
>
> diff --git a/drivers/media/video/tiler/tmm-pat.c
> b/drivers/media/video/tiler/tmm-pat.c
> new file mode 100644
> index 000..ccd32b4
> --- /dev/null
> +++ b/drivers/media/video/tiler/tmm-pat.c
> @@ -0,0 +1,274 @@
> +/*
> + * tmm-pat.c
> + *
> + * DMM driver support functions for TI TILER hardware block.
> + *
> + * Authors: Lajos Molnar
> + * David Sin
> + *
> + * Copyright (C) 2009-2010 Texas Instruments, Inc.
> + *
> + * This package is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
> + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
> + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "tmm.h"
> +
> +/* Page size granularity can be 4k, 16k, or 64k */
> +#define DMM_PAGE 0x1000
> +
[Hiremath, Vaibhav] You can use SZ_4K, SZ_16K macros here.
> +/* Memory limit to cache free pages. TILER will eventually use this much */
> +static u32 cache_limit = CONFIG_TILER_CACHE_LIMIT << 20;
> +module_param_named(cache, cache_limit, uint, 0644);
> +MODULE_PARM_DESC(cache, "Cache free pages if total memory is under this
> limit");
> +
> +/* global state - statically initialized */
> +static LIST_HEAD(free_list); /* page cache: list of free pages */
> +static u32 total_mem;/* total memory allocated (free & used)
> */
> +static u32 refs; /* number of tmm_pat instances */
> +static DEFINE_MUTEX(mtx);/* global mutex */
> +
> +/* The page struct pointer and physical address of each page.*/
> +struct mem {
> + struct list_head list;
> + struct page *pg;/* page struct */
> + u32 pa; /* physical address */
> +};
> +
> +/* Used to keep track of mem per tmm_pat_get_pages call */
> +struct fast {
[Hiremath, Vaibhav] Can you think of some better naming convention here, "fast"
is bit confusing here?
Does following convention make sense to you here,
struct mem => struct tmm_page
struct fast => struct tmm_pages
> + struct list_head list;
> + struct mem **mem; /* array of page info */
> + u32 *pa;/* array of physical addresses */
> + u32 num;/* number of pages */
> +};
> +
> +/* TMM PAT private structure */
> +struct dmm_mem {
> + struct list_head fast_list;
> + struct dmm *dmm;
> +};
> +
> +/**
> + * Frees pages in a fast structure. Moves pages to the free list if there
> + * are less pages used than max_to_keep. Otherwise, it frees the
> pages
> + */
> +static void free_fast(struct fast *f)
[Hiremath, Vaibhav] Same here, free_pages. Applicable to all places.
> +{
> + s32 i = 0;
> +
> + /* mutex is locked */
> + for (i = 0; i < f->num; i++) {
> + if (total_mem < cache_limit) {
> + /* cache free page if under the limit */
> + list_add(&f->mem[i]->list, &free_list);
> + } else {
> + /* otherwise, free */
> + total_mem -= PAGE_SIZE;
[Hiremath, Vaibhav] I have one Q here,
What if DMM/Tiler page size is different than Linux PAGE_SIZE? Does this driver
will still work? Have you tested it?
Thanks,
Vaibhav
> + __free_page(f->mem[i]->pg);
> + }
> + }
> + kfree(f->pa);
> + kfree(f->mem);
> + /* remove only if element was added */
> + if (f->list.next)
> + list_del(&f->list);
> + kfree(f);
> +}
> +
> +/* allocate and flush a page */
> +static struct mem *alloc_mem(void)
> +{
> + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> + if (!m)
> + return NULL;
> +
> + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> + if (!m->pg) {
> + kfree(m);
> + return NULL;
> + }
> +
> + m->pa = page_to_ph
RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
OK -- I will revisit this. Thanks for the explanation.
-David
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Saturday, July 24, 2010 3:01 AM
To: Sin, David
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-omap@vger.kernel.org; Tony
Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar,
Santosh; Molnar, Lajos
Subject: Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and
implementation
On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
> +/* allocate and flush a page */
> +static struct mem *alloc_mem(void)
> +{
> + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> + if (!m)
> + return NULL;
> +
> + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> + if (!m->pg) {
> + kfree(m);
> + return NULL;
> + }
> +
> + m->pa = page_to_phys(m->pg);
> +
> + /* flush the cache entry for each page we allocate. */
> + dmac_flush_range(page_address(m->pg),
> + page_address(m->pg) + PAGE_SIZE);
> + outer_flush_range(m->pa, m->pa + PAGE_SIZE);
NAK. This is an abuse of these interfaces, and is buggy in any case.
ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
there's no guarantee that if you flush the caches for a particular
range of virtual space, that it will stay flushed until you decide
to read it. So flushing the caches in some memory allocator can't
guarantee that when you eventually get around to using the page that
there won't be cache lines associated with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation
On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
> +/* allocate and flush a page */
> +static struct mem *alloc_mem(void)
> +{
> + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
> + if (!m)
> + return NULL;
> +
> + m->pg = alloc_page(GFP_KERNEL | GFP_DMA);
> + if (!m->pg) {
> + kfree(m);
> + return NULL;
> + }
> +
> + m->pa = page_to_phys(m->pg);
> +
> + /* flush the cache entry for each page we allocate. */
> + dmac_flush_range(page_address(m->pg),
> + page_address(m->pg) + PAGE_SIZE);
> + outer_flush_range(m->pa, m->pa + PAGE_SIZE);
NAK. This is an abuse of these interfaces, and is buggy in any case.
ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
there's no guarantee that if you flush the caches for a particular
range of virtual space, that it will stay flushed until you decide
to read it. So flushing the caches in some memory allocator can't
guarantee that when you eventually get around to using the page that
there won't be cache lines associated with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
