Hi Russell,
On Tue, Dec 9, 2014 at 8:29 AM, Russell King - ARM Linux
wrote:
> On Tue, Dec 09, 2014 at 11:19:40AM +0100, Arend van Spriel wrote:
>> The issue did not trigger overnight so it seems setting bit 22 > Attribute _Override_ Enable> solves the issue over here. Now the question is
>> how t
On Tue, Dec 09, 2014 at 10:29:05AM +, Russell King - ARM Linux wrote:
> On Tue, Dec 09, 2014 at 11:19:40AM +0100, Arend van Spriel wrote:
> > The issue did not trigger overnight so it seems setting bit 22 > Attribute _Override_ Enable> solves the issue over here. Now the question is
> > how to
On 12/09/14 11:29, Russell King - ARM Linux wrote:
On Tue, Dec 09, 2014 at 11:19:40AM +0100, Arend van Spriel wrote:
The issue did not trigger overnight so it seems setting bit 22 solves the issue over here. Now the question is
how to move forward with this. As I understood from Catalin this pa
On Tue, Dec 09, 2014 at 11:19:40AM +0100, Arend van Spriel wrote:
> The issue did not trigger overnight so it seems setting bit 22 Attribute _Override_ Enable> solves the issue over here. Now the question is
> how to move forward with this. As I understood from Catalin this patch was
> not include
On 12/08/14 18:01, Arend van Spriel wrote:
On 12/08/14 17:03, Catalin Marinas wrote:
On Mon, Dec 08, 2014 at 03:01:32PM +, Arnd Bergmann wrote:
[ 0.00] PL310 OF: cache setting yield illegal associativity
[ 0.00] PL310 OF: -1069781724 calculated, only 8 and 16 legal
[ 0.00] L2C-3
On 12/08/14 17:03, Catalin Marinas wrote:
On Mon, Dec 08, 2014 at 03:01:32PM +, Arnd Bergmann wrote:
[0.00] PL310 OF: cache setting yield illegal associativity
[0.00] PL310 OF: -1069781724 calculated, only 8 and 16 legal
[0.00] L2C-310 enabling early BRESP for Cortex-
On Mon, Dec 08, 2014 at 04:38:57PM +, Arnd Bergmann wrote:
> On Monday 08 December 2014 17:22:44 Arend van Spriel wrote:
> > >> The log: first the ring allocation info is printed. Starting at
> > >> 16.124847, ring 2, 3 and 4 are rings used for device to host. In this
> > >> log the failure is
On Mon, Dec 08, 2014 at 04:50:43PM +, Catalin Marinas wrote:
> On Mon, Dec 08, 2014 at 04:38:57PM +, Arnd Bergmann wrote:
> > On Monday 08 December 2014 17:22:44 Arend van Spriel wrote:
> > > >> The log: first the ring allocation info is printed. Starting at
> > > >> 16.124847, ring 2, 3 an
On Mon, Dec 08, 2014 at 03:55:57PM +, Catalin Marinas wrote:
> On Mon, Dec 08, 2014 at 12:55:38PM +, Johannes Stezenbach wrote:
> > On Fri, Dec 05, 2014 at 06:53:03PM +, Catalin Marinas wrote:
> > >
> > > BTW, if you really have a PL310-like L2 cache, have a look at some
> > > patches
On Mon, Dec 08, 2014 at 05:38:57PM +0100, Arnd Bergmann wrote:
> On Monday 08 December 2014 17:22:44 Arend van Spriel wrote:
> > >> The log: first the ring allocation info is printed. Starting at
> > >> 16.124847, ring 2, 3 and 4 are rings used for device to host. In this
> > >> log the failure is
On Monday 08 December 2014 17:22:44 Arend van Spriel wrote:
> >> The log: first the ring allocation info is printed. Starting at
> >> 16.124847, ring 2, 3 and 4 are rings used for device to host. In this
> >> log the failure is on a read of ring 3. Ring 3 is 1024 entries of each
> >> 16 bytes. The
On 12/08/14 16:01, Arnd Bergmann wrote:
On Monday 08 December 2014 13:47:38 Hante Meuleman wrote:
Still using outlook, but will limit the line length, I hope that works for the
moment. Attached is a log with the requested information, it is a little
bit non-standard though. The dump code from th
On Mon, Dec 08, 2014 at 03:01:32PM +, Arnd Bergmann wrote:
> [0.00] PL310 OF: cache setting yield illegal associativity
> [0.00] PL310 OF: -1069781724 calculated, only 8 and 16 legal
> [0.00] L2C-310 enabling early BRESP for Cortex-A9
> [0.00] L2C-310 full line o
On Mon, Dec 08, 2014 at 12:55:38PM +, Johannes Stezenbach wrote:
> On Fri, Dec 05, 2014 at 06:53:03PM +, Catalin Marinas wrote:
> > On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:
> > >
> > > Does your system have an L2 cache? What's the SoC topology, can PCIe see
> > > su
On Monday 08 December 2014 15:17:33 Russell King - ARM Linux wrote:
> On Mon, Dec 08, 2014 at 04:01:32PM +0100, Arnd Bergmann wrote:
> > In your log, I see this message:
> >
> > [0.00] PL310 OF: cache setting yield illegal associativity
> > [0.00] PL310 OF: -1069781724 calculated,
On Mon, Dec 08, 2014 at 04:01:32PM +0100, Arnd Bergmann wrote:
> In your log, I see this message:
>
> [0.00] PL310 OF: cache setting yield illegal associativity
> [0.00] PL310 OF: -1069781724 calculated, only 8 and 16 legal
> [0.00] L2C-310 enabling early BRESP for Cortex-A
On Monday 08 December 2014 13:47:38 Hante Meuleman wrote:
> Still using outlook, but will limit the line length, I hope that works for the
> moment. Attached is a log with the requested information, it is a little
> bit non-standard though. The dump code from the mm was copied in
> the driver and c
Still using outlook, but will limit the line length, I hope that works for the
moment. Attached is a log with the requested information, it is a little
bit non-standard though. The dump code from the mm was copied in
the driver and called from there, mapping the prints back to our local
printf, but
On Fri, Dec 05, 2014 at 06:53:03PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:
> >
> > 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
On 12/05/14 19:53, Catalin Marinas wrote:
On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:
On Fri, Dec 05, 2014 at 09:22:22AM +, Arend van Spriel wrote:
For our brcm80211 development we are working on getting brcmfmac driver
up and running on a Broadcom ARM-based platform. T
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
On 12/05/14 19:28, Catalin Marinas wrote:
On Fri, Dec 05, 2014 at 03:06:48PM +, Russell King - ARM Linux wrote:
I've been doing more digging into the current DMA code, and I'm dismayed
to see that there's new bugs in it...
commit 513510ddba9650fc7da456eefeb0ead7632324f6
Author: Laura Abbott
On Fri, Dec 05, 2014 at 06:39:45PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 09:22:22AM +, 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 dev
On Fri, Dec 05, 2014 at 09:22:22AM +, 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
On Fri, Dec 05, 2014 at 06:24:43PM +, Russell King - ARM Linux wrote:
> On Fri, Dec 05, 2014 at 05:38:39PM +, Catalin Marinas wrote:
> > On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> > > In any case, wouldn't using a u64 type for "address" be better - isn't
> >
On Fri, Dec 05, 2014 at 03:06:48PM +, Russell King - ARM Linux wrote:
> I've been doing more digging into the current DMA code, and I'm dismayed
> to see that there's new bugs in it...
>
> commit 513510ddba9650fc7da456eefeb0ead7632324f6
> Author: Laura Abbott
> Date: Thu Oct 9 15:26:40 2014
On Fri, Dec 05, 2014 at 05:38:39PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> > In any case, wouldn't using a u64 type for "address" be better - isn't
> > "long long" 128-bit on 64-bit architectures?
>
> No, it's still 64-bit. There
On Fri, Dec 05, 2014 at 11:11:14AM +, Russell King - ARM Linux wrote:
> In any case, wouldn't using a u64 type for "address" be better - isn't
> "long long" 128-bit on 64-bit architectures?
No, it's still 64-bit. There is no 128-bit integer in the C standard.
--
Catalin
--
To unsubscribe fro
I've been doing more digging into the current DMA code, and I'm dismayed
to see that there's new bugs in it...
commit 513510ddba9650fc7da456eefeb0ead7632324f6
Author: Laura Abbott
Date: Thu Oct 9 15:26:40 2014 -0700
common: dma-mapping: introduce common remapping functions
This uses map_v
vrijdag 5 december 2014 14:24
To: Hante Meuleman
Cc: Will Deacon; Arend Van Spriel; Marek Szyprowski;
linux-arm-ker...@lists.infradead.org; David Miller;
linux-kernel@vger.kernel.org; brcm80211-dev-list; linux-wireless
Subject: Re: using DMA-API on ARM
Please wrap your message - replying to a mes
e Meuleman
Cc: Will Deacon; Arend Van Spriel; Marek Szyprowski;
linux-arm-ker...@lists.infradead.org; David Miller;
linux-kernel@vger.kernel.org; brcm80211-dev-list; linux-wireless
Subject: Re: using DMA-API on ARM
Please wrap your message - replying to a message which looks like this in
my edi
Please wrap your message - replying to a message which looks like this in
my editor is far from easy, and gives me much more work to /manually/
reformat it before I can reply to it:
On Fri, Dec 05, 2014 at 12:56:45PM +, Hante Meuleman wrote:
> The problem is with data coming from device, so DM
On Fri, Dec 05, 2014 at 01:43:01PM +0100, Arend van Spriel wrote:
> Ok. You already had a peek in our code checking the memory barriers, which
> does not have the dma_sync_single_for_cpu() "workaround" yet. So here some
> more background. The problem is in DMA_FROM_DEVICE direction. Because of the
riginal Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: vrijdag 5 december 2014 13:24
To: Russell King - ARM Linux
Cc: Arend Van Spriel; Marek Szyprowski; linux-arm-ker...@lists.infradead.org;
David Miller; linux-kernel@vger.kernel.org; brcm80211-dev-list; linux-wireless
Subject: Re: u
On 05-12-14 10:45, Russell King - ARM Linux wrote:
On Fri, Dec 05, 2014 at 10:22:22AM +0100, 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 t
On Fri, Dec 05, 2014 at 09:45:08AM +, Russell King - ARM Linux wrote:
> On Fri, Dec 05, 2014 at 10:22:22AM +0100, 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
ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: vrijdag 5 december 2014 12:11
To: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org; Arend Van Spriel; linux-wireless;
brcm80211-dev-list; David Miller; linux-kernel@vger.kernel.org
Subject: Re: using DMA-API on ARM
On Fri, Dec 05, 2014 at 10:52:02AM
On Fri, Dec 05, 2014 at 10:52:02AM +0100, Arnd Bergmann wrote:
> I'm still puzzled why you'd need a single dma_sync_single_for_cpu()
> after dma_alloc_coherent though, you should not need any. Is it possible
> that the driver accidentally uses __raw_readl() instead of readl()
> in some places and y
On Friday 05 December 2014 10:22:22 Arend van Spriel wrote:
> Hi Russell,
>
> 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
> bri
On Fri, Dec 05, 2014 at 10:22:22AM +0100, 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
40 matches
Mail list logo
