mv64x60 updates

Hi Andrew.

This patch briges the mv64x60 related code up to the latest that I have.

Quoted 5 lines · Mark A. Greer

Hi Andrew.

This patch briges the mv64x60 related code up to the latest that I have.

Mark, ...

I am a bit bewildered by what you are doing here. How does this mv64x60 code relate to the mv643xx_eth driver from the mips folk ?

Friendly,

Sven Luther

Quoted 15 lines · Sven Luther

Quoted 5 lines · Mark A. Greer

Hi Andrew.

This patch briges the mv64x60 related code up to the latest that I have.

Mark, ...

I am a bit bewildered by what you are doing here. How does this mv64x60 code
relate to the mv643xx_eth driver from the mips folk ?

Quoted 4 lines

Friendly,

Sven Luther

Hi Sven.

The mv64x60 is a Marvell host bridge with some I/O ctlrs including 3

enet cltrs. There are virtually identical versions for MIPS (called mv64x4x) and PPC (called mv64x6x). The mv643xx_eth driver was originally written by the MIPS folks, as you note, but Dale Farnsworth

has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's

patch(es) have been accepted and are queued to go into the mainline tree at some point.

Did I answer your question?

Mark

Quoted 9 lines · Mark A. Greer

Quoted 5 lines · Sven Luther

On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:

Quoted 3 lines

has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's

Ok, so the code in question is in addition to the existing driver from the mips guys and works with it ?

I had the impression that it was a separate
driver development or something.

Quoted 6 lines

patch(es) have been accepted and are queued to go into the mainline tree at some point.

Ok. Do you know if Dale's patches are available separatedly while they are not yet in mainline, so Nicolas Det can work on them and make sure they also work on the Pegasos board, which is not an embedded board but from the chrp lineage. Nicolas already did some mv643xx ethernet driver work last summer, but apparently had trouble integrating this in the mainline kernel, and it seems his work has now been redone by Dale or something. Do you know who the right person to communicate with about this would be ? The MIPS folk didn't reply to any of our mails about this subject.

Please see bk://[email protected]/linux-2.5-mv643xx-enet. Most of this is
in netdev and mm, and on track to go into linux-2.5.

Quoted 3 lines

Did I answer your question?

I think so. I was just surprised to see this 64x6x work go to arch/ppc instead to drivers/net.

Quoted 12 lines · Sven Luther

Ok. Do you know if Dale's patches are available separatedly while they are not
yet in mainline, so Nicolas Det can work on them and make sure they also work
on the Pegasos board, which is not an embedded board but from the chrp lineage. Nicolas already did some mv643xx ethernet driver work last summer, but apparently had trouble integrating this in the mainline kernel, and it seems his work has now been redone by Dale or something. Do you know who the
right person to communicate with about this would be ? The MIPS folk didn't reply to any of our mails about this subject.

Nicolas has emailed me off-line and he & Dale are now in contact. FYI, this is part of the email from Dale to Nicolas:

Quoted 2 lines

Quoted 2 lines

I am a bit bewildered by what you are doing here. How does this mv64x60 code relate to the mv643xx_eth driver from the mips folk ?

[...]

Quoted 2 lines · Mark A. Greer

has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's

Ok, so the code in question is in addition to the existing driver from the mips guys and works with it ? I had the impression that it was a separate driver development or something.

Ok. Do you know if Dale's patches are available separatedly while they are not yet in mainline, so Nicolas Det can work on them and make sure they also work on the Pegasos board, which is not an embedded board but from the chrp

lineage. Nicolas already did some mv643xx ethernet driver work last summer, but apparently had trouble integrating this in the mainline kernel, and it

seems his work has now been redone by Dale or something. Do you know who the right person to communicate with about this would be ? The MIPS folk didn't reply to any of our mails about this subject.

Quoted 5 lines · Sven Luther

Quoted 2 lines

Quoted 2 lines

I am a bit bewildered by what you are doing here. How does this mv64x60 code relate to the mv643xx_eth driver from the mips folk ?

[...]

Quoted 7 lines

