[PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

Hello all,

the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
according to erratum #2 (erratum text included below).  Basically the
most intrusive part is the addition of two new RGMII Internal Delay
modes; one for TX delay only, and the other for RX delay only (i.e, not
both at the same time).

Please review, and since this affects both netdev and powerpc trees,
one maintainer should ack them for the other to push upstream (i.e,
Kumar acks them, and Leo picks them up to go through netdev or the
other way around; either way is fine with me).  I'm hoping they're
trivial enough to go in 2.6.24.

Depending on how the review goes, a follow-on patch to u-boot will be
sent out that fixes up the phy-connection-type in the device tree (from
"rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).

Thanks,

Kim

mpc8360 rev 2.1 erratum #2:
-----------
Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII  when working
with Rev Pilot MDS for proper RGMII operation:

IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)

The Phy (Marvell 88e1111) should be configured NOT to work with RGMII
delay for TxD.

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
> 
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below).  Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
> 
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me).  I'm hoping they're
> trivial enough to go in 2.6.24.
> 
> Depending on how the review goes, a follow-on patch to u-boot will be
> sent out that fixes up the phy-connection-type in the device tree (from
> "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).

I've upgraded CPU to rev2.1, board rev0.3.

Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
the results:

If I use -rxid, then geth not able to transmit anything.
With -txid geth not able to receive anything.

With just -id everything works fine though...


Maybe there should be another condition, in addition to cpu rev2.1?

> Thanks,
> 
> Kim
> 
> mpc8360 rev 2.1 erratum #2:
> -----------
> Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII  when working
> with Rev Pilot MDS for proper RGMII operation:
> 
> IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> 
> The Phy (Marvell 88e1111) should be configured NOT to work with RGMII
> delay for TxD.

Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Thu, 8 Nov 2007 17:16:11 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > Hello all,
> > 
> > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > according to erratum #2 (erratum text included below).  Basically the
> > most intrusive part is the addition of two new RGMII Internal Delay
> > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > both at the same time).
> > 
> > Please review, and since this affects both netdev and powerpc trees,
> > one maintainer should ack them for the other to push upstream (i.e,
> > Kumar acks them, and Leo picks them up to go through netdev or the
> > other way around; either way is fine with me).  I'm hoping they're
> > trivial enough to go in 2.6.24.
> > 
> > Depending on how the review goes, a follow-on patch to u-boot will be
> > sent out that fixes up the phy-connection-type in the device tree (from
> > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> 
> I've upgraded CPU to rev2.1, board rev0.3.
> 
thanks for testing this.  I tested these patches on a "pilot assy 0.3".

> Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> the results:
> 
> If I use -rxid, then geth not able to transmit anything.
> With -txid geth not able to receive anything.
> 
> With just -id everything works fine though...
> 
> 
> Maybe there should be another condition, in addition to cpu rev2.1?
> 
the errata simply states 'pilot boards', but we can probably modify
u-boot to look at the cpu rev and the board rev (BCSR 12).

My bcsr12 looks like:

=>  md.b f800000c 1
f800000c: 10    .

what is yours?

If it's something like 0x03, the u-boot patch will probably look like:

if ((bcsr[12] == 0x10) &&
    (immr->sysconf.spridr == SPR_8360_REV21 ||
     immr->sysconf.spridr == SPR_8360E_REV21))
	/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
        ...

but these linux patches would remain the same (the clk and data delay
settings for the UCC's are still valid; it's just the PHY config
that is triggering your problem from what I can tell).

Thanks,

Kim

> > mpc8360 rev 2.1 erratum #2:
> > -----------
> > Recommended AC timings for chip 8360Rev2.1 UCC ETH RGMII  when working
> > with Rev Pilot MDS for proper RGMII operation:
> > 
> > IMMR_BASE + 0x14A8[4:5] = 11 (clk delay for UCC 2)
> > IMMR_BASE + 0x14A8[18:19] = 11 (clk delay for UCC 1)
> > IMMR_BASE + 0x14AC[20:27] = 10101010 (data delay for both UCC's)
> > 
> > The Phy (Marvell 88e1111) should be configured NOT to work with RGMII
> > delay for TxD.

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> On Thu, 8 Nov 2007 17:16:11 +0300
> Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> 
> > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > Hello all,
> > > 
> > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > according to erratum #2 (erratum text included below).  Basically the
> > > most intrusive part is the addition of two new RGMII Internal Delay
> > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > both at the same time).
> > > 
> > > Please review, and since this affects both netdev and powerpc trees,
> > > one maintainer should ack them for the other to push upstream (i.e,
> > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > other way around; either way is fine with me).  I'm hoping they're
> > > trivial enough to go in 2.6.24.
> > > 
> > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > sent out that fixes up the phy-connection-type in the device tree (from
> > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > 
> > I've upgraded CPU to rev2.1, board rev0.3.
> > 
> thanks for testing this.  I tested these patches on a "pilot assy 0.3".

Same here.

> > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > the results:
> > 
> > If I use -rxid, then geth not able to transmit anything.
> > With -txid geth not able to receive anything.
> > 
> > With just -id everything works fine though...
> > 
> > 
> > Maybe there should be another condition, in addition to cpu rev2.1?
> > 
> the errata simply states 'pilot boards', but we can probably modify
> u-boot to look at the cpu rev and the board rev (BCSR 12).
> 
> My bcsr12 looks like:
> 
> =>  md.b f800000c 1
> f800000c: 10    .
> 
> what is yours?

=> md.b f800000c 1
f800000c: 10    .

:-/

U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX
CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz

root@b1:~# cat /proc/cpuinfo 
processor       : 0
cpu             : e300c1
clock           : 528.000000MHz
revision        : 3.1 (pvr 8083 0031)
bogomips        : 131.58
timebase        : 66000000
platform        : MPC836x MDS


+               /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+               svid = mfspr(SPRN_SVR);
+               if (svid == 0x80480021) {

^^ that branch executes on the board I'm testing.

> If it's something like 0x03, the u-boot patch will probably look like:
> 
> if ((bcsr[12] == 0x10) &&
>     (immr->sysconf.spridr == SPR_8360_REV21 ||
>      immr->sysconf.spridr == SPR_8360E_REV21))
> 	/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
>         ...
> 
> but these linux patches would remain the same (the clk and data delay
> settings for the UCC's are still valid; it's just the PHY config
> that is triggering your problem from what I can tell).

Yup, most likely this is not UCC specific, but PHY. For some reason
delays making harm here...


Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Thu, 8 Nov 2007 21:39:52 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Thu, Nov 08, 2007 at 12:15:08PM -0600, Kim Phillips wrote:
> > On Thu, 8 Nov 2007 17:16:11 +0300
> > Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > 
> > > On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> > > > Hello all,
> > > > 
> > > > the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> > > > according to erratum #2 (erratum text included below).  Basically the
> > > > most intrusive part is the addition of two new RGMII Internal Delay
> > > > modes; one for TX delay only, and the other for RX delay only (i.e, not
> > > > both at the same time).
> > > > 
> > > > Please review, and since this affects both netdev and powerpc trees,
> > > > one maintainer should ack them for the other to push upstream (i.e,
> > > > Kumar acks them, and Leo picks them up to go through netdev or the
> > > > other way around; either way is fine with me).  I'm hoping they're
> > > > trivial enough to go in 2.6.24.
> > > > 
> > > > Depending on how the review goes, a follow-on patch to u-boot will be
> > > > sent out that fixes up the phy-connection-type in the device tree (from
> > > > "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
> > > 
> > > I've upgraded CPU to rev2.1, board rev0.3.
> > > 
> > thanks for testing this.  I tested these patches on a "pilot assy 0.3".
> 
> Same here.
> 
> > > Applied 5/5 patches onto paulus/powerpc.git at e403149c92a. Here is
> > > the results:
> > > 
> > > If I use -rxid, then geth not able to transmit anything.
> > > With -txid geth not able to receive anything.
> > > 
> > > With just -id everything works fine though...
> > > 
> > > 
> > > Maybe there should be another condition, in addition to cpu rev2.1?
> > > 
> > the errata simply states 'pilot boards', but we can probably modify
> > u-boot to look at the cpu rev and the board rev (BCSR 12).
> > 
> > My bcsr12 looks like:
> > 
> > =>  md.b f800000c 1
> > f800000c: 10    .
> > 
> > what is yours?
> 
> => md.b f800000c 1
> f800000c: 10    .
> 
> :-/
> 
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX
> CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz
> 
> root@b1:~# cat /proc/cpuinfo 
> processor       : 0
> cpu             : e300c1
> clock           : 528.000000MHz
> revision        : 3.1 (pvr 8083 0031)
> bogomips        : 131.58
> timebase        : 66000000
> platform        : MPC836x MDS
> 

check.  :/

> 
> +               /* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
> +               svid = mfspr(SPRN_SVR);
> +               if (svid == 0x80480021) {
> 
> ^^ that branch executes on the board I'm testing.

right, but whether it does or not doesn't affect your failure outcome
either I'm assuming.

> > If it's something like 0x03, the u-boot patch will probably look like:
> > 
> > if ((bcsr[12] == 0x10) &&
> >     (immr->sysconf.spridr == SPR_8360_REV21 ||
> >      immr->sysconf.spridr == SPR_8360E_REV21))
> > 	/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> >         ...
> > 
> > but these linux patches would remain the same (the clk and data delay
> > settings for the UCC's are still valid; it's just the PHY config
> > that is triggering your problem from what I can tell).
> 
> Yup, most likely this is not UCC specific, but PHY. For some reason
> delays making harm here...

hmm..

Net:   UEC: PHY is Marvell 88E11x1 (1410cc2)

I have jumper JP1 set to 3.3V.

can you send me your:

=> md.b f8000000 15
f8000000: 04 04 00 c6 94 60 00 00 ac 2f 00 b8 10 3f 30 02    .....`.../...?0.
f8000010: 05 07 05 15 11    .....

and maybe try the following on top of these 5 patches (to specify rgmii
mode in the bcsr's):

diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 0a72260..753071e 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -98,6 +98,11 @@ static void __init mpc836x_mds_setup_arch(void)
 			!= NULL){
 		uint svid;
 
+		/* configure RGMII mode for both GETH ports */
+#define BCSR8_TSECXM_RGMII 0xf0
+		clrbits8(&bcsr_regs[8], BCSR8_TSECXM_RGMII);
+
+
 		/* Reset the Ethernet PHY */
 #define BCSR9_GETHRST 0x20
 		clrbits8(&bcsr_regs[9], BCSR9_GETHRST);

Thanks,

Kim

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
[...]
> right, but whether it does or not doesn't affect your failure outcome
> either I'm assuming.
> 
> > > If it's something like 0x03, the u-boot patch will probably look like:
> > > 
> > > if ((bcsr[12] == 0x10) &&
> > >     (immr->sysconf.spridr == SPR_8360_REV21 ||
> > >      immr->sysconf.spridr == SPR_8360E_REV21))
> > > 	/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > >         ...
> > > 
> > > but these linux patches would remain the same (the clk and data delay
> > > settings for the UCC's are still valid; it's just the PHY config
> > > that is triggering your problem from what I can tell).
> > 
> > Yup, most likely this is not UCC specific, but PHY. For some reason
> > delays making harm here...

And today I was unable to reproduce yesterday's behaviour. Your
patches works fine, with sixth patch and without it. With -rxid
and with just -id.

Though, after few resets I hit on that:

- - - -
U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX

Reset Status: External/Internal Soft, External/Internal Hard

CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz
Board: Freescale MPC8360EMDS
I2C:   ready
DRAM:  256 MB (DDR2, 64-bit, ECC on)
SDRAM: 64 MB (local bus)
FLASH: 32 MB
In:    serial
Out:   serial
Err:   serial
Net:   UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
read wrong value : mii_id 1,mii_reg 2, base e0103120
read wrong value : mii_id 1,mii_reg 3, base e0103120
UEC: PHY is Generic MII (ffffffff)
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 1, base e0103120
read wrong value : mii_id 1,mii_reg 5, base e0103120
FSL UEC1: Full Duplex
switching to rgmii 100
FSL UEC1: Speed 100BT
FSL UEC1: Link is up
FSL UEC0, FSL UEC1
- - - -

And UCC1 does not work at all. After another reset that message
disappears and it does work again.


So, I think hardware is tricking me in various ways, not your
patches fault.

:-(

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Fri, 9 Nov 2007 16:25:07 +0300
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:

> On Thu, Nov 08, 2007 at 01:11:35PM -0600, Kim Phillips wrote:
> [...]
> > right, but whether it does or not doesn't affect your failure outcome
> > either I'm assuming.
> > 
> > > > If it's something like 0x03, the u-boot patch will probably look like:
> > > > 
> > > > if ((bcsr[12] == 0x10) &&
> > > >     (immr->sysconf.spridr == SPR_8360_REV21 ||
> > > >      immr->sysconf.spridr == SPR_8360E_REV21))
> > > > 	/* if phy-connection-type is "rgmii-id", set it to "rgmii-rxid" */
> > > >         ...
> > > > 
> > > > but these linux patches would remain the same (the clk and data delay
> > > > settings for the UCC's are still valid; it's just the PHY config
> > > > that is triggering your problem from what I can tell).
> > > 
> > > Yup, most likely this is not UCC specific, but PHY. For some reason
> > > delays making harm here...
> 
> And today I was unable to reproduce yesterday's behaviour. Your
> patches works fine, with sixth patch and without it. With -rxid
> and with just -id.

excellent.  btw, you should be paying a 50% packet loss price by not
going with the -rxid.  ping your board with '-q -s 1400 -i 0.01 -c 100'
to notice the difference.

> 
> Though, after few resets I hit on that:
> 
> - - - -
> U-Boot 1.3.0-rc3-g281df457-dirty (Nov  6 2007 - 18:19:35) MPC83XX
> 
> Reset Status: External/Internal Soft, External/Internal Hard
> 
> CPU:   e300c1, MPC8360E, Rev: 21 at 528 MHz, CSB:  264 MHz
> Board: Freescale MPC8360EMDS
> I2C:   ready
> DRAM:  256 MB (DDR2, 64-bit, ECC on)
> SDRAM: 64 MB (local bus)
> FLASH: 32 MB
> In:    serial
> Out:   serial
> Err:   serial
> Net:   UEC: PHY is Marvell 88E11x1 (1410cc2)
> FSL UEC0: Full Duplex
> switching to rgmii 100
> FSL UEC0: Speed 100BT
> FSL UEC0: Link is up
> read wrong value : mii_id 1,mii_reg 2, base e0103120
> read wrong value : mii_id 1,mii_reg 3, base e0103120
> UEC: PHY is Generic MII (ffffffff)
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 1, base e0103120
> read wrong value : mii_id 1,mii_reg 5, base e0103120
> FSL UEC1: Full Duplex
> switching to rgmii 100
> FSL UEC1: Speed 100BT
> FSL UEC1: Link is up
> FSL UEC0, FSL UEC1
> - - - -
> 
> And UCC1 does not work at all. After another reset that message
> disappears and it does work again.
> 
the RGMII bcsr settings survive soft-resets, which confuse u-boot since
it uses GMII mode.

Kim

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Anton Vorontsov]

On Mon, Nov 05, 2007 at 12:15:30PM -0600, Kim Phillips wrote:
> Hello all,
> 
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below).  Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
> 
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me).  I'm hoping they're
> trivial enough to go in 2.6.24.

All five patches are

Tested-by: Anton Vorontsov <avorontsov@ru.mvista.com>


Let's hope they'll hit 2.6.24.

Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kim Phillips]

On Mon, 5 Nov 2007 12:15:30 -0600
Kim Phillips <kim.phillips@freescale.com> wrote:

> Hello all,
> 
> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
> according to erratum #2 (erratum text included below).  Basically the
> most intrusive part is the addition of two new RGMII Internal Delay
> modes; one for TX delay only, and the other for RX delay only (i.e, not
> both at the same time).
> 
> Please review, and since this affects both netdev and powerpc trees,
> one maintainer should ack them for the other to push upstream (i.e,
> Kumar acks them, and Leo picks them up to go through netdev or the
> other way around; either way is fine with me).  I'm hoping they're
> trivial enough to go in 2.6.24.
> 
Kumar, Leo, 

re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
issued his Tested-by.

Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
to go through netdev?

Kim

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Jeff Garzik]

