mv64x60 updates

[Nicolas DET]

Hello James,

On 07/03/2005, you wrote:
> Hi Nicolas,

> A few general comments:-

> - mv64x60 stuff is best posted to linuxppc-embedded

ok.
I would just add that our platform (Pegasos II) is using MV64361 from
Marvell and is a complete computer.

> - you change several generic files to support your platform. It should
>    be possible to support new mv64x60 platforms by writing a new
>    xxx_setup.c file in arch/ppc/platforms with no other generic changes.
>    It is a goal that all mv64x60 boards can be supported by the generic
>    code in arch/ppc/syslib. If some changes need to be made outside
>    arch/ppc/platforms to support your board, try to make them generic so
>    that other similar boards would be able to use them. I suggest you
>    clone chrp_setup.c or katana.c rather than adding conditionals in
>    chrp_setup.c for your board. Then use code in your board specific
>    setup file to call arch/ppc/syslib mv64x60 routines as appropriate.

There is almost no changes compare to 2.6.11 (from kernel.org).

Pegasos II is a CHRP machine, as a result all related code is inside
arch/ppc/platform/chrp_*
There is almost nothing to do (but normal CHRP stuff) for the Pegasos
machine. I don't think it's plan clone
chrp_setup.c
I think Sven Luther could answer this better than me anyway.

About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
hardcoded IRQ, hardcoded register base, it changes 
chipset configuration... whereas all of these is already done by the
Pegasos II OpenFirmWare.

I'm open to any solution to have every MV64x60 platform supported.
The Pegasos would _only_ requiere to get correct IRQ and register base for
get_resources stuff and to have the correct flags for the request_irq().
This is only for the ethernet driver.

> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
>    Setup device platform data for your board in your platform file.
>    If something needs to be added to the platform data for a generic
>    change to mv643xx_eth, do that rather than add platform conditionals
>    in the driver.

In this case, the ethernet driver should get the request_irq() flags from
something in arch/ppc/ or arch/mips/

> - why do you need to use SA_SHIRQ in the ethernet driver?

Because the IRQ we use for ethernet is shared with others devices.

Regards
-- 
Nicolas DET
MorphOS & Linux developer