Quoted 2 lines · Mark A. Greer

has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's

Ok, so the code in question is in addition to the existing driver from the mips guys and works with it ? I had the impression that it was a separate driver development or something.

The code in mv64x60.c is related to but separate from the ethernet driver. It is platform-specific code that passes register addresses, irqs, mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.

All of my changes to the mv643xx ethernet driver have been posted to LKML or the netdev list. I have removed all arch-specific code from the ethernet driver itself.

Quoted 3 lines

Ok. Do you know if Dale's patches are available separatedly while they are not yet in mainline, so Nicolas Det can work on them and make sure they also work on the Pegasos board, which is not an embedded board but from the chrp

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

Quoted 2 lines

lineage. Nicolas already did some mv643xx ethernet driver work last summer, but apparently had trouble integrating this in the mainline kernel, and it

I'm sorry I wasn't aware of Nicolas' work on the driver.

Quoted 3 lines

seems his work has now been redone by Dale or something. Do you know who the right person to communicate with about this would be ? The MIPS folk didn't reply to any of our mails about this subject.

Sounds familiar. Fortunately, Jeff Garzik picked up my changes. I would appreciate feedback from you or Nicolas on the current driver.

Quoted 14 lines · Dale Farnsworth

Quoted 5 lines · Sven Luther

Quoted 2 lines

Quoted 2 lines

I am a bit bewildered by what you are doing here. How does this mv64x60 code relate to the mv643xx_eth driver from the mips folk ?

[...]

Quoted 7 lines

Quoted 2 lines · Mark A. Greer

has spent a lot of time making it work on both MIPS and PPC. The code you see in the mv64x60.c file is a part of that. I believe that Dale's

Ok, so the code in question is in addition to the existing driver from the mips guys and works with it ? I had the impression that it was a separate driver development or something.

Quoted 7 lines

The code in mv64x60.c is related to but separate from the ethernet driver. It is platform-specific code that passes register addresses, irqs, mac addrs, phy addrs, etc. to the arch-agnostic ethernet driver.

All of my changes to the mv643xx ethernet driver have been posted to LKML or the netdev list. I have removed all arch-specific code from the ethernet driver itself.

What is the status of this with regard to the 2.6.11 mainline kernel ?

Quoted 4 lines

Quoted 3 lines

Ok. Do you know if Dale's patches are available separatedly while they are not yet in mainline, so Nicolas Det can work on them and make sure they also work on the Pegasos board, which is not an embedded board but from the chrp

Quoted 1 line

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one.

Quoted 6 lines · Sven Luther

Quoted 1 line · Dale Farnsworth

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one.

Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of those are just 64340-> 643xx replacements though.

What are your plans for mainline inclusion of the rest of those, and is it ok

to work directly with your stuff ? Do you have any experimental or dangerous parts in the above ? And did you ever get the gigabit ethernet port working on a powerpc board ? Or are there some Kconfig parts i have missed ?

Quoted 4 lines · Sven Luther

Quoted 3 lines · Sven Luther

Quoted 1 line · Dale Farnsworth

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

Quoted 6 lines

Quoted 3 lines

I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one.

Ok, i think that did it, and i have a 200kb diff against 2.6.11 :) Many of those are just 64340-> 643xx replacements though.

Yes, renames and Lindent make for big diffs.

Quoted 1 line

What are your plans for mainline inclusion of the rest of those, and is it ok

I've submitted it for mainline inclusion. Jeff Garzik put it in netdev-2.6 (and thus in the mm patches) for testing and it's on track for going into mainline. I hope it will happen in the next few days, but that's up to Jeff.

Quoted 3 lines

to work directly with your stuff ? Do you have any experimental or dangerous parts in the above ? And did you ever get the gigabit ethernet port working on a powerpc board ? Or are there some Kconfig parts i have missed ?

By all means, try it. Several people are using it without complaints, but I'd appreciate your feedback. There isn't anything dangerous in there. Gigabit works for me. I'm not sure what Kconfig parts would be needed specifically for gigabit support.

Updates are coming though. James Chapman has sent me several patches that provide: use of the mii library for phy management, additional ethtool support, message level support, compile fix for non-NAPI, and much cleanup. We're working the kinks out now and I expect to submit these patches in the next few days.

Quoted 4 lines · Dale Farnsworth

By all means, try it. Several people are using it without complaints, but I'd appreciate your feedback. There isn't anything dangerous in there. Gigabit works for me. I'm not sure what Kconfig parts would be needed specifically for gigabit support.

I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to build it, and even insmod it, but the module doesn't do a thing, and not even a single line shows up in dmesg. I guess i am either missing a part of the patch or there is something wrong with the probe code.

I have gotten the diff against :

include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig, adding :

config MV643XX_ETH
tristate "MV-643XX Ethernet support"

(quoted diff) +3 -2

-       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
+       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
        help
          This driver supports the gigabit Ethernet on the Marvell MV643XX
-         chipset which is used in the Momenco Ocelot C and Jaguar ATX.
+         chipset which is used in the Momenco Ocelot C and Jaguar ATX and
+         Pegasos II, amongst other PPC and MIPS boards.

I have no idea where your MV64360 comes from, it seems to be not existent in any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find combo :/ Will have to look more.

Anyway, how do you probe for the chip ? On the pegasos we used to map on the marvell pci id :

0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362 System Controller (rev 03)

too bad Marvell didn't do the logical thing and made the ethernet port appear as separated devices on a third internal pci bus.

Quoted 26 lines · Sven Luther

Quoted 4 lines · Dale Farnsworth

By all means, try it. Several people are using it without complaints, but I'd appreciate your feedback. There isn't anything dangerous in there. Gigabit works for me. I'm not sure what Kconfig parts would be needed specifically for gigabit support.

I added just a PPC_CHRP dependency on the MV64XXX_ETH entry, and i was able to build it, and even insmod it, but the module doesn't do a thing, and not even a single line shows up in dmesg. I guess i am either missing a part of the patch or there is something wrong with the probe code.

I have gotten the diff against :

include/linux/mv643xx.h drivers/net/mv643xx_eth.[ch] and drivers/net/Kconfig, adding :

config MV643XX_ETH
tristate "MV-643XX Ethernet support"

(quoted diff) +3 -2

-       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX
+       depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || PPC_CHRP
        help
          This driver supports the gigabit Ethernet on the Marvell MV643XX
-         chipset which is used in the Momenco Ocelot C and Jaguar ATX.
+         chipset which is used in the Momenco Ocelot C and Jaguar ATX and
+         Pegasos II, amongst other PPC and MIPS boards.

Quoted 4 lines

I have no idea where your MV64360 comes from, it seems to be not existent in any other Kconfig, ... oh well, maybe i am wrong, i wasn't able to do a recursive bk co, so maybe i missed a bunch of Kconfig files with my grep/find combo :/ Will have to look more.

MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and CHESTNUT. If I understand correctly, it should be defined for any board using the MV64360. I don't think we want the PPC_CHRP dependency.

Quoted 6 lines

Anyway, how do you probe for the chip ? On the pegasos we used to map on the marvell pci id :

0000:00:00.0 Host bridge: Marvell Technology Group Ltd. MV64360/64361/64362 System Controller (rev 03)

Quoted 2 lines

too bad Marvell didn't do the logical thing and made the ethernet port appear as separated devices on a third internal pci bus.

The mv643xx_eth probe is dependent on having the appropriate platform device entry. See eth0_device and mv64x60_add_pds() in arch/ppc/syslib/mv643x60.c .

Ah, i guess that was the missing bit. Basically i need to set MV64360 for my board, but since it is a generic PPC_CHRP, how is that supposed to work ?
Could you send me maybe a list of files which need merging yet, compared to 2.6.11 ? I guess it just doesn't work because i am missing pieces.

Quoted 9 lines

Quoted 8 lines

Anyway, how do you probe for the chip ? On the pegasos we used to map on the marvell pci id :

0000:00:00.0 Host bridge: Marvell Technology Group Ltd.
MV64360/64361/64362 System Controller (rev 03)

too bad Marvell didn't do the logical thing and made the ethernet port appear as separated devices on a third internal pci bus.

Quoted 3 lines

The mv643xx_eth probe is dependent on having the appropriate platform device entry. See eth0_device and mv64x60_add_pds() in arch/ppc/syslib/mv643x60.c .

The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports (only port1 is wired though) mapped at interrupt 9, shared with other devices. I guess that would be the only real difference with the other currently supported hardware, right ?

Will look at the above mentioned files and function and try to enable it.

Quoted 3 lines · Dale Farnsworth

MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and CHESTNUT. If I understand correctly, it should be defined for any board using the MV64360. I don't think we want the PPC_CHRP dependency.

Ah, i guess that was the missing bit. Basically i need to set MV64360 for my board, but since it is a generic PPC_CHRP, how is that supposed to work ?

Could you send me maybe a list of files which need merging yet, compared to 2.6.11 ? I guess it just doesn't work because i am missing pieces.

The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports (only port1 is wired though) mapped at interrupt 9, shared with other devices. I guess that would be the only real difference with the other currently supported hardware, right ?

Quoted 8 lines · Sven Luther

Quoted 3 lines · Dale Farnsworth

MV64360 is in arch/ppc/Kconfig, and is currently defined for KATANA and CHESTNUT. If I understand correctly, it should be defined for any board using the MV64360. I don't think we want the PPC_CHRP dependency.

Ah, i guess that was the missing bit. Basically i need to set MV64360 for my board, but since it is a generic PPC_CHRP, how is that supposed to work ?

Quoted 2 lines

Could you send me maybe a list of files which need merging yet, compared to 2.6.11 ? I guess it just doesn't work because i am missing pieces.

I would be guessing, since I've focused on the ethernet driver. Mark Greer <[email protected]> has done the core mv64[34]60 core support. Nicholas is working with regarding Pegasos II support.

Quoted 4 lines

The pegasos has the mv64360 registers mapped at 0xf1000000, and the ports (only port1 is wired though) mapped at interrupt 9, shared with other devices. I guess that would be the only real difference with the other currently supported hardware, right ?

Nicholas implied that the PCI IRQs are different as well.

But i hear Nicolas has done some useful work yesterday evening, i will review it as soon as he is back from dreamland :)

But i hear Nicolas has done some useful work yesterday evening, i will review it as soon as he is back from dreamland :)

Hello Sven,

Quoted 2 lines · you

But i hear Nicolas has done some useful work yesterday evening, i will review it as soon as he is back from dreamland :)

You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2

This patch shouldn't break mv code for others platform (non PegasosII), and fix Pegasos II init...

Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:

in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the ressources tables for Pegasos II hardware (register base & IRQ). in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for request_irq if pegasos II detected

The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/... because I use this function to use the correct flags in the ethernet driver.

Of course, this patch may be discuss as there are several architecture using Marvell chipsets and each requieres some specific code. I don't know where it's the best to place mv64360_ispeasos2(), maybe this func could even be renamed mv64x60_ispegasos2()..

Please, people from others MV64x60 architectures review this patch, modify if it neeeded and check it doesn't break your architecture (I shouldn't but for MIPS ethernet).

Regards

Hi Nicolas,

A few general comments:-

- mv64x60 stuff is best posted to linuxppc-embedded

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

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

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

Hi Nicolas,

A few general comments:-

- mv64x60 stuff is best posted to linuxppc-embedded

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

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

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

Hello James,

Quoted 1 line · you

Hi Nicolas,

Quoted 3 lines

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.

Quoted 10 lines

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

I have appended a (slightly revised) version of the patch, which is against a
saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet, which is what Mark and Dale are working on. Viewed like that the patch is against to really manageable size, altough it may need some fine-tuning. The
rest of your comments probably apply to Dale's and Mark's work in the above
tree though.

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.

Hello James,

Quoted 1 line

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

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

Quoted 4 lines · Nicolas DET

Hello James,

Quoted 1 line

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

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

I've included an untested patch below that adds support for passing IRQ flags via platform device.

For the pegasos 2, you'll need the second patch which applies after the one I previously sent for chrp_setup.c.

Sven + Nicolas, please let me know if this compiles/works for you.

Notice that benh is telling me that you should use SA_SHIRQ always and that SA_INTERRUPT should go away, and that you should contact him online if you have trouble with that.

Quoted 2 lines

For the pegasos 2, you'll need the second patch which applies after the one I previously sent for chrp_setup.c.

Ok, will test this anyway, and tell you how it works.

Quoted 8 lines

Notice that benh is telling me that you should use SA_SHIRQ always and that SA_INTERRUPT should go away, and that you should contact him online if you have trouble with that.

Quoted 2 lines

For the pegasos 2, you'll need the second patch which applies after the one I previously sent for chrp_setup.c.

Ok, will test this anyway, and tell you how it works.

GHeh, ok, just picked up the discussion. Yes, there is really no reason to use SA_INTERRUPT here, this is a thing of the past.

Quoted 7 lines · Benjamin Herrenschmidt

Quoted 7 lines

Notice that benh is telling me that you should use SA_SHIRQ always and that SA_INTERRUPT should go away, and that you should contact him online if you have trouble with that.

Quoted 2 lines

For the pegasos 2, you'll need the second patch which applies after the one I previously sent for chrp_setup.c.

Quoted 4 lines

Quoted 1 line

Ok, will test this anyway, and tell you how it works.

GHeh, ok, just picked up the discussion. Yes, there is really no reason to use SA_INTERRUPT here, this is a thing of the past.

Excellent. Thanks.

Here's a new patch to try. :-)

Quoted 8 lines · Dale Farnsworth

Quoted 7 lines · Benjamin Herrenschmidt

Quoted 7 lines

Notice that benh is telling me that you should use SA_SHIRQ always and that SA_INTERRUPT should go away, and that you should contact him online if you have trouble with that.

Quoted 2 lines

For the pegasos 2, you'll need the second patch which applies after the one I previously sent for chrp_setup.c.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

Ok, will test this anyway, and tell you how it works.

GHeh, ok, just picked up the discussion. Yes, there is really no reason to use SA_INTERRUPT here, this is a thing of the past.

Excellent. Thanks.

Here's a new patch to try. :-)

Hehe, i did that myself :)

Anyway, i have another problem though, namely that even though i do arch_initcall(mv643xx_eth_add_pds), mv643xx_eth_add_pds is never called, and in the mv643xx_eth driver itself, altough the module init is done, _probe never gets called. I will now do a build without any #ifdefs around the chrp_setup.c stuff (And Christophe Hellwig proposed moving the stuff into arch/ppc/platform/pegasos_mv643xx_eth.c), and see if that will solve it.

Also going to add the explicit detection of the marvell bridge in the OF tree, but need to decide what to check for there.

Ok, i should have something working. adding here both sven2-dale.diff which is a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against 2.6.11.

There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c especially with regard the headers, and also the proper copyright/attibution of it (since dale wrote it and i just pasted it and did the detection stuff benh mentioned above.

I am unsure also about the :

(quoted diff) +3 -0

@@ -44,6 +44,9 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/delay.h>
+#ifdef PPC_MULTIPLATEFORM
+#include <mv64x60.h>
+#endif
 #include "mv643xx_eth.h"
 
 /*

hunk. dale can you check it ?

Comments are welcome, in particular benh, i guess my detection code will beak horribly if there is another host node prior to the marvell one in the OF tree, which is not the case currently on pegasos though.

Quoted 21 lines

Ok, i should have something working. adding here both sven2-dale.diff which is a patch against linux-2.5-mv643xx-enet and sven2.diff which is a patch against 2.6.11.

There is still a bit of cleanup needed in arch/ppc/platforms/mv643xx_eth_pegasos.c especially with regard the headers, and also the proper copyright/attibution of it (since dale wrote it and i just pasted it and did the detection stuff benh mentioned above.

I am unsure also about the :

(quoted diff) +3 -0

@@ -44,6 +44,9 @@
 #include <asm/pgtable.h>
 #include <asm/system.h>
 #include <asm/delay.h>
+#ifdef PPC_MULTIPLATEFORM
+#include <mv64x60.h>
+#endif
 #include "mv643xx_eth.h"
 

Quoted 3 lines

(quoted diff) +0 -0

 /*

hunk. dale can you check it ?

Looks broken...

Quoted 3 lines

Comments are welcome, in particular benh, i guess my detection code will beak horribly if there is another host node prior to the marvell one in the OF tree, which is not the case currently on pegasos though.

Why are you looking at vid/did ? Isn't there some name string (model, compatible, whatever) you can use ? Or is your OF too bad to even give such info ?

You can also iterate after the find_devices() using np->next

vendor-id             0x11AB (4523)
device-id             0x6460 (25696)
revision-id           0x3 (3)
class-code            0x60000 (393216)
subsystem-id          0x0 (0)
subsystem-vendor-id   0x0 (0)
.vendor-name          "Marvell"
.part-number          "MV6436x"
.description          "System Controller for PowerPC Processors"
.class                "Bridge Device"
.subclass             "Host/PCI"
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "host"
reg                   0:0

assigned-addresses

In the /pci/host node, i also have :

model "Pegasos2"

In the root node, and in the new OF, we even have a /discovery2/port@1 or something such, but it is unreleased yet.

The thing is not that there is no info, just to chose which info is best.

Christoph suggested to not do that though, but use the normal pci stuff and match on the host pci id with pci_dev_present. This is what i was thinking of doing too, and may be more logical, no ?

Quoted 16 lines · Sven Luther

vendor-id             0x11AB (4523)
device-id             0x6460 (25696)
revision-id           0x3 (3)
class-code            0x60000 (393216)
subsystem-id          0x0 (0)
subsystem-vendor-id   0x0 (0)
.vendor-name          "Marvell"
.part-number          "MV6436x"
.description          "System Controller for PowerPC Processors"
.class                "Bridge Device"
.subclass             "Host/PCI"
devsel-speed          0x0 (0)
min-grant             0x0 (0)
max-latency           0x0 (0)
name                  "host"
reg                   0:0

Quoted 1 line

assigned-addresses

Ok, teach them the interest in having a "model" and "compatible" property in them for their next version...

Quoted 6 lines

In the /pci/host node, i also have :

model "Pegasos2"

In the root node, and in the new OF, we even have a /discovery2/port@1 or something such, but it is unreleased yet.

Ugh ? What is that supposed to be ?

If it's an ethernet port, it should be called "ethernet".

Quoted 5 lines

The thing is not that there is no info, just to chose which info is best.

Christoph suggested to not do that though, but use the normal pci stuff and match on the host pci id with pci_dev_present. This is what i was thinking of doing too, and may be more logical, no ?

Yah, if there is no meaningful OF name, then probably.

Also going to add the explicit detection of the marvell bridge in the OF tree,

but need to decide what to check for there.

Quoted 3 lines · Sven Luther

Also going to add the explicit detection of the marvell bridge in the OF tree,

Do you really need to do that, though? Just finding "Pegasos" or "Pegasos2" in the 'model' field of the device tree should be sufficient, shouldn't it? (if I'm reading the code correctly)

Quoted 1 line

but need to decide what to check for there.

The only way that I know of to tell if you're on a mv64x60 bridge is to do a pci cfg read of the vendor/device id fields of fcn 0 of the

bridge's device on that pci hose. By default, the bus number of both hoses are 0 (but OF probably sets the second one to be > 0 depending on how many pci buses there are hanging off hose 0), the bridge will be device 0 on both hoses, the vendor id will be PCI_VENDOR_ID_MARVELL (0x11ab) and the device id will be PCI_DEVICE_ID_MARVELL_MV64360 (0x6460) for a mv64360.

Unfortunately, the bus number of each hose, the device # of the bridge's device on that hose (see "PCI P2P Configuration" register offsets 0x1d14 & 0x1d94), and the vendor & device ids (by a pci cfg write to those fields) can all be changed by the fw . I guess the device tree tells you the bus number of each hose so you can generate the proper cfg access and I doubt OF changes the bridge's device # and pci vendor/dev id but I wanted to make you aware of the potential.

Hello,

Ok, thanks for your help, here is the final (hopefully) and cleaned up version of my patches :

1) mv643xx-eth-pegasos.diff
This is the arch/ppc/platform diff, benh, could you look it over, and merge it in ? It is not really usefull without the mv643xx_eth.c changes, but dale is going to move those in together with his patches.

2) linux-2.5-mv643xx-enet-pegasos.diff
This is just two small hunks against dale's linux-2.5-mv643xx-enet tree, which include the SA_INTERRUPT -> SA_IRQ and the Kconfig change. Dale said he would merge them with his stuff, hopefully for 2.6.12.

3) mv643xx-eth.diff
This is the linux-2.5-mv643xx-enet diff against 2.6.11, together with the linux-2.5-mv643xx-enet-pegasos.diff changes, for those who want to build against 2.6.11.

So to build against the linux-2.5-mv643xx-enet tree, you need 1) and 2) and to build against 2.6.11 you need 1) and 3).

I am currently running the patches included in these changes, and will include them in the debian 2.6.11 kernels unless i hear otherwise.

Quoted 15 lines · luther

Hello,

Ok, thanks for your help, here is the final (hopefully) and cleaned up version of my patches :

1) mv643xx-eth-pegasos.diff
This is the arch/ppc/platform diff, benh, could you look it over, and
merge it in ? It is not really usefull without the mv643xx_eth.c
changes, but dale is going to move those in together with his patches.

2) linux-2.5-mv643xx-enet-pegasos.diff
This is just two small hunks against dale's linux-2.5-mv643xx-enet
tree, which include the SA_INTERRUPT -> SA_IRQ and the Kconfig change.
Dale said he would merge them with his stuff, hopefully for 2.6.12.

Quoted 8 lines

3) mv643xx-eth.diff
This is the linux-2.5-mv643xx-enet diff against 2.6.11, together with
the linux-2.5-mv643xx-enet-pegasos.diff changes, for those who want to
build against 2.6.11.

So to build against the linux-2.5-mv643xx-enet tree, you need 1) and 2) and to build against 2.6.11 you need 1) and 3).

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.

Hi Nicolas,

A few general comments:-

- mv64x60 stuff is best posted to linuxppc-embedded

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

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

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

/james

Quoted 35 lines · Nicolas DET

Hello Sven,

Quoted 2 lines · you

But i hear Nicolas has done some useful work yesterday evening, i will review it as soon as he is back from dreamland :)

You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2

This patch shouldn't break mv code for others platform (non PegasosII), and fix Pegasos II init...

Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:

in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the ressources tables for Pegasos II hardware (register base & IRQ). in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for request_irq if pegasos II detected

The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/... because I use this function to use the correct flags in the ethernet driver.

Of course, this patch may be discuss as there are several architecture using Marvell chipsets and each requieres some specific code. I don't know where it's the best to place mv64360_ispeasos2(), maybe this func could even be renamed mv64x60_ispegasos2()..

Quoted 5 lines

Please, people from others MV64x60 architectures review this patch, modify if it neeeded and check it doesn't break your architecture (I shouldn't but for MIPS ethernet).

Regards

_______________________________________________
Linuxppc-dev mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Welcome to the world of embedded people who use #ifdef's for their platforms :)

Quoted 3 lines · Dale Farnsworth

All of my changes to the mv643xx ethernet driver have been posted to LKML or the netdev list. I have removed all arch-specific code from the ethernet driver itself.

What is the status of this with regard to the 2.6.11 mainline kernel ?

Quoted 1 line

See bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet

I guess i need to look there, as in mainline 2.6.11, there doesn't seem to be direct related code between the ppc specific mv64x60 stuff, and the mips related ethernet one.

Well, as i am doing the powerpc debian 2.6.11 kernel, i really would like to port your work to the pegasos, but what i have seen from the code in the mainline kernel doesn't really make sense.