Kim Phillips wrote:
> On Mon, 5 Nov 2007 12:15:30 -0600
> Kim Phillips <kim.phillips@freescale.com> wrote:
> 
>> Hello all,
>>
>> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
>> according to erratum #2 (erratum text included below).  Basically the
>> most intrusive part is the addition of two new RGMII Internal Delay
>> modes; one for TX delay only, and the other for RX delay only (i.e, not
>> both at the same time).
>>
>> Please review, and since this affects both netdev and powerpc trees,
>> one maintainer should ack them for the other to push upstream (i.e,
>> Kumar acks them, and Leo picks them up to go through netdev or the
>> other way around; either way is fine with me).  I'm hoping they're
>> trivial enough to go in 2.6.24.
>>
> Kumar, Leo, 
> 
> re-ping due to (a) it's been 2 weeks and (b) Anton Vorontsov has since
> issued his Tested-by.
> 
> Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
> to go through netdev?

FWIW I just got back from vacation...  I'm grabbing what DaveM has 
collected into davem/netdev-2.6.git, and then going from there...

	Jeff

Re: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Kumar Gala]

On Nov 19, 2007, at 7:30 PM, Jeff Garzik wrote:

> Kim Phillips wrote:
>> On Mon, 5 Nov 2007 12:15:30 -0600
>> Kim Phillips <kim.phillips@freescale.com> wrote:
>>> Hello all,
>>>
>>> the following patches fix RGMII timing for rev. 2.1 of the mpc8360,
>>> according to erratum #2 (erratum text included below).  Basically  
>>> the
>>> most intrusive part is the addition of two new RGMII Internal Delay
>>> modes; one for TX delay only, and the other for RX delay only  
>>> (i.e, not
>>> both at the same time).
>>>
>>> Please review, and since this affects both netdev and powerpc trees,
>>> one maintainer should ack them for the other to push upstream (i.e,
>>> Kumar acks them, and Leo picks them up to go through netdev or the
>>> other way around; either way is fine with me).  I'm hoping they're
>>> trivial enough to go in 2.6.24.
>>>
>> Kumar, Leo, re-ping due to (a) it's been 2 weeks and (b) Anton  
>> Vorontsov has since
>> issued his Tested-by.
>> Might I suggest Kumar ack the powerpc patches, and Leo/Jeff apply 5/5
>> to go through netdev?
>
> FWIW I just got back from vacation...  I'm grabbing what DaveM has  
> collected into davem/netdev-2.6.git, and then going from there...

