* 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).