From: Arnd Bergmann <arnd@arndb.de>
To: Jonas Bonn <jonas@southpole.se>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 07/19] OpenRISC: DMA
Date: Tue, 5 Jul 2011 17:37:29 +0200 [thread overview]
Message-ID: <201107051737.30120.arnd@arndb.de> (raw)
In-Reply-To: <1309641352-18714-8-git-send-email-jonas@southpole.se>
On Saturday 02 July 2011, Jonas Bonn wrote:
> +void *or1k_dma_alloc_coherent(struct device *dev, size_t size,
> + dma_addr_t *dma_handle, gfp_t flag)
> +{
> + int order;
> + unsigned long page, va;
> + pgprot_t prot;
> + struct vm_struct *area;
> +
> + /* Only allocate page size areas. */
> + size = PAGE_ALIGN(size);
> + order = get_order(size);
> +
> + page = __get_free_pages(flag, order);
> + if (!page)
> + return NULL;
> +
> + /* Allocate some common virtual space to map the new pages. */
> + area = get_vm_area(size, VM_ALLOC);
> + if (area == NULL) {
> + free_pages(page, order);
> + return NULL;
> + }
> + va = (unsigned long)area->addr;
> +
> + /* This gives us the real physical address of the first page. */
> + *dma_handle = __pa(page);
> +
> + prot = PAGE_KERNEL_NOCACHE;
> +
> + /* This isn't so much ioremap as just simply 'remap' */
> + if (ioremap_page_range(va, va + size, *dma_handle, prot)) {
> + vfree(area->addr);
> + return NULL;
> + }
> +
> + return (void *)va;
> +}
This will result in having conflicting mappings, one with and another
without caching, which a lot of CPU architectures don't like. Are you
sure that you can handle this with or1k?
I think at the very least you will need to flush the cache for
the linear mapping, to avoid writing back dirty cache lines over
the DMA buffer.
You can save a little memory by using alloc_pages_exact instead of
get_free_pages, which always gives you a power-of-two size.
Also, isn't get_vm_area+ioremap_page_range the same as ioremap
on or1k?
In the case that ioremap_page_ranges fails, I think you have a
memory leak, or worse, because areas is not backed by the pages at that
moment.
Arnd
next prev parent reply other threads:[~2011-07-05 15:37 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-02 21:15 OpenRISC Architecture: Patch set version 2 Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 01/19] OpenRISC: Boot code Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 02/19] OpenRISC: Device tree Jonas Bonn
2011-07-03 18:07 ` Segher Boessenkool
2011-07-03 20:51 ` Grant Likely
[not found] ` <CACxGe6tFX=EQjaL-4EjSXquY5eh+bca29=d=cE5-YAVCUVRCvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-03 21:39 ` Benjamin Herrenschmidt
2011-07-03 21:39 ` Benjamin Herrenschmidt
2011-07-04 4:58 ` Jonas Bonn
2011-07-04 4:58 ` Jonas Bonn
2011-07-04 5:35 ` Grant Likely
2011-07-02 21:15 ` [PATCH v2 03/19] OpenRISC: Memory management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 04/19] OpenRISC: Signal handling Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 05/19] OpenRISC: Build infrastructure Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 06/19] OpenRISC: PTrace Jonas Bonn
2011-07-03 19:40 ` Marcin Slusarz
2011-07-05 15:42 ` Arnd Bergmann
2011-07-05 16:05 ` Jonas Bonn
2011-07-05 16:42 ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 07/19] OpenRISC: DMA Jonas Bonn
2011-07-05 15:37 ` Arnd Bergmann [this message]
2011-07-08 7:36 ` Jonas Bonn
2011-07-08 7:36 ` Jonas Bonn
2011-07-08 7:44 ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 08/19] OpenRISC: Timekeeping Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 09/19] OpenRISC: IRQ Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 10/19] OpenRISC: System calls Jonas Bonn
2011-07-05 15:39 ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 11/19] OpenRISC: Idle/Power management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 12/19] OpenRISC: Scheduling/Process management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 13/19] OpenRISC: GPIO Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 14/19] OpenRISC: Module support Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 15/19] OpenRISC: Traps Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 16/19] OpenRISC: Headers Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 17/19] OpenRISC: Library routines Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 18/19] OpenRISC: Miscellaneous Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 19/19] OpenRISC: Add MAINTAINERS entry Jonas Bonn
2011-07-05 15:56 ` OpenRISC Architecture: Patch set version 2 Arnd Bergmann
2011-07-06 15:51 ` linux-next inclusion request: OpenRISC architecture Jonas Bonn
2011-07-16 3:55 ` Stephen Rothwell
[not found] ` <20110707163231.ebc75eef6be02f5490c949d7@canb.auug.org.au>
[not found] ` <201107071305.02061.arnd@arndb.de>
2011-07-16 4:01 ` arm-soc tree inclusion Stephen Rothwell
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=201107051737.30120.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=jonas@southpole.se \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.