[patch 00/14] Current 4xx patch series

[patch 00/14] Current 4xx patch series

[Josh Boyer]

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.

Patches 1 through 7 are likely ready to be merged if there are no large
objections.  The Walnut stuff likely needs another round or two.  The Bamboo
patches can likely go in, but there is no rush there.

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.

As an aside, I'll likely be setting up a git tree for 4xx soon.  Hopefully
that will help with some of the larger-ish patches.

josh
-- 

Re: [patch 00/14] Current 4xx patch series

[Hollis Blanchard]

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

Re: [patch 00/14] Current 4xx patch series

[Josh Boyer]

On Thu, 2 Aug 2007 20:57:26 +0000 (UTC)
Hollis Blanchard <hollisb@us.ibm.com> wrote:

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

I plan on submitting a series to Paul tomorrow-ish for 2.6.24.  Too
late for 2.6.23.

> > 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

Re: [patch 00/14] Current 4xx patch series

[Benjamin Herrenschmidt]

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.

Re: [patch 00/14] Current 4xx patch series

[Josh Boyer]

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:
> > 
> > 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

Re: [patch 00/14] Current 4xx patch series

[Benjamin Herrenschmidt]

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:
> > 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 ?
> 
> :)
> 
> 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.