PowerPC PCI DMA issues (prefetch/coherency?)

PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Hello All,

We're developing on a Freescale MPC8272 and are having some nasty 
problems with PCI bus mastering and data corruption.

We have some custom hardware that is bus mastering, reading data from 
the CPUs memory for it's own use. Most of the time, the data is correct, 
however occasionally we are seeing data that appears to be from 
somewhere else in memory (usually memory that has already been read by 
the PCI device). The problem looks like stale data on the PCI bridge 
prefetch buffers or a cache coherency problem, but we've been unable to 
come up with a solution to our problem. It is my understanding that it 
shouldn't be a cache coherency problem as the CPU cache should be 
snooped as the data is read from memory. Even if it were an issue, the 
pci_map_sg* functions should have sorted out any cache coherency issues 
before the DMA operation started.

I've not been able to find anything on the Freescale data sheet that 
provides any way of flushing the prefetch cache on the PCI bridge. We've 
done a bit of experimenting, and found that turning off prefetch appears 
to solve (or possibly mask?) the problem (at the expensive of massive 
performance problems). I've also tried DMA'ing two adjacent userspace 
buffers in memory (from the same page), and see corruption on the second 
buffer. If I populate both buffers, then DMA them both, the data is 
fine. If I populate the first, DMA the first, then populate the second 
and DMA the second, corruption occurs at the start of the second buffer. 
If I add 8-32 bytes of padding between the buffers, the problem goes away.

The PCI spec says that the PCI bridge is supposed to flush any data from 
it's prefetch buffers that are not read by the bus master, so 
technically, this isn't supposed to happen.

I've tried making sure that buffers are cache line (and page) aligned, 
and are multiples of cache lines, but it's made no difference. PIO mode 
works fine, and I've checked the data with the CPU just before, and 
immediately after the DMA and the driver sees no data integrity issues. 
There are memory write barriers just before the DMA start, so all the 
registers should be correct before the DMA starts.

For background info, the device doing the bus mastering is a Xilinx 
Virtex 5 FPGA. We've monitored the data as it comes off the PCI bus 
using ChipScope - so the firmware should not be manipulating the data in 
any way.

We have some hardware/firmware/drivers that has a lot of common code 
that runs on an x86 platform (as opposed to powerpc), and that works 
without any issues whatsoever.

Has anyone got any ideas what this might be? Does anyone of know issues 
with PCI bridges on the PowerPC platform? Is there extra things that 
need to be done from the driver when DMAing on PowerPC (I've looked at 
other drivers and there's nothing obvious). The chip errata doesn't have 
anything on it that looks like it could cause this.

I'm really hoping this is something that we're doing wrong in the driver 
or the firmware, but we've been through both the firmware and drivers 
countless times and are unable to see anything wrong.

Any thoughts/ideas would be much appreciated!

Regards,
Chris

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Michael S. Zick]

On Tue June 16 2009, Chris Pringle wrote:
> Hello All,
> 
> We're developing on a Freescale MPC8272 and are having some nasty 
> problems with PCI bus mastering and data corruption.
> 
> We have some custom hardware that is bus mastering, reading data from 
> the CPUs memory for it's own use. Most of the time, the data is correct, 
> however occasionally we are seeing data that appears to be from 
> somewhere else in memory (usually memory that has already been read by 
> the PCI device). The problem looks like stale data on the PCI bridge 
> prefetch buffers or a cache coherency problem, but we've been unable to 
> come up with a solution to our problem. It is my understanding that it 
> shouldn't be a cache coherency problem as the CPU cache should be 
> snooped as the data is read from memory. Even if it were an issue, the 
> pci_map_sg* functions should have sorted out any cache coherency issues 
> before the DMA operation started.
> 
> I've not been able to find anything on the Freescale data sheet that 
> provides any way of flushing the prefetch cache on the PCI bridge. We've 
> done a bit of experimenting, and found that turning off prefetch appears 
> to solve (or possibly mask?) the problem (at the expensive of massive 
> performance problems). I've also tried DMA'ing two adjacent userspace 
> buffers in memory (from the same page), and see corruption on the second 
> buffer. If I populate both buffers, then DMA them both, the data is 
> fine. If I populate the first, DMA the first, then populate the second 
> and DMA the second, corruption occurs at the start of the second buffer. 
> If I add 8-32 bytes of padding between the buffers, the problem goes away.
> 
> The PCI spec says that the PCI bridge is supposed to flush any data from 
> it's prefetch buffers that are not read by the bus master, so 
> technically, this isn't supposed to happen.
> 
> I've tried making sure that buffers are cache line (and page) aligned, 
> and are multiples of cache lines, but it's made no difference. PIO mode 
> works fine, and I've checked the data with the CPU just before, and 
> immediately after the DMA and the driver sees no data integrity issues. 
> There are memory write barriers just before the DMA start, so all the 
> registers should be correct before the DMA starts.
> 
> For background info, the device doing the bus mastering is a Xilinx 
> Virtex 5 FPGA. We've monitored the data as it comes off the PCI bus 
> using ChipScope - so the firmware should not be manipulating the data in 
> any way.
> 
> We have some hardware/firmware/drivers that has a lot of common code 
> that runs on an x86 platform (as opposed to powerpc), and that works 
> without any issues whatsoever.
> 
> Has anyone got any ideas what this might be? Does anyone of know issues 
> with PCI bridges on the PowerPC platform? Is there extra things that 
> need to be done from the driver when DMAing on PowerPC (I've looked at 
> other drivers and there's nothing obvious). The chip errata doesn't have 
> anything on it that looks like it could cause this.
> 
> I'm really hoping this is something that we're doing wrong in the driver 
> or the firmware, but we've been through both the firmware and drivers 
> countless times and are unable to see anything wrong.
> 
> Any thoughts/ideas would be much appreciated!
> 

Did you actually check the load image for proper alignment?
Like in:

gen2-32 compressed # objdump -x vmlinux.bin
- - - - -
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
- - - - -
 21 .data.page_aligned 00001800  c068a000  0068a000  0058b000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
 22 .data.cacheline_aligned 000026c0  c068b800  0068b800  0058c800  2**6
                  CONTENTS, ALLOC, LOAD, DATA
 23 .data.read_mostly 00001e98  c068dec0  0068dec0  0058eec0  2**6
                  CONTENTS, ALLOC, LOAD, DATA

= = = =

I had to make this change to the x86 loader script to get alignment for VIA:

diff --git a/arch/x86/kernel/vmlinux_32.lds.S b/arch/x86/kernel/vmlinux_32.lds.S
index 62ad500..26f68a5 100644
--- a/arch/x86/kernel/vmlinux_32.lds.S
+++ b/arch/x86/kernel/vmlinux_32.lds.S
@@ -82,7 +82,7 @@ SECTIONS
        *(.data.idt)
   }

-  . = ALIGN(32);
+  . = ALIGN(L1_CACHE_BYTES);
   .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
        *(.data.cacheline_aligned)
   }

= = = =

Eyeball your loader script if you haven't already done so.

Mike
> Regards,
> Chris
> 

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Hu Gang]

On Tue, 16 Jun 2009 14:58:27 +0100
Chris Pringle <chris.pringle@oxtel.com> wrote:

> Hello All,
> 
> We're developing on a Freescale MPC8272 and are having some nasty 
> problems with PCI bus mastering and data corruption.
> 
> We have some custom hardware that is bus mastering, reading data from 
> the CPUs memory for it's own use. Most of the time, the data is correct, 
> however occasionally we are seeing data that appears to be from 
> somewhere else in memory (usually memory that has already been read by 
> the PCI device). The problem looks like stale data on the PCI bridge 
> prefetch buffers or a cache coherency problem, but we've been unable to 
> come up with a solution to our problem. It is my understanding that it 
> shouldn't be a cache coherency problem as the CPU cache should be 
> snooped as the data is read from memory. Even if it were an issue, the 
> pci_map_sg* functions should have sorted out any cache coherency issues 
> before the DMA operation started.
> 
> I've not been able to find anything on the Freescale data sheet that 
> provides any way of flushing the prefetch cache on the PCI bridge. We've 
> done a bit of experimenting, and found that turning off prefetch appears 
> to solve (or possibly mask?) the problem (at the expensive of massive 
> performance problems). I've also tried DMA'ing two adjacent userspace 
> buffers in memory (from the same page), and see corruption on the second 
> buffer. If I populate both buffers, then DMA them both, the data is 
> fine. If I populate the first, DMA the first, then populate the second 
> and DMA the second, corruption occurs at the start of the second buffer. 
> If I add 8-32 bytes of padding between the buffers, the problem goes away.
> 
> The PCI spec says that the PCI bridge is supposed to flush any data from 
> it's prefetch buffers that are not read by the bus master, so 
> technically, this isn't supposed to happen.
> 
> I've tried making sure that buffers are cache line (and page) aligned, 
> and are multiples of cache lines, but it's made no difference. PIO mode 
> works fine, and I've checked the data with the CPU just before, and 
> immediately after the DMA and the driver sees no data integrity issues. 
> There are memory write barriers just before the DMA start, so all the 
> registers should be correct before the DMA starts.
> 
> For background info, the device doing the bus mastering is a Xilinx 
> Virtex 5 FPGA. We've monitored the data as it comes off the PCI bus 
> using ChipScope - so the firmware should not be manipulating the data in 
> any way.
> 
> We have some hardware/firmware/drivers that has a lot of common code 
> that runs on an x86 platform (as opposed to powerpc), and that works 
> without any issues whatsoever.
> 
> Has anyone got any ideas what this might be? Does anyone of know issues 
> with PCI bridges on the PowerPC platform? Is there extra things that 
> need to be done from the driver when DMAing on PowerPC (I've looked at 
> other drivers and there's nothing obvious). The chip errata doesn't have 
> anything on it that looks like it could cause this.
> 
> I'm really hoping this is something that we're doing wrong in the driver 
> or the firmware, but we've been through both the firmware and drivers 
> countless times and are unable to see anything wrong.
> 
> Any thoughts/ideas would be much appreciated!
> 
> Regards,
> Chris

Can you try allocate the data buffer using dma_alloc_coherent, that can making
the data coherency.

I got the similar issues in the arm cpu with a dma device base on spartan3, using
the dma_alloc_coherent making it works well.

hope this help. 

thanks.
-- 
steve

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

On Tue, Jun 16, 2009 at 02:58:27PM +0100, Chris Pringle wrote:
> We're developing on a Freescale MPC8272 and are having some nasty  
> problems with PCI bus mastering and data corruption.

What kernel version?  What firmware?  Custom board, or one in upstream
(which one)?

> We have some custom hardware that is bus mastering, reading data from  
> the CPUs memory for it's own use. Most of the time, the data is correct,  
> however occasionally we are seeing data that appears to be from  
> somewhere else in memory (usually memory that has already been read by  
> the PCI device). The problem looks like stale data on the PCI bridge  
> prefetch buffers or a cache coherency problem, but we've been unable to  
> come up with a solution to our problem. It is my understanding that it  
> shouldn't be a cache coherency problem as the CPU cache should be  
> snooped as the data is read from memory. Even if it were an issue, the  
> pci_map_sg* functions should have sorted out any cache coherency issues  
> before the DMA operation started.

Cache coherency on PCI DMA requires that the memory be mapped with the M
attribute on this chip, but that should be happening based on detection of
the core.

Also make sure that you park the bus on PCI and raise its arbitration
priority, as done at the end of fixup_pci in arch/powerpc/boot/cuboot-pq2.c.

BTW, you may want to post to linuxppc-dev@lists.ozlabs.org for
powerpc-specific issues, especially this kind of hardware issue.

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Scott Wood wrote:
> On Tue, Jun 16, 2009 at 02:58:27PM +0100, Chris Pringle wrote:
>   
>> We're developing on a Freescale MPC8272 and are having some nasty  
>> problems with PCI bus mastering and data corruption.
>>     
>
> What kernel version?  What firmware?  Custom board, or one in upstream
> (which one)?
>   
The kernel version is 2.6.26. Firmware is custom on a custom board.
> Cache coherency on PCI DMA requires that the memory be mapped with the M
> attribute on this chip, but that should be happening based on detection of
> the core.
>   
I'm not sure where to look to verify this?
> Also make sure that you park the bus on PCI and raise its arbitration
> priority, as done at the end of fixup_pci in arch/powerpc/boot/cuboot-pq2.c.
>   
Since this is a reasonably recent kernel, I'd guess that both of these 
things are correct. I've had a quick look in that file and there is code 
in there raising arbitartion priority and parking the bus.
> BTW, you may want to post to linuxppc-dev@lists.ozlabs.org for
> powerpc-specific issues, especially this kind of hardware issue.
>
>   
I've just posted there :-)

Interestingly, I've just turned off cache snooping and the problem has 
got much worse. This has surprised me as I thought that part of the job 
done by pci_map_sg was to flush the CPU cache - so I wasn't expecting 
this to make any difference. The memory corruption with the cache 
snooping turned off is almost identical to that which I'm seeing with it 
turned on, only much, much worse.


-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Chris Pringle wrote:
> The kernel version is 2.6.26. Firmware is custom on a custom board.
>> Cache coherency on PCI DMA requires that the memory be mapped with the M
>> attribute on this chip, but that should be happening based on 
>> detection of
>> the core.
>>   
> I'm not sure where to look to verify this?

Check asm/cputable.h for CPU_FTR_NEED_COHERENT.  Make sure that 
CONFIG_8260 is one of the #ifdefs that turns that on.  It looks like 
that was in place by 2.6.26 in arch/powerpc.  I'm not sure what to look 
for in arch/ppc.

>> Also make sure that you park the bus on PCI and raise its arbitration
>> priority, as done at the end of fixup_pci in 
>> arch/powerpc/boot/cuboot-pq2.c.
>>   
> Since this is a reasonably recent kernel,

Not really, there was a fair amount of 82xx work in the mid-2.6.20s. 
The addition of CPU_FTR_NEED_COHERENT to 82xx was somewhere in that time.

Can you try 2.6.30?

> I'd guess that both of these 
> things are correct. I've had a quick look in that file and there is code 
> in there raising arbitartion priority and parking the bus.

Just because the code is there doesn't mean you're using it -- are you 
using cuImage?  Are you using arch/ppc or arch/powerpc?

Typically this would be done by firmware; it's only in cuboot because 
u-boot wasn't doing it.

>> BTW, you may want to post to linuxppc-dev@lists.ozlabs.org for
>> powerpc-specific issues, especially this kind of hardware issue.
>>
>>   
> I've just posted there :-)

Doh, sorry. :-)

> Interestingly, I've just turned off cache snooping and the problem has 
> got much worse. This has surprised me as I thought that part of the job 
> done by pci_map_sg was to flush the CPU cache

It only flushes the cache on hardware that doesn't do coherent DMA.

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Chris Pringle wrote:
> The kernel version is 2.6.26. Firmware is custom on a custom board.
>> Cache coherency on PCI DMA requires that the memory be mapped with the M
>> attribute on this chip, but that should be happening based on 
>> detection of
>> the core.
>>   
> I'm not sure where to look to verify this?

Check asm/cputable.h for CPU_FTR_NEED_COHERENT.  Make sure that 
CONFIG_8260 is one of the #ifdefs that turns that on.  It looks like 
that was in place by 2.6.26 in arch/powerpc.  I'm not sure what to look 
for in arch/ppc.

>> Also make sure that you park the bus on PCI and raise its arbitration
>> priority, as done at the end of fixup_pci in 
>> arch/powerpc/boot/cuboot-pq2.c.
>>   
> Since this is a reasonably recent kernel,

Not really, there was a fair amount of 82xx work in the mid-2.6.20s. 
The addition of CPU_FTR_NEED_COHERENT to 82xx was somewhere in that time.

Can you try 2.6.30?

> I'd guess that both of these 
> things are correct. I've had a quick look in that file and there is code 
> in there raising arbitartion priority and parking the bus.

Just because the code is there doesn't mean you're using it -- are you 
using cuImage?  Are you using arch/ppc or arch/powerpc?

Typically this would be done by firmware; it's only in cuboot because 
u-boot wasn't doing it.

>> BTW, you may want to post to linuxppc-dev@lists.ozlabs.org for
>> powerpc-specific issues, especially this kind of hardware issue.
>>
>>   
> I've just posted there :-)

Doh, sorry. :-)

> Interestingly, I've just turned off cache snooping and the problem has 
> got much worse. This has surprised me as I thought that part of the job 
> done by pci_map_sg was to flush the CPU cache

It only flushes the cache on hardware that doesn't do coherent DMA.

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Scott Wood wrote:
>
> Check asm/cputable.h for CPU_FTR_NEED_COHERENT.  Make sure that 
> CONFIG_8260 is one of the #ifdefs that turns that on.  It looks like 
> that was in place by 2.6.26 in arch/powerpc.  I'm not sure what to 
> look for in arch/ppc.
I've just checked that and it's definitely switched on in CPU_FTR_COMMON 
(CONFIG_8260 is also being used).
>
>>> Also make sure that you park the bus on PCI and raise its arbitration
>>> priority, as done at the end of fixup_pci in 
>>> arch/powerpc/boot/cuboot-pq2.c.
>>>   
>> Since this is a reasonably recent kernel,
>
> Not really, there was a fair amount of 82xx work in the mid-2.6.20s. 
> The addition of CPU_FTR_NEED_COHERENT to 82xx was somewhere in that time.
>
> Can you try 2.6.30?
I'll give it a try, but that won't be a quick thing to do - will 
hopefully manage to get that done tomorrow if it patches without too 
many issues. I should point out that we've got the low latency patches 
on this kernel too; I guess it'd be worth trying it without them before 
I move kernels.
>
>> I'd guess that both of these things are correct. I've had a quick 
>> look in that file and there is code in there raising arbitartion 
>> priority and parking the bus.
>
> Just because the code is there doesn't mean you're using it -- are you 
> using cuImage?  Are you using arch/ppc or arch/powerpc?
>
> Typically this would be done by firmware; it's only in cuboot because 
> u-boot wasn't doing it.
Just checked this is being called and it is. We're using arch/powerpc.
>
>
>> Interestingly, I've just turned off cache snooping and the problem 
>> has got much worse. This has surprised me as I thought that part of 
>> the job done by pci_map_sg was to flush the CPU cache
>
> It only flushes the cache on hardware that doesn't do coherent DMA.
>
Ah right - that would explain what we're seeing then... Doh. Thought I 
might have been onto something then. Is there any way to force a cache 
flush? That'd at least prove it was a caching issue if it resolved the 
problem.

Thanks,
Chris

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Scott Wood wrote:
>
> Check asm/cputable.h for CPU_FTR_NEED_COHERENT.  Make sure that 
> CONFIG_8260 is one of the #ifdefs that turns that on.  It looks like 
> that was in place by 2.6.26 in arch/powerpc.  I'm not sure what to 
> look for in arch/ppc.
I've just checked that and it's definitely switched on in CPU_FTR_COMMON 
(CONFIG_8260 is also being used).
>
>>> Also make sure that you park the bus on PCI and raise its arbitration
>>> priority, as done at the end of fixup_pci in 
>>> arch/powerpc/boot/cuboot-pq2.c.
>>>   
>> Since this is a reasonably recent kernel,
>
> Not really, there was a fair amount of 82xx work in the mid-2.6.20s. 
> The addition of CPU_FTR_NEED_COHERENT to 82xx was somewhere in that time.
>
> Can you try 2.6.30?
I'll give it a try, but that won't be a quick thing to do - will 
hopefully manage to get that done tomorrow if it patches without too 
many issues. I should point out that we've got the low latency patches 
on this kernel too; I guess it'd be worth trying it without them before 
I move kernels.
>
>> I'd guess that both of these things are correct. I've had a quick 
>> look in that file and there is code in there raising arbitartion 
>> priority and parking the bus.
>
> Just because the code is there doesn't mean you're using it -- are you 
> using cuImage?  Are you using arch/ppc or arch/powerpc?
>
> Typically this would be done by firmware; it's only in cuboot because 
> u-boot wasn't doing it.
Just checked this is being called and it is. We're using arch/powerpc.
>
>
>> Interestingly, I've just turned off cache snooping and the problem 
>> has got much worse. This has surprised me as I thought that part of 
>> the job done by pci_map_sg was to flush the CPU cache
>
> It only flushes the cache on hardware that doesn't do coherent DMA.
>
Ah right - that would explain what we're seeing then... Doh. Thought I 
might have been onto something then. Is there any way to force a cache 
flush? That'd at least prove it was a caching issue if it resolved the 
problem.

Thanks,
Chris

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Chris Pringle wrote:
> Ah right - that would explain what we're seeing then... Doh. Thought I 
> might have been onto something then. Is there any way to force a cache 
> flush? That'd at least prove it was a caching issue if it resolved the 
> problem.

You could enable CONFIG_NOT_COHERENT_CACHE.

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Chris Pringle wrote:
> Ah right - that would explain what we're seeing then... Doh. Thought I 
> might have been onto something then. Is there any way to force a cache 
> flush? That'd at least prove it was a caching issue if it resolved the 
> problem.

You could enable CONFIG_NOT_COHERENT_CACHE.

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Arnd Bergmann]

On Tuesday 16 June 2009, Scott Wood wrote:
> Chris Pringle wrote:
> > Ah right - that would explain what we're seeing then... Doh. Thought I 
> > might have been onto something then. Is there any way to force a cache 
> > flush? That'd at least prove it was a caching issue if it resolved the 
> > problem.
> 
> You could enable CONFIG_NOT_COHERENT_CACHE.

If the whole system is noncoherent, that is the right solution. If the
device is the only one, you can also use dma_alloc_noncoherent() and
flush explicitly with dma_cache_sync().

	Arnd <><

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Arnd Bergmann wrote:
> On Tuesday 16 June 2009, Scott Wood wrote:
>> Chris Pringle wrote:
>>> Ah right - that would explain what we're seeing then... Doh. Thought I 
>>> might have been onto something then. Is there any way to force a cache 
>>> flush? That'd at least prove it was a caching issue if it resolved the 
>>> problem.
>> You could enable CONFIG_NOT_COHERENT_CACHE.
> 
> If the whole system is noncoherent, that is the right solution.

I meant it more as a test than a permanent solution...

