From: Arend van Spriel <arend@broadcom.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>,
linux-wireless <linux-wireless@vger.kernel.org>,
"brcm80211-dev-list@broadcom.com"
<brcm80211-dev-list@broadcom.com>,
David Miller <davem@davemloft.net>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: using DMA-API on ARM
Date: Fri, 5 Dec 2014 20:50:56 +0100 [thread overview]
Message-ID: <54820CA0.6000600@broadcom.com> (raw)
In-Reply-To: <20141205185303.GG31222@e104818-lin.cambridge.arm.com>
On 12/05/14 19:53, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 06:39:45PM +0000, Catalin Marinas wrote:
>> On Fri, Dec 05, 2014 at 09:22:22AM +0000, Arend van Spriel wrote:
>>> For our brcm80211 development we are working on getting brcmfmac driver
>>> up and running on a Broadcom ARM-based platform. The wireless device is
>>> a PCIe device, which is hooked up to the system behind a PCIe host
>>> bridge, and we transfer information between host and device using a
>>> descriptor ring buffer allocated using dma_alloc_coherent(). We mostly
>>> tested on x86 and seen no issue. However, on this ARM platform
>>> (single-core A9) we detect occasionally that the descriptor content is
>>> invalid. When this occurs we do a dma_sync_single_for_cpu() and this is
>>> retried a number of times if the problem persists. Actually, found out
>>> that someone made a mistake by using virt_to_dma(va) to get the
>>> dma_handle parameter. So probably we only provided a delay in the retry
>>> loop. After fixing that a single call to dma_sync_single_for_cpu() is
>>> sufficient. The DMA-API-HOWTO clearly states that:
>>
>> Does your system have an L2 cache? What's the SoC topology, can PCIe see
>> such L2 cache (or snoop the L1 caches)?
>
> BTW, if you really have a PL310-like L2 cache, have a look at some
> patches (I've seen similar symptoms) and make sure your configuration is
> correct:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6395/1
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6529/1
>
> The first one is vexpress specific. The second one was eventually
> discarded by Russell (I don't remember the reason, I guess it's because
> SoC code is supposed to set the right bits in there anyway). In your
> case, such bits may be set up by firmware, so Linux cannot fix anything
> up.
I guess by firmware you mean to bootloader. This one boots with CFE
bootloader which Broadcom maintains itself so could look into that.
Regards,
Arend
WARNING: multiple messages have this Message-ID (diff)
From: arend@broadcom.com (Arend van Spriel)
To: linux-arm-kernel@lists.infradead.org
Subject: using DMA-API on ARM
Date: Fri, 5 Dec 2014 20:50:56 +0100 [thread overview]
Message-ID: <54820CA0.6000600@broadcom.com> (raw)
In-Reply-To: <20141205185303.GG31222@e104818-lin.cambridge.arm.com>
On 12/05/14 19:53, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 06:39:45PM +0000, Catalin Marinas wrote:
>> On Fri, Dec 05, 2014 at 09:22:22AM +0000, Arend van Spriel wrote:
>>> For our brcm80211 development we are working on getting brcmfmac driver
>>> up and running on a Broadcom ARM-based platform. The wireless device is
>>> a PCIe device, which is hooked up to the system behind a PCIe host
>>> bridge, and we transfer information between host and device using a
>>> descriptor ring buffer allocated using dma_alloc_coherent(). We mostly
>>> tested on x86 and seen no issue. However, on this ARM platform
>>> (single-core A9) we detect occasionally that the descriptor content is
>>> invalid. When this occurs we do a dma_sync_single_for_cpu() and this is
>>> retried a number of times if the problem persists. Actually, found out
>>> that someone made a mistake by using virt_to_dma(va) to get the
>>> dma_handle parameter. So probably we only provided a delay in the retry
>>> loop. After fixing that a single call to dma_sync_single_for_cpu() is
>>> sufficient. The DMA-API-HOWTO clearly states that:
>>
>> Does your system have an L2 cache? What's the SoC topology, can PCIe see
>> such L2 cache (or snoop the L1 caches)?
>
> BTW, if you really have a PL310-like L2 cache, have a look at some
> patches (I've seen similar symptoms) and make sure your configuration is
> correct:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6395/1
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6529/1
>
> The first one is vexpress specific. The second one was eventually
> discarded by Russell (I don't remember the reason, I guess it's because
> SoC code is supposed to set the right bits in there anyway). In your
> case, such bits may be set up by firmware, so Linux cannot fix anything
> up.
I guess by firmware you mean to bootloader. This one boots with CFE
bootloader which Broadcom maintains itself so could look into that.
Regards,
Arend
next prev parent reply other threads:[~2014-12-05 19:50 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
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 [this message]
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=54820CA0.6000600@broadcom.com \
--to=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=linux@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 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.