From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH] sh: declared coherent memory support
Date: Sun, 13 Jan 2008 16:33:02 +0000 [thread overview]
Message-ID: <20080113163302.GA7532@linux-sh.org> (raw)
In-Reply-To: <20080113135447.30289.54583.sendpatchset@clockwork.opensource.se>
On Sun, Jan 13, 2008 at 10:54:47PM +0900, Magnus Damm wrote:
> This patch adds declared coherent memory support to the sh architecture. All
> functions are copied straight from the x86 implementation and the header files
> are adjusted to use the newfunctions instead of the former consistent_alloc()
> code.
>
[snip]
> - memset(vp, 0, size);
> + if (dev = NULL || (dev->coherent_dma_mask < 0xffffffff))
> + gfp |= GFP_DMA;
>
This is obviously not something we care about, we don't have a ZONE_DMA,
and GFP_DMA has no meaning here. The page allocator will obviously still
do the right thing, but it's a bit ambiguous to suggest that we have some
sort of bogus limitation. The coherent_dma_mask is basically unintersting
in the general case, there are two situations in which we care about it,
and those are > 32-bits physical, or a restricted address space. In the
latter case we have to bounce it anyways, so a bogus DMA zone isn't going
to make a difference there. Likewise, in the > 32-bits physical case, we
also just don't care.
> + ret = (void *)__get_free_pages(gfp, order);
> +
> + if (ret != NULL) {
> + memset(ret, 0, size);
> + *dma_handle = virt_to_phys(ret);
> }
> + return ret;
> +}
> +EXPORT_SYMBOL(dma_alloc_coherent);
>
I do wonder whether it's sane to forego the dma_cache_sync() in the
allocation path in this case. If the allocation is satisfied by the
bitmap, it can probably be skipped, but as far as data we're fetching and
remapping from the page allocator, I suspect this is still going to need
a sync.
> + mem_base = ioremap(bus_addr, size);
> + if (!mem_base)
> + goto out;
> +
This should be ioremap_nocache().
> + dev->dma_mem = kzalloc(sizeof(struct dma_coherent_mem), GFP_KERNEL);
> + if (!dev->dma_mem)
> + goto out;
This can probably be kmalloc(), since everything is being initialized
anyways, no point in zeroing it out.
> +void dma_release_declared_memory(struct device *dev)
> +{
> + struct dma_coherent_mem *mem = dev->dma_mem;
>
> - free_pages(addr, get_order(size));
> + if (!mem)
> + return;
> + dev->dma_mem = NULL;
> + iounmap(mem->virt_base);
> + kfree(mem->bitmap);
> + kfree(mem);
> +}
What happens if someone is still using the bitmap?
next prev parent reply other threads:[~2008-01-13 16:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-13 13:54 [PATCH] sh: declared coherent memory support Magnus Damm
2008-01-13 16:33 ` Paul Mundt [this message]
2008-01-24 9:35 ` [PATCH] sh: declared coherent memory support V2 Magnus Damm
2008-01-24 10:49 ` Paul Mundt
2008-01-25 3:42 ` [PATCH] sh: declared coherent memory support V2 fix Magnus Damm
2008-01-29 0:46 ` Paul Mundt
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=20080113163302.GA7532@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@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