linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  reply	other threads:[~2011-07-05 15:37 UTC|newest]

Thread overview: 47+ 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-02 21:15   ` 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   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 05/19] OpenRISC: Build infrastructure Jonas Bonn
2011-07-02 21:15   ` 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: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:44       ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 08/19] OpenRISC: Timekeeping Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 09/19] OpenRISC: IRQ Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 10/19] OpenRISC: System calls Jonas Bonn
2011-07-02 21:15   ` 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   ` 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   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 18/19] OpenRISC: Miscellaneous Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 19/19] OpenRISC: Add MAINTAINERS entry Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-05 15:56 ` OpenRISC Architecture: Patch set version 2 Arnd Bergmann

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).