On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
For those interested, here's my current 4xx patch series. There are a few
cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
another round of Bamboo patches. These are all based off of Paul's current
tree.
Bamboo is booting for me with your patches. Let's get them in soon...
Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
that Ben and David have poked at. If it doesn't get merged soon, I'll take
a look at getting it working again.
Please!
--
Hollis Blanchard
IBM Linux Technology Center
On Thu, 2 Aug 2007 20:57:26 +0000 (UTC)
Hollis Blanchard [off-list ref] wrote:
On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
quoted
For those interested, here's my current 4xx patch series. There are a few
cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
another round of Bamboo patches. These are all based off of Paul's current
tree.
Bamboo is booting for me with your patches. Let's get them in soon...
I plan on submitting a series to Paul tomorrow-ish for 2.6.24. Too
late for 2.6.23.
quoted
Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
that Ben and David have poked at. If it doesn't get merged soon, I'll take
a look at getting it working again.
Please!
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Either way, I'm hoping we can get something into 2.6.24.
josh
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-08-02 22:38:17
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Ask :-) What specifically do you want to know ?
Ben.
On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
quoted
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Ask :-) What specifically do you want to know ?
:)
Are the guts mostly the same, and if so why wasn't the existing driver just
modified to do the device tree probing, perhaps in addition to the arch/ppc
method?
I can answer the "are they similar" myself with inspection, but I just haven't
found the time yet. So just some history about the patch would be good in
general I think.
josh
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-08-03 00:34:53
On Thu, 2007-08-02 at 19:26 -0500, Josh Boyer wrote:
On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
quoted
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
quoted
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Ask :-) What specifically do you want to know ?
:)
Are the guts mostly the same, and if so why wasn't the existing driver just
modified to do the device tree probing, perhaps in addition to the arch/ppc
method?
I can answer the "are they similar" myself with inspection, but I just haven't
found the time yet. So just some history about the patch would be good in
general I think.
Guts are the same with subtle differences :-)
The main reason not to modify the existing one was because I wanted to
be conservative and not take any chance at breaking arch/ppc. Also, we
did that in earlier versions internally (have both OCP and device-tree
probing) and it's a terrible mess. Since arch/ppc is doomed, I wanted to
avoid designing something that can do both for no real benefit.
There are other subtle differences, such as the locking of the MDIO
accesses, and locking bits and pieces in general (EMAC wasn't tested in
SMP environments, and while it was tested with preempt, there are a few
subtle differences and issues that went unnoticed).
I also haven't brought back the workarounds for the loss of the Rx clock
with some PHYs at this stage. I need to get my hand on HW that has this
issue to be able to decide what to do I believe. The thing is, global
whacking of clock control registers like the old driver does is a bit
scary, totally per-chip-type, and requires locking vs. other parts of
the system that may want to access the same registers etc...
However, some of the chip folks told me it might be possible instead to
just use loopback mode when there is no link. So I want to investigate
that possibility first, but for that, I need HW that has the symptoms
and so far, I think I don't.
Finally, we still need to add in proper DMA unmapping. The current
driver never unmaps which is a problem on Axon when using the iommu.
Cheers,
Ben.