Jeff,

I've pulled and pushed the arch/powepc bits of these fixes.  I leave  
the PHYY and driver bits to you.

- k

RE: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)

[Li Yang]

> -----Original Message-----
> From: Phillips Kim=20
> Sent: Tuesday, November 06, 2007 2:16 AM
> To: Li Yang-r58472; Kumar Gala; netdev@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org
> Cc: jgarzik@pobox.com; paulus@samba.org
> Subject: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2=20
> (RGMII Timing)
>=20
> Hello all,
>=20
> the following patches fix RGMII timing for rev. 2.1 of the=20
> mpc8360, according to erratum #2 (erratum text included=20
> below).  Basically the most intrusive part is the addition of=20
> two new RGMII Internal Delay modes; one for TX delay only,=20
> and the other for RX delay only (i.e, not both at the same time).
>=20
> Please review, and since this affects both netdev and powerpc=20
> trees, one maintainer should ack them for the other to push=20
> upstream (i.e, Kumar acks them, and Leo picks them up to go=20
> through netdev or the other way around; either way is fine=20
> with me).  I'm hoping they're trivial enough to go in 2.6.24.
>=20
> Depending on how the review goes, a follow-on patch to u-boot=20
> will be sent out that fixes up the phy-connection-type in the=20
> device tree (from "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
>=20

2-4
Acked-by: Li Yang <leoli@freescale.com>