linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* MACE DMA problem on Powermac 7300
@ 2009-12-06 22:36 Risto Suominen
  2009-12-07  2:03 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 3+ messages in thread
From: Risto Suominen @ 2009-12-06 22:36 UTC (permalink / raw)
  To: LinuxPPC-dev

Hi, everybody,

I post this in hope that somebody could shed some light on how should
the DMA work in conjunction with the MACE ethernet controller. I find
difficult to understand why it does not work in my case:

What happens? First two bytes of a received frame are not what they
should be in more than 50% of frames. This can be avoided by receiving
the frame on a word boundary, but with the usual skb_reserve(..., 2)
(to make the IP header land on word boundary), it won't work.

So, I can make the driver work by receiving at 0 offset, and then
moving the data 2 bytes up, before handing it over to upper layers.

This used to work with a 2.4.27 kernel, obviously the Grand Central
DBDMA controller can receive on non-word boundaries. Now I have
2.6.15.7.

Any ideas, what could cause this kind of behaviour (and regression)?

Best regards,
Risto Suominen

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: MACE DMA problem on Powermac 7300
  2009-12-06 22:36 MACE DMA problem on Powermac 7300 Risto Suominen
@ 2009-12-07  2:03 ` Benjamin Herrenschmidt
  2009-12-07 16:22   ` Risto Suominen
  0 siblings, 1 reply; 3+ messages in thread
From: Benjamin Herrenschmidt @ 2009-12-07  2:03 UTC (permalink / raw)
  To: Risto Suominen; +Cc: LinuxPPC-dev

On Mon, 2009-12-07 at 00:36 +0200, Risto Suominen wrote:
> I post this in hope that somebody could shed some light on how should
> the DMA work in conjunction with the MACE ethernet controller. I find
> difficult to understand why it does not work in my case:
> 
> What happens? First two bytes of a received frame are not what they
> should be in more than 50% of frames. This can be avoided by receiving
> the frame on a word boundary, but with the usual skb_reserve(..., 2)
> (to make the IP header land on word boundary), it won't work.
> 
> So, I can make the driver work by receiving at 0 offset, and then
> moving the data 2 bytes up, before handing it over to upper layers.
> 
> This used to work with a 2.4.27 kernel, obviously the Grand Central
> DBDMA controller can receive on non-word boundaries. Now I have
> 2.6.15.7.
> 
> Any ideas, what could cause this kind of behaviour (and regression)?

Cache coherency bugs in the chipset or HW bugs in DBDMA, we've been
seeing those on/off on those old apple chipsets...

Try forcing a 32 bytes alignment ?

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: MACE DMA problem on Powermac 7300
  2009-12-07  2:03 ` Benjamin Herrenschmidt
@ 2009-12-07 16:22   ` Risto Suominen
  0 siblings, 0 replies; 3+ messages in thread
From: Risto Suominen @ 2009-12-07 16:22 UTC (permalink / raw)
  To: LinuxPPC-dev

Hi, Ben,

2009/12/7, Benjamin Herrenschmidt <benh@kernel.crashing.org>:
>
> Cache coherency bugs in the chipset or HW bugs in DBDMA, we've been
> seeing those on/off on those old apple chipsets...
>
> Try forcing a 32 bytes alignment ?
>
You're thinking of placing the DMA descriptors on different cache lines?

That's excactly what I did with de2104x. But it was easier, I think.
The chip handled its own DMA, and by writing a skip value to a
register... I don't know this GC DMA controller well enough and
haven't found the documentation either...

But I tried the de21041 board with unmodified driver on this 7300, and
it works. The problem was on a 5500.

Risto

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-12-07 16:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-06 22:36 MACE DMA problem on Powermac 7300 Risto Suominen
2009-12-07  2:03 ` Benjamin Herrenschmidt
2009-12-07 16:22   ` Risto Suominen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).