From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Arend van Spriel <arend@broadcom.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Hante Meuleman <meuleman@broadcom.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
brcm80211-dev-list <brcm80211-dev-list@broadcom.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Will Deacon <Will.Deacon@arm.com>,
David Miller <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: using DMA-API on ARM
Date: Fri, 5 Dec 2014 19:25:44 +0000 [thread overview]
Message-ID: <20141205192544.GY11285@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <548205DD.4080101@broadcom.com>
On Fri, Dec 05, 2014 at 08:22:05PM +0100, Arend van Spriel wrote:
> On 12/05/14 19:28, Catalin Marinas wrote:
> >This is solved by using a pre-allocated, pre-mapped atomic_pool which
> >avoids any further mapping. __dma_alloc() calls __alloc_from_pool() when
> >!__GFP_WAIT.
>
> So we are actually calling dma_alloc_coherent() with GFP_KERNEL during
> device probe. That last paragraph Russell pointed out seems to suggest this
> is not allowed.
device probe is a schedulable, sleepable context, so dma_alloc_coherent()
is fine there. As Catalin points out, and as I realised after sending
them ail, it does check for __GFP_WAIT and uses a smaller atomic pool
for those allocations. This explains why no one has hit any warnings in
map_vm_area.
So, it's safe from atomic contexts after all.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: using DMA-API on ARM
Date: Fri, 5 Dec 2014 19:25:44 +0000 [thread overview]
Message-ID: <20141205192544.GY11285@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <548205DD.4080101@broadcom.com>
On Fri, Dec 05, 2014 at 08:22:05PM +0100, Arend van Spriel wrote:
> On 12/05/14 19:28, Catalin Marinas wrote:
> >This is solved by using a pre-allocated, pre-mapped atomic_pool which
> >avoids any further mapping. __dma_alloc() calls __alloc_from_pool() when
> >!__GFP_WAIT.
>
> So we are actually calling dma_alloc_coherent() with GFP_KERNEL during
> device probe. That last paragraph Russell pointed out seems to suggest this
> is not allowed.
device probe is a schedulable, sleepable context, so dma_alloc_coherent()
is fine there. As Catalin points out, and as I realised after sending
them ail, it does check for __GFP_WAIT and uses a smaller atomic pool
for those allocations. This explains why no one has hit any warnings in
map_vm_area.
So, it's safe from atomic contexts after all.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2014-12-05 19:25 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 9:22 using DMA-API on ARM Arend van Spriel
2014-12-05 9:22 ` Arend van Spriel
2014-12-05 9:45 ` Russell King - ARM Linux
2014-12-05 9:45 ` Russell King - ARM Linux
2014-12-05 12:24 ` Will Deacon
2014-12-05 12:24 ` Will Deacon
2014-12-05 12:56 ` Hante Meuleman
2014-12-05 12:56 ` Hante Meuleman
2014-12-05 13:23 ` Russell King - ARM Linux
2014-12-05 13:23 ` Russell King - ARM Linux
2014-12-05 14:20 ` Hante Meuleman
2014-12-05 14:20 ` Hante Meuleman
2014-12-05 14:47 ` Arend van Spriel
2014-12-05 14:47 ` Arend van Spriel
2014-12-08 13:47 ` Hante Meuleman
2014-12-08 13:47 ` Hante Meuleman
2014-12-08 15:01 ` Arnd Bergmann
2014-12-08 15:01 ` Arnd Bergmann
2014-12-08 15:17 ` Russell King - ARM Linux
2014-12-08 15:17 ` Russell King - ARM Linux
2014-12-08 15:22 ` Arnd Bergmann
2014-12-08 15:22 ` Arnd Bergmann
2014-12-08 16:03 ` Catalin Marinas
2014-12-08 16:03 ` Catalin Marinas
2014-12-08 17:01 ` Arend van Spriel
2014-12-08 17:01 ` Arend van Spriel
2014-12-09 10:19 ` Arend van Spriel
2014-12-09 10:19 ` Arend van Spriel
2014-12-09 10:29 ` Russell King - ARM Linux
2014-12-09 10:29 ` Russell King - ARM Linux
2014-12-09 11:07 ` Arend van Spriel
2014-12-09 11:07 ` Arend van Spriel
2014-12-09 11:54 ` Catalin Marinas
2014-12-09 11:54 ` Catalin Marinas
2015-01-20 15:22 ` Fabio Estevam
2015-01-20 15:22 ` Fabio Estevam
2014-12-08 16:22 ` Arend van Spriel
2014-12-08 16:22 ` Arend van Spriel
2014-12-08 16:38 ` Arnd Bergmann
2014-12-08 16:38 ` Arnd Bergmann
2014-12-08 16:47 ` Russell King - ARM Linux
2014-12-08 16:47 ` Russell King - ARM Linux
2014-12-08 16:50 ` Catalin Marinas
2014-12-08 16:50 ` Catalin Marinas
2014-12-08 16:54 ` Russell King - ARM Linux
2014-12-08 16:54 ` Russell King - ARM Linux
2014-12-05 15:06 ` Russell King - ARM Linux
2014-12-05 15:06 ` Russell King - ARM Linux
2014-12-05 18:28 ` Catalin Marinas
2014-12-05 18:28 ` Catalin Marinas
2014-12-05 19:22 ` Arend van Spriel
2014-12-05 19:22 ` Arend van Spriel
2014-12-05 19:25 ` Russell King - ARM Linux [this message]
2014-12-05 19:25 ` Russell King - ARM Linux
2014-12-05 12:43 ` Arend van Spriel
2014-12-05 12:43 ` Arend van Spriel
2014-12-05 12:59 ` Russell King - ARM Linux
2014-12-05 12:59 ` Russell King - ARM Linux
2014-12-05 9:52 ` Arnd Bergmann
2014-12-05 9:52 ` Arnd Bergmann
2014-12-05 11:11 ` Russell King - ARM Linux
2014-12-05 11:11 ` Russell King - ARM Linux
2014-12-05 11:49 ` Hante Meuleman
2014-12-05 11:49 ` Hante Meuleman
2014-12-05 17:38 ` Catalin Marinas
2014-12-05 17:38 ` Catalin Marinas
2014-12-05 18:24 ` Russell King - ARM Linux
2014-12-05 18:24 ` Russell King - ARM Linux
2014-12-05 18:31 ` Catalin Marinas
2014-12-05 18:31 ` Catalin Marinas
2014-12-05 18:39 ` Catalin Marinas
2014-12-05 18:39 ` Catalin Marinas
2014-12-05 18:53 ` Catalin Marinas
2014-12-05 18:53 ` Catalin Marinas
2014-12-05 19:50 ` Arend van Spriel
2014-12-05 19:50 ` Arend van Spriel
2014-12-08 12:55 ` Johannes Stezenbach
2014-12-08 12:55 ` Johannes Stezenbach
2014-12-08 15:55 ` Catalin Marinas
2014-12-08 15:55 ` Catalin Marinas
2014-12-08 16:50 ` Johannes Stezenbach
2014-12-08 16:50 ` Johannes Stezenbach
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=20141205192544.GY11285@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=Will.Deacon@arm.com \
--cc=arend@broadcom.com \
--cc=brcm80211-dev-list@broadcom.com \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=meuleman@broadcom.com \
/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.