All of lore.kernel.org
 help / color / mirror / Atom feed
From: thomas@koeller.dyndns.org (Thomas Koeller)
To: linux-arm-kernel@lists.infradead.org
Subject: DMA using data buffer vmapped in kernel space
Date: Thu, 4 Mar 2010 22:11:08 +0100	[thread overview]
Message-ID: <201003042211.28569.thomas@koeller.dyndns.org> (raw)

Hi,

I am writing a driver that loads a firmware blob into its device. The driver
calls request_firmware() and gets a struct firmware * that contains a
data buffer pointer in its 'data' member. The buffer is then passed to a
SPI driver to send it to the device.

The SPI driver uses DMA and, in preparation for that, eventually calls
dma_cache_maint() (contained in arch/arm/mm/dma-mapping.c). At this
point, the whole thing goes bad because there is a check:

	BUG_ON(!virt_addr_valid(start) || !virt_addr_valid(start + size - 1));

and the address obtained via request_firmware() fails this check.

The request_firmware() function creates the data buffer by allocating a
number of single pages in a loop, places them in an array, and finally
creates a kernel mapping by calling vmap(). The vmap() result is the
buffer address passed to the DMA.

I do not understand the purpose of the failing check. The virt_addr_valid()
macro checks whether its argument is below high_memory. But why would the
virtual address of a DMA data buffer matter at all? After all, the pages
are resident, so I cannot see any problem here. Can anybody explain?

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100304/11d54161/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Koeller <thomas@koeller.dyndns.org>
To: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: DMA using data buffer vmapped in kernel space
Date: Thu, 4 Mar 2010 22:11:08 +0100	[thread overview]
Message-ID: <201003042211.28569.thomas@koeller.dyndns.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Hi,

I am writing a driver that loads a firmware blob into its device. The driver
calls request_firmware() and gets a struct firmware * that contains a
data buffer pointer in its 'data' member. The buffer is then passed to a
SPI driver to send it to the device.

The SPI driver uses DMA and, in preparation for that, eventually calls
dma_cache_maint() (contained in arch/arm/mm/dma-mapping.c). At this
point, the whole thing goes bad because there is a check:

	BUG_ON(!virt_addr_valid(start) || !virt_addr_valid(start + size - 1));

and the address obtained via request_firmware() fails this check.

The request_firmware() function creates the data buffer by allocating a
number of single pages in a loop, places them in an array, and finally
creates a kernel mapping by calling vmap(). The vmap() result is the
buffer address passed to the DMA.

I do not understand the purpose of the failing check. The virt_addr_valid()
macro checks whether its argument is below high_memory. But why would the
virtual address of a DMA data buffer matter at all? After all, the pages
are resident, so I cannot see any problem here. Can anybody explain?

Thomas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

             reply	other threads:[~2010-03-04 21:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-04 21:11 Thomas Koeller [this message]
2010-03-04 21:11 ` DMA using data buffer vmapped in kernel space Thomas Koeller
2010-03-04 21:36 ` Russell King - ARM Linux
2010-03-04 21:36   ` Russell King - ARM Linux
2010-03-06 13:07   ` Thomas Koeller
2010-03-06 13:07     ` Thomas Koeller
2010-03-06 19:31     ` Russell King - ARM Linux
2010-03-06 19:31       ` Russell King - ARM Linux
2010-03-09  7:45       ` Lin Mac
2010-03-09  7:45         ` Lin Mac
2010-03-09  9:14         ` Russell King - ARM Linux
2010-03-09  9:14           ` Russell King - ARM Linux
2010-03-09  9:29           ` David Miller
2010-03-09  9:29             ` David Miller
2010-03-09 10:16             ` Russell King - ARM Linux
2010-03-09 10:16               ` Russell King - ARM Linux
2010-03-09 10:20               ` David Miller
2010-03-09 10:20                 ` David Miller

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=201003042211.28569.thomas@koeller.dyndns.org \
    --to=thomas@koeller.dyndns.org \
    --cc=linux-arm-kernel@lists.infradead.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.