From: Takashi Iwai <tiwai@suse.de>
To: Russell King <rmk+alsa@arm.linux.org.uk>
Cc: Jaroslav Kysela <perex@suse.cz>,
Alsa Devel list <alsa-devel@lists.sourceforge.net>
Subject: Re: [PATCH] 1/3 Implement generic device DMA mapping support
Date: Mon, 01 Mar 2004 19:34:57 +0100 [thread overview]
Message-ID: <s5hwu64fmb2.wl@alsa2.suse.de> (raw)
In-Reply-To: <20040301182224.M24955@flint.arm.linux.org.uk>
At Mon, 1 Mar 2004 18:22:24 +0000,
Russell King wrote:
>
> On Mon, Mar 01, 2004 at 06:51:56PM +0100, Takashi Iwai wrote:
> > a small concern about GFP_KERNEL is that i experienced the stall when
> > the kernel tried to allocate large continuous pages with GFP_KERNEL,
> > e.g. modprobe stops infinitely in the module init phase (and you
> > cannot even interrupt that process).
> >
> > does dma_alloc_coherent(GFP_KERNEL) with big pages work without stall?
>
> It depends where the stall was coming from. Do you have any further
> details?
first of alll, i have to mention that it happend in the time of 2.4
kernels. i've not tested with 2.6 kernels at all.
a typical case was es1968 driver, which allocates the all buffer pages
at the initialization. when __get_free_pages() for 256MB with
GFP_KERNEL is called, it goes to sleep and never gets back. since
the context is uninterruptible, modprobe stucks and doesn't accept
SIGKILL.
anyway, i need to this behavior again with the recent kernel.
> Also, on a similar note, I hope someone noticed one of the comments I
> added in the second patch:
>
> + *
> + * Really, we want to move this type of thing into dma_alloc_coherent()
> + * so dma_mask doesn't have to be messed with.
>
> (referring to the hack towards the top of memalloc.c.)
>
> This is something which really needs solving more cleanly.
yep!
> What I
> think you're trying to do is to allocate pages for devices whose
> DMA mask indicates (eg) 28 bit addressing is possible, but without
> the "ISA DMA" (<16MB) restriction? Could you confirm this?
yes, that's it.
> If this is correct, I suspect it may be something which is not
> limited to sound devices, and as such should probably be covered
> by the generic code (iow, dma_alloc_coherent.) However, that's
> going to require discussion with other several people.
i hope it, too. for example, this kind of large buffer allocation
might be needed for video devices, too.
> Currently, x86 dma_alloc_coherent() is:
>
> if (dev == NULL || (*dev->dma_mask < 0xffffffff))
> gfp |= GFP_DMA;
> ret = (void *)__get_free_pages(gfp, get_order(size));
>
> if (ret != NULL) {
> memset(ret, 0, size);
> *dma_handle = virt_to_phys(ret);
> }
> return ret;
>
> I'm thinking of something more like:
>
> order = get_order(size);
>
> mask = 16*1024*1024-1;
> if (dev)
> mask = dev->dma_mask;
>
> while (1) {
> ret = (void *)__get_free_pages(gfp, order);
>
> if (ret == NULL || gfp & GFP_DMA)
> break;
>
> handle = virt_to_phys(ret);
> if ((handle & ~mask) == 0) {
> memset(ret, 0, size);
> *dma_handle = handle;
> break;
> }
>
> free_pages((unsigned long)ret, order);
> gfp |= GFP_DMA;
> }
>
> return ret;
>
> Does that look reasonable? If so, I'll float the idea around x86
> people.
yes, it looks fine. thanks!
Takashi
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
next prev parent reply other threads:[~2004-03-01 18:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-29 22:38 [PATCH] 1/3 Implement generic device DMA mapping support Russell King
2004-02-29 22:42 ` [PATCH] 2/3 " Russell King
2004-02-29 22:43 ` [PATCH] 3/3 " Russell King
2004-03-01 15:41 ` [PATCH] 1/3 " Takashi Iwai
2004-03-01 15:38 ` Jaroslav Kysela
2004-03-01 17:45 ` Russell King
2004-03-01 17:51 ` Takashi Iwai
2004-03-01 18:22 ` Russell King
2004-03-01 18:34 ` Takashi Iwai [this message]
2004-03-01 18:44 ` Takashi Iwai
2004-03-02 15:23 ` Takashi Iwai
2004-03-02 14:09 ` Takashi Iwai
2004-03-02 14:26 ` Russell King
2004-03-02 14:38 ` Takashi Iwai
2004-03-02 14:55 ` Russell King
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=s5hwu64fmb2.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=perex@suse.cz \
--cc=rmk+alsa@arm.linux.org.uk \
/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