> If the
> device is the only one, you can also use dma_alloc_noncoherent() and
> flush explicitly with dma_cache_sync().

I don't see how that would help -- aren't those also controlled by 
CONFIG_NOT_COHERENT_CACHE?

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Scott Wood]

Arnd Bergmann wrote:
> On Tuesday 16 June 2009, Scott Wood wrote:
>> Chris Pringle wrote:
>>> Ah right - that would explain what we're seeing then... Doh. Thought I 
>>> might have been onto something then. Is there any way to force a cache 
>>> flush? That'd at least prove it was a caching issue if it resolved the 
>>> problem.
>> You could enable CONFIG_NOT_COHERENT_CACHE.
> 
> If the whole system is noncoherent, that is the right solution.

I meant it more as a test than a permanent solution...

> If the
> device is the only one, you can also use dma_alloc_noncoherent() and
> flush explicitly with dma_cache_sync().

I don't see how that would help -- aren't those also controlled by 
CONFIG_NOT_COHERENT_CACHE?

-Scott

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Arnd Bergmann]

On Tuesday 16 June 2009, Scott Wood wrote:
> > If the
> > device is the only one, you can also use dma_alloc_noncoherent() and
> > flush explicitly with dma_cache_sync().
> 
> I don't see how that would help -- aren't those also controlled by 
> CONFIG_NOT_COHERENT_CACHE?

Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).

Actually there seems to be a bug in here: Since dma_alloc_noncoherent
gives you a coherent mapping (or NULL) on noncoherent machines,
dma_cache_sync() is redundant and should not actually flush the
cache, or we should change dma_alloc_noncoherent to do a simple
alloc_pages on CONFIG_NON_COHERENT_CACHE and leave dma_cache_sync()
as it is.

	Arnd <><

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Arnd Bergmann]

On Tuesday 16 June 2009, Scott Wood wrote:
> > If the
> > device is the only one, you can also use dma_alloc_noncoherent() and
> > flush explicitly with dma_cache_sync().
> 
> I don't see how that would help -- aren't those also controlled by 
> CONFIG_NOT_COHERENT_CACHE?

Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).

Actually there seems to be a bug in here: Since dma_alloc_noncoherent
gives you a coherent mapping (or NULL) on noncoherent machines,
dma_cache_sync() is redundant and should not actually flush the
cache, or we should change dma_alloc_noncoherent to do a simple
alloc_pages on CONFIG_NON_COHERENT_CACHE and leave dma_cache_sync()
as it is.

	Arnd <><

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
> On Tuesday 16 June 2009, Scott Wood wrote:
> > > If the
> > > device is the only one, you can also use dma_alloc_noncoherent() and
> > > flush explicitly with dma_cache_sync().
> > 
> > I don't see how that would help -- aren't those also controlled by 
> > CONFIG_NOT_COHERENT_CACHE?
> 
> Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
> dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).

But we still need to sync the result of dma_map_* when used multiple
times for a single mapping.

Cheers,
Ben.

> Actually there seems to be a bug in here: Since dma_alloc_noncoherent
> gives you a coherent mapping (or NULL) on noncoherent machines,
> dma_cache_sync() is redundant and should not actually flush the
> cache, or we should change dma_alloc_noncoherent to do a simple
> alloc_pages on CONFIG_NON_COHERENT_CACHE and leave dma_cache_sync()
> as it is.
> 
> 	Arnd <><
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[FUJITA Tomonori]

On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
> > On Tuesday 16 June 2009, Scott Wood wrote:
> > > > If the
> > > > device is the only one, you can also use dma_alloc_noncoherent() and
> > > > flush explicitly with dma_cache_sync().
> > > 
> > > I don't see how that would help -- aren't those also controlled by 
> > > CONFIG_NOT_COHERENT_CACHE?
> > 
> > Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
> > dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).
> 
> But we still need to sync the result of dma_map_* when used multiple
> times for a single mapping.

We have dma_sync_{single|sg}_for_{cpu|device} API for the above
purpose.

dma_cache_sync is supposed to be used only with the buffers that
dma_alloc_noncoherent() returns. On architecutures that maps
dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
supposed to be NOP.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[FUJITA Tomonori]

On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
> > On Tuesday 16 June 2009, Scott Wood wrote:
> > > > If the
> > > > device is the only one, you can also use dma_alloc_noncoherent() and
> > > > flush explicitly with dma_cache_sync().
> > > 
> > > I don't see how that would help -- aren't those also controlled by 
> > > CONFIG_NOT_COHERENT_CACHE?
> > 
> > Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
> > dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).
> 
> But we still need to sync the result of dma_map_* when used multiple
> times for a single mapping.

We have dma_sync_{single|sg}_for_{cpu|device} API for the above
purpose.

dma_cache_sync is supposed to be used only with the buffers that
dma_alloc_noncoherent() returns. On architecutures that maps
dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
supposed to be NOP.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Leon Woestenberg]

Hello all,

On Wed, Jun 17, 2009 at 2:37 AM, FUJITA
Tomonori<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Wed, 17 Jun 2009 10:18:45 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
>> > On Tuesday 16 June 2009, Scott Wood wrote:
>> > > > If the
>> > > > device is the only one, you can also use dma_alloc_noncoherent() and
>> > > > flush explicitly with dma_cache_sync().
>> > >
>> > > I don't see how that would help -- aren't those also controlled by
>> > > CONFIG_NOT_COHERENT_CACHE?
>> >
>> > Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
>> > dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).
>>
>> But we still need to sync the result of dma_map_* when used multiple
>> times for a single mapping.
>
> We have dma_sync_{single|sg}_for_{cpu|device} API for the above
> purpose.
>
> dma_cache_sync is supposed to be used only with the buffers that
> dma_alloc_noncoherent() returns. On architecutures that maps
> dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
> supposed to be NOP.

This discussion raised some doubt with me about my use case:

I my case (note I am not the poster) I am using (what LDD3 calls)
streaming mappings:

I use pci_map_sg(), have the device perform either DMA master reads or
writes to the bus address using PCIe.
After that, I use pci_unmap_sg().

My assumption is that pci_unmap_sg() either makes the cache coherent
or invalidated and thus I do not need to take further actions.
This is on a MPC83xx or 85xx system.

Is this assumption correct?

Regards,

Leon/

-- 
Leon

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Leon Woestenberg]

Hello all,

On Wed, Jun 17, 2009 at 2:37 AM, FUJITA
Tomonori<fujita.tomonori@lab.ntt.co.jp> wrote:
> On Wed, 17 Jun 2009 10:18:45 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
>> > On Tuesday 16 June 2009, Scott Wood wrote:
>> > > > If the
>> > > > device is the only one, you can also use dma_alloc_noncoherent() and
>> > > > flush explicitly with dma_cache_sync().
>> > >
>> > > I don't see how that would help -- aren't those also controlled by
>> > > CONFIG_NOT_COHERENT_CACHE?
>> >
>> > Ah, yes you are right. PowerPC implements dma_alloc_noncoherent as
>> > dma_alloc_coherent, so dma_cache_sync() is actually a NOP (or should be).
>>
>> But we still need to sync the result of dma_map_* when used multiple
>> times for a single mapping.
>
> We have dma_sync_{single|sg}_for_{cpu|device} API for the above
> purpose.
>
> dma_cache_sync is supposed to be used only with the buffers that
> dma_alloc_noncoherent() returns. On architecutures that maps
> dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
> supposed to be NOP.

This discussion raised some doubt with me about my use case:

I my case (note I am not the poster) I am using (what LDD3 calls)
streaming mappings:

I use pci_map_sg(), have the device perform either DMA master reads or
writes to the bus address using PCIe.
After that, I use pci_unmap_sg().

My assumption is that pci_unmap_sg() either makes the cache coherent
or invalidated and thus I do not need to take further actions.
This is on a MPC83xx or 85xx system.

Is this assumption correct?

Regards,

Leon/

-- 
Leon

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-06-17 at 09:37 +0900, FUJITA Tomonori wrote:
> 
> dma_cache_sync is supposed to be used only with the buffers that
> dma_alloc_noncoherent() returns. On architecutures that maps
> dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
> supposed to be NOP.
> 
Or at least a sync() on powerpc but yeah, I see. We should probably do
that.

Cheers,
Ben.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-06-17 at 09:37 +0900, FUJITA Tomonori wrote:
> 
> dma_cache_sync is supposed to be used only with the buffers that
> dma_alloc_noncoherent() returns. On architecutures that maps
> dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
> supposed to be NOP.
> 
Or at least a sync() on powerpc but yeah, I see. We should probably do
that.

Cheers,
Ben.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
> I use pci_map_sg(), have the device perform either DMA master reads or
> writes to the bus address using PCIe.
> After that, I use pci_unmap_sg().
> 
> My assumption is that pci_unmap_sg() either makes the cache coherent
> or invalidated and thus I do not need to take further actions.
> This is on a MPC83xx or 85xx system.
> 
> Is this assumption correct?

It is, as far as I understand things :-) Those APIs are fun.

You should only need the explicit sync calls if you are going to peek or
poke at the DMA mapped memory before you unmap it.

Cheers,
Ben.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
> I use pci_map_sg(), have the device perform either DMA master reads or
> writes to the bus address using PCIe.
> After that, I use pci_unmap_sg().
> 
> My assumption is that pci_unmap_sg() either makes the cache coherent
> or invalidated and thus I do not need to take further actions.
> This is on a MPC83xx or 85xx system.
> 
> Is this assumption correct?

It is, as far as I understand things :-) Those APIs are fun.

You should only need the explicit sync calls if you are going to peek or
poke at the DMA mapped memory before you unmap it.

Cheers,
Ben.

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Leon Woestenberg]

Hello Benjamin,

On Wed, Jun 17, 2009 at 3:08 AM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
>> I use pci_map_sg(), have the device perform either DMA master reads or
>> writes to the bus address using PCIe.
>> After that, I use pci_unmap_sg().
>>
>> My assumption is that pci_unmap_sg() either makes the cache coherent
>> or invalidated and thus I do not need to take further actions.
>> This is on a MPC83xx or 85xx system.
>>
>> Is this assumption correct?
>
> It is, as far as I understand things :-) Those APIs are fun.
>
> You should only need the explicit sync calls if you are going to peek or
> poke at the DMA mapped memory before you unmap it.
>
Thanks, then at least I understand things in the corr^H^H^H^Hsame way :-)

And btw, I hadn't seen any data mismatch yet.

Regards,
-- 
Leon 'likewise' Woestenberg

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Leon Woestenberg]

Hello Benjamin,

On Wed, Jun 17, 2009 at 3:08 AM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
>> I use pci_map_sg(), have the device perform either DMA master reads or
>> writes to the bus address using PCIe.
>> After that, I use pci_unmap_sg().
>>
>> My assumption is that pci_unmap_sg() either makes the cache coherent
>> or invalidated and thus I do not need to take further actions.
>> This is on a MPC83xx or 85xx system.
>>
>> Is this assumption correct?
>
> It is, as far as I understand things :-) Those APIs are fun.
>
> You should only need the explicit sync calls if you are going to peek or
> poke at the DMA mapped memory before you unmap it.
>
Thanks, then at least I understand things in the corr^H^H^H^Hsame way :-)

And btw, I hadn't seen any data mismatch yet.

Regards,
-- 
Leon 'likewise' Woestenberg

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

> You could enable CONFIG_NOT_COHERENT_CACHE.
>
I've just tried this (I had to edit Kconfig in power/platforms to make 
the build system accept it), and interestingly it's making no 
difference. I'm using streaming mappings, and are using the pci_map_sg 
functions to ensure the memory is mapped/flushed correctly. I've also 
explicitly put in a pci_dma_sync_sg_for_device, however that's also not 
made any difference. Turning the cpu cache snoop off has the same affect 
as it did without CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any 
other ideas?

Will back off the low latency patches next, and give 2.6.30 a try - see 
if that makes any difference.

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

> You could enable CONFIG_NOT_COHERENT_CACHE.
>
I've just tried this (I had to edit Kconfig in power/platforms to make 
the build system accept it), and interestingly it's making no 
difference. I'm using streaming mappings, and are using the pci_map_sg 
functions to ensure the memory is mapped/flushed correctly. I've also 
explicitly put in a pci_dma_sync_sg_for_device, however that's also not 
made any difference. Turning the cpu cache snoop off has the same affect 
as it did without CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any 
other ideas?

Will back off the low latency patches next, and give 2.6.30 a try - see 
if that makes any difference.

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Chris Pringle wrote:
>> You could enable CONFIG_NOT_COHERENT_CACHE.
>>
> I've just tried this (I had to edit Kconfig in power/platforms to make 
> the build system accept it), and interestingly it's making no 
> difference. I'm using streaming mappings, and are using the pci_map_sg 
> functions to ensure the memory is mapped/flushed correctly. I've also 
> explicitly put in a pci_dma_sync_sg_for_device, however that's also 
> not made any difference. Turning the cpu cache snoop off has the same 
> affect as it did without CONFIG_NOT_COHERENT_CACHE; it gets much 
> worse. Any other ideas?
>
> Will back off the low latency patches next, and give 2.6.30 a try - 
> see if that makes any difference.
>
Low latency patches made no difference. Tried it with 2.6.30 and it now 
works. There are a couple of commits contributing to the fix, including 
one introduced between 2.6.29-rc8 and 2.6.29 proper in 
powerpc/kernel/head_32.S (couple of commits with the name "Fix Respect 
_PAGE_COHERENT on classic ppc32 SW TLB load machines"). I've tried 
backporting this to 2.6.29-rc8 and it then worked. Backporting to 2.6.26 
made no difference however, so I suspect there are other things fixed 
which are also contributing.

I'm going to move to 2.6.29/2.6.30 which should resolve our issue.

Thanks to all who have contributed to this thread.

Chris

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Chris Pringle wrote:
> Chris Pringle wrote:
>>> You could enable CONFIG_NOT_COHERENT_CACHE.
>>>
>> I've just tried this (I had to edit Kconfig in power/platforms to 
>> make the build system accept it), and interestingly it's making no 
>> difference. I'm using streaming mappings, and are using the 
>> pci_map_sg functions to ensure the memory is mapped/flushed 
>> correctly. I've also explicitly put in a pci_dma_sync_sg_for_device, 
>> however that's also not made any difference. Turning the cpu cache 
>> snoop off has the same affect as it did without 
>> CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any other ideas?
>>
>> Will back off the low latency patches next, and give 2.6.30 a try - 
>> see if that makes any difference.
>>
> Low latency patches made no difference. Tried it with 2.6.30 and it 
> now works. There are a couple of commits contributing to the fix, 
> including one introduced between 2.6.29-rc8 and 2.6.29 proper in 
> powerpc/kernel/head_32.S (couple of commits with the name "Fix Respect 
> _PAGE_COHERENT on classic ppc32 SW TLB load machines"). I've tried 
> backporting this to 2.6.29-rc8 and it then worked. Backporting to 
> 2.6.26 made no difference however, so I suspect there are other things 
> fixed which are also contributing.
>
> I'm going to move to 2.6.29/2.6.30 which should resolve our issue.
>
> Thanks to all who have contributed to this thread.
>
The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE 
needs _PAGE_COHERENT in order to work correctly, and in fact there is 
now a comment in there to that affect in 2.6.29. Backporting that change 
has made it work on 2.6.26. Both this patch, and the fix to head_32.S 
are needed for it to work correctly on older kernels.

Chris

-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Sergej.Stepanov]

>The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE
>needs _PAGE_COHERENT in order to work correctly, and in fact there is
>now a comment in there to that affect in 2.6.29. Backporting that change
>has made it work on 2.6.26. Both this patch, and the fix to head_32.S
>are needed for it to work correctly on older kernels.
>
>Chris

Hello Chris,

sorry for dummy, but if it possible, could you, please, send a corresponding summary patch of backporting you've done for older kernels?
or just summary of that changes once again?

Many thanks

Sergej.

AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Sergej.Stepanov]

>The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE
>needs _PAGE_COHERENT in order to work correctly, and in fact there is
>now a comment in there to that affect in 2.6.29. Backporting that change
>has made it work on 2.6.26. Both this patch, and the fix to head_32.S
>are needed for it to work correctly on older kernels.
>
>Chris

Hello Chris,

sorry for dummy, but if it possible, could you, please, send a correspondin=
g summary patch of backporting you've done for older kernels?
or just summary of that changes once again?

Many thanks

Sergej.=

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

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

Hi Sergej,

I've attached the patch used to fix this issue. Both the patch to 
pgtable32.h and head_32.S are required in order to make it work. The 
change to pgtable32.h ensures that all pages are marked cache coherent 
(results in setting the M bit). The change to head_32.S ensures that the 
M bit is not unconditionally masked out - it should only be masked out 
if CPU_FTR_NEED_COHERENT is not set.

Hope this helps.

Cheers,
Chris

Sergej.Stepanov@ids.de wrote:
>> The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE
>> needs _PAGE_COHERENT in order to work correctly, and in fact there is
>> now a comment in there to that affect in 2.6.29. Backporting that change
>> has made it work on 2.6.26. Both this patch, and the fix to head_32.S
>> are needed for it to work correctly on older kernels.
>>
>> Chris
>>     
>
> Hello Chris,
>
> sorry for dummy, but if it possible, could you, please, send a corresponding summary patch of backporting you've done for older kernels?
> or just summary of that changes once again?
>
> Many thanks
>
> Sergej.


-- 

______________________________
Chris Pringle
Software Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com


____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

[-- Attachment #2: dma-cache-coherency-fix.patch --]
[-- Type: text/x-patch, Size: 2590 bytes --]

diff -r -U3 ./arch/powerpc/kernel/head_32.S ../../kernel.WORKS/linux-2.6.26/arch/powerpc/kernel/head_32.S
--- ./arch/powerpc/kernel/head_32.S	2008-07-13 22:51:29.000000000 +0100
+++ ../../kernel.WORKS/linux-2.6.26/arch/powerpc/kernel/head_32.S	2009-06-17 18:18:04.000000000 +0100
@@ -501,8 +501,11 @@
 	and	r1,r1,r2		/* writable if _RW and _DIRTY */
 	rlwimi	r3,r3,32-1,30,30	/* _PAGE_USER -> PP msb */
 	rlwimi	r3,r3,32-1,31,31	/* _PAGE_USER -> PP lsb */
-	ori	r1,r1,0xe14		/* clear out reserved bits and M */
+	ori	r1,r1,0xe04		/* clear out reserved bits */
 	andc	r1,r3,r1		/* PP = user? (rw&dirty? 2: 3): 0 */
+BEGIN_FTR_SECTION
+	rlwinm	r1,r1,0,~_PAGE_COHERENT	/* clear M (coherence not required) */
+END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
 	mtspr	SPRN_RPA,r1
 	mfspr	r3,SPRN_IMISS
 	tlbli	r3
@@ -575,8 +578,12 @@
 	and	r1,r1,r2		/* writable if _RW and _DIRTY */
 	rlwimi	r3,r3,32-1,30,30	/* _PAGE_USER -> PP msb */
 	rlwimi	r3,r3,32-1,31,31	/* _PAGE_USER -> PP lsb */
-	ori	r1,r1,0xe14		/* clear out reserved bits and M */
+	ori	r1,r1,0xe04		/* clear out reserved bits */
 	andc	r1,r3,r1		/* PP = user? (rw&dirty? 2: 3): 0 */
+BEGIN_FTR_SECTION
+	rlwinm	r1,r1,0,~_PAGE_COHERENT	/* clear M (coherence not required) */
+END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
+    /*ori     r1,r1,0x10*/
 	mtspr	SPRN_RPA,r1
 	mfspr	r3,SPRN_DMISS
 	tlbld	r3
@@ -643,8 +650,12 @@
 	stw	r3,0(r2)		/* update PTE (accessed/dirty bits) */
 	/* Convert linux-style PTE to low word of PPC-style PTE */
 	rlwimi	r3,r3,32-1,30,30	/* _PAGE_USER -> PP msb */
-	li	r1,0xe15		/* clear out reserved bits and M */
+	li	r1,0xe05		/* clear out reserved bits & PP lsb */
 	andc	r1,r3,r1		/* PP = user? 2: 0 */
+BEGIN_FTR_SECTION
+	rlwinm	r1,r1,0,~_PAGE_COHERENT	/* clear M (coherence not required) */
+END_FTR_SECTION_IFCLR(CPU_FTR_NEED_COHERENT)
+    /*ori     r1,r1,0x10*/
 	mtspr	SPRN_RPA,r1
 	mfspr	r3,SPRN_DMISS
 	tlbld	r3
diff -r -U3 ./include/asm-powerpc/pgtable-ppc32.h ../../kernel.WORKS/linux-2.6.26/include/asm-powerpc/pgtable-ppc32.h
--- ./include/asm-powerpc/pgtable-ppc32.h	2008-07-13 22:51:29.000000000 +0100
+++ ../../kernel.WORKS/linux-2.6.26/include/asm-powerpc/pgtable-ppc32.h	2009-06-18 12:11:57.000000000 +0100
@@ -408,7 +408,7 @@
 #ifdef CONFIG_44x
 #define _PAGE_BASE	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
 #else
-#define _PAGE_BASE	(_PAGE_PRESENT | _PAGE_ACCESSED)
+#define _PAGE_BASE	(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT)
 #endif
 #define _PAGE_WRENABLE	(_PAGE_RW | _PAGE_DIRTY | _PAGE_HWWRITE)
 #define _PAGE_KERNEL	(_PAGE_BASE | _PAGE_SHARED | _PAGE_WRENABLE)

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Prodyut Hazarika]

> I tried, using our JTAG debugger (BDI3000), to pause operation after=20
> calling dma_alloc_coherent to examine the TLB entry for the memory=20
> returned by the call (which was just past=20
> CONFIG_CONSISTENT_START=3D0xff100000).  The TLB list loaded at the =
time=20
> that I paused operation did not show a mapping for this area.  I guess

> the kernel swaps TLB entries on the fly so it isn't limited to only 64

> entries?  I will try to sleep in the same context as the=20
> dma_alloc_coherent call to try to catch the TLB entry while loaded to=20
> see if it has the I bit set.

> If that fails, any ideas?

Sleeping won't cause the entry to appear at the TLB.
After the dma_alloc call, try to deference the pointer returned.
As a result of the dereference, a DataTLB Miss will happen which will
result in
the appropriate entry put in TLB.
Then do a JTAG break right after the dereference, and you should be able
to see the TLB entry.

Thanks
Prodyut



Mikhail Zolotaryov wrote:
> Hi Tom,
>
> possible solution could be to use tasklet to perform DMA-related job=20
> (as in most cases DMA transfer is interrupt driven - makes sense).
>
>
> Tom Burns wrote:
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling=20
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from=20
>> __dma_sync().  This OOPses on PPC440 since it tries to call directly=20
>> the assembly instruction dcbi, which can only be executed in=20
>> supervisor mode.  We tried that before resorting to manual cache line

>> management with usermode-safe assembly calls.
>>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>> Hi,
>>>
>>> Why manage cache lines  manually, if appropriate code is a part of=20
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies=20
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>> Hi Adam,
>>>>
>>>> =20
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our=20
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>    =20
>>>> (using
>>>> =20
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
timing)
>>>>> end up being partially corrupted when we try to parse the data in
the
>>>>> virtual page. We have confirmed the data is good before the
PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>    =20
>>>> memory
>>>> =20
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of
16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>    =20
>>>> buffer
>>>> =20
>>>>> was used.    =20
>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region

>>>> has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines
appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example
on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>> =20
>>>>> Hi Adam,
>>>>>
>>>>> =20
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>      =20
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>    =20
>>>> board)
>>>> =20
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.=20
>>>>> 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is=20
>>>>> L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the
L2C
>>>>> entry.
>>>>>         L2C0: l2c {
>>>>>               ...
>>>>>         }
>>>>>
>>>>> =20
>>>>>> I am seeing this problem with our custom IDE driver which is=20
>>>>>> based on
>>>>>>      =20
>>>>
>>>> =20
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to
allocate
>>>>>>      =20
>>>> the
>>>> =20
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page.

>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.=20
>>>>>> Perhaps I should convert these to the DMA API calls as you
suggest.
>>>>>>      =20
>>>>> Could you give more details on the consistency problem? It is a
good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt

>>>>> wrote:
>>>>> =20
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>   =20
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the
following
>>>>>>>        =20
>>>>> section:
>>>>> =20
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>        =20
>>>>> _PAGE_GUARDED)
>>>>> =20
>>>>>>> #else
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see
if
>>>>>>>        =20
>>>>> that =20
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>        =20
>>>>> which =20
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to
check
>>>>>>>        =20
>>>>> the =20
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>        =20
>>>>> masked =20
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the
cache
>>>>>>>        =20
>>>>
>>>> =20
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>        =20
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>      =20
>>>> AFAIK,
>>>> =20
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>      =20
>>>>> isn't
>>>>> =20
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to
make
>>>>>>      =20
>>>>> sure
>>>>> =20
>>>>>> they use the appropriate DMA APIs which will do cache flushing
when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>      =20
>>>
>>>
>>
>>
>
>
--------------------------------------------------------

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains =
information that is confidential and proprietary to AppliedMicro =
Corporation or its subsidiaries. It is to be used solely for the purpose =
of furthering the parties' business relationship. All unauthorized =
review, use, disclosure or distribution is prohibited. If you are not =
the intended recipient, please contact the sender by reply e-mail and =
destroy all copies of the original message.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Tom Burns]

Hi Ben,

Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 09:43 -0400, Tom Burns wrote:
>   
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling 
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().  
>> This OOPses on PPC440 since it tries to call directly the assembly 
>> instruction dcbi, which can only be executed in supervisor mode.  We 
>> tried that before resorting to manual cache line management with 
>> usermode-safe assembly calls.
>>     
>
> Wait a minute.... usermode ? You are doing all of that from userspace ?
> I don't understand the story here. You can't call all those kernel APIs
> form userspace in the first place, indeed... But then an IDE driver has
> nothing to do in userspace neither.
>   
Sorry, I was referring to whether or not the CPU is in supervisor mode. 
Our code is all in the kernel, not userspace :).  I can see now from the 
value of MSR at the time of the OOPS that the processor was in 
supervisor mode, I missed that earlier.  Looks like you're right about 
the bad address, I will investigate.

Thanks,
Tom

> Cheers,
> Ben.
>
>   
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>     
>>> Hi,
>>>
>>> Why manage cache lines  manually, if appropriate code is a part of 
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>       
>>>> Hi Adam,
>>>>
>>>>  
>>>>         
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>     
>>>>>           
>>>> (using
>>>>  
>>>>         
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>     
>>>>>           
>>>> memory
>>>>  
>>>>         
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>     
>>>>>           
>>>> buffer
>>>>  
>>>>         
>>>>> was used.     
>>>>>           
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>  
>>>>         
>>>>> Hi Adam,
>>>>>
>>>>>    
>>>>>           
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>       
>>>>>>             
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>     
>>>>>           
>>>> board)
>>>>  
>>>>         
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>>         L2C0: l2c {
>>>>>               ...
>>>>>         }
>>>>>
>>>>>    
>>>>>           
>>>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>>>       
>>>>>>             
>>>>  
>>>>         
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>       
>>>>>>             
>>>> the
>>>>  
>>>>         
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>       
>>>>>>             
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut   
>>>>>
>>>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>>>    
>>>>>           
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>      
>>>>>>             
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>         
>>>>>>>               
>>>>> section:
>>>>>    
>>>>>           
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>         
>>>>>>>               
>>>>> _PAGE_GUARDED)
>>>>>    
>>>>>           
>>>>>>> #else
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>         
>>>>>>>               
>>>>> that    
>>>>>           
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>         
>>>>>>>               
>>>>> which    
>>>>>           
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>         
>>>>>>>               
>>>>> the    
>>>>>           
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>         
>>>>>>>               
>>>>> masked    
>>>>>           
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>         
>>>>>>>               
>>>>  
>>>>         
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>         
>>>>>>>               
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>       
>>>>>>             
>>>> AFAIK,
>>>>  
>>>>         
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>       
>>>>>>             
>>>>> isn't
>>>>>    
>>>>>           
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>       
>>>>>>             
>>>>> sure
>>>>>    
>>>>>           
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>       
>>>>>>             
>>>       
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>     
>
>
>
>   

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Pravin Bathija]

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

Benjamin Herrenschmidt wrote:
> Do you know many drivers that do config space accesses without using
> the config space accessors ?

> Such drivers should be banned to oblivion.

> Cheers,
> Ben.

I'm not aware of such drivers in the 2.6.30+ kernel.
 
Thanks,
Pravin

On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
>




[-- Attachment #2: Type: text/html, Size: 1544 bytes --]

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Fri, 2009-09-11 at 10:17 +0300, Mikhail Zolotaryov wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
> >   
> >> Hi Tom,
> >>
> >> In my case __dma_sync() calls flush_dcache_range() (it's due to 
> >> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of 
> >> dcbi - that's the difference as dcbf is not privileged.
> >>     
> >
> > What it calls depends on the direction of the transfer.

> Would not agree with you in this point as __dma_sync() code is:

Well, it -does- depend on the direction of the transfer... and -also- on
the size & alignement :-)

Anyway, that is probably not the problem. From the log I've seen, it
just looks like a page fault due to a bad virtual address passed there.

Cheers,
Ben.

>         case DMA_FROM_DEVICE:
>                 /*
>                  * invalidate only when cache-line aligned otherwise 
> there is
>                  * the potential for discarding uncommitted data from 
> the cache
>                  */
>                 if ((start & (L1_CACHE_BYTES - 1)) || (size & 
> (L1_CACHE_BYTES - 1)))
>                         flush_dcache_range(start, end);
>                 else
>                         invalidate_dcache_range(start, end);
>                 break;
> 
> So, actual instruction used depends on address/size alignment.
> 
> >  The tasklet runs
> > in priviledged mode, dcbi should work just fine... if passed a correct
> > address :-)
> >
> > Cheers,
> > Ben.
> >
> >   
> >> Tom Burns wrote:
> >>     
> >>> Hi Mikhail,
> >>>
> >>> Sorry, this DMA code is in a tasklet.  Are you suggesting the 
> >>> processor is in supervisor mode at that time?  Calling 
> >>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates 
> >>> the OOPS.  The entire oops is as follows, if it's relevant:
> >>>
> >>> Oops: kernel access of bad area, sig: 11 [#1]
> >>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> >>> REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
> >>> MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
> >>> DEAR: 3fd39000, ESR: 00800000
> >>> TASK = de5db7d0[157] 'cat' THREAD: df116000
> >>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> >>> 0079a169
> >>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> >>> 10177000
> >>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> >>> e11f59cc
> >>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> >>> 87d39009
> >>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> >>> LR [c0010c30] __dma_sync+0x58/0xac
> >>> Call Trace:
> >>> [df117c80] [0000000a] 0xa (unreliable)
> >>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> >>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> >>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> >>> [df117d10] [c00067a8] do_softirq+0x54/0x58
> >>> [df117d20] [c001edb4] irq_exit+0x48/0x58
> >>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> >>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> >>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> >>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> >>> [df117ec0] [c00171ac] mmput+0x50/0xd4
> >>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> >>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> >>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> >>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> >>> Instruction dump:
> >>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> >>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> >>> 7c0004ac
> >>> Kernel panic - not syncing: Aiee, killing interrupt handler!
> >>> Rebooting in 180 seconds..
> >>>
> >>>
> >>> Cheers,
> >>> Tom
> >>>
> >>> Mikhail Zolotaryov wrote:
> >>>       
> >>>> Hi Tom,
> >>>>
> >>>> possible solution could be to use tasklet to perform DMA-related job 
> >>>> (as in most cases DMA transfer is interrupt driven - makes sense).
> >>>>
> >>>>
> >>>> Tom Burns wrote:
> >>>>         
> >>>>> Hi,
> >>>>>
> >>>>> With the default config for the Sequoia board on 2.6.24, calling 
> >>>>> pci_dma_sync_sg_for_cpu() results in executing
> >>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
> >>>>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
> >>>>> the assembly instruction dcbi, which can only be executed in 
> >>>>> supervisor mode.  We tried that before resorting to manual cache 
> >>>>> line management with usermode-safe assembly calls.
> >>>>>
> >>>>> Regards,
> >>>>> Tom Burns
> >>>>> International Datacasting Corporation
> >>>>>
> >>>>> Mikhail Zolotaryov wrote:
> >>>>>           
> >>>>>> Hi,
> >>>>>>
> >>>>>> Why manage cache lines  manually, if appropriate code is a part of 
> >>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> >>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>>>>
> >>>>>> Prodyut Hazarika wrote:
> >>>>>>             
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
> >>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>>>>     
> >>>>>>>>                 
> >>>>>>> (using
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on 
> >>>>>>>> timing)
> >>>>>>>> end up being partially corrupted when we try to parse the data in 
> >>>>>>>> the
> >>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>>>>     
> >>>>>>>>                 
> >>>>>>> memory
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>>>>> corrupted, we see a random portion of it (always a multiple of 
> >>>>>>>> 16byte
> >>>>>>>> cache lines) is overwritten with old data from the last time the
> >>>>>>>>     
> >>>>>>>>                 
> >>>>>>> buffer
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> was used.     
> >>>>>>>>                 
> >>>>>>> This looks like a cache coherency problem.
> >>>>>>> Can you ensure that the TLB entries corresponding to the DMA 
> >>>>>>> region has
> >>>>>>> the CacheInhibit bit set.
> >>>>>>> You will need a BDI connected to your system.
> >>>>>>>
> >>>>>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>>>>> since in 440 cores,
> >>>>>>> L1Cache coherency is managed entirely by software.
> >>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for 
> >>>>>>> example on
> >>>>>>> how to do it.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Prodyut
> >>>>>>>
> >>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>>>>     
> >>>>>>>>                 
> >>>>>>> board)
> >>>>>>>  
> >>>>>>>               
> >>>>>>>> have L2Cache.
> >>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
> >>>>>>>> 440EPx
> >>>>>>>> has a 440 cpu core, but no L2Cache.
> >>>>>>>> Could you please tell me which SoC you are using?
> >>>>>>>> You can also refer to the appropriate dts file to see if there is 
> >>>>>>>> L2C.
> >>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>>>>> entry.
> >>>>>>>>         L2C0: l2c {
> >>>>>>>>               ...
> >>>>>>>>         }
> >>>>>>>>
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>> I am seeing this problem with our custom IDE driver which is 
> >>>>>>>>> based on
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>>  
> >>>>>>>               
> >>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>> the
> >>>>>>>  
> >>>>>>>               
> >>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual 
> >>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather 
> >>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as 
> >>>>>>>>> you suggest.
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>>> Could you give more details on the consistency problem? It is a good
> >>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() 
> >>>>>>>> should
> >>>>>>>> work too
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin 
> >>>>>>>> Herrenschmidt wrote:
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>>>>   
> >>>>>>>>>                   
> >>>>>>>>>> Hi Adam,
> >>>>>>>>>>
> >>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> section:
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>>> #ifdef CONFIG_44x
> >>>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> _PAGE_GUARDED)
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>>> #else
> >>>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>>>>> #endif
> >>>>>>>>>>
> >>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> that 
> >>>>>>>>                 
> >>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> which 
> >>>>>>>>                 
> >>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> the 
> >>>>>>>>                 
> >>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>> masked 
> >>>>>>>>                 
> >>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>  
> >>>>>>>               
> >>>>>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>>>>         
> >>>>>>>>>>                     
> >>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>> AFAIK,
> >>>>>>>  
> >>>>>>>               
> >>>>>>>>> the 440 core just ignores M.
> >>>>>>>>>
> >>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>>> isn't
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>> enabled or not working ?
> >>>>>>>>>
> >>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>>> sure
> >>>>>>>>  
> >>>>>>>>                 
> >>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>>>>> needed.
> >>>>>>>>>
> >>>>>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ben.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       
> >>>>>>>>>                   
> >>>>>>             
> >>>>>           
> >>>>         
> >>>       
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev@lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>     
> >
> >   

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Mikhail Zolotaryov]

Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
>   
>> Hi Tom,
>>
>> In my case __dma_sync() calls flush_dcache_range() (it's due to 
>> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of 
>> dcbi - that's the difference as dcbf is not privileged.
>>     
>
> What it calls depends on the direction of the transfer.
Would not agree with you in this point as __dma_sync() code is:

        case DMA_FROM_DEVICE:
                /*
                 * invalidate only when cache-line aligned otherwise 
there is
                 * the potential for discarding uncommitted data from 
the cache
                 */
                if ((start & (L1_CACHE_BYTES - 1)) || (size & 
(L1_CACHE_BYTES - 1)))
                        flush_dcache_range(start, end);
                else
                        invalidate_dcache_range(start, end);
                break;

So, actual instruction used depends on address/size alignment.

>  The tasklet runs
> in priviledged mode, dcbi should work just fine... if passed a correct
> address :-)
>
> Cheers,
> Ben.
>
>   
>> Tom Burns wrote:
>>     
>>> Hi Mikhail,
>>>
>>> Sorry, this DMA code is in a tasklet.  Are you suggesting the 
>>> processor is in supervisor mode at that time?  Calling 
>>> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates 
>>> the OOPS.  The entire oops is as follows, if it's relevant:
>>>
>>> Oops: kernel access of bad area, sig: 11 [#1]
>>> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
>>> REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
>>> MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
>>> DEAR: 3fd39000, ESR: 00800000
>>> TASK = de5db7d0[157] 'cat' THREAD: df116000
>>> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
>>> 0079a169
>>> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
>>> 10177000
>>> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
>>> e11f59cc
>>> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
>>> 87d39009
>>> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
>>> LR [c0010c30] __dma_sync+0x58/0xac
>>> Call Trace:
>>> [df117c80] [0000000a] 0xa (unreliable)
>>> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
>>> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
>>> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
>>> [df117d10] [c00067a8] do_softirq+0x54/0x58
>>> [df117d20] [c001edb4] irq_exit+0x48/0x58
>>> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
>>> [df117d40] [c00020e0] ret_from_except+0x0/0x18
>>> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
>>> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
>>> [df117ec0] [c00171ac] mmput+0x50/0xd4
>>> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
>>> [df117ef0] [c001c818] do_exit+0x134/0x6f8
>>> [df117f30] [c001ce14] do_group_exit+0x38/0x74
>>> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
>>> Instruction dump:
>>> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
>>> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
>>> 7c0004ac
>>> Kernel panic - not syncing: Aiee, killing interrupt handler!
>>> Rebooting in 180 seconds..
>>>
>>>
>>> Cheers,
>>> Tom
>>>
>>> Mikhail Zolotaryov wrote:
>>>       
>>>> Hi Tom,
>>>>
>>>> possible solution could be to use tasklet to perform DMA-related job 
>>>> (as in most cases DMA transfer is interrupt driven - makes sense).
>>>>
>>>>
>>>> Tom Burns wrote:
>>>>         
>>>>> Hi,
>>>>>
>>>>> With the default config for the Sequoia board on 2.6.24, calling 
>>>>> pci_dma_sync_sg_for_cpu() results in executing
>>>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
>>>>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
>>>>> the assembly instruction dcbi, which can only be executed in 
>>>>> supervisor mode.  We tried that before resorting to manual cache 
>>>>> line management with usermode-safe assembly calls.
>>>>>
>>>>> Regards,
>>>>> Tom Burns
>>>>> International Datacasting Corporation
>>>>>
>>>>> Mikhail Zolotaryov wrote:
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> Why manage cache lines  manually, if appropriate code is a part of 
>>>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>>>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>>>>
>>>>>> Prodyut Hazarika wrote:
>>>>>>             
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>>  
>>>>>>>               
>>>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>>>>     
>>>>>>>>                 
>>>>>>> (using
>>>>>>>  
>>>>>>>               
>>>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on 
>>>>>>>> timing)
>>>>>>>> end up being partially corrupted when we try to parse the data in 
>>>>>>>> the
>>>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>>>>     
>>>>>>>>                 
>>>>>>> memory
>>>>>>>  
>>>>>>>               
>>>>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>>>>> corrupted, we see a random portion of it (always a multiple of 
>>>>>>>> 16byte
>>>>>>>> cache lines) is overwritten with old data from the last time the
>>>>>>>>     
>>>>>>>>                 
>>>>>>> buffer
>>>>>>>  
>>>>>>>               
>>>>>>>> was used.     
>>>>>>>>                 
>>>>>>> This looks like a cache coherency problem.
>>>>>>> Can you ensure that the TLB entries corresponding to the DMA 
>>>>>>> region has
>>>>>>> the CacheInhibit bit set.
>>>>>>> You will need a BDI connected to your system.
>>>>>>>
>>>>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>>>>> since in 440 cores,
>>>>>>> L1Cache coherency is managed entirely by software.
>>>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for 
>>>>>>> example on
>>>>>>> how to do it.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Prodyut
>>>>>>>
>>>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>>>>  
>>>>>>>               
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>>>>     
>>>>>>>>                 
>>>>>>> board)
>>>>>>>  
>>>>>>>               
>>>>>>>> have L2Cache.
>>>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
>>>>>>>> 440EPx
>>>>>>>> has a 440 cpu core, but no L2Cache.
>>>>>>>> Could you please tell me which SoC you are using?
>>>>>>>> You can also refer to the appropriate dts file to see if there is 
>>>>>>>> L2C.
>>>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>>>>> entry.
>>>>>>>>         L2C0: l2c {
>>>>>>>>               ...
>>>>>>>>         }
>>>>>>>>
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> I am seeing this problem with our custom IDE driver which is 
>>>>>>>>> based on
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>>  
>>>>>>>               
>>>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>> the
>>>>>>>  
>>>>>>>               
>>>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual 
>>>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather 
>>>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as 
>>>>>>>>> you suggest.
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>>> Could you give more details on the consistency problem? It is a good
>>>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() 
>>>>>>>> should
>>>>>>>> work too
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin 
>>>>>>>> Herrenschmidt wrote:
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>>>>   
>>>>>>>>>                   
>>>>>>>>>> Hi Adam,
>>>>>>>>>>
>>>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> section:
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>>> #ifdef CONFIG_44x
>>>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> _PAGE_GUARDED)
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>>> #else
>>>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>>>>> #endif
>>>>>>>>>>
>>>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> that 
>>>>>>>>                 
>>>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> which 
>>>>>>>>                 
>>>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> the 
>>>>>>>>                 
>>>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>> masked 
>>>>>>>>                 
>>>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>  
>>>>>>>               
>>>>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>>>>         
>>>>>>>>>>                     
>>>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>> AFAIK,
>>>>>>>  
>>>>>>>               
>>>>>>>>> the 440 core just ignores M.
>>>>>>>>>
>>>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>>> isn't
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> enabled or not working ?
>>>>>>>>>
>>>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>>> sure
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>>>>> needed.
>>>>>>>>>
>>>>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ben.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       
>>>>>>>>>                   
>>>>>>             
>>>>>           
>>>>         
>>>       
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>     
>
>   

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Thu, 2009-09-10 at 22:35 -0700, Pravin Bathija wrote:
> Thanks Stefan. The whole intention of the patch/hack (or whatever one
> might call it :) ) was to avoid rogue drivers from setting
> pci_cache_line_size to non-zero value even though the underlying
> hardware doesn't support MRM calls. Nonetheless this approach works
> only if the drivers use the kernel API for PCI config space access
> provided by the powerpc platform driver.
> 
Do you know many drivers that do config space accesses without using
the config space accessors ?

Such drivers should be banned to oblivion.

Cheers,
Ben.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Pravin Bathija]

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

> Stefan Roese wrote:
> Correct. IIRC, some PATA driver as Pravin already mentioned.
 
> Cheers,
> Stefan

Thanks Stefan. The whole intention of the patch/hack (or whatever one might call it :) ) was to avoid rogue drivers from setting pci_cache_line_size to non-zero value even though the underlying hardware doesn't support MRM calls. Nonetheless this approach works only if the drivers use the kernel API for PCI config space access provided by the powerpc platform driver.

Regards,
Pravin


On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
> 
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...




[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Stefan Roese]

On Friday 11 September 2009 07:17:50 Benjamin Herrenschmidt wrote:
> On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> > It's already there. See commit:
> >
> > 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> >
> > powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
> 
> Ok, that's another way to do it. Will catch nasty drivers who
> try to write directly rather than clear pci_cache_line_size I suppose...

Correct. IIRC, some PATA driver as Pravin already mentioned.
 
Cheers,
Stefan

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Fri, 2009-09-11 at 07:12 +0200, Stefan Roese wrote:
> 
> It's already there. See commit:
> 
> 5ce4b59653b2c2053cd9a011918ac1e4747f24cc
> 
> powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata
> 
Ok, that's another way to do it. Will catch nasty drivers who
try to write directly rather than clear pci_cache_line_size I suppose...

Cheers,
Ben.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Stefan Roese]

On Friday 11 September 2009 04:44:34 Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:
> > There is also a patch that was submitted for 440EPX a couple of years
> > back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
> > commands. Whether MRM is used or not depends on the value of
> > PCI_CACHE_LINE_SIZE register. I see that the changes are no longer
> > present in linux 2.6.30+ kernels. Although the patch certainly resolved
> > the hang issue with Silicon Image 680 PATA card as the 680 driver
> > attempts to use MRM commands - I don't know if it would resolve the data
> > corruption issue. It is certainly worth trying in my opinion. Below is a
> > link to the patch submission:
> >
> > http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=cffefde924123e685327
> > 48dd58fcb780eab5e219
> 
> The changes in the above repository is a quick hack that can't be merged
> as-is (and afaik hasn't been submitted).
> 
> If indeed we need to clamp the PCI cache line size on those critters,
> then we need something in ppc4xx_pci.c to detect the need, set
> pci_cache_line_size to 0 and eventually fixup the existing values in
> devices in case u-boot don't have them right.
> 
> Care to send a patch ? :-)

It's already there. See commit:

5ce4b59653b2c2053cd9a011918ac1e4747f24cc

powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata


Cheers,
Stefan

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Thu, 2009-09-10 at 13:30 -0700, Pravin Bathija wrote:

> There is also a patch that was submitted for 440EPX a couple of years
> back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
> commands. Whether MRM is used or not depends on the value of
> PCI_CACHE_LINE_SIZE register. I see that the changes are no longer
> present in linux 2.6.30+ kernels. Although the patch certainly resolved
> the hang issue with Silicon Image 680 PATA card as the 680 driver
> attempts to use MRM commands - I don't know if it would resolve the data
> corruption issue. It is certainly worth trying in my opinion. Below is a
> link to the patch submission:
> 
> http://git.denx.de/?p=linux-2.6-denx.git;a=commit;h=cffefde924123e685327
> 48dd58fcb780eab5e219

The changes in the above repository is a quick hack that can't be merged
as-is (and afaik hasn't been submitted).

If indeed we need to clamp the PCI cache line size on those critters,
then we need something in ppc4xx_pci.c to detect the need, set
pci_cache_line_size to 0 and eventually fixup the existing values in
devices in case u-boot don't have them right.

Care to send a patch ? :-)

Cheers,
Ben

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Thu, 2009-09-10 at 15:53 -0400, Tom Burns wrote:
> Hi,
> 
> Thank you everyone for your help.
> 
> I've been looking into the other dma/pci API calls (dma_alloc_coherent, 
> pci_alloc_consistent).  I don't see how either of these return memory 
> mapped to a TLB with the I bit set to 1 in kernel 2.6.24.  In our kernel 
> code, the only use of the PPC44x_TLB_I define is in head_44x.S in 
> _start.  We have CONFIG_NON_COHERENT_CACHE enabled.

It uses _PAGE_NO_CACHE which translates into the I bit in the TLB from
the TLB miss handler.

> We changed our code to use dma_alloc_coherent, removed our manual 
> cacheline flushing, and saw the corrupted data return.  To me this means 
> dma_alloc_coherent cannot be setting the I=1 bit in the TLB entry.

It must and it is. However, what are you allocating with
dma_alloc_coherent ? The actual data buffers must -also- be properly
cache managed, probably via dma_sync().

It would help tremendously if you sent us the source of the driver :-)

> I tried, using our JTAG debugger (BDI3000), to pause operation after 
> calling dma_alloc_coherent to examine the TLB entry for the memory 
> returned by the call (which was just past 
> CONFIG_CONSISTENT_START=0xff100000).  The TLB list loaded at the time 
> that I paused operation did not show a mapping for this area.  I guess 
> the kernel swaps TLB entries on the fly so it isn't limited to only 64 
> entries?  I will try to sleep in the same context as the 
> dma_alloc_coherent call to try to catch the TLB entry while loaded to 
> see if it has the I bit set.
> 
Ben.

> If that fails, any ideas?
> 
> Thanks,
> Tom Burns
> International Datacasting Corporation
> 
> Mikhail Zolotaryov wrote:
> > Hi Tom,
> >
> > possible solution could be to use tasklet to perform DMA-related job 
> > (as in most cases DMA transfer is interrupt driven - makes sense).
> >
> >
> > Tom Burns wrote:
> >> Hi,
> >>
> >> With the default config for the Sequoia board on 2.6.24, calling 
> >> pci_dma_sync_sg_for_cpu() results in executing
> >> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
> >> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
> >> the assembly instruction dcbi, which can only be executed in 
> >> supervisor mode.  We tried that before resorting to manual cache line 
> >> management with usermode-safe assembly calls.
> >>
> >> Regards,
> >> Tom Burns
> >> International Datacasting Corporation
> >>
> >> Mikhail Zolotaryov wrote:
> >>> Hi,
> >>>
> >>> Why manage cache lines  manually, if appropriate code is a part of 
> >>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> >>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>
> >>> Prodyut Hazarika wrote:
> >>>> Hi Adam,
> >>>>
> >>>>  
> >>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
> >>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>     
> >>>> (using
> >>>>  
> >>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> >>>>> end up being partially corrupted when we try to parse the data in the
> >>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>     
> >>>> memory
> >>>>  
> >>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>> corrupted, we see a random portion of it (always a multiple of 16byte
> >>>>> cache lines) is overwritten with old data from the last time the
> >>>>>     
> >>>> buffer
> >>>>  
> >>>>> was used.     
> >>>>
> >>>> This looks like a cache coherency problem.
> >>>> Can you ensure that the TLB entries corresponding to the DMA region 
> >>>> has
> >>>> the CacheInhibit bit set.
> >>>> You will need a BDI connected to your system.
> >>>>
> >>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>> since in 440 cores,
> >>>> L1Cache coherency is managed entirely by software.
> >>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> >>>> how to do it.
> >>>>
> >>>> Thanks
> >>>> Prodyut
> >>>>
> >>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>  
> >>>>> Hi Adam,
> >>>>>
> >>>>>  
> >>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>       
> >>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>     
> >>>> board)
> >>>>  
> >>>>> have L2Cache.
> >>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
> >>>>> 440EPx
> >>>>> has a 440 cpu core, but no L2Cache.
> >>>>> Could you please tell me which SoC you are using?
> >>>>> You can also refer to the appropriate dts file to see if there is 
> >>>>> L2C.
> >>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>> entry.
> >>>>>         L2C0: l2c {
> >>>>>               ...
> >>>>>         }
> >>>>>
> >>>>>  
> >>>>>> I am seeing this problem with our custom IDE driver which is 
> >>>>>> based on
> >>>>>>       
> >>>>
> >>>>  
> >>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>       
> >>>> the
> >>>>  
> >>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
> >>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
> >>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
> >>>>>>       
> >>>>> Could you give more details on the consistency problem? It is a good
> >>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
> >>>>> work too
> >>>>>
> >>>>> Thanks
> >>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt 
> >>>>> wrote:
> >>>>>  
> >>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>    
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>         
> >>>>> section:
> >>>>>  
> >>>>>>> #ifdef CONFIG_44x
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>         
> >>>>> _PAGE_GUARDED)
> >>>>>  
> >>>>>>> #else
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>         
> >>>>> that  
> >>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>         
> >>>>> which  
> >>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>         
> >>>>> the  
> >>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>         
> >>>>> masked  
> >>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>         
> >>>>
> >>>>  
> >>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>         
> >>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>       
> >>>> AFAIK,
> >>>>  
> >>>>>> the 440 core just ignores M.
> >>>>>>
> >>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>       
> >>>>> isn't
> >>>>>  
> >>>>>> enabled or not working ?
> >>>>>>
> >>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>       
> >>>>> sure
> >>>>>  
> >>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>> needed.
> >>>>>>
> >>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ben.
> >>>>>>
> >>>>>>
> >>>>>>       
> >>>
> >>>
> >>
> >>
> >
> >
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-09-09 at 17:40 +0300, Mikhail Zolotaryov wrote:
> Hi Tom,
> 
> In my case __dma_sync() calls flush_dcache_range() (it's due to 
> alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of 
> dcbi - that's the difference as dcbf is not privileged.

What it calls depends on the direction of the transfer. The tasklet runs
in priviledged mode, dcbi should work just fine... if passed a correct
address :-)

Cheers,
Ben.

> Tom Burns wrote:
> > Hi Mikhail,
> >
> > Sorry, this DMA code is in a tasklet.  Are you suggesting the 
> > processor is in supervisor mode at that time?  Calling 
> > pci_dma_sync_sg_for_cpu() from the tasklet context is what generates 
> > the OOPS.  The entire oops is as follows, if it's relevant:
> >
> > Oops: kernel access of bad area, sig: 11 [#1]
> > NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> > REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
> > MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
> > DEAR: 3fd39000, ESR: 00800000
> > TASK = de5db7d0[157] 'cat' THREAD: df116000
> > GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> > 0079a169
> > GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> > 10177000
> > GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> > e11f59cc
> > GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> > 87d39009
> > NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> > LR [c0010c30] __dma_sync+0x58/0xac
> > Call Trace:
> > [df117c80] [0000000a] 0xa (unreliable)
> > [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> > [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> > [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> > [df117d10] [c00067a8] do_softirq+0x54/0x58
> > [df117d20] [c001edb4] irq_exit+0x48/0x58
> > [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> > [df117d40] [c00020e0] ret_from_except+0x0/0x18
> > [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> > [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> > [df117ec0] [c00171ac] mmput+0x50/0xd4
> > [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> > [df117ef0] [c001c818] do_exit+0x134/0x6f8
> > [df117f30] [c001ce14] do_group_exit+0x38/0x74
> > [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> > Instruction dump:
> > 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> > 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> > 7c0004ac
> > Kernel panic - not syncing: Aiee, killing interrupt handler!
> > Rebooting in 180 seconds..
> >
> >
> > Cheers,
> > Tom
> >
> > Mikhail Zolotaryov wrote:
> >> Hi Tom,
> >>
> >> possible solution could be to use tasklet to perform DMA-related job 
> >> (as in most cases DMA transfer is interrupt driven - makes sense).
> >>
> >>
> >> Tom Burns wrote:
> >>> Hi,
> >>>
> >>> With the default config for the Sequoia board on 2.6.24, calling 
> >>> pci_dma_sync_sg_for_cpu() results in executing
> >>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
> >>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
> >>> the assembly instruction dcbi, which can only be executed in 
> >>> supervisor mode.  We tried that before resorting to manual cache 
> >>> line management with usermode-safe assembly calls.
> >>>
> >>> Regards,
> >>> Tom Burns
> >>> International Datacasting Corporation
> >>>
> >>> Mikhail Zolotaryov wrote:
> >>>> Hi,
> >>>>
> >>>> Why manage cache lines  manually, if appropriate code is a part of 
> >>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> >>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>>
> >>>> Prodyut Hazarika wrote:
> >>>>> Hi Adam,
> >>>>>
> >>>>>  
> >>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
> >>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>>     
> >>>>> (using
> >>>>>  
> >>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on 
> >>>>>> timing)
> >>>>>> end up being partially corrupted when we try to parse the data in 
> >>>>>> the
> >>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>>     
> >>>>> memory
> >>>>>  
> >>>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>>> corrupted, we see a random portion of it (always a multiple of 
> >>>>>> 16byte
> >>>>>> cache lines) is overwritten with old data from the last time the
> >>>>>>     
> >>>>> buffer
> >>>>>  
> >>>>>> was used.     
> >>>>>
> >>>>> This looks like a cache coherency problem.
> >>>>> Can you ensure that the TLB entries corresponding to the DMA 
> >>>>> region has
> >>>>> the CacheInhibit bit set.
> >>>>> You will need a BDI connected to your system.
> >>>>>
> >>>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>>> since in 440 cores,
> >>>>> L1Cache coherency is managed entirely by software.
> >>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for 
> >>>>> example on
> >>>>> how to do it.
> >>>>>
> >>>>> Thanks
> >>>>> Prodyut
> >>>>>
> >>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>>  
> >>>>>> Hi Adam,
> >>>>>>
> >>>>>>  
> >>>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>>       
> >>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>>     
> >>>>> board)
> >>>>>  
> >>>>>> have L2Cache.
> >>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
> >>>>>> 440EPx
> >>>>>> has a 440 cpu core, but no L2Cache.
> >>>>>> Could you please tell me which SoC you are using?
> >>>>>> You can also refer to the appropriate dts file to see if there is 
> >>>>>> L2C.
> >>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>>> entry.
> >>>>>>         L2C0: l2c {
> >>>>>>               ...
> >>>>>>         }
> >>>>>>
> >>>>>>  
> >>>>>>> I am seeing this problem with our custom IDE driver which is 
> >>>>>>> based on
> >>>>>>>       
> >>>>>
> >>>>>  
> >>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>>       
> >>>>> the
> >>>>>  
> >>>>>>> physical DMA memory and alloc_pages() to allocate a virtual 
> >>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather 
> >>>>>>> buffer. Perhaps I should convert these to the DMA API calls as 
> >>>>>>> you suggest.
> >>>>>>>       
> >>>>>> Could you give more details on the consistency problem? It is a good
> >>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() 
> >>>>>> should
> >>>>>> work too
> >>>>>>
> >>>>>> Thanks
> >>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin 
> >>>>>> Herrenschmidt wrote:
> >>>>>>  
> >>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>>   
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>>         
> >>>>>> section:
> >>>>>>  
> >>>>>>>> #ifdef CONFIG_44x
> >>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>>         
> >>>>>> _PAGE_GUARDED)
> >>>>>>  
> >>>>>>>> #else
> >>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>>> #endif
> >>>>>>>>
> >>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>>         
> >>>>>> that 
> >>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>>         
> >>>>>> which 
> >>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>>         
> >>>>>> the 
> >>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>>         
> >>>>>> masked 
> >>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>>         
> >>>>>
> >>>>>  
> >>>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>>         
> >>>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>>       
> >>>>> AFAIK,
> >>>>>  
> >>>>>>> the 440 core just ignores M.
> >>>>>>>
> >>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>>       
> >>>>>> isn't
> >>>>>>  
> >>>>>>> enabled or not working ?
> >>>>>>>
> >>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>>       
> >>>>>> sure
> >>>>>>  
> >>>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>>> needed.
> >>>>>>>
> >>>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Ben.
> >>>>>>>
> >>>>>>>
> >>>>>>>       
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-09-09 at 10:10 -0400, Tom Burns wrote:
> Hi Mikhail,
> 
> Sorry, this DMA code is in a tasklet.  Are you suggesting the processor 
> is in supervisor mode at that time?  Calling pci_dma_sync_sg_for_cpu() 
> from the tasklet context is what generates the OOPS.  The entire oops is 
> as follows, if it's relevant:

Yes. A tasklet runs in supervisor mode.

> Oops: kernel access of bad area, sig: 11 [#1]

That seems to indicate that your passed an incorrect address to dcbi
(ie, an address that isn't currently mapped, 0x3fd39000 according to
your log), so that looks like a driver bug to me (unless something is
busted in 2.6.24 version of __dma_sync on 44x...)

Cheers,
Ben.

> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
> MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
> DEAR: 3fd39000, ESR: 00800000
> TASK = de5db7d0[157] 'cat' THREAD: df116000
> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> 0079a169
> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> 10177000
> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> e11f59cc
> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> 87d39009
> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> LR [c0010c30] __dma_sync+0x58/0xac
> Call Trace:
> [df117c80] [0000000a] 0xa (unreliable)
> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> [df117d10] [c00067a8] do_softirq+0x54/0x58
> [df117d20] [c001edb4] irq_exit+0x48/0x58
> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> [df117ec0] [c00171ac] mmput+0x50/0xd4
> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> 7c0004ac
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> Rebooting in 180 seconds..
> 
> 
> Cheers,
> Tom
> 
> Mikhail Zolotaryov wrote:
> > Hi Tom,
> >
> > possible solution could be to use tasklet to perform DMA-related job 
> > (as in most cases DMA transfer is interrupt driven - makes sense).
> >
> >
> > Tom Burns wrote:
> >> Hi,
> >>
> >> With the default config for the Sequoia board on 2.6.24, calling 
> >> pci_dma_sync_sg_for_cpu() results in executing
> >> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
> >> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
> >> the assembly instruction dcbi, which can only be executed in 
> >> supervisor mode.  We tried that before resorting to manual cache line 
> >> management with usermode-safe assembly calls.
> >>
> >> Regards,
> >> Tom Burns
> >> International Datacasting Corporation
> >>
> >> Mikhail Zolotaryov wrote:
> >>> Hi,
> >>>
> >>> Why manage cache lines  manually, if appropriate code is a part of 
> >>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> >>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>
> >>> Prodyut Hazarika wrote:
> >>>> Hi Adam,
> >>>>
> >>>>  
> >>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
> >>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>     
> >>>> (using
> >>>>  
> >>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> >>>>> end up being partially corrupted when we try to parse the data in the
> >>>>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>>>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>>>     
> >>>> memory
> >>>>  
> >>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>> corrupted, we see a random portion of it (always a multiple of 16byte
> >>>>> cache lines) is overwritten with old data from the last time the
> >>>>>     
> >>>> buffer
> >>>>  
> >>>>> was used.     
> >>>>
> >>>> This looks like a cache coherency problem.
> >>>> Can you ensure that the TLB entries corresponding to the DMA region 
> >>>> has
> >>>> the CacheInhibit bit set.
> >>>> You will need a BDI connected to your system.
> >>>>
> >>>> Also, you will need to invalidate and flush the lines appropriately,
> >>>> since in 440 cores,
> >>>> L1Cache coherency is managed entirely by software.
> >>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> >>>> how to do it.
> >>>>
> >>>> Thanks
> >>>> Prodyut
> >>>>
> >>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>  
> >>>>> Hi Adam,
> >>>>>
> >>>>>  
> >>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>       
> >>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>     
> >>>> board)
> >>>>  
> >>>>> have L2Cache.
> >>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
> >>>>> 440EPx
> >>>>> has a 440 cpu core, but no L2Cache.
> >>>>> Could you please tell me which SoC you are using?
> >>>>> You can also refer to the appropriate dts file to see if there is 
> >>>>> L2C.
> >>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>>>> entry.
> >>>>>         L2C0: l2c {
> >>>>>               ...
> >>>>>         }
> >>>>>
> >>>>>  
> >>>>>> I am seeing this problem with our custom IDE driver which is 
> >>>>>> based on
> >>>>>>       
> >>>>
> >>>>  
> >>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>>>       
> >>>> the
> >>>>  
> >>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
> >>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
> >>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
> >>>>>>       
> >>>>> Could you give more details on the consistency problem? It is a good
> >>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
> >>>>> work too
> >>>>>
> >>>>> Thanks
> >>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt 
> >>>>> wrote:
> >>>>>  
> >>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>    
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>>>         
> >>>>> section:
> >>>>>  
> >>>>>>> #ifdef CONFIG_44x
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>         
> >>>>> _PAGE_GUARDED)
> >>>>>  
> >>>>>>> #else
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>>>         
> >>>>> that  
> >>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>>>         
> >>>>> which  
> >>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>>>         
> >>>>> the  
> >>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>>>         
> >>>>> masked  
> >>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>>>         
> >>>>
> >>>>  
> >>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>         
> >>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>       
> >>>> AFAIK,
> >>>>  
> >>>>>> the 440 core just ignores M.
> >>>>>>
> >>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>>>       
> >>>>> isn't
> >>>>>  
> >>>>>> enabled or not working ?
> >>>>>>
> >>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>>>       
> >>>>> sure
> >>>>>  
> >>>>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>>>> needed.
> >>>>>>
> >>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ben.
> >>>>>>
> >>>>>>
> >>>>>>       
> >>>
> >>>
> >>
> >>
> >
> >
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Wed, 2009-09-09 at 09:43 -0400, Tom Burns wrote:
> Hi,
> 
> With the default config for the Sequoia board on 2.6.24, calling 
> pci_dma_sync_sg_for_cpu() results in executing
> invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().  
> This OOPses on PPC440 since it tries to call directly the assembly 
> instruction dcbi, which can only be executed in supervisor mode.  We 
> tried that before resorting to manual cache line management with 
> usermode-safe assembly calls.

Wait a minute.... usermode ? You are doing all of that from userspace ?
I don't understand the story here. You can't call all those kernel APIs
form userspace in the first place, indeed... But then an IDE driver has
nothing to do in userspace neither.

Cheers,
Ben.

> Regards,
> Tom Burns
> International Datacasting Corporation
> 
> Mikhail Zolotaryov wrote:
> > Hi,
> >
> > Why manage cache lines  manually, if appropriate code is a part of 
> > __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> > CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >
> > Prodyut Hazarika wrote:
> >> Hi Adam,
> >>
> >>  
> >>> Yes, I am using the 440EPx (same as the sequoia board). Our 
> >>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>     
> >> (using
> >>  
> >>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> >>> end up being partially corrupted when we try to parse the data in the
> >>> virtual page. We have confirmed the data is good before the PCI-IDE
> >>> bridge. We are creating two 8K pages and map them to physical DMA
> >>>     
> >> memory
> >>  
> >>> using single-entry scatter/gather structs. When a DMA block is
> >>> corrupted, we see a random portion of it (always a multiple of 16byte
> >>> cache lines) is overwritten with old data from the last time the
> >>>     
> >> buffer
> >>  
> >>> was used.     
> >>
> >> This looks like a cache coherency problem.
> >> Can you ensure that the TLB entries corresponding to the DMA region has
> >> the CacheInhibit bit set.
> >> You will need a BDI connected to your system.
> >>
> >> Also, you will need to invalidate and flush the lines appropriately,
> >> since in 440 cores,
> >> L1Cache coherency is managed entirely by software.
> >> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> >> how to do it.
> >>
> >> Thanks
> >> Prodyut
> >>
> >> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>  
> >>> Hi Adam,
> >>>
> >>>    
> >>>> Are you sure there is L2 cache on the 440?
> >>>>       
> >>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>     
> >> board)
> >>  
> >>> have L2Cache.
> >>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> >>> has a 440 cpu core, but no L2Cache.
> >>> Could you please tell me which SoC you are using?
> >>> You can also refer to the appropriate dts file to see if there is L2C.
> >>> For example, in canyonlands.dts (460EX based board), we have the L2C
> >>> entry.
> >>>         L2C0: l2c {
> >>>               ...
> >>>         }
> >>>
> >>>    
> >>>> I am seeing this problem with our custom IDE driver which is based on
> >>>>       
> >>
> >>  
> >>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
> >>>>       
> >> the
> >>  
> >>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
> >>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
> >>>> Perhaps I should convert these to the DMA API calls as you suggest.
> >>>>       
> >>> Could you give more details on the consistency problem? It is a good
> >>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
> >>> work too
> >>>
> >>> Thanks
> >>> Prodyut   
> >>>
> >>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> >>>    
> >>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>      
> >>>>> Hi Adam,
> >>>>>
> >>>>> If you have a look in include/asm-ppc/pgtable.h for the following
> >>>>>         
> >>> section:
> >>>    
> >>>>> #ifdef CONFIG_44x
> >>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>         
> >>> _PAGE_GUARDED)
> >>>    
> >>>>> #else
> >>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>> #endif
> >>>>>
> >>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
> >>>>>         
> >>> that    
> >>>>> fixes your issue - this causes the 'M' bit to be set on the page
> >>>>>         
> >>> which    
> >>>>> sure enforce cache coherency. If it doesn't, you'll need to check
> >>>>>         
> >>> the    
> >>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
> >>>>>         
> >>> masked    
> >>>>> out on arch/powerpc, but was fixed in later kernels when the cache
> >>>>>         
> >>
> >>  
> >>>>> coherency issues with non-SMP systems were resolved).
> >>>>>         
> >>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>       
> >> AFAIK,
> >>  
> >>>> the 440 core just ignores M.
> >>>>
> >>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
> >>>>       
> >>> isn't
> >>>    
> >>>> enabled or not working ?
> >>>>
> >>>> The L1 cache on 440 is simply not coherent, so drivers have to make
> >>>>       
> >>> sure
> >>>    
> >>>> they use the appropriate DMA APIs which will do cache flushing when
> >>>> needed.
> >>>>
> >>>> Adam, what driver is causing you that sort of problems ?
> >>>>
> >>>> Cheers,
> >>>> Ben.
> >>>>
> >>>>
> >>>>       
> >
> >
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Pravin Bathija]

> Tom Burns wrote=20
> Hi,
>=20
> Thank you everyone for your help.
>=20
> I've been looking into the other dma/pci API calls
(dma_alloc_coherent,
> pci_alloc_consistent).  I don't see how either of these return memory
> mapped to a TLB with the I bit set to 1 in kernel 2.6.24.  In our
> kernel
> code, the only use of the PPC44x_TLB_I define is in head_44x.S in
> _start.  We have CONFIG_NON_COHERENT_CACHE enabled.
>=20
> We changed our code to use dma_alloc_coherent, removed our manual
> cacheline flushing, and saw the corrupted data return.  To me this
> means
> dma_alloc_coherent cannot be setting the I=3D1 bit in the TLB entry.
>=20
> I tried, using our JTAG debugger (BDI3000), to pause operation after
> calling dma_alloc_coherent to examine the TLB entry for the memory
> returned by the call (which was just past
> CONFIG_CONSISTENT_START=3D0xff100000).  The TLB list loaded at the =
time
> that I paused operation did not show a mapping for this area.  I guess
> the kernel swaps TLB entries on the fly so it isn't limited to only 64
> entries?  I will try to sleep in the same context as the
> dma_alloc_coherent call to try to catch the TLB entry while loaded to
> see if it has the I bit set.
>=20
> If that fails, any ideas?
>=20
> Thanks,
> Tom Burns
> International Datacasting Corporation
>=20

There is also a patch that was submitted for 440EPX a couple of years
back. The 440EPX SOC causes hangs with Memory Read Multiple (MRM)
commands. Whether MRM is used or not depends on the value of
PCI_CACHE_LINE_SIZE register. I see that the changes are no longer
present in linux 2.6.30+ kernels. Although the patch certainly resolved
the hang issue with Silicon Image 680 PATA card as the 680 driver
attempts to use MRM commands - I don't know if it would resolve the data
corruption issue. It is certainly worth trying in my opinion. Below is a
link to the patch submission:

http://git.denx.de/?p=3Dlinux-2.6-denx.git;a=3Dcommit;h=3Dcffefde924123e6=
85327
48dd58fcb780eab5e219





> Mikhail Zolotaryov wrote:
> > Hi Tom,
> >
> > possible solution could be to use tasklet to perform DMA-related job
> > (as in most cases DMA transfer is interrupt driven - makes sense).
> >
> >
> > Tom Burns wrote:
> >> Hi,
> >>
> >> With the default config for the Sequoia board on 2.6.24, calling
> >> pci_dma_sync_sg_for_cpu() results in executing
> >> invalidate_dcache_range() in arch/ppc/kernel/misc.S from
> >> __dma_sync().  This OOPses on PPC440 since it tries to call
directly
> >> the assembly instruction dcbi, which can only be executed in
> >> supervisor mode.  We tried that before resorting to manual cache
> line
> >> management with usermode-safe assembly calls.
> >>
> >> Regards,
> >> Tom Burns
> >> International Datacasting Corporation
> >>
> >> Mikhail Zolotaryov wrote:
> >>> Hi,
> >>>
> >>> Why manage cache lines  manually, if appropriate code is a part of
> >>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies
> >>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
> >>>
> >>> Prodyut Hazarika wrote:
> >>>> Hi Adam,
> >>>>
> >>>>
> >>>>> Yes, I am using the 440EPx (same as the sequoia board). Our
> >>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> >>>>>
> >>>> (using
> >>>>
> >>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> timing)
> >>>>> end up being partially corrupted when we try to parse the data
in
> the
> >>>>> virtual page. We have confirmed the data is good before the PCI-
> IDE
> >>>>> bridge. We are creating two 8K pages and map them to physical
DMA
> >>>>>
> >>>> memory
> >>>>
> >>>>> using single-entry scatter/gather structs. When a DMA block is
> >>>>> corrupted, we see a random portion of it (always a multiple of
> 16byte
> >>>>> cache lines) is overwritten with old data from the last time the
> >>>>>
> >>>> buffer
> >>>>
> >>>>> was used.
> >>>>
> >>>> This looks like a cache coherency problem.
> >>>> Can you ensure that the TLB entries corresponding to the DMA
> region
> >>>> has
> >>>> the CacheInhibit bit set.
> >>>> You will need a BDI connected to your system.
> >>>>
> >>>> Also, you will need to invalidate and flush the lines
> appropriately,
> >>>> since in 440 cores,
> >>>> L1Cache coherency is managed entirely by software.
> >>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for
> example on
> >>>> how to do it.
> >>>>
> >>>> Thanks
> >>>> Prodyut
> >>>>
> >>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> >>>>
> >>>>> Hi Adam,
> >>>>>
> >>>>>
> >>>>>> Are you sure there is L2 cache on the 440?
> >>>>>>
> >>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
> >>>>>
> >>>> board)
> >>>>
> >>>>> have L2Cache.
> >>>>> It seems you are using a Sequoia board, which has a 440EPx SoC.
> >>>>> 440EPx
> >>>>> has a 440 cpu core, but no L2Cache.
> >>>>> Could you please tell me which SoC you are using?
> >>>>> You can also refer to the appropriate dts file to see if there
is
> >>>>> L2C.
> >>>>> For example, in canyonlands.dts (460EX based board), we have the
> L2C
> >>>>> entry.
> >>>>>         L2C0: l2c {
> >>>>>               ...
> >>>>>         }
> >>>>>
> >>>>>
> >>>>>> I am seeing this problem with our custom IDE driver which is
> >>>>>> based on
> >>>>>>
> >>>>
> >>>>
> >>>>>> pretty old code. Our driver uses pci_alloc_consistent() to
> allocate
> >>>>>>
> >>>> the
> >>>>
> >>>>>> physical DMA memory and alloc_pages() to allocate a virtual
> page.
> >>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer.
> >>>>>> Perhaps I should convert these to the DMA API calls as you
> suggest.
> >>>>>>
> >>>>> Could you give more details on the consistency problem? It is a
> good
> >>>>> idea to change to the new DMA APIs, but pci_alloc_consistent()
> should
> >>>>> work too
> >>>>>
> >>>>> Thanks
> >>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin
> Herrenschmidt
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> >>>>>>
> >>>>>>> Hi Adam,
> >>>>>>>
> >>>>>>> If you have a look in include/asm-ppc/pgtable.h for the
> following
> >>>>>>>
> >>>>> section:
> >>>>>
> >>>>>>> #ifdef CONFIG_44x
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> >>>>>>>
> >>>>> _PAGE_GUARDED)
> >>>>>
> >>>>>>> #else
> >>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> >>>>>>> #endif
> >>>>>>>
> >>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and
see
> if
> >>>>>>>
> >>>>> that
> >>>>>>> fixes your issue - this causes the 'M' bit to be set on the
> page
> >>>>>>>
> >>>>> which
> >>>>>>> sure enforce cache coherency. If it doesn't, you'll need to
> check
> >>>>>>>
> >>>>> the
> >>>>>>> 'M' bit isn't being masked out in head_44x.S (it was
originally
> >>>>>>>
> >>>>> masked
> >>>>>>> out on arch/powerpc, but was fixed in later kernels when the
> cache
> >>>>>>>
> >>>>
> >>>>
> >>>>>>> coherency issues with non-SMP systems were resolved).
> >>>>>>>
> >>>>>> I have some doubts about the usefulness of doing that for 4xx.
> >>>>>>
> >>>> AFAIK,
> >>>>
> >>>>>> the 440 core just ignores M.
> >>>>>>
> >>>>>> The problem lies probably elsewhere. Maybe the L2 cache
> coherency
> >>>>>>
> >>>>> isn't
> >>>>>
> >>>>>> enabled or not working ?
> >>>>>>
> >>>>>> The L1 cache on 440 is simply not coherent, so drivers have to
> make
> >>>>>>
> >>>>> sure
> >>>>>
> >>>>>> they use the appropriate DMA APIs which will do cache flushing
> when
> >>>>>> needed.
> >>>>>>
> >>>>>> Adam, what driver is causing you that sort of problems ?
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Ben.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> >>>
> >>
> >>
> >
> >
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Tom Burns]

Hi,

Thank you everyone for your help.

I've been looking into the other dma/pci API calls (dma_alloc_coherent, 
pci_alloc_consistent).  I don't see how either of these return memory 
mapped to a TLB with the I bit set to 1 in kernel 2.6.24.  In our kernel 
code, the only use of the PPC44x_TLB_I define is in head_44x.S in 
_start.  We have CONFIG_NON_COHERENT_CACHE enabled.

We changed our code to use dma_alloc_coherent, removed our manual 
cacheline flushing, and saw the corrupted data return.  To me this means 
dma_alloc_coherent cannot be setting the I=1 bit in the TLB entry.

I tried, using our JTAG debugger (BDI3000), to pause operation after 
calling dma_alloc_coherent to examine the TLB entry for the memory 
returned by the call (which was just past 
CONFIG_CONSISTENT_START=0xff100000).  The TLB list loaded at the time 
that I paused operation did not show a mapping for this area.  I guess 
the kernel swaps TLB entries on the fly so it isn't limited to only 64 
entries?  I will try to sleep in the same context as the 
dma_alloc_coherent call to try to catch the TLB entry while loaded to 
see if it has the I bit set.

If that fails, any ideas?

Thanks,
Tom Burns
International Datacasting Corporation

Mikhail Zolotaryov wrote:
> Hi Tom,
>
> possible solution could be to use tasklet to perform DMA-related job 
> (as in most cases DMA transfer is interrupt driven - makes sense).
>
>
> Tom Burns wrote:
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling 
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
>> the assembly instruction dcbi, which can only be executed in 
>> supervisor mode.  We tried that before resorting to manual cache line 
>> management with usermode-safe assembly calls.
>>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>> Hi,
>>>
>>> Why manage cache lines  manually, if appropriate code is a part of 
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>> Hi Adam,
>>>>
>>>>  
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>     
>>>> (using
>>>>  
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>     
>>>> memory
>>>>  
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>     
>>>> buffer
>>>>  
>>>>> was used.     
>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region 
>>>> has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>  
>>>>> Hi Adam,
>>>>>
>>>>>  
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>       
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>     
>>>> board)
>>>>  
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
>>>>> 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is 
>>>>> L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>>         L2C0: l2c {
>>>>>               ...
>>>>>         }
>>>>>
>>>>>  
>>>>>> I am seeing this problem with our custom IDE driver which is 
>>>>>> based on
>>>>>>       
>>>>
>>>>  
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>       
>>>> the
>>>>  
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>       
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt 
>>>>> wrote:
>>>>>  
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>    
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>         
>>>>> section:
>>>>>  
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>         
>>>>> _PAGE_GUARDED)
>>>>>  
>>>>>>> #else
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>         
>>>>> that  
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>         
>>>>> which  
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>         
>>>>> the  
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>         
>>>>> masked  
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>         
>>>>
>>>>  
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>         
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>       
>>>> AFAIK,
>>>>  
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>       
>>>>> isn't
>>>>>  
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>       
>>>>> sure
>>>>>  
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>       
>>>
>>>
>>
>>
>
>

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Mikhail Zolotaryov]

Hi Tom,

In my case __dma_sync() calls flush_dcache_range() (it's due to 
alignment) from a tasklet - no OOPS. It uses dcbf instruction instead of 
dcbi - that's the difference as dcbf is not privileged.

Tom Burns wrote:
> Hi Mikhail,
>
> Sorry, this DMA code is in a tasklet.  Are you suggesting the 
> processor is in supervisor mode at that time?  Calling 
> pci_dma_sync_sg_for_cpu() from the tasklet context is what generates 
> the OOPS.  The entire oops is as follows, if it's relevant:
>
> Oops: kernel access of bad area, sig: 11 [#1]
> NIP: c0003ab0 LR: c0010c30 CTR: 02400001
> REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
> MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
> DEAR: 3fd39000, ESR: 00800000
> TASK = de5db7d0[157] 'cat' THREAD: df116000
> GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
> 0079a169
> GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
> 10177000
> GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
> e11f59cc
> GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
> 87d39009
> NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
> LR [c0010c30] __dma_sync+0x58/0xac
> Call Trace:
> [df117c80] [0000000a] 0xa (unreliable)
> [df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
> [df117ce0] [c001ee24] tasklet_action+0x60/0xcc
> [df117cf0] [c001ef04] __do_softirq+0x74/0xe0
> [df117d10] [c00067a8] do_softirq+0x54/0x58
> [df117d20] [c001edb4] irq_exit+0x48/0x58
> [df117d30] [c00069d0] do_IRQ+0x6c/0xc0
> [df117d40] [c00020e0] ret_from_except+0x0/0x18
> [df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
> [df117e90] [c0053ebc] exit_mmap+0x64/0xec
> [df117ec0] [c00171ac] mmput+0x50/0xd4
> [df117ed0] [c001aef8] exit_mm+0x80/0xe0
> [df117ef0] [c001c818] do_exit+0x134/0x6f8
> [df117f30] [c001ce14] do_group_exit+0x38/0x74
> [df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
> Instruction dump:
> 7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
> 7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
> 7c0004ac
> Kernel panic - not syncing: Aiee, killing interrupt handler!
> Rebooting in 180 seconds..
>
>
> Cheers,
> Tom
>
> Mikhail Zolotaryov wrote:
>> Hi Tom,
>>
>> possible solution could be to use tasklet to perform DMA-related job 
>> (as in most cases DMA transfer is interrupt driven - makes sense).
>>
>>
>> Tom Burns wrote:
>>> Hi,
>>>
>>> With the default config for the Sequoia board on 2.6.24, calling 
>>> pci_dma_sync_sg_for_cpu() results in executing
>>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
>>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
>>> the assembly instruction dcbi, which can only be executed in 
>>> supervisor mode.  We tried that before resorting to manual cache 
>>> line management with usermode-safe assembly calls.
>>>
>>> Regards,
>>> Tom Burns
>>> International Datacasting Corporation
>>>
>>> Mikhail Zolotaryov wrote:
>>>> Hi,
>>>>
>>>> Why manage cache lines  manually, if appropriate code is a part of 
>>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>>
>>>> Prodyut Hazarika wrote:
>>>>> Hi Adam,
>>>>>
>>>>>  
>>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>>     
>>>>> (using
>>>>>  
>>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on 
>>>>>> timing)
>>>>>> end up being partially corrupted when we try to parse the data in 
>>>>>> the
>>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>>     
>>>>> memory
>>>>>  
>>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>>> corrupted, we see a random portion of it (always a multiple of 
>>>>>> 16byte
>>>>>> cache lines) is overwritten with old data from the last time the
>>>>>>     
>>>>> buffer
>>>>>  
>>>>>> was used.     
>>>>>
>>>>> This looks like a cache coherency problem.
>>>>> Can you ensure that the TLB entries corresponding to the DMA 
>>>>> region has
>>>>> the CacheInhibit bit set.
>>>>> You will need a BDI connected to your system.
>>>>>
>>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>>> since in 440 cores,
>>>>> L1Cache coherency is managed entirely by software.
>>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for 
>>>>> example on
>>>>> how to do it.
>>>>>
>>>>> Thanks
>>>>> Prodyut
>>>>>
>>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>>  
>>>>>> Hi Adam,
>>>>>>
>>>>>>  
>>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>>       
>>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>>     
>>>>> board)
>>>>>  
>>>>>> have L2Cache.
>>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
>>>>>> 440EPx
>>>>>> has a 440 cpu core, but no L2Cache.
>>>>>> Could you please tell me which SoC you are using?
>>>>>> You can also refer to the appropriate dts file to see if there is 
>>>>>> L2C.
>>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>>> entry.
>>>>>>         L2C0: l2c {
>>>>>>               ...
>>>>>>         }
>>>>>>
>>>>>>  
>>>>>>> I am seeing this problem with our custom IDE driver which is 
>>>>>>> based on
>>>>>>>       
>>>>>
>>>>>  
>>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>>       
>>>>> the
>>>>>  
>>>>>>> physical DMA memory and alloc_pages() to allocate a virtual 
>>>>>>> page. It then uses pci_map_sg() to map to a scatter/gather 
>>>>>>> buffer. Perhaps I should convert these to the DMA API calls as 
>>>>>>> you suggest.
>>>>>>>       
>>>>>> Could you give more details on the consistency problem? It is a good
>>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() 
>>>>>> should
>>>>>> work too
>>>>>>
>>>>>> Thanks
>>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin 
>>>>>> Herrenschmidt wrote:
>>>>>>  
>>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>>   
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>>         
>>>>>> section:
>>>>>>  
>>>>>>>> #ifdef CONFIG_44x
>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>>         
>>>>>> _PAGE_GUARDED)
>>>>>>  
>>>>>>>> #else
>>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>>> #endif
>>>>>>>>
>>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>>         
>>>>>> that 
>>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>>         
>>>>>> which 
>>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>>         
>>>>>> the 
>>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>>         
>>>>>> masked 
>>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>>         
>>>>>
>>>>>  
>>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>>         
>>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>>       
>>>>> AFAIK,
>>>>>  
>>>>>>> the 440 core just ignores M.
>>>>>>>
>>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>>       
>>>>>> isn't
>>>>>>  
>>>>>>> enabled or not working ?
>>>>>>>
>>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>>       
>>>>>> sure
>>>>>>  
>>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>>> needed.
>>>>>>>
>>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ben.
>>>>>>>
>>>>>>>
>>>>>>>       
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Mikhail Zolotaryov]

Hi Tom,

possible solution could be to use tasklet to perform DMA-related job (as 
in most cases DMA transfer is interrupt driven - makes sense).


Tom Burns wrote:
> Hi,
>
> With the default config for the Sequoia board on 2.6.24, calling 
> pci_dma_sync_sg_for_cpu() results in executing
> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
> the assembly instruction dcbi, which can only be executed in 
> supervisor mode.  We tried that before resorting to manual cache line 
> management with usermode-safe assembly calls.
>
> Regards,
> Tom Burns
> International Datacasting Corporation
>
> Mikhail Zolotaryov wrote:
>> Hi,
>>
>> Why manage cache lines  manually, if appropriate code is a part of 
>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>
>> Prodyut Hazarika wrote:
>>> Hi Adam,
>>>
>>>  
>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>     
>>> (using
>>>  
>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>> end up being partially corrupted when we try to parse the data in the
>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>     
>>> memory
>>>  
>>>> using single-entry scatter/gather structs. When a DMA block is
>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>> cache lines) is overwritten with old data from the last time the
>>>>     
>>> buffer
>>>  
>>>> was used.     
>>>
>>> This looks like a cache coherency problem.
>>> Can you ensure that the TLB entries corresponding to the DMA region has
>>> the CacheInhibit bit set.
>>> You will need a BDI connected to your system.
>>>
>>> Also, you will need to invalidate and flush the lines appropriately,
>>> since in 440 cores,
>>> L1Cache coherency is managed entirely by software.
>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>> how to do it.
>>>
>>> Thanks
>>> Prodyut
>>>
>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>  
>>>> Hi Adam,
>>>>
>>>>   
>>>>> Are you sure there is L2 cache on the 440?
>>>>>       
>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>     
>>> board)
>>>  
>>>> have L2Cache.
>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>>> has a 440 cpu core, but no L2Cache.
>>>> Could you please tell me which SoC you are using?
>>>> You can also refer to the appropriate dts file to see if there is L2C.
>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>> entry.
>>>>         L2C0: l2c {
>>>>               ...
>>>>         }
>>>>
>>>>   
>>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>>       
>>>
>>>  
>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>       
>>> the
>>>  
>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>       
>>>> Could you give more details on the consistency problem? It is a good
>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>> work too
>>>>
>>>> Thanks
>>>> Prodyut  
>>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>>   
>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>     
>>>>>> Hi Adam,
>>>>>>
>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>         
>>>> section:
>>>>   
>>>>>> #ifdef CONFIG_44x
>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>         
>>>> _PAGE_GUARDED)
>>>>   
>>>>>> #else
>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>> #endif
>>>>>>
>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>         
>>>> that   
>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>         
>>>> which   
>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>         
>>>> the   
>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>         
>>>> masked   
>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>         
>>>
>>>  
>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>         
>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>       
>>> AFAIK,
>>>  
>>>>> the 440 core just ignores M.
>>>>>
>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>       
>>>> isn't
>>>>   
>>>>> enabled or not working ?
>>>>>
>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>       
>>>> sure
>>>>   
>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>> needed.
>>>>>
>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>
>>>>> Cheers,
>>>>> Ben.
>>>>>
>>>>>
>>>>>       
>>
>>
>
>

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Tom Burns]

Hi Mikhail,

Sorry, this DMA code is in a tasklet.  Are you suggesting the processor 
is in supervisor mode at that time?  Calling pci_dma_sync_sg_for_cpu() 
from the tasklet context is what generates the OOPS.  The entire oops is 
as follows, if it's relevant:

Oops: kernel access of bad area, sig: 11 [#1]
NIP: c0003ab0 LR: c0010c30 CTR: 02400001
REGS: df117bd0 TRAP: 0300   Tainted: P         (2.6.24.2)
MSR: 00029000 <EE,ME>  CR: 44224042  XER: 20000000
DEAR: 3fd39000, ESR: 00800000
TASK = de5db7d0[157] 'cat' THREAD: df116000
GPR00: e11e5854 df117c80 de5db7d0 3fd39000 02400001 0000001f 00000002
0079a169
GPR08: 00000001 c0310000 00000000 c0010c84 24224042 101c0dac c0310000
10177000
GPR16: deb14200 df116000 e12062d0 e11f6104 de0f16c0 e11f0000 c0310000
e11f59cc
GPR24: e11f62d0 e11f0000 e11f0000 00000000 00000002 defee014 3fd39008
87d39009
NIP [c0003ab0] invalidate_dcache_range+0x1c/0x30
LR [c0010c30] __dma_sync+0x58/0xac
Call Trace:
[df117c80] [0000000a] 0xa (unreliable)
[df117c90] [e11e5854] DoTasklet+0x67c/0xc90 [ideDriverDuo_cyph]
[df117ce0] [c001ee24] tasklet_action+0x60/0xcc
[df117cf0] [c001ef04] __do_softirq+0x74/0xe0
[df117d10] [c00067a8] do_softirq+0x54/0x58
[df117d20] [c001edb4] irq_exit+0x48/0x58
[df117d30] [c00069d0] do_IRQ+0x6c/0xc0
[df117d40] [c00020e0] ret_from_except+0x0/0x18
[df117e00] [c00501e0] unmap_vmas+0x2c4/0x560
[df117e90] [c0053ebc] exit_mmap+0x64/0xec
[df117ec0] [c00171ac] mmput+0x50/0xd4
[df117ed0] [c001aef8] exit_mm+0x80/0xe0
[df117ef0] [c001c818] do_exit+0x134/0x6f8
[df117f30] [c001ce14] do_group_exit+0x38/0x74
[df117f40] [c0001a80] ret_from_syscall+0x0/0x3c
Instruction dump:
7c0018ac 38630020 4200fff8 7c0004ac 4e800020 38a0001f 7c632878 7c832050
7c842a14 5484d97f 4d820020 7c8903a6 <7c001bac> 38630020 4200fff8
7c0004ac
Kernel panic - not syncing: Aiee, killing interrupt handler!
Rebooting in 180 seconds..


Cheers,
Tom

Mikhail Zolotaryov wrote:
> Hi Tom,
>
> possible solution could be to use tasklet to perform DMA-related job 
> (as in most cases DMA transfer is interrupt driven - makes sense).
>
>
> Tom Burns wrote:
>> Hi,
>>
>> With the default config for the Sequoia board on 2.6.24, calling 
>> pci_dma_sync_sg_for_cpu() results in executing
>> invalidate_dcache_range() in arch/ppc/kernel/misc.S from 
>> __dma_sync().  This OOPses on PPC440 since it tries to call directly 
>> the assembly instruction dcbi, which can only be executed in 
>> supervisor mode.  We tried that before resorting to manual cache line 
>> management with usermode-safe assembly calls.
>>
>> Regards,
>> Tom Burns
>> International Datacasting Corporation
>>
>> Mikhail Zolotaryov wrote:
>>> Hi,
>>>
>>> Why manage cache lines  manually, if appropriate code is a part of 
>>> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
>>> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>>>
>>> Prodyut Hazarika wrote:
>>>> Hi Adam,
>>>>
>>>>  
>>>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>>>     
>>>> (using
>>>>  
>>>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>>>> end up being partially corrupted when we try to parse the data in the
>>>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>>>     
>>>> memory
>>>>  
>>>>> using single-entry scatter/gather structs. When a DMA block is
>>>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>>>> cache lines) is overwritten with old data from the last time the
>>>>>     
>>>> buffer
>>>>  
>>>>> was used.     
>>>>
>>>> This looks like a cache coherency problem.
>>>> Can you ensure that the TLB entries corresponding to the DMA region 
>>>> has
>>>> the CacheInhibit bit set.
>>>> You will need a BDI connected to your system.
>>>>
>>>> Also, you will need to invalidate and flush the lines appropriately,
>>>> since in 440 cores,
>>>> L1Cache coherency is managed entirely by software.
>>>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>>>> how to do it.
>>>>
>>>> Thanks
>>>> Prodyut
>>>>
>>>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>>>  
>>>>> Hi Adam,
>>>>>
>>>>>  
>>>>>> Are you sure there is L2 cache on the 440?
>>>>>>       
>>>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>>>     
>>>> board)
>>>>  
>>>>> have L2Cache.
>>>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 
>>>>> 440EPx
>>>>> has a 440 cpu core, but no L2Cache.
>>>>> Could you please tell me which SoC you are using?
>>>>> You can also refer to the appropriate dts file to see if there is 
>>>>> L2C.
>>>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>>>> entry.
>>>>>         L2C0: l2c {
>>>>>               ...
>>>>>         }
>>>>>
>>>>>  
>>>>>> I am seeing this problem with our custom IDE driver which is 
>>>>>> based on
>>>>>>       
>>>>
>>>>  
>>>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>>>       
>>>> the
>>>>  
>>>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
>>>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
>>>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>>>       
>>>>> Could you give more details on the consistency problem? It is a good
>>>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>>>> work too
>>>>>
>>>>> Thanks
>>>>> Prodyut  On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt 
>>>>> wrote:
>>>>>  
>>>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>>>    
>>>>>>> Hi Adam,
>>>>>>>
>>>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>>>         
>>>>> section:
>>>>>  
>>>>>>> #ifdef CONFIG_44x
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>>>         
>>>>> _PAGE_GUARDED)
>>>>>  
>>>>>>> #else
>>>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>>>> #endif
>>>>>>>
>>>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>>>         
>>>>> that  
>>>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>>>         
>>>>> which  
>>>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>>>         
>>>>> the  
>>>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>>>         
>>>>> masked  
>>>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>>>         
>>>>
>>>>  
>>>>>>> coherency issues with non-SMP systems were resolved).
>>>>>>>         
>>>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>>>       
>>>> AFAIK,
>>>>  
>>>>>> the 440 core just ignores M.
>>>>>>
>>>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>>>       
>>>>> isn't
>>>>>  
>>>>>> enabled or not working ?
>>>>>>
>>>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>>>       
>>>>> sure
>>>>>  
>>>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>>>> needed.
>>>>>>
>>>>>> Adam, what driver is causing you that sort of problems ?
>>>>>>
>>>>>> Cheers,
>>>>>> Ben.
>>>>>>
>>>>>>
>>>>>>       
>>>
>>>
>>
>>
>
>

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Tom Burns]

Hi,

With the default config for the Sequoia board on 2.6.24, calling 
pci_dma_sync_sg_for_cpu() results in executing
invalidate_dcache_range() in arch/ppc/kernel/misc.S from __dma_sync().  
This OOPses on PPC440 since it tries to call directly the assembly 
instruction dcbi, which can only be executed in supervisor mode.  We 
tried that before resorting to manual cache line management with 
usermode-safe assembly calls.

Regards,
Tom Burns
International Datacasting Corporation

Mikhail Zolotaryov wrote:
> Hi,
>
> Why manage cache lines  manually, if appropriate code is a part of 
> __dma_sync / dma_sync_single_for_device of DMA API ? (implies 
> CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)
>
> Prodyut Hazarika wrote:
>> Hi Adam,
>>
>>  
>>> Yes, I am using the 440EPx (same as the sequoia board). Our 
>>> ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>>     
>> (using
>>  
>>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>>> end up being partially corrupted when we try to parse the data in the
>>> virtual page. We have confirmed the data is good before the PCI-IDE
>>> bridge. We are creating two 8K pages and map them to physical DMA
>>>     
>> memory
>>  
>>> using single-entry scatter/gather structs. When a DMA block is
>>> corrupted, we see a random portion of it (always a multiple of 16byte
>>> cache lines) is overwritten with old data from the last time the
>>>     
>> buffer
>>  
>>> was used.     
>>
>> This looks like a cache coherency problem.
>> Can you ensure that the TLB entries corresponding to the DMA region has
>> the CacheInhibit bit set.
>> You will need a BDI connected to your system.
>>
>> Also, you will need to invalidate and flush the lines appropriately,
>> since in 440 cores,
>> L1Cache coherency is managed entirely by software.
>> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
>> how to do it.
>>
>> Thanks
>> Prodyut
>>
>> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>>  
>>> Hi Adam,
>>>
>>>    
>>>> Are you sure there is L2 cache on the 440?
>>>>       
>>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>>     
>> board)
>>  
>>> have L2Cache.
>>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>>> has a 440 cpu core, but no L2Cache.
>>> Could you please tell me which SoC you are using?
>>> You can also refer to the appropriate dts file to see if there is L2C.
>>> For example, in canyonlands.dts (460EX based board), we have the L2C
>>> entry.
>>>         L2C0: l2c {
>>>               ...
>>>         }
>>>
>>>    
>>>> I am seeing this problem with our custom IDE driver which is based on
>>>>       
>>
>>  
>>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>>       
>> the
>>  
>>>> physical DMA memory and alloc_pages() to allocate a virtual page. 
>>>> It then uses pci_map_sg() to map to a scatter/gather buffer. 
>>>> Perhaps I should convert these to the DMA API calls as you suggest.
>>>>       
>>> Could you give more details on the consistency problem? It is a good
>>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>>> work too
>>>
>>> Thanks
>>> Prodyut   
>>>
>>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>>    
>>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>>      
>>>>> Hi Adam,
>>>>>
>>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>>         
>>> section:
>>>    
>>>>> #ifdef CONFIG_44x
>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>>         
>>> _PAGE_GUARDED)
>>>    
>>>>> #else
>>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>>> #endif
>>>>>
>>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>>         
>>> that    
>>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>>         
>>> which    
>>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>>         
>>> the    
>>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>>         
>>> masked    
>>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>>         
>>
>>  
>>>>> coherency issues with non-SMP systems were resolved).
>>>>>         
>>>> I have some doubts about the usefulness of doing that for 4xx.
>>>>       
>> AFAIK,
>>  
>>>> the 440 core just ignores M.
>>>>
>>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>>       
>>> isn't
>>>    
>>>> enabled or not working ?
>>>>
>>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>>       
>>> sure
>>>    
>>>> they use the appropriate DMA APIs which will do cache flushing when
>>>> needed.
>>>>
>>>> Adam, what driver is causing you that sort of problems ?
>>>>
>>>> Cheers,
>>>> Ben.
>>>>
>>>>
>>>>       
>
>

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Mikhail Zolotaryov]

Hi,

Why manage cache lines  manually, if appropriate code is a part of 
__dma_sync / dma_sync_single_for_device of DMA API ? (implies 
CONFIG_NOT_COHERENT_CACHE enabled, as default for Sequoia Board)

Prodyut Hazarika wrote:
> Hi Adam,
>
>   
>> Yes, I am using the 440EPx (same as the sequoia board). 
>> Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
>>     
> (using
>   
>> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
>> end up being partially corrupted when we try to parse the data in the
>> virtual page. We have confirmed the data is good before the PCI-IDE
>> bridge. We are creating two 8K pages and map them to physical DMA
>>     
> memory
>   
>> using single-entry scatter/gather structs. When a DMA block is
>> corrupted, we see a random portion of it (always a multiple of 16byte
>> cache lines) is overwritten with old data from the last time the
>>     
> buffer
>   
>> was used. 
>>     
>
> This looks like a cache coherency problem.
> Can you ensure that the TLB entries corresponding to the DMA region has
> the CacheInhibit bit set.
> You will need a BDI connected to your system.
>
> Also, you will need to invalidate and flush the lines appropriately,
> since in 440 cores,
> L1Cache coherency is managed entirely by software.
> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> how to do it.
>
> Thanks
> Prodyut
>
> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
>   
>> Hi Adam,
>>
>>     
>>> Are you sure there is L2 cache on the 440?
>>>       
>> It depends on the SoC you are using. SoC like 460EX (Canyonlands
>>     
> board)
>   
>> have L2Cache.
>> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
>> has a 440 cpu core, but no L2Cache.
>> Could you please tell me which SoC you are using?
>> You can also refer to the appropriate dts file to see if there is L2C.
>> For example, in canyonlands.dts (460EX based board), we have the L2C
>> entry.
>>         L2C0: l2c {
>>               ...
>>         }
>>
>>     
>>> I am seeing this problem with our custom IDE driver which is based on
>>>       
>
>   
>>> pretty old code. Our driver uses pci_alloc_consistent() to allocate
>>>       
> the
>   
>>> physical DMA memory and alloc_pages() to allocate a virtual page. It 
>>> then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I 
>>> should convert these to the DMA API calls as you suggest.
>>>       
>> Could you give more details on the consistency problem? It is a good
>> idea to change to the new DMA APIs, but pci_alloc_consistent() should
>> work too
>>
>> Thanks
>> Prodyut	
>>
>> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
>>     
>>> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
>>>       
>>>> Hi Adam,
>>>>
>>>> If you have a look in include/asm-ppc/pgtable.h for the following
>>>>         
>> section:
>>     
>>>> #ifdef CONFIG_44x
>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
>>>>         
>> _PAGE_GUARDED)
>>     
>>>> #else
>>>> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
>>>> #endif
>>>>
>>>> Try adding _PAGE_COHERENT to the appropriate line above and see if
>>>>         
>> that 
>>     
>>>> fixes your issue - this causes the 'M' bit to be set on the page
>>>>         
>> which 
>>     
>>>> sure enforce cache coherency. If it doesn't, you'll need to check
>>>>         
>> the 
>>     
>>>> 'M' bit isn't being masked out in head_44x.S (it was originally
>>>>         
>> masked 
>>     
>>>> out on arch/powerpc, but was fixed in later kernels when the cache
>>>>         
>
>   
>>>> coherency issues with non-SMP systems were resolved).
>>>>         
>>> I have some doubts about the usefulness of doing that for 4xx.
>>>       
> AFAIK,
>   
>>> the 440 core just ignores M.
>>>
>>> The problem lies probably elsewhere. Maybe the L2 cache coherency
>>>       
>> isn't
>>     
>>> enabled or not working ?
>>>
>>> The L1 cache on 440 is simply not coherent, so drivers have to make
>>>       
>> sure
>>     
>>> they use the appropriate DMA APIs which will do cache flushing when
>>> needed.
>>>
>>> Adam, what driver is causing you that sort of problems ?
>>>
>>> Cheers,
>>> Ben.
>>>
>>>
>>>       

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Tue, 2009-09-08 at 16:00 -0400, Adam Zilkie wrote:
> We are using pci_alloc_consistent()

Then your flush should have no effect since pci_alloc_consistent will
return I=1 mapped memory, unless you don't have
CONFIG_NOT_COHERENT_CACHE for some reason.

Cheers,
Ben.

> Adam
> 
> On Tue, 2009-09-08 at 12:56 -0700, Prodyut Hazarika wrote:
> > > We have found that using flush_dcache_range() after each DMA solves
> > the
> > > problem. Ideally, we'd like to be able to allocate the virtual page in
> > > cache inhibited memory to avoid the performance loss from all the
> > flush
> > > calls. To do this, we'd have to change our TLB sizes and reserve a TLB
> > > in memory as cache inhibited (using the 'I' bit). Will update if this
> > > works as well. Thanks for your help in this.
> > 
> > Aren't you using dma_alloc_coherent to get buffers that are shared
> > between CPU and external devices?
> > 
> > Thanks
> > Prodyut
> > 
> > On Tue, 2009-09-08 at 11:59 -0700, Prodyut Hazarika wrote:
> > > Hi Adam,
> > > 
> > > > Yes, I am using the 440EPx (same as the sequoia board). 
> > > > Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> > > (using
> > > > the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> > timing)
> > > > end up being partially corrupted when we try to parse the data in
> > the
> > > > virtual page. We have confirmed the data is good before the PCI-IDE
> > > > bridge. We are creating two 8K pages and map them to physical DMA
> > > memory
> > > > using single-entry scatter/gather structs. When a DMA block is
> > > > corrupted, we see a random portion of it (always a multiple of
> > 16byte
> > > > cache lines) is overwritten with old data from the last time the
> > > buffer
> > > > was used. 
> > > 
> > > This looks like a cache coherency problem.
> > > Can you ensure that the TLB entries corresponding to the DMA region
> > has
> > > the CacheInhibit bit set.
> > > You will need a BDI connected to your system.
> > > 
> > > Also, you will need to invalidate and flush the lines appropriately,
> > > since in 440 cores,
> > > L1Cache coherency is managed entirely by software.
> > > Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> > > how to do it.
> > > 
> > > Thanks
> > > Prodyut
> > > 
> > > On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > > > Hi Adam,
> > > > 
> > > > > Are you sure there is L2 cache on the 440?
> > > > 
> > > > It depends on the SoC you are using. SoC like 460EX (Canyonlands
> > > board)
> > > > have L2Cache.
> > > > It seems you are using a Sequoia board, which has a 440EPx SoC.
> > 440EPx
> > > > has a 440 cpu core, but no L2Cache.
> > > > Could you please tell me which SoC you are using?
> > > > You can also refer to the appropriate dts file to see if there is
> > L2C.
> > > > For example, in canyonlands.dts (460EX based board), we have the L2C
> > > > entry.
> > > >         L2C0: l2c {
> > > >               ...
> > > >         }
> > > > 
> > > > >I am seeing this problem with our custom IDE driver which is based
> > on
> > > 
> > > > >pretty old code. Our driver uses pci_alloc_consistent() to allocate
> > > the
> > > > 
> > > > >physical DMA memory and alloc_pages() to allocate a virtual page.
> > It 
> > > > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I
> > 
> > > > >should convert these to the DMA API calls as you suggest.
> > > > 
> > > > Could you give more details on the consistency problem? It is a good
> > > > idea to change to the new DMA APIs, but pci_alloc_consistent()
> > should
> > > > work too
> > > > 
> > > > Thanks
> > > > Prodyut	
> > > > 
> > > > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > > > Hi Adam,
> > > > > > 
> > > > > > If you have a look in include/asm-ppc/pgtable.h for the
> > following
> > > > section:
> > > > > > #ifdef CONFIG_44x
> > > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > > > _PAGE_GUARDED)
> > > > > > #else
> > > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > > > #endif
> > > > > > 
> > > > > > Try adding _PAGE_COHERENT to the appropriate line above and see
> > if
> > > > that 
> > > > > > fixes your issue - this causes the 'M' bit to be set on the page
> > > > which 
> > > > > > sure enforce cache coherency. If it doesn't, you'll need to
> > check
> > > > the 
> > > > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > > > masked 
> > > > > > out on arch/powerpc, but was fixed in later kernels when the
> > cache
> > > 
> > > > > > coherency issues with non-SMP systems were resolved).
> > > > > 
> > > > > I have some doubts about the usefulness of doing that for 4xx.
> > > AFAIK,
> > > > > the 440 core just ignores M.
> > > > > 
> > > > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > > > isn't
> > > > > enabled or not working ?
> > > > > 
> > > > > The L1 cache on 440 is simply not coherent, so drivers have to
> > make
> > > > sure
> > > > > they use the appropriate DMA APIs which will do cache flushing
> > when
> > > > > needed.
> > > > > 
> > > > > Adam, what driver is causing you that sort of problems ?
> > > > > 
> > > > > Cheers,
> > > > > Ben.
> > > > > 
> > > > > 
> > > -- 
> > > Adam Zilkie
> > > Software Designer,
> > > International Datacasting Corp.
> > > 
> > > This message and the documents attached hereto are intended only for
> > the
> > > addressee and may contain privileged or confidential information. Any
> > > unauthorized disclosure is strictly prohibited. If you have received
> > > this message in error, please notify us immediately so that we may
> > > correct our internal records. Please then delete the original message.
> > > Thank you.
> > > --------------------------------------------------------
> > > 
> > > CONFIDENTIALITY NOTICE: This e-mail message, including any
> > attachments, is for the sole use of the intended recipient(s) and
> > contains information that is confidential and proprietary to
> > AppliedMicro Corporation or its subsidiaries. It is to be used solely
> > for the purpose of furthering the parties' business relationship. All
> > unauthorized review, use, disclosure or distribution is prohibited. If
> > you are not the intended recipient, please contact the sender by reply
> > e-mail and destroy all copies of the original message.
> > > 

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Tue, 2009-09-08 at 15:30 -0400, Adam Zilkie wrote:
> All,
> 
> We have found that using flush_dcache_range() after each DMA solves the
> problem. Ideally, we'd like to be able to allocate the virtual page in
> cache inhibited memory to avoid the performance loss from all the flush
> calls. To do this, we'd have to change our TLB sizes and reserve a TLB
> in memory as cache inhibited (using the 'I' bit). Will update if this
> works as well. Thanks for your help in this.

I think the problem is that you are manipulating the TLB directly, which
you shouldn't have to do. You also shouldn't have to use
flush_dcache_range() yourself neither.

It should all be handled by the DMA and PCI DMA APIs, you are just not
using those correctly.

You have two choice. You can either allocate memory permanently mapped
with I=1, in which case, use pci_alloc_consistent() (or
dma_alloc_coherent(), same thing).

Or you can use "normal" memory and ensure you flush/invalidate the cache
at the right time, which you can do with something like
pci_map_sg/pci_unmap_sg (or dma_* variants) or the dma_sync_* functions.

It's all pretty standard mechanisms in Linux, other platforms also have
non-coherent DMA (such as some ARMs) and those functions are generic.

Cheers,
Ben.

> Regards,
> Adam
> 
> On Tue, 2009-09-08 at 11:59 -0700, Prodyut Hazarika wrote:
> > Hi Adam,
> > 
> > > Yes, I am using the 440EPx (same as the sequoia board). 
> > > Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> > (using
> > > the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> > > end up being partially corrupted when we try to parse the data in the
> > > virtual page. We have confirmed the data is good before the PCI-IDE
> > > bridge. We are creating two 8K pages and map them to physical DMA
> > memory
> > > using single-entry scatter/gather structs. When a DMA block is
> > > corrupted, we see a random portion of it (always a multiple of 16byte
> > > cache lines) is overwritten with old data from the last time the
> > buffer
> > > was used. 
> > 
> > This looks like a cache coherency problem.
> > Can you ensure that the TLB entries corresponding to the DMA region has
> > the CacheInhibit bit set.
> > You will need a BDI connected to your system.
> > 
> > Also, you will need to invalidate and flush the lines appropriately,
> > since in 440 cores,
> > L1Cache coherency is managed entirely by software.
> > Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> > how to do it.
> > 
> > Thanks
> > Prodyut
> > 
> > On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > > Hi Adam,
> > > 
> > > > Are you sure there is L2 cache on the 440?
> > > 
> > > It depends on the SoC you are using. SoC like 460EX (Canyonlands
> > board)
> > > have L2Cache.
> > > It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> > > has a 440 cpu core, but no L2Cache.
> > > Could you please tell me which SoC you are using?
> > > You can also refer to the appropriate dts file to see if there is L2C.
> > > For example, in canyonlands.dts (460EX based board), we have the L2C
> > > entry.
> > >         L2C0: l2c {
> > >               ...
> > >         }
> > > 
> > > >I am seeing this problem with our custom IDE driver which is based on
> > 
> > > >pretty old code. Our driver uses pci_alloc_consistent() to allocate
> > the
> > > 
> > > >physical DMA memory and alloc_pages() to allocate a virtual page. It 
> > > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I 
> > > >should convert these to the DMA API calls as you suggest.
> > > 
> > > Could you give more details on the consistency problem? It is a good
> > > idea to change to the new DMA APIs, but pci_alloc_consistent() should
> > > work too
> > > 
> > > Thanks
> > > Prodyut	
> > > 
> > > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > > Hi Adam,
> > > > > 
> > > > > If you have a look in include/asm-ppc/pgtable.h for the following
> > > section:
> > > > > #ifdef CONFIG_44x
> > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > > _PAGE_GUARDED)
> > > > > #else
> > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > > #endif
> > > > > 
> > > > > Try adding _PAGE_COHERENT to the appropriate line above and see if
> > > that 
> > > > > fixes your issue - this causes the 'M' bit to be set on the page
> > > which 
> > > > > sure enforce cache coherency. If it doesn't, you'll need to check
> > > the 
> > > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > > masked 
> > > > > out on arch/powerpc, but was fixed in later kernels when the cache
> > 
> > > > > coherency issues with non-SMP systems were resolved).
> > > > 
> > > > I have some doubts about the usefulness of doing that for 4xx.
> > AFAIK,
> > > > the 440 core just ignores M.
> > > > 
> > > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > > isn't
> > > > enabled or not working ?
> > > > 
> > > > The L1 cache on 440 is simply not coherent, so drivers have to make
> > > sure
> > > > they use the appropriate DMA APIs which will do cache flushing when
> > > > needed.
> > > > 
> > > > Adam, what driver is causing you that sort of problems ?
> > > > 
> > > > Cheers,
> > > > Ben.
> > > > 
> > > > 
> > -- 
> > Adam Zilkie
> > Software Designer,
> > International Datacasting Corp.
> > 
> > This message and the documents attached hereto are intended only for the
> > addressee and may contain privileged or confidential information. Any
> > unauthorized disclosure is strictly prohibited. If you have received
> > this message in error, please notify us immediately so that we may
> > correct our internal records. Please then delete the original message.
> > Thank you.
> > --------------------------------------------------------
> > 
> > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> > 

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Tue, 2009-09-08 at 14:01 -0400, Adam Zilkie wrote:
> Hi Prodyut,
> 
> Yes, I am using the 440EPx (same as the sequoia board). 
> Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus (using
> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> end up being partially corrupted when we try to parse the data in the
> virtual page. We have confirmed the data is good before the PCI-IDE
> bridge. We are creating two 8K pages and map them to physical DMA memory
> using single-entry scatter/gather structs. When a DMA block is
> corrupted, we see a random portion of it (always a multiple of 16byte
> cache lines) is overwritten with old data from the last time the buffer
> was used. 

Smells to me like you aren't properly using the dma or pci dma APIs to
flush/invalidate the cache around your transfers.

Ben.


> Regards,
> Adam
> 
> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > Hi Adam,
> > 
> > > Are you sure there is L2 cache on the 440?
> > 
> > It depends on the SoC you are using. SoC like 460EX (Canyonlands board)
> > have L2Cache.
> > It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> > has a 440 cpu core, but no L2Cache.
> > Could you please tell me which SoC you are using?
> > You can also refer to the appropriate dts file to see if there is L2C.
> > For example, in canyonlands.dts (460EX based board), we have the L2C
> > entry.
> >         L2C0: l2c {
> >               ...
> >         }
> > 
> > >I am seeing this problem with our custom IDE driver which is based on 
> > >pretty old code. Our driver uses pci_alloc_consistent() to allocate the
> > 
> > >physical DMA memory and alloc_pages() to allocate a virtual page. It 
> > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I 
> > >should convert these to the DMA API calls as you suggest.
> > 
> > Could you give more details on the consistency problem? It is a good
> > idea to change to the new DMA APIs, but pci_alloc_consistent() should
> > work too
> > 
> > Thanks
> > Prodyut	
> > 
> > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > Hi Adam,
> > > > 
> > > > If you have a look in include/asm-ppc/pgtable.h for the following
> > section:
> > > > #ifdef CONFIG_44x
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > _PAGE_GUARDED)
> > > > #else
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > #endif
> > > > 
> > > > Try adding _PAGE_COHERENT to the appropriate line above and see if
> > that 
> > > > fixes your issue - this causes the 'M' bit to be set on the page
> > which 
> > > > sure enforce cache coherency. If it doesn't, you'll need to check
> > the 
> > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > masked 
> > > > out on arch/powerpc, but was fixed in later kernels when the cache 
> > > > coherency issues with non-SMP systems were resolved).
> > > 
> > > I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> > > the 440 core just ignores M.
> > > 
> > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > isn't
> > > enabled or not working ?
> > > 
> > > The L1 cache on 440 is simply not coherent, so drivers have to make
> > sure
> > > they use the appropriate DMA APIs which will do cache flushing when
> > > needed.
> > > 
> > > Adam, what driver is causing you that sort of problems ?
> > > 
> > > Cheers,
> > > Ben.
> > > 
> > > 

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

We are using pci_alloc_consistent()

Adam

On Tue, 2009-09-08 at 12:56 -0700, Prodyut Hazarika wrote:
> > We have found that using flush_dcache_range() after each DMA solves
> the
> > problem. Ideally, we'd like to be able to allocate the virtual page in
> > cache inhibited memory to avoid the performance loss from all the
> flush
> > calls. To do this, we'd have to change our TLB sizes and reserve a TLB
> > in memory as cache inhibited (using the 'I' bit). Will update if this
> > works as well. Thanks for your help in this.
> 
> Aren't you using dma_alloc_coherent to get buffers that are shared
> between CPU and external devices?
> 
> Thanks
> Prodyut
> 
> On Tue, 2009-09-08 at 11:59 -0700, Prodyut Hazarika wrote:
> > Hi Adam,
> > 
> > > Yes, I am using the 440EPx (same as the sequoia board). 
> > > Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> > (using
> > > the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
> timing)
> > > end up being partially corrupted when we try to parse the data in
> the
> > > virtual page. We have confirmed the data is good before the PCI-IDE
> > > bridge. We are creating two 8K pages and map them to physical DMA
> > memory
> > > using single-entry scatter/gather structs. When a DMA block is
> > > corrupted, we see a random portion of it (always a multiple of
> 16byte
> > > cache lines) is overwritten with old data from the last time the
> > buffer
> > > was used. 
> > 
> > This looks like a cache coherency problem.
> > Can you ensure that the TLB entries corresponding to the DMA region
> has
> > the CacheInhibit bit set.
> > You will need a BDI connected to your system.
> > 
> > Also, you will need to invalidate and flush the lines appropriately,
> > since in 440 cores,
> > L1Cache coherency is managed entirely by software.
> > Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> > how to do it.
> > 
> > Thanks
> > Prodyut
> > 
> > On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > > Hi Adam,
> > > 
> > > > Are you sure there is L2 cache on the 440?
> > > 
> > > It depends on the SoC you are using. SoC like 460EX (Canyonlands
> > board)
> > > have L2Cache.
> > > It seems you are using a Sequoia board, which has a 440EPx SoC.
> 440EPx
> > > has a 440 cpu core, but no L2Cache.
> > > Could you please tell me which SoC you are using?
> > > You can also refer to the appropriate dts file to see if there is
> L2C.
> > > For example, in canyonlands.dts (460EX based board), we have the L2C
> > > entry.
> > >         L2C0: l2c {
> > >               ...
> > >         }
> > > 
> > > >I am seeing this problem with our custom IDE driver which is based
> on
> > 
> > > >pretty old code. Our driver uses pci_alloc_consistent() to allocate
> > the
> > > 
> > > >physical DMA memory and alloc_pages() to allocate a virtual page.
> It 
> > > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I
> 
> > > >should convert these to the DMA API calls as you suggest.
> > > 
> > > Could you give more details on the consistency problem? It is a good
> > > idea to change to the new DMA APIs, but pci_alloc_consistent()
> should
> > > work too
> > > 
> > > Thanks
> > > Prodyut	
> > > 
> > > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > > Hi Adam,
> > > > > 
> > > > > If you have a look in include/asm-ppc/pgtable.h for the
> following
> > > section:
> > > > > #ifdef CONFIG_44x
> > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > > _PAGE_GUARDED)
> > > > > #else
> > > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > > #endif
> > > > > 
> > > > > Try adding _PAGE_COHERENT to the appropriate line above and see
> if
> > > that 
> > > > > fixes your issue - this causes the 'M' bit to be set on the page
> > > which 
> > > > > sure enforce cache coherency. If it doesn't, you'll need to
> check
> > > the 
> > > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > > masked 
> > > > > out on arch/powerpc, but was fixed in later kernels when the
> cache
> > 
> > > > > coherency issues with non-SMP systems were resolved).
> > > > 
> > > > I have some doubts about the usefulness of doing that for 4xx.
> > AFAIK,
> > > > the 440 core just ignores M.
> > > > 
> > > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > > isn't
> > > > enabled or not working ?
> > > > 
> > > > The L1 cache on 440 is simply not coherent, so drivers have to
> make
> > > sure
> > > > they use the appropriate DMA APIs which will do cache flushing
> when
> > > > needed.
> > > > 
> > > > Adam, what driver is causing you that sort of problems ?
> > > > 
> > > > Cheers,
> > > > Ben.
> > > > 
> > > > 
> > -- 
> > Adam Zilkie
> > Software Designer,
> > International Datacasting Corp.
> > 
> > This message and the documents attached hereto are intended only for
> the
> > addressee and may contain privileged or confidential information. Any
> > unauthorized disclosure is strictly prohibited. If you have received
> > this message in error, please notify us immediately so that we may
> > correct our internal records. Please then delete the original message.
> > Thank you.
> > --------------------------------------------------------
> > 
> > CONFIDENTIALITY NOTICE: This e-mail message, including any
> attachments, is for the sole use of the intended recipient(s) and
> contains information that is confidential and proprietary to
> AppliedMicro Corporation or its subsidiaries. It is to be used solely
> for the purpose of furthering the parties' business relationship. All
> unauthorized review, use, disclosure or distribution is prohibited. If
> you are not the intended recipient, please contact the sender by reply
> e-mail and destroy all copies of the original message.
> > 
-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Prodyut Hazarika]

> We have found that using flush_dcache_range() after each DMA solves
the
> problem. Ideally, we'd like to be able to allocate the virtual page in
> cache inhibited memory to avoid the performance loss from all the
flush
> calls. To do this, we'd have to change our TLB sizes and reserve a TLB
> in memory as cache inhibited (using the 'I' bit). Will update if this
> works as well. Thanks for your help in this.

Aren't you using dma_alloc_coherent to get buffers that are shared
between CPU and external devices?

Thanks
Prodyut

On Tue, 2009-09-08 at 11:59 -0700, Prodyut Hazarika wrote:
> Hi Adam,
>=20
> > Yes, I am using the 440EPx (same as the sequoia board).=20
> > Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> (using
> > the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on
timing)
> > end up being partially corrupted when we try to parse the data in
the
> > virtual page. We have confirmed the data is good before the PCI-IDE
> > bridge. We are creating two 8K pages and map them to physical DMA
> memory
> > using single-entry scatter/gather structs. When a DMA block is
> > corrupted, we see a random portion of it (always a multiple of
16byte
> > cache lines) is overwritten with old data from the last time the
> buffer
> > was used.=20
>=20
> This looks like a cache coherency problem.
> Can you ensure that the TLB entries corresponding to the DMA region
has
> the CacheInhibit bit set.
> You will need a BDI connected to your system.
>=20
> Also, you will need to invalidate and flush the lines appropriately,
> since in 440 cores,
> L1Cache coherency is managed entirely by software.
> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> how to do it.
>=20
> Thanks
> Prodyut
>=20
> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > Hi Adam,
> >=20
> > > Are you sure there is L2 cache on the 440?
> >=20
> > It depends on the SoC you are using. SoC like 460EX (Canyonlands
> board)
> > have L2Cache.
> > It seems you are using a Sequoia board, which has a 440EPx SoC.
440EPx
> > has a 440 cpu core, but no L2Cache.
> > Could you please tell me which SoC you are using?
> > You can also refer to the appropriate dts file to see if there is
L2C.
> > For example, in canyonlands.dts (460EX based board), we have the L2C
> > entry.
> >         L2C0: l2c {
> >               ...
> >         }
> >=20
> > >I am seeing this problem with our custom IDE driver which is based
on
>=20
> > >pretty old code. Our driver uses pci_alloc_consistent() to allocate
> the
> >=20
> > >physical DMA memory and alloc_pages() to allocate a virtual page.
It=20
> > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I

> > >should convert these to the DMA API calls as you suggest.
> >=20
> > Could you give more details on the consistency problem? It is a good
> > idea to change to the new DMA APIs, but pci_alloc_consistent()
should
> > work too
> >=20
> > Thanks
> > Prodyut=09
> >=20
> > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > Hi Adam,
> > > >=20
> > > > If you have a look in include/asm-ppc/pgtable.h for the
following
> > section:
> > > > #ifdef CONFIG_44x
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > _PAGE_GUARDED)
> > > > #else
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > #endif
> > > >=20
> > > > Try adding _PAGE_COHERENT to the appropriate line above and see
if
> > that=20
> > > > fixes your issue - this causes the 'M' bit to be set on the page
> > which=20
> > > > sure enforce cache coherency. If it doesn't, you'll need to
check
> > the=20
> > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > masked=20
> > > > out on arch/powerpc, but was fixed in later kernels when the
cache
>=20
> > > > coherency issues with non-SMP systems were resolved).
> > >=20
> > > I have some doubts about the usefulness of doing that for 4xx.
> AFAIK,
> > > the 440 core just ignores M.
> > >=20
> > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > isn't
> > > enabled or not working ?
> > >=20
> > > The L1 cache on 440 is simply not coherent, so drivers have to
make
> > sure
> > > they use the appropriate DMA APIs which will do cache flushing
when
> > > needed.
> > >=20
> > > Adam, what driver is causing you that sort of problems ?
> > >=20
> > > Cheers,
> > > Ben.
> > >=20
> > >=20
> --=20
> Adam Zilkie
> Software Designer,
> International Datacasting Corp.
>=20
> This message and the documents attached hereto are intended only for
the
> addressee and may contain privileged or confidential information. Any
> unauthorized disclosure is strictly prohibited. If you have received
> this message in error, please notify us immediately so that we may
> correct our internal records. Please then delete the original message.
> Thank you.
> --------------------------------------------------------
>=20
> CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and
contains information that is confidential and proprietary to
AppliedMicro Corporation or its subsidiaries. It is to be used solely
for the purpose of furthering the parties' business relationship. All
unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.
>=20
--=20
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is strictly prohibited. If you have received
this message in error, please notify us immediately so that we may
correct our internal records. Please then delete the original message.
Thank you.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

All,

We have found that using flush_dcache_range() after each DMA solves the
problem. Ideally, we'd like to be able to allocate the virtual page in
cache inhibited memory to avoid the performance loss from all the flush
calls. To do this, we'd have to change our TLB sizes and reserve a TLB
in memory as cache inhibited (using the 'I' bit). Will update if this
works as well. Thanks for your help in this.

Regards,
Adam

On Tue, 2009-09-08 at 11:59 -0700, Prodyut Hazarika wrote:
> Hi Adam,
> 
> > Yes, I am using the 440EPx (same as the sequoia board). 
> > Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
> (using
> > the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> > end up being partially corrupted when we try to parse the data in the
> > virtual page. We have confirmed the data is good before the PCI-IDE
> > bridge. We are creating two 8K pages and map them to physical DMA
> memory
> > using single-entry scatter/gather structs. When a DMA block is
> > corrupted, we see a random portion of it (always a multiple of 16byte
> > cache lines) is overwritten with old data from the last time the
> buffer
> > was used. 
> 
> This looks like a cache coherency problem.
> Can you ensure that the TLB entries corresponding to the DMA region has
> the CacheInhibit bit set.
> You will need a BDI connected to your system.
> 
> Also, you will need to invalidate and flush the lines appropriately,
> since in 440 cores,
> L1Cache coherency is managed entirely by software.
> Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
> how to do it.
> 
> Thanks
> Prodyut
> 
> On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> > Hi Adam,
> > 
> > > Are you sure there is L2 cache on the 440?
> > 
> > It depends on the SoC you are using. SoC like 460EX (Canyonlands
> board)
> > have L2Cache.
> > It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> > has a 440 cpu core, but no L2Cache.
> > Could you please tell me which SoC you are using?
> > You can also refer to the appropriate dts file to see if there is L2C.
> > For example, in canyonlands.dts (460EX based board), we have the L2C
> > entry.
> >         L2C0: l2c {
> >               ...
> >         }
> > 
> > >I am seeing this problem with our custom IDE driver which is based on
> 
> > >pretty old code. Our driver uses pci_alloc_consistent() to allocate
> the
> > 
> > >physical DMA memory and alloc_pages() to allocate a virtual page. It 
> > >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I 
> > >should convert these to the DMA API calls as you suggest.
> > 
> > Could you give more details on the consistency problem? It is a good
> > idea to change to the new DMA APIs, but pci_alloc_consistent() should
> > work too
> > 
> > Thanks
> > Prodyut	
> > 
> > On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > > Hi Adam,
> > > > 
> > > > If you have a look in include/asm-ppc/pgtable.h for the following
> > section:
> > > > #ifdef CONFIG_44x
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> > _PAGE_GUARDED)
> > > > #else
> > > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > > #endif
> > > > 
> > > > Try adding _PAGE_COHERENT to the appropriate line above and see if
> > that 
> > > > fixes your issue - this causes the 'M' bit to be set on the page
> > which 
> > > > sure enforce cache coherency. If it doesn't, you'll need to check
> > the 
> > > > 'M' bit isn't being masked out in head_44x.S (it was originally
> > masked 
> > > > out on arch/powerpc, but was fixed in later kernels when the cache
> 
> > > > coherency issues with non-SMP systems were resolved).
> > > 
> > > I have some doubts about the usefulness of doing that for 4xx.
> AFAIK,
> > > the 440 core just ignores M.
> > > 
> > > The problem lies probably elsewhere. Maybe the L2 cache coherency
> > isn't
> > > enabled or not working ?
> > > 
> > > The L1 cache on 440 is simply not coherent, so drivers have to make
> > sure
> > > they use the appropriate DMA APIs which will do cache flushing when
> > > needed.
> > > 
> > > Adam, what driver is causing you that sort of problems ?
> > > 
> > > Cheers,
> > > Ben.
> > > 
> > > 
> -- 
> Adam Zilkie
> Software Designer,
> International Datacasting Corp.
> 
> This message and the documents attached hereto are intended only for the
> addressee and may contain privileged or confidential information. Any
> unauthorized disclosure is strictly prohibited. If you have received
> this message in error, please notify us immediately so that we may
> correct our internal records. Please then delete the original message.
> Thank you.
> --------------------------------------------------------
> 
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. All unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
> 
-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Prodyut Hazarika]

Hi Adam,

> Yes, I am using the 440EPx (same as the sequoia board).=20
> Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus
(using
> the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
> end up being partially corrupted when we try to parse the data in the
> virtual page. We have confirmed the data is good before the PCI-IDE
> bridge. We are creating two 8K pages and map them to physical DMA
memory
> using single-entry scatter/gather structs. When a DMA block is
> corrupted, we see a random portion of it (always a multiple of 16byte
> cache lines) is overwritten with old data from the last time the
buffer
> was used.=20

This looks like a cache coherency problem.
Can you ensure that the TLB entries corresponding to the DMA region has
the CacheInhibit bit set.
You will need a BDI connected to your system.

Also, you will need to invalidate and flush the lines appropriately,
since in 440 cores,
L1Cache coherency is managed entirely by software.
Please look at drivers/net/ibm_newemac/mal.c and core.c for example on
how to do it.

Thanks
Prodyut

On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> Hi Adam,
>=20
> > Are you sure there is L2 cache on the 440?
>=20
> It depends on the SoC you are using. SoC like 460EX (Canyonlands
board)
> have L2Cache.
> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> has a 440 cpu core, but no L2Cache.
> Could you please tell me which SoC you are using?
> You can also refer to the appropriate dts file to see if there is L2C.
> For example, in canyonlands.dts (460EX based board), we have the L2C
> entry.
>         L2C0: l2c {
>               ...
>         }
>=20
> >I am seeing this problem with our custom IDE driver which is based on

> >pretty old code. Our driver uses pci_alloc_consistent() to allocate
the
>=20
> >physical DMA memory and alloc_pages() to allocate a virtual page. It=20
> >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I=20
> >should convert these to the DMA API calls as you suggest.
>=20
> Could you give more details on the consistency problem? It is a good
> idea to change to the new DMA APIs, but pci_alloc_consistent() should
> work too
>=20
> Thanks
> Prodyut=09
>=20
> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > Hi Adam,
> > >=20
> > > If you have a look in include/asm-ppc/pgtable.h for the following
> section:
> > > #ifdef CONFIG_44x
> > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> _PAGE_GUARDED)
> > > #else
> > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > #endif
> > >=20
> > > Try adding _PAGE_COHERENT to the appropriate line above and see if
> that=20
> > > fixes your issue - this causes the 'M' bit to be set on the page
> which=20
> > > sure enforce cache coherency. If it doesn't, you'll need to check
> the=20
> > > 'M' bit isn't being masked out in head_44x.S (it was originally
> masked=20
> > > out on arch/powerpc, but was fixed in later kernels when the cache

> > > coherency issues with non-SMP systems were resolved).
> >=20
> > I have some doubts about the usefulness of doing that for 4xx.
AFAIK,
> > the 440 core just ignores M.
> >=20
> > The problem lies probably elsewhere. Maybe the L2 cache coherency
> isn't
> > enabled or not working ?
> >=20
> > The L1 cache on 440 is simply not coherent, so drivers have to make
> sure
> > they use the appropriate DMA APIs which will do cache flushing when
> > needed.
> >=20
> > Adam, what driver is causing you that sort of problems ?
> >=20
> > Cheers,
> > Ben.
> >=20
> >=20
--=20
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is strictly prohibited. If you have received
this message in error, please notify us immediately so that we may
correct our internal records. Please then delete the original message.
Thank you.
--------------------------------------------------------

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains =
information that is confidential and proprietary to AppliedMicro =
Corporation or its subsidiaries. It is to be used solely for the purpose =
of furthering the parties' business relationship. All unauthorized =
review, use, disclosure or distribution is prohibited. If you are not =
the intended recipient, please contact the sender by reply e-mail and =
destroy all copies of the original message.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

Hi Prodyut,

Yes, I am using the 440EPx (same as the sequoia board). 
Our ideDriver is DMA'ing blocks of 192-byte data over the PCI bus (using
the Sil0680A PCI-IDE bridge). Most of the DMA's (depending on timing)
end up being partially corrupted when we try to parse the data in the
virtual page. We have confirmed the data is good before the PCI-IDE
bridge. We are creating two 8K pages and map them to physical DMA memory
using single-entry scatter/gather structs. When a DMA block is
corrupted, we see a random portion of it (always a multiple of 16byte
cache lines) is overwritten with old data from the last time the buffer
was used. 

Regards,
Adam

On Thu, 2009-09-03 at 13:27 -0700, Prodyut Hazarika wrote:
> Hi Adam,
> 
> > Are you sure there is L2 cache on the 440?
> 
> It depends on the SoC you are using. SoC like 460EX (Canyonlands board)
> have L2Cache.
> It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
> has a 440 cpu core, but no L2Cache.
> Could you please tell me which SoC you are using?
> You can also refer to the appropriate dts file to see if there is L2C.
> For example, in canyonlands.dts (460EX based board), we have the L2C
> entry.
>         L2C0: l2c {
>               ...
>         }
> 
> >I am seeing this problem with our custom IDE driver which is based on 
> >pretty old code. Our driver uses pci_alloc_consistent() to allocate the
> 
> >physical DMA memory and alloc_pages() to allocate a virtual page. It 
> >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I 
> >should convert these to the DMA API calls as you suggest.
> 
> Could you give more details on the consistency problem? It is a good
> idea to change to the new DMA APIs, but pci_alloc_consistent() should
> work too
> 
> Thanks
> Prodyut	
> 
> On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > > Hi Adam,
> > > 
> > > If you have a look in include/asm-ppc/pgtable.h for the following
> section:
> > > #ifdef CONFIG_44x
> > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
> _PAGE_GUARDED)
> > > #else
> > > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > > #endif
> > > 
> > > Try adding _PAGE_COHERENT to the appropriate line above and see if
> that 
> > > fixes your issue - this causes the 'M' bit to be set on the page
> which 
> > > sure enforce cache coherency. If it doesn't, you'll need to check
> the 
> > > 'M' bit isn't being masked out in head_44x.S (it was originally
> masked 
> > > out on arch/powerpc, but was fixed in later kernels when the cache 
> > > coherency issues with non-SMP systems were resolved).
> > 
> > I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> > the 440 core just ignores M.
> > 
> > The problem lies probably elsewhere. Maybe the L2 cache coherency
> isn't
> > enabled or not working ?
> > 
> > The L1 cache on 440 is simply not coherent, so drivers have to make
> sure
> > they use the appropriate DMA APIs which will do cache flushing when
> > needed.
> > 
> > Adam, what driver is causing you that sort of problems ?
> > 
> > Cheers,
> > Ben.
> > 
> > 
-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Thu, 2009-09-03 at 13:20 +0100, Wrobel Heinz-R39252 wrote:
> Hi,
> 
> This doesn't seem right. If we are talking about a single CPU core chip,
> i.e., just one data cache, then setting M is typically a) useless and
> could even b) cause a performance penalty depending on a chip's
> implementation.
> The M bit is required if *other* cores with caches need to see changes
> for coherency of their caches. You wouldn't set it for one core only
> because your own core knows about its own cache.
> The possible performance penalty could happen because you need some way
> to tell the others that they better intercept a transaction. And that
> could, depending on the chip, by a clock extra or so per transaction.
> Now, in theory, a DMA engine could have caches, read from cache content
> first, and could snoop the bus on global transactions like another core,
> but I have never heard of such a beast. 

Actually there are some freescale part, afaik, that require M for proper
cache coherency :-) I don't have names off the top of my mind, I think
it has to be with PCI inbound buffers.

In this case, however, it's 440 on which I believe M is simply ignored.

Cheers,
Ben.

> Hope this helps,
> 
> Heinz
> 
> -----Original Message-----
> From: linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> ] On Behalf Of Chris Pringle
> Sent: Donnerstag, 3. September 2009 10:05
> To: azilkie@datacast.com
> Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
> Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
> 
> Hi Adam,
> 
> If you have a look in include/asm-ppc/pgtable.h for the following
> section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
> 
> Try adding _PAGE_COHERENT to the appropriate line above and see if that
> fixes your issue - this causes the 'M' bit to be set on the page which
> sure enforce cache coherency. If it doesn't, you'll need to check the
> 'M' bit isn't being masked out in head_44x.S (it was originally masked
> out on arch/powerpc, but was fixed in later kernels when the cache
> coherency issues with non-SMP systems were resolved).
> 
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry
> (pgtable-ppc32.h)
> 
> Hope this helps!
> 
> Cheers,
> Chris
> 
> Adam Zilkie wrote:
> > Hi Chris,
> >
> > I am having a problem similar to what you described in this
> discussion.
> > We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with 
> > compiles arch/ppc/kernel/head_44x.c (quite different from 
> > /arch/powerpc/kernel/head_32.S). I would like to apply your 
> > backporting patch to this architecture. Any help would be appreciated.
> >
> > Regards,
> > Adam
> >
> >   
> 
> 

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Prodyut Hazarika]

Hi Adam,

> Are you sure there is L2 cache on the 440?

It depends on the SoC you are using. SoC like 460EX (Canyonlands board)
have L2Cache.
It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
has a 440 cpu core, but no L2Cache.
Could you please tell me which SoC you are using?
You can also refer to the appropriate dts file to see if there is L2C.
For example, in canyonlands.dts (460EX based board), we have the L2C
entry.
        L2C0: l2c {
              ...
        }

>I am seeing this problem with our custom IDE driver which is based on=20
>pretty old code. Our driver uses pci_alloc_consistent() to allocate the

>physical DMA memory and alloc_pages() to allocate a virtual page. It=20
>then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I=20
>should convert these to the DMA API calls as you suggest.

Could you give more details on the consistency problem? It is a good
idea to change to the new DMA APIs, but pci_alloc_consistent() should
work too

Thanks
Prodyut=09

On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > Hi Adam,
> >=20
> > If you have a look in include/asm-ppc/pgtable.h for the following
section:
> > #ifdef CONFIG_44x
> > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED |
_PAGE_GUARDED)
> > #else
> > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > #endif
> >=20
> > Try adding _PAGE_COHERENT to the appropriate line above and see if
that=20
> > fixes your issue - this causes the 'M' bit to be set on the page
which=20
> > sure enforce cache coherency. If it doesn't, you'll need to check
the=20
> > 'M' bit isn't being masked out in head_44x.S (it was originally
masked=20
> > out on arch/powerpc, but was fixed in later kernels when the cache=20
> > coherency issues with non-SMP systems were resolved).
>=20
> I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> the 440 core just ignores M.
>=20
> The problem lies probably elsewhere. Maybe the L2 cache coherency
isn't
> enabled or not working ?
>=20
> The L1 cache on 440 is simply not coherent, so drivers have to make
sure
> they use the appropriate DMA APIs which will do cache flushing when
> needed.
>=20
> Adam, what driver is causing you that sort of problems ?
>=20
> Cheers,
> Ben.
>=20
>=20
--=20
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is strictly prohibited. If you have received
this message in error, please notify us immediately so that we may
correct our internal records. Please then delete the original message.
Thank you.


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--------------------------------------------------------

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, =
is for the sole use of the intended recipient(s) and contains =
information that is confidential and proprietary to AppliedMicro =
Corporation or its subsidiaries. It is to be used solely for the purpose =
of furthering the parties' business relationship. All unauthorized =
review, use, disclosure or distribution is prohibited. If you are not =
the intended recipient, please contact the sender by reply e-mail and =
destroy all copies of the original message.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Josh Boyer]

On Thu, Sep 03, 2009 at 12:04:50PM -0400, Adam Zilkie wrote:
>Ben,
>
>Thanks for your info.
>
>Are you sure there is L2 cache on the 440?

It depends on which 440 SoC you have.  It also depends on that being 
configured in the kernel even if it does exist.

>I am seeing this problem with our custom IDE driver which is based on
>pretty old code. Our driver uses pci_alloc_consistent() to allocate the
>physical DMA memory and alloc_pages() to allocate a virtual page. It
>then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I
>should convert these to the DMA API calls as you suggest.

I would suggest updating the code.  I have no idea if that is the problem,
but it should probably be done anyway.

josh

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

Ben,

Thanks for your info.

Are you sure there is L2 cache on the 440?

I am seeing this problem with our custom IDE driver which is based on
pretty old code. Our driver uses pci_alloc_consistent() to allocate the
physical DMA memory and alloc_pages() to allocate a virtual page. It
then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I
should convert these to the DMA API calls as you suggest.

Regards,
Adam

On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > Hi Adam,
> > 
> > If you have a look in include/asm-ppc/pgtable.h for the following section:
> > #ifdef CONFIG_44x
> > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> > #else
> > #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> > #endif
> > 
> > Try adding _PAGE_COHERENT to the appropriate line above and see if that 
> > fixes your issue - this causes the 'M' bit to be set on the page which 
> > sure enforce cache coherency. If it doesn't, you'll need to check the 
> > 'M' bit isn't being masked out in head_44x.S (it was originally masked 
> > out on arch/powerpc, but was fixed in later kernels when the cache 
> > coherency issues with non-SMP systems were resolved).
> 
> I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> the 440 core just ignores M.
> 
> The problem lies probably elsewhere. Maybe the L2 cache coherency isn't
> enabled or not working ?
> 
> The L1 cache on 440 is simply not coherent, so drivers have to make sure
> they use the appropriate DMA APIs which will do cache flushing when
> needed.
> 
> Adam, what driver is causing you that sort of problems ?
> 
> Cheers,
> Ben.
> 
> 
-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

Chris,

I noticed the following comment in pgtable.h: 

* - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
 *     doesn't support SMP. So we can use this as software bit, like
 *     DIRTY.

And _PAGE_COHERENT is not defined for the 44x (giving a compile error
when I add it the _PAGE_BASE line as you suggested). This would confirm
that the M bit is meaningless for the PPC440

Regards,
Adam


On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> Hi Adam,
> 
> If you have a look in include/asm-ppc/pgtable.h for the following section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
> 
> Try adding _PAGE_COHERENT to the appropriate line above and see if that 
> fixes your issue - this causes the 'M' bit to be set on the page which 
> sure enforce cache coherency. If it doesn't, you'll need to check the 
> 'M' bit isn't being masked out in head_44x.S (it was originally masked 
> out on arch/powerpc, but was fixed in later kernels when the cache 
> coherency issues with non-SMP systems were resolved).
> 
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry 
> (pgtable-ppc32.h)
> 
> Hope this helps!
> 
> Cheers,
> Chris
> 
> Adam Zilkie wrote:
> > Hi Chris,
> >
> > I am having a problem similar to what you described in this discussion.
> > We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
> > arch/ppc/kernel/head_44x.c (quite different
> > from /arch/powerpc/kernel/head_32.S). I would like to apply your
> > backporting patch to this architecture. Any help would be appreciated.
> >
> > Regards,
> > Adam 
> >
> >   
> 
> 
-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

In our case, we were suffering coherency issues on an 8260 when using 
DMA with PCI. Setting the 'M' bit cured all of our DMA coherency issues.

There is a comment in "pgtable-ppc32.h" on 2.6.29.6 that says:
"We always set _PAGE_COHERENT when SMP is enabled *or* the processor 
might need it for DMA coherency". Freescale had also suggested setting 
the 'M' bit when we submitted a support request.

I've no idea how this bit affects other PowerPC chips. Looking briefly 
through some of the header files, it looks as if the 'M' bit should not 
be set for 44x, so the issue is probably not the same as the one I had.

Cheers,
Chris

Wrobel Heinz-R39252 wrote:
> Hi,
>
> This doesn't seem right. If we are talking about a single CPU core chip,
> i.e., just one data cache, then setting M is typically a) useless and
> could even b) cause a performance penalty depending on a chip's
> implementation.
> The M bit is required if *other* cores with caches need to see changes
> for coherency of their caches. You wouldn't set it for one core only
> because your own core knows about its own cache.
> The possible performance penalty could happen because you need some way
> to tell the others that they better intercept a transaction. And that
> could, depending on the chip, by a clock extra or so per transaction.
> Now, in theory, a DMA engine could have caches, read from cache content
> first, and could snoop the bus on global transactions like another core,
> but I have never heard of such a beast. 
>
> Hope this helps,
>
> Heinz
>
> -----Original Message-----
> From: linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> [mailto:linuxppc-dev-bounces+heinz.wrobel=freescale.com@lists.ozlabs.org
> ] On Behalf Of Chris Pringle
> Sent: Donnerstag, 3. September 2009 10:05
> To: azilkie@datacast.com
> Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
> Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
>
> Hi Adam,
>
> If you have a look in include/asm-ppc/pgtable.h for the following
> section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
>
> Try adding _PAGE_COHERENT to the appropriate line above and see if that
> fixes your issue - this causes the 'M' bit to be set on the page which
> sure enforce cache coherency. If it doesn't, you'll need to check the
> 'M' bit isn't being masked out in head_44x.S (it was originally masked
> out on arch/powerpc, but was fixed in later kernels when the cache
> coherency issues with non-SMP systems were resolved).
>
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry
> (pgtable-ppc32.h)
>
> Hope this helps!
>
> Cheers,
> Chris
>
> Adam Zilkie wrote:
>   
>> Hi Chris,
>>
>> I am having a problem similar to what you described in this
>>     
> discussion.
>   
>> We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with 
>> compiles arch/ppc/kernel/head_44x.c (quite different from 
>> /arch/powerpc/kernel/head_32.S). I would like to apply your 
>> backporting patch to this architecture. Any help would be appreciated.
>>
>> Regards,
>> Adam
>>
>>   
>>     
>
>
>   
____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Wrobel Heinz-R39252]

Hi,

This doesn't seem right. If we are talking about a single CPU core chip,
i.e., just one data cache, then setting M is typically a) useless and
could even b) cause a performance penalty depending on a chip's
implementation.
The M bit is required if *other* cores with caches need to see changes
for coherency of their caches. You wouldn't set it for one core only
because your own core knows about its own cache.
The possible performance penalty could happen because you need some way
to tell the others that they better intercept a transaction. And that
could, depending on the chip, by a clock extra or so per transaction.
Now, in theory, a DMA engine could have caches, read from cache content
first, and could snoop the bus on global transactions like another core,
but I have never heard of such a beast.=20

Hope this helps,

Heinz

-----Original Message-----
From: linuxppc-dev-bounces+heinz.wrobel=3Dfreescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+heinz.wrobel=3Dfreescale.com@lists.ozlabs.or=
g
] On Behalf Of Chris Pringle
Sent: Donnerstag, 3. September 2009 10:05
To: azilkie@datacast.com
Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

Hi Adam,

If you have a look in include/asm-ppc/pgtable.h for the following
section:
#ifdef CONFIG_44x
#define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
#else
#define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
#endif

Try adding _PAGE_COHERENT to the appropriate line above and see if that
fixes your issue - this causes the 'M' bit to be set on the page which
sure enforce cache coherency. If it doesn't, you'll need to check the
'M' bit isn't being masked out in head_44x.S (it was originally masked
out on arch/powerpc, but was fixed in later kernels when the cache
coherency issues with non-SMP systems were resolved).

The patch I had fixed two problems on 2.6.26 for 'powerpc':
1) It stopped the 'M' bit being masked out (head_32.S)
2) It set the cache coherency ('M' bit) flag on each page table entry
(pgtable-ppc32.h)

Hope this helps!

Cheers,
Chris

Adam Zilkie wrote:
> Hi Chris,
>
> I am having a problem similar to what you described in this
discussion.
> We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with=20
> compiles arch/ppc/kernel/head_44x.c (quite different from=20
> /arch/powerpc/kernel/head_32.S). I would like to apply your=20
> backporting patch to this architecture. Any help would be appreciated.
>
> Regards,
> Adam
>
>  =20


--=20

______________________________
Chris Pringle
Software Design Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053 Registered Office: James
House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Benjamin Herrenschmidt]

On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> Hi Adam,
> 
> If you have a look in include/asm-ppc/pgtable.h for the following section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
> 
> Try adding _PAGE_COHERENT to the appropriate line above and see if that 
> fixes your issue - this causes the 'M' bit to be set on the page which 
> sure enforce cache coherency. If it doesn't, you'll need to check the 
> 'M' bit isn't being masked out in head_44x.S (it was originally masked 
> out on arch/powerpc, but was fixed in later kernels when the cache 
> coherency issues with non-SMP systems were resolved).

I have some doubts about the usefulness of doing that for 4xx. AFAIK,
the 440 core just ignores M.

The problem lies probably elsewhere. Maybe the L2 cache coherency isn't
enabled or not working ?

The L1 cache on 440 is simply not coherent, so drivers have to make sure
they use the appropriate DMA APIs which will do cache flushing when
needed.

Adam, what driver is causing you that sort of problems ?

Cheers,
Ben.

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Chris Pringle]

Hi Adam,

If you have a look in include/asm-ppc/pgtable.h for the following section:
#ifdef CONFIG_44x
#define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
#else
#define _PAGE_BASE    (_PAGE_PRESENT | _PAGE_ACCESSED)
#endif

Try adding _PAGE_COHERENT to the appropriate line above and see if that 
fixes your issue - this causes the 'M' bit to be set on the page which 
sure enforce cache coherency. If it doesn't, you'll need to check the 
'M' bit isn't being masked out in head_44x.S (it was originally masked 
out on arch/powerpc, but was fixed in later kernels when the cache 
coherency issues with non-SMP systems were resolved).

The patch I had fixed two problems on 2.6.26 for 'powerpc':
1) It stopped the 'M' bit being masked out (head_32.S)
2) It set the cache coherency ('M' bit) flag on each page table entry 
(pgtable-ppc32.h)

Hope this helps!

Cheers,
Chris

Adam Zilkie wrote:
> Hi Chris,
>
> I am having a problem similar to what you described in this discussion.
> We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
> arch/ppc/kernel/head_44x.c (quite different
> from /arch/powerpc/kernel/head_32.S). I would like to apply your
> backporting patch to this architecture. Any help would be appreciated.
>
> Regards,
> Adam 
>
>   


-- 

______________________________
Chris Pringle
Software Design Engineer

Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK

Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com

____________________________

Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ

Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)

[Adam Zilkie]

Hi Chris,

I am having a problem similar to what you described in this discussion.
We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
arch/ppc/kernel/head_44x.c (quite different
from /arch/powerpc/kernel/head_32.S). I would like to apply your
backporting patch to this architecture. Any help would be appreciated.

Regards,
Adam 

-- 
Adam Zilkie
Software Designer,
International Datacasting Corp.

This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you.