* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Scott Wood @ 2009-05-20 14:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Li Yang, Wolfgang Denk, LKML List
In-Reply-To: <156C2E1E-8E67-4358-B72E-4BB67D79C2AF@kernel.crashing.org>
Kumar Gala wrote:
> Scott, any feedback if our boards have 8M or 32M flash modules?
According to the manual, it comes with 8 but can be expanded to 32. I
don't think we swapped out the flash SIMM that came with the board.
As I wrote earlier in the thread, I don't see any way a current u-boot
would enable more than 8MiB of flash on this board anyway. I'd go ahead
and apply the patch.
-Scott
^ permalink raw reply
* Re: mpc5200 fec error
From: Jon Smirl @ 2009-05-20 15:14 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEBE@dekaexchange.deka.local>
On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
>> > I am able to reproduce the error using 2.6.29.2-rt11. =A0I was able to
>> > mitigate the problem by raising the priority of the transmit irq.
>> > However when running an NFS server on the pcm030 under high cpu load I
>> > now get
>> >
>> > [ =A0132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ =A0132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ =A0133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ =A0134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
>> >
>> > Raising the priority of the rx irq does not seem to fix this problem
>> > though.
>>
>> Hi Eric,
>>
>> This error has been seen before in non-rt kernels. =A0I haven't had the
>> chance to track it down and kill it yet. =A0I believe there are locking
>> issues associated with it.
>
> Uuuh, I recall this message. Kept me busy for some time :(
>
> You might try this patch which helped in our situation.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Subject: Enable XLB pipelining for MPC5200B
> From: Wolfram Sang <w.sang@pengutronix.de>
>
> Enable pipelining as it helps getting rid of FEC problems.
> Not intended for upstream, this must be dealt differently there.
>
> This patch is disabled by default. The bootloader should enable this feat=
ure.
> So, this patch is only intended to be used where the bootloader does it i=
n a
> wrong manner and can't be replaced.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
>
> ---
> =A0arch/powerpc/platforms/52xx/mpc52xx_common.c | =A0 =A07 +++++++
> =A01 file changed, 7 insertions(+)
>
> Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
> +++ arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) =3D=3D MPC5200_SV=
R)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_be32(&xlb->config, in_be32(&xlb->confi=
g) | MPC52xx_XLB_CFG_PLDIS);
> +#if 0
> + =A0 =A0 =A0 /*
> + =A0 =A0 =A0 =A0* Enable pipelining, fixes FEC problems. The previous wo=
rkaround is not
> + =A0 =A0 =A0 =A0* needed, as we have an MPC5200B (not A).
> + =A0 =A0 =A0 =A0*/
> + =A0 =A0 =A0 out_be32(&xlb->config, in_be32(&xlb->config) & ~MPC52xx_XLB=
_CFG_PLDIS);
> +#endif
>
> =A0 =A0 =A0 =A0iounmap(xlb);
> =A0}
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> Wolfram,
>
> Thanks, but no luck with this patch. =A0It was already setup correctly by=
U-Boot.
I don't see where this gets enabled in the u-boot source. Have you
added it locally?
These are the only two I see:
cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << 13);
cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << 15);
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Linux pcf8574 driver based MPC8349EA
From: xuemingmin @ 2009-05-20 14:44 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
Recently , I'm busy with a project based on the main board - MPC8349EA. We use a pcf8574 connected I2C bus. Now my task is programming to test I2C bus. I find that file system contains the chip(pcf8574) module .And I add this module into the kernel. But I find that system only registers the driver,not device.And I can not get the device's major and minor device number. Therefore, I can not create the device file to operate the device.
My question:
How can I use the device which is not registered in the system,or can you provide some advices to complete the task.
[-- Attachment #2: Type: text/html, Size: 799 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Jon Smirl @ 2009-05-20 15:17 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1242806865-2334-1-git-send-email-w.sang@pengutronix.de>
T24gV2VkLCBNYXkgMjAsIDIwMDkgYXQgNDowNyBBTSwgV29sZnJhbSBTYW5nIDx3LnNhbmdAcGVu
Z3V0cm9uaXguZGU+IHdyb3RlOgo+IEFkZCBhIG5vZGUgZm9yIHRoZSBpMmMgZWVwcm9tIGFuZCBk
ZWxldGUgdGhlIHN1cGVyZmxvdXMgZ3Bpby1leGFtcGxlLgo+Cj4gU2lnbmVkLW9mZi1ieTogV29s
ZnJhbSBTYW5nIDx3LnNhbmdAcGVuZ3V0cm9uaXguZGU+Cj4gQ2M6IEdyYW50IExpa2VseSA8Z3Jh
bnQubGlrZWx5QHNlY3JldGxhYi5jYT4KPiBDYzogbGludXhwcGMtZGV2QG96bGFicy5vcmcKPiAt
LS0KPiCgYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3BjbTAzMC5kdHMgfCCgIDI2ICsrKystLS0tLS0t
LS0tLS0tLS0tLS0tLS0tCj4goDEgZmlsZXMgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCAyMiBk
ZWxldGlvbnMoLSkKPgo+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvcGNtMDMw
LmR0cyBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9wY20wMzAuZHRzCj4gaW5kZXggODk1ODM0Ny4u
MzNjZTQ4OCAxMDA2NDQKPiAtLS0gYS9hcmNoL3Bvd2VycGMvYm9vdC9kdHMvcGNtMDMwLmR0cwo+
ICsrKyBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9wY20wMzAuZHRzCj4gQEAgLTI1OCwzNCArMjU4
LDE2IEBACj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoGNvbXBhdGlibGUgPSAibnhw
LHBjZjg1NjMiOwo+IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKByZWcgPSA8MHg1MT47
Cj4goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKB9Owo+IC0goCCgIKAgoCCgIKAgoCCgIKAgoCCgIC8q
IEZJWE1FOiBFRVBST00gKi8KPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCBlZXByb21ANTIgewo+
ICsgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgY29tcGF0aWJsZSA9ICJhdDI0LDI0YzMy
IjsKPiArIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHJlZyA9IDwweDUyPjsKPiArIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCB9OwoKR3JhbnQgc3VnZ2VzdGVkIHRoaXMgZWFybGllci4uLgoJ
CQllZXByb21ANTIgewoJCQkJY29tcGF0aWJsZSA9ICJhdG1lbCwyNGMzMiIsICJlZXByb20iOwoJ
CQkJcmVnID0gPDB4NTI+OwoJCQl9OwoKCgoKPiCgIKAgoCCgIKAgoCCgIKB9Owo+Cj4goCCgIKAg
oCCgIKAgoCCgc3JhbUA4MDAwIHsKPiCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoGNvbXBhdGlibGUg
PSAiZnNsLG1wYzUyMDBiLXNyYW0iLCJmc2wsbXBjNTIwMC1zcmFtIjsKPiCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoHJlZyA9IDwweDgwMDAgMHg0MDAwPjsKPiCgIKAgoCCgIKAgoCCgIKB9Owo+IC0K
PiAtIKAgoCCgIKAgoCCgIKAgLyogVGhpcyBpcyBvbmx5IGFuIGV4YW1wbGUgZGV2aWNlIHRvIHNo
b3cgdGhlIHVzYWdlIG9mIGdwaW9zLiBJdCBtYXBzIGFsbCBhdmFpbGFibGUKPiAtIKAgoCCgIKAg
oCCgIKAgoCogZ3Bpb3MgdG8gdGhlICJncGlvLXByb3ZpZGVyIiBkZXZpY2UuCj4gLSCgIKAgoCCg
IKAgoCCgIKAqLwo+IC0goCCgIKAgoCCgIKAgoCBncGlvIHsKPiAtIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCBjb21wYXRpYmxlID0gImdwaW8tcHJvdmlkZXIiOwo+IC0KPiAtIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgLyogbXBjNTJ4eCCgIKAgoCCgIKBl
eHAuY29uIKAgoCCgIKAgcGF0Y2hmaWVsZCAqLwo+IC0goCCgIKAgoCCgIKAgoCCgIKAgoCCgIGdw
aW9zID0gPCZncGlvX3drdXAgoCCgIDAgMCAvKiBHUElPX1dLVVBfNyCgIKAgoDExZCCgIKAgoCCg
IKAgoCBqcDEzLTMgoCCgICovCj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgJmdw
aW9fd2t1cCCgIKAgMSAwIC8qIEdQSU9fV0tVUF82IKAgoCCgMTRjIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgKi8KPiAtIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAmZ3Bpb193a3VwIKAg
oCA2IDAgLyogUFNDMl80IKAgoCCgIKAgoCA0M2MgoCCgIKAgoCCgIKAgeDUtMTEgoCCgIKAqLwo+
IC0goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCZncGlvX3NpbXBsZSCgIDIgMCAvKiBJ
UkRBXzEgoCCgIKAgoCCgIDI0YyCgIKAgoCCgIKAgoCB4Ny02IKAgoHNldCBHUFNfUE9SVF9DT05G
SUdbSVJEQV0gPSAwICovCj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgJmdwaW9f
c2ltcGxlIKAgMyAwIC8qIElSREFfMCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIHg4LTUgoCCg
c2V0IEdQU19QT1JUX0NPTkZJR1tJUkRBXSA9IDAgKi8KPiAtIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCCgIKAgoCCgIKAmZ3B0MiCgIKAgoCCgIKAwIDAgLyogdGltZXIyIKAgoCCgIKAgoCAxMmQgoCCg
IKAgoCCgIKAgeDQtNCCgIKAgoCAqLwo+IC0goCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAg
oCZncHQzIKAgoCCgIKAgoDAgMCAvKiB0aW1lcjMgoCCgIKAgoCCgIDEzZCCgIKAgoCCgIKAgoCB4
Ni00IKAgoCCgICovCj4gLSCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgJmdwdDQgoCCg
IKAgoCCgMCAwIC8qIHRpbWVyNCCgIKAgoCCgIKAgNjFjIKAgoCCgIKAgoCCgIHgyLTE2IKAgoCCg
Ki8KPiAtIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAmZ3B0NSCgIKAgoCCgIKAwIDAg
LyogdGltZXI1IKAgoCCgIKAgoCA0NGMgoCCgIKAgoCCgIKAgeDctMTEgoCCgIKAqLwo+IC0goCCg
IKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCZncHQ2IKAgoCCgIKAgoDAgMCAvKiB0aW1lcjYg
oCCgIKAgoCCgIDYwYyCgIKAgoCCgIKAgoCB4OC0xNSCgIKAgoCovCj4gLSCgIKAgoCCgIKAgoCCg
IKAgoCCgIKAgoCCgIKAgoCCgJmdwdDcgoCCgIKAgoCCgMCAwIC8qIHRpbWVyNyCgIKAgoCCgIKAg
MzZhIKAgoCCgIKAgoCCgIHgxNy05IKAgoCCgKi8KPiAtIKAgoCCgIKAgoCCgIKAgoCCgIKAgoCCg
IKAgoCCgIKA+Owo+IC0goCCgIKAgoCCgIKAgoCB9Owo+IKAgoCCgIKB9Owo+Cj4goCCgIKAgoHBj
aUBmMDAwMGQwMCB7Cj4gLS0KPiAxLjYuMgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0Cj4gTGludXhw
cGMtZGV2QG96bGFicy5vcmcKPiBodHRwczovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9s
aW51eHBwYy1kZXYKPgoKCgotLSAKSm9uIFNtaXJsCmpvbnNtaXJsQGdtYWlsLmNvbQo=
^ permalink raw reply
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-20 15:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910905200814p63915ff8pf65614dbb8dc9adf@mail.gmail.com>
-----Original Message-----
From: Jon Smirl [mailto:jonsmirl@gmail.com]=20
Sent: Wednesday, May 20, 2009 11:15
To: Eric Millbrandt
Cc: Wolfram Sang; Grant Likely; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
>> > I am able to reproduce the error using 2.6.29.2-rt11. I was able =
to
>> > mitigate the problem by raising the priority of the transmit irq.
>> > However when running an NFS server on the pcm030 under high cpu =
load I
>> > now get
>> >
>> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ 132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ 133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
>> > [ 134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
>> >
>> > Raising the priority of the rx irq does not seem to fix this =
problem
>> > though.
>>
>> Hi Eric,
>>
>> This error has been seen before in non-rt kernels. I haven't had the
>> chance to track it down and kill it yet. I believe there are locking
>> issues associated with it.
>
> Uuuh, I recall this message. Kept me busy for some time :(
>
> You might try this patch which helped in our situation.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Subject: Enable XLB pipelining for MPC5200B
> From: Wolfram Sang <w.sang@pengutronix.de>
>
> Enable pipelining as it helps getting rid of FEC problems.
> Not intended for upstream, this must be dealt differently there.
>
> This patch is disabled by default. The bootloader should enable this =
feature.
> So, this patch is only intended to be used where the bootloader does =
it in a
> wrong manner and can't be replaced.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
>
> ---
> arch/powerpc/platforms/52xx/mpc52xx_common.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
> +++ arch/powerpc/platforms/52xx/mpc52xx_common.c
> @@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
> */
> if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) =3D=3D MPC5200_SVR)
> out_be32(&xlb->config, in_be32(&xlb->config) | =
MPC52xx_XLB_CFG_PLDIS);
> +#if 0
> + /*
> + * Enable pipelining, fixes FEC problems. The previous =
workaround is not
> + * needed, as we have an MPC5200B (not A).
> + */
> + out_be32(&xlb->config, in_be32(&xlb->config) & =
~MPC52xx_XLB_CFG_PLDIS);
> +#endif
>
> iounmap(xlb);
> }
>
> --
> Pengutronix e.K. | Wolfram Sang =
|
> Industrial Linux Solutions | =
http://www.pengutronix.de/ |
>
> Wolfram,
>
> Thanks, but no luck with this patch. It was already setup correctly =
by U-Boot.
I don't see where this gets enabled in the u-boot source. Have you
added it locally?
These are the only two I see:
cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << =
13);
cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << =
15);
--=20
Jon Smirl
jonsmirl@gmail.com
If you look a few more lines down you should see
# if defined(CFG_XLB_PIPELINING)
/* Enable piplining */
*(vu_long *)(MPC5XXX_XLBARB + 0x40) &=3D ~(1 << 31);
# endif
I obtained the u-boot sources directly from phytec, for my phyCore, so I =
am not sure if they added it.
_________________________________________________________________________=
________________
This e-mail and the information, including any attachments, it contains =
are intended to be a confidential communication only to the person or =
entity to whom it is addressed and may contain information that is =
privileged. If the reader of this message is not the intended recipient, =
you are hereby notified that any dissemination, distribution or copying =
of this communication is strictly prohibited. If you have received this =
communication in error, please immediately notify the sender and destroy =
the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: mpc5200 fec error
From: Jon Smirl @ 2009-05-20 15:29 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEBF@dekaexchange.deka.local>
On Wed, May 20, 2009 at 11:28 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
> -----Original Message-----
> From: Jon Smirl [mailto:jonsmirl@gmail.com]
> Sent: Wednesday, May 20, 2009 11:15
> To: Eric Millbrandt
> Cc: Wolfram Sang; Grant Likely; linuxppc-dev@ozlabs.org
> Subject: Re: mpc5200 fec error
>
> On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
> <emillbrandt@dekaresearch.com> wrote:
>>> > I am able to reproduce the error using 2.6.29.2-rt11. =A0I was able t=
o
>>> > mitigate the problem by raising the priority of the transmit irq.
>>> > However when running an NFS server on the pcm030 under high cpu load =
I
>>> > now get
>>> >
>>> > [ =A0132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ =A0132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ =A0133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ =A0134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> >
>>> > Raising the priority of the rx irq does not seem to fix this problem
>>> > though.
>>>
>>> Hi Eric,
>>>
>>> This error has been seen before in non-rt kernels. =A0I haven't had the
>>> chance to track it down and kill it yet. =A0I believe there are locking
>>> issues associated with it.
>>
>> Uuuh, I recall this message. Kept me busy for some time :(
>>
>> You might try this patch which helped in our situation.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Subject: Enable XLB pipelining for MPC5200B
>> From: Wolfram Sang <w.sang@pengutronix.de>
>>
>> Enable pipelining as it helps getting rid of FEC problems.
>> Not intended for upstream, this must be dealt differently there.
>>
>> This patch is disabled by default. The bootloader should enable this fea=
ture.
>> So, this patch is only intended to be used where the bootloader does it =
in a
>> wrong manner and can't be replaced.
>>
>> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>> Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
>>
>> ---
>> =A0arch/powerpc/platforms/52xx/mpc52xx_common.c | =A0 =A07 +++++++
>> =A01 file changed, 7 insertions(+)
>>
>> Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
>> +++ arch/powerpc/platforms/52xx/mpc52xx_common.c
>> @@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
>> =A0 =A0 =A0 =A0 */
>> =A0 =A0 =A0 =A0if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) =3D=3D MPC5200_S=
VR)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_be32(&xlb->config, in_be32(&xlb->conf=
ig) | MPC52xx_XLB_CFG_PLDIS);
>> +#if 0
>> + =A0 =A0 =A0 /*
>> + =A0 =A0 =A0 =A0* Enable pipelining, fixes FEC problems. The previous w=
orkaround is not
>> + =A0 =A0 =A0 =A0* needed, as we have an MPC5200B (not A).
>> + =A0 =A0 =A0 =A0*/
>> + =A0 =A0 =A0 out_be32(&xlb->config, in_be32(&xlb->config) & ~MPC52xx_XL=
B_CFG_PLDIS);
>> +#endif
>>
>> =A0 =A0 =A0 =A0iounmap(xlb);
>> =A0}
>>
>> --
>> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | W=
olfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
>> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.=
pengutronix.de/ =A0|
>>
>> Wolfram,
>>
>> Thanks, but no luck with this patch. =A0It was already setup correctly b=
y U-Boot.
>
>
> I don't see where this gets enabled in the u-boot source. Have you
> added it locally?
>
> These are the only two I see:
> cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << 13=
);
> cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << 15=
);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
> If you look a few more lines down you should see
> # if defined(CFG_XLB_PIPELINING)
> =A0 =A0 =A0 =A0/* Enable piplining */
> =A0 =A0 =A0 =A0*(vu_long *)(MPC5XXX_XLBARB + 0x40) &=3D ~(1 << 31);
> # endif
>
> I obtained the u-boot sources directly from phytec, for my phyCore, so I =
am not sure if they added it.
It is ok in main u-boot source. I just missed the lower section.
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Delay on intialization ide subsystem(most likely)
From: Bartlomiej Zolnierkiewicz @ 2009-05-20 15:56 UTC (permalink / raw)
To: Andrey Gusev; +Cc: linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <20090516004007.3a7b9787@power-debian>
On Friday 15 May 2009 22:40:07 Andrey Gusev wrote:
> On Wed, 13 May 2009 20:46:33 +0200
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> > > On Wed, 13 May 2009 15:28:26 +0200
> > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > >
> > > > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote:
> > > > > On Mon, 27 Apr 2009 23:21:48 +0200
> > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > >
> > > > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote:
> > > > > > > On Sat, 25 Apr 2009 16:48:38 +0200
> > > > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote:
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > I have tested linux-2.6.30-rc3 on my system and find
> > > > > > > > > some problems. One of them is delaying on
> > > > > > > > > initialization IDE subsystem. I don't have this problem
> > > > > > > > > on 2.6.29.1. The difference is looked on log of dmesg.
> > > > > > > >
> > > > > > > > Unfortunately this doesn't give us any hint about the root
> > > > > > > > cause of the bug so please try narrowing the problem down
> > > > > > > > to the specific change using git-bisect (sorry, there
> > > > > > > > were 212 drivers/ide/ commits during v2.6.29..v2.6.30-rc3
> > > > > > > > and much much more non-drivers/ide/ ones).
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Bart
> > > > > > > >
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > >
> > > > > > > The full result of bisect is:
> > > > > > >
> > > > > > >
> > > > > > > git bisect start
> > > > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux
> > > > > > > 2.6.29 git bisect good
> > > > > > > 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84 # bad:
> > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3
> > > > > > > git bisect bad 091069740304c979f957ceacec39c461d0192158 #
> > > > > > > good: [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB
> > > > > > > (11166): pvrusb2: Implement status fetching from
> > > > > > > sub-devices git bisect good
> > > > > > > 40f07111be99b71c1e8d40c13cdc38445add787f # good:
> > > > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg:
> > > > > > > slicoss: Specify the license for Sahara SXG and Slicoss
> > > > > > > drivers git bisect good
> > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8
> > > > > > >
> > > > > > >
> > > > > > > git bisect start 'drivers/ide/'
> > > > > >
> > > > > > Please note that limiting search space to drivers/ide/ may not
> > > > > > give reliable results in case problem was introduced by some
> > > > > > other kernel area.
> > > > > >
> > > > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging:
> > > > > > > sxg: slicoss: Specify the license for Sahara SXG and
> > > > > > > Slicoss drivers git bisect good
> > > > > > > ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad:
> > > > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3
> > > > > > > git bisect bad 091069740304c979f957ceacec39c461d0192158 #
> > > > > > > good: [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd:
> > > > > > > convert cdrom_decode_status() to use switch statements git
> > > > > > > bisect good e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d #
> > > > > > > good: [3153c26b54230d025c6d536e8d3015def4524906] ide:
> > > > > > > refactor tf_read() method git bisect good
> > > > > > > 3153c26b54230d025c6d536e8d3015def4524906 # good:
> > > > > > > [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix
> > > > > > > HPT370 DMA timeouts git bisect good
> > > > > > > c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad:
> > > > > > > [d5f840bf74c09ca5a31e518c9d984999926b5f44] ide: Remove void
> > > > > > > casts git bisect bad
> > > > > > > d5f840bf74c09ca5a31e518c9d984999926b5f44 # bad:
> > > > > > > [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use
> > > > > > > ATA_DMA_* constants git bisect bad
> > > > > > > 59c8d04f5ee97ea46da854e9adbbaa45d988c39d
> > > > > >
> > > > > > Uhh.. something went wrong during bisect.
> > > > > >
> > > > > > "hpt366: use ATA_DMA_* constants" cannot be a first bad commit
> > > > > > because hpt366 is not even used on this system.
> > > > > >
> > > > > > Could it be that the delay doesn't happen on every boot for
> > > > > > "bad" kernels?
> > > > > >
> > > > > > Also, is 2.6.30-rc1 okay?
> > > > > >
> > > > > > Thanks,
> > > > > > Bart
> > > > > >
> > > > >
> > > > > Hello all!
> > > > >
> > > > > I continue to find reason of bug. I made more testing with
> > > > > bisect and got result:
> > > > >
> > > > > git bisect start
> > > > > # bad: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix
> > > > > HPT370 DMA timeouts git bisect bad
> > > > > # good:
> > > > > [fb4252e59452c18b88af014a2c4ee697bbf8cbc6] at91_ide: turn on
> > > > > PIO 6 support git bisect good
> > > > > fb4252e59452c18b88af014a2c4ee697bbf8cbc6 # good:
> > > > > [2e1c63b7ed36532b68f0eddd6a184d7ba1013b89] Merge branch
> > > > > 'for-rc1/xen/core' of
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git
> > > > > bisect good 2e1c63b7ed36532b68f0eddd6a184d7ba1013b89 # bad:
> > > > > [cd97824994042b809493807ea644ba26c0c23290] Merge
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git
> > > > > bisect bad cd97824994042b809493807ea644ba26c0c23290 # bad:
> > > > > [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes
> > > > > git bisect bad a2c252ebdeaab28c9b400570594d576dae295958 # good:
> > > > > [b897e6fbc49dd84b2634bca664344d503b907ce9] Merge branch
> > > > > 'drm-intel-next' of
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
> > > > > git bisect good b897e6fbc49dd84b2634bca664344d503b907ce9 #
> > > > > good: [dfbc4752eab33e66f113f9daa2effbe241cd661d] brd: support
> > > > > barriers git bisect good
> > > > > dfbc4752eab33e66f113f9daa2effbe241cd661d # good:
> > > > > [a23c218bd36e11120daf18e00a91d5dc20e288e6] Merge branch 'merge'
> > > > > of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
> > > > > git bisect good a23c218bd36e11120daf18e00a91d5dc20e288e6 #
> > > > > good: [23da64b4714812b66ecf010e7dfb3ed1bf2eda69] Merge branch
> > > > > 'for-linus' of git://git.kernel.dk/linux-2.6-block git bisect
> > > > > good 23da64b4714812b66ecf010e7dfb3ed1bf2eda69 # good:
> > > > > [a228df6339e0d385b8149c860d81b6007f5e9c81] GFS2: Move umount
> > > > > flush rwsem git bisect good
> > > > > a228df6339e0d385b8149c860d81b6007f5e9c81 # skip:
> > > > > [1328df725239804ae30fc7257c1a3185e679b517] GFS2: Use
> > > > > DEFINE_SPINLOCK git bisect skip
> > > > > 1328df725239804ae30fc7257c1a3185e679b517 # good:
> > > > > [10d2198805d7faa2b193485446ff6b1de42c9b78] GFS2: cleanup
> > > > > file_operations mess git bisect good
> > > > > 10d2198805d7faa2b193485446ff6b1de42c9b78
> > > > >
> > > > > As I understand, I found bad commit, but it includes 5 commits.
> > > > > I checked them and they are good. So, I did git checkout
> > > > > a2c252ebdeaab28c9b400570594d576dae295958 and test one more time
> > > > > this commit. I found that bag is unstable. The boot can be bad
> > > > > or good on this commit. I compared dmesg of 'bad' and 'good'
> > > > > booting, but it is equal till delay.
> > > >
> > > > Thanks for doing it.
> > > >
> > > > > Any suggestions?
> > > >
> > > > Hard to tell...
> > > >
> > > > I went through all commits in-between
> > > >
> > > > fb4252e59452c18b88af014a2c4ee697bbf8cbc6
> > > >
> > > > and
> > > >
> > > > a2c252ebdeaab28c9b400570594d576dae295958
> > > >
> > > > and there are no obvious candidates..
> > > >
> > > > Could you please refresh my memory and tell me whether 2.6.30-rc2
> > > > was OK?
> > > >
> > >
> > > It was ok, but I don't sure now. I tested only one boot, but this
> > > problem is not stable. I am rechecking it.
> >
> > Ok.
> >
> > Please also recheck first 'good' commit if 2.6.30-rc2 turns out to be
> > 'bad'.
>
> My last testing is very interesting. I check boot of each kernel at
> least 10 times. I checked 2.6.30-rc2, it is good. Rest results:
>
> git bisect start
> # good: [0882e8dd3aad33eca41696d463bb896e6c8817eb] Linux 2.6.30-rc2
> git bisect good 0882e8dd3aad33eca41696d463bb896e6c8817eb
> # bad: [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes git
> bisect bad a2c252ebdeaab28c9b400570594d576dae295958 # good:
> [c2572f2b4ffc27ba79211aceee3bef53a59bb5cd] brd: fix cacheflushing git
> bisect good c2572f2b4ffc27ba79211aceee3bef53a59bb5cd # bad:
> [b71a0c296cee4debaf446760fbd29ead1587a7ac] powerpc: pseries/dtl.c
> should include asm/firmware.h git bisect bad
> b71a0c296cee4debaf446760fbd29ead1587a7ac
>
> Last commit had delay only on 10 time, but it ripped my system, I can't
> read any place on my hard drive. I can't mount any other device on it.
> Fortunately, I have tmpfs and I mounted second hard disk on it place.
> After my computer didn't turn on. It looks like dead drive or
> controller, but after on/off and replace disks, it has alived. Below
> is log of this bad boot.
I think that is an old problem which for some reasons gets triggered more
easily in newer kernels or a hardware issue (or just combination of both).
[...]
> > [ BTW the above bisection points that the problem was introduced
> > outside of drivers/ide or that it was introduced earlier that we'd
> > initially thought ]
> >
> > > I have added second hard drive and got new issue. May be this log
> > > (dmesg) can tell you something. It is on first known 'bad commit'.
> > > 2.6.29.2 can't properly
> >
> > It tells us that there is some IRQ routing problem... seems like a
> > platform or ide-pmac specific problem. Does some earlier kernel work
> > OK with this configuration?
>
> I have Debian's 2.6.26, it has same problem. Don't take attention to time, I
> caught another bug on Aureal Vortex2, this driver kills kernel completely and
> system time too. I am lucky on bugs on this machine.
[...]
> [477194869.958131] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
[...]
> [477194895.065957] ide-pmac lost interrupt, dma status: 8480
> [477194895.068535] hdb: lost interrupt
> [477194895.070952] hdb: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> [477194895.073444] ide: failed opcode was: unknown
> [477194895.076053] hda: DMA disabled
> [477194895.078504] hdb: DMA disabled
> [477194895.209948] ide0: reset: success
> [477194895.430619] hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
This drive is one of the "quirky" drives which has special workarounds in
some host drivers...
OK, lets try something else. I went through IDE code and fixed outstanding
issues which may be related to these problems + mixed-in pending bugfixes.
The end result is a patch for 2.6.30-rc6 below, please try it.
diff --git a/drivers/ide/hpt366.c b/drivers/ide/hpt366.c
index 0feb66c..7ce68ef 100644
--- a/drivers/ide/hpt366.c
+++ b/drivers/ide/hpt366.c
@@ -138,14 +138,6 @@
#undef HPT_RESET_STATE_ENGINE
#undef HPT_DELAY_INTERRUPT
-static const char *quirk_drives[] = {
- "QUANTUM FIREBALLlct08 08",
- "QUANTUM FIREBALLP KA6.4",
- "QUANTUM FIREBALLP LM20.4",
- "QUANTUM FIREBALLP LM20.5",
- NULL
-};
-
static const char *bad_ata100_5[] = {
"IBM-DTLA-307075",
"IBM-DTLA-307060",
@@ -729,27 +721,13 @@ static void hpt3xx_set_pio_mode(ide_drive_t *drive, const u8 pio)
hpt3xx_set_mode(drive, XFER_PIO_0 + pio);
}
-static void hpt3xx_quirkproc(ide_drive_t *drive)
-{
- char *m = (char *)&drive->id[ATA_ID_PROD];
- const char **list = quirk_drives;
-
- while (*list)
- if (strstr(m, *list++)) {
- drive->quirk_list = 1;
- return;
- }
-
- drive->quirk_list = 0;
-}
-
static void hpt3xx_maskproc(ide_drive_t *drive, int mask)
{
ide_hwif_t *hwif = drive->hwif;
struct pci_dev *dev = to_pci_dev(hwif->dev);
struct hpt_info *info = hpt3xx_get_info(hwif->dev);
- if (drive->quirk_list == 0)
+ if ((drive->dev_flags & IDE_DFLAG_NIEN_QUIRK) == 0)
return;
if (info->chip_type >= HPT370) {
@@ -1404,7 +1382,6 @@ static int __devinit hpt36x_init(struct pci_dev *dev, struct pci_dev *dev2)
static const struct ide_port_ops hpt3xx_port_ops = {
.set_pio_mode = hpt3xx_set_pio_mode,
.set_dma_mode = hpt3xx_set_mode,
- .quirkproc = hpt3xx_quirkproc,
.maskproc = hpt3xx_maskproc,
.mdma_filter = hpt3xx_mdma_filter,
.udma_filter = hpt3xx_udma_filter,
diff --git a/drivers/ide/ide-eh.c b/drivers/ide/ide-eh.c
index 5d5fb96..fab7e89 100644
--- a/drivers/ide/ide-eh.c
+++ b/drivers/ide/ide-eh.c
@@ -408,8 +408,9 @@ static ide_startstop_t do_reset1(ide_drive_t *drive, int do_not_try_atapi)
/* more than enough time */
udelay(10);
/* clear SRST, leave nIEN (unless device is on the quirk list) */
- tp_ops->write_devctl(hwif, (drive->quirk_list == 2 ? 0 : ATA_NIEN) |
- ATA_DEVCTL_OBS);
+ tp_ops->write_devctl(hwif,
+ ((drive->dev_flags & IDE_DFLAG_NIEN_QUIRK) ? 0 : ATA_NIEN) |
+ ATA_DEVCTL_OBS);
/* more than enough time */
udelay(10);
hwif->poll_timeout = jiffies + WAIT_WORSTCASE;
diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
index 35dc38d..a4622b8 100644
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -503,11 +503,15 @@ repeat:
if ((hwif->host->host_flags & IDE_HFLAG_SERIALIZE) &&
hwif != prev_port) {
+ ide_drive_t *cur_dev =
+ prev_port ? prev_port->cur_dev : NULL;
+
/*
* set nIEN for previous port, drives in the
- * quirk_list may not like intr setups/cleanups
+ * quirk list may not like intr setups/cleanups
*/
- if (prev_port && prev_port->cur_dev->quirk_list == 0)
+ if (cur_dev &&
+ (cur_dev->dev_flags & IDE_DFLAG_NIEN_QUIRK) == 0)
prev_port->tp_ops->write_devctl(prev_port,
ATA_NIEN |
ATA_DEVCTL_OBS);
@@ -696,7 +700,7 @@ void ide_timer_expiry (unsigned long data)
}
spin_lock_irq(&hwif->lock);
enable_irq(hwif->irq);
- if (startstop == ide_stopped) {
+ if (startstop == ide_stopped && hwif->polling == 0) {
ide_unlock_port(hwif);
plug_device = 1;
}
@@ -868,7 +872,7 @@ irqreturn_t ide_intr (int irq, void *dev_id)
* same irq as is currently being serviced here, and Linux
* won't allow another of the same (on any CPU) until we return.
*/
- if (startstop == ide_stopped) {
+ if (startstop == ide_stopped && hwif->polling == 0) {
BUG_ON(hwif->handler);
ide_unlock_port(hwif);
plug_device = 1;
diff --git a/drivers/ide/ide-iops.c b/drivers/ide/ide-iops.c
index c19a221..c1b5e86 100644
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -269,6 +269,29 @@ no_80w:
return 0;
}
+static const char *nien_quirk_list[] = {
+ "QUANTUM FIREBALLlct08 08",
+ "QUANTUM FIREBALLP KA6.4",
+ "QUANTUM FIREBALLP KA9.1",
+ "QUANTUM FIREBALLP KX13.6",
+ "QUANTUM FIREBALLP KX20.5",
+ "QUANTUM FIREBALLP KX27.3",
+ "QUANTUM FIREBALLP LM20.4",
+ "QUANTUM FIREBALLP LM20.5",
+ NULL
+};
+
+void ide_check_nien_quirk_list(ide_drive_t *drive)
+{
+ const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
+
+ for (list = nien_quirk_list; *list != NULL; list++)
+ if (strstr(m, *list) != NULL) {
+ drive->dev_flags |= IDE_DFLAG_NIEN_QUIRK;
+ return;
+ }
+}
+
int ide_driveid_update(ide_drive_t *drive)
{
u16 *id;
@@ -352,7 +375,7 @@ int ide_config_drive_speed(ide_drive_t *drive, u8 speed)
tp_ops->exec_command(hwif, ATA_CMD_SET_FEATURES);
- if (drive->quirk_list == 2)
+ if (drive->dev_flags & IDE_DFLAG_NIEN_QUIRK)
tp_ops->write_devctl(hwif, ATA_DEVCTL_OBS);
error = __ide_wait_stat(drive, drive->ready_stat,
diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 7f264ed..2399bc0 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -295,7 +295,7 @@ int ide_dev_read_id(ide_drive_t *drive, u8 cmd, u16 *id)
timeout = ((cmd == ATA_CMD_ID_ATA) ? WAIT_WORSTCASE : WAIT_PIDENTIFY) / 2;
- if (ide_busy_sleep(hwif, timeout, use_altstatus))
+ if (ide_busy_sleep(drive, timeout, use_altstatus))
return 1;
/* wait for IRQ and ATA_DRQ */
@@ -316,8 +316,9 @@ int ide_dev_read_id(ide_drive_t *drive, u8 cmd, u16 *id)
return rc;
}
-int ide_busy_sleep(ide_hwif_t *hwif, unsigned long timeout, int altstatus)
+int ide_busy_sleep(ide_drive_t *drive, unsigned long timeout, int altstatus)
{
+ ide_hwif_t *hwif = drive->hwif;
u8 stat;
timeout += jiffies;
@@ -330,6 +331,8 @@ int ide_busy_sleep(ide_hwif_t *hwif, unsigned long timeout, int altstatus)
return 0;
} while (time_before(jiffies, timeout));
+ printk(KERN_ERR "%s: timeout in %s\n", drive->name, __func__);
+
return 1; /* drive timed-out */
}
@@ -420,7 +423,7 @@ static int do_probe (ide_drive_t *drive, u8 cmd)
tp_ops->dev_select(drive);
msleep(50);
tp_ops->exec_command(hwif, ATA_CMD_DEV_RESET);
- (void)ide_busy_sleep(hwif, WAIT_WORSTCASE, 0);
+ (void)ide_busy_sleep(drive, WAIT_WORSTCASE, 0);
rc = ide_dev_read_id(drive, cmd, id);
}
@@ -699,8 +702,12 @@ static int ide_probe_port(ide_hwif_t *hwif)
if (irqd)
disable_irq(hwif->irq);
- if (ide_port_wait_ready(hwif) == -EBUSY)
- printk(KERN_DEBUG "%s: Wait for ready failed before probe !\n", hwif->name);
+ rc = ide_port_wait_ready(hwif);
+ if (rc == -ENODEV) {
+ printk(KERN_INFO "%s: no devices on the port\n", hwif->name);
+ goto out;
+ } else if (rc == -EBUSY)
+ printk(KERN_ERR "%s: not ready before the probe\n", hwif->name);
/*
* Second drive should only exist if first drive was found,
@@ -711,7 +718,7 @@ static int ide_probe_port(ide_hwif_t *hwif)
if (drive->dev_flags & IDE_DFLAG_PRESENT)
rc = 0;
}
-
+out:
/*
* Use cached IRQ number. It might be (and is...) changed by probe
* code above
@@ -729,6 +736,8 @@ static void ide_port_tune_devices(ide_hwif_t *hwif)
int i;
ide_port_for_each_present_dev(i, drive, hwif) {
+ ide_check_nien_quirk_list(drive);
+
if (port_ops && port_ops->quirkproc)
port_ops->quirkproc(drive);
}
diff --git a/drivers/ide/pdc202xx_new.c b/drivers/ide/pdc202xx_new.c
index b68906c..65ba823 100644
--- a/drivers/ide/pdc202xx_new.c
+++ b/drivers/ide/pdc202xx_new.c
@@ -40,18 +40,6 @@
#define DBG(fmt, args...)
#endif
-static const char *pdc_quirk_drives[] = {
- "QUANTUM FIREBALLlct08 08",
- "QUANTUM FIREBALLP KA6.4",
- "QUANTUM FIREBALLP KA9.1",
- "QUANTUM FIREBALLP LM20.4",
- "QUANTUM FIREBALLP KX13.6",
- "QUANTUM FIREBALLP KX20.5",
- "QUANTUM FIREBALLP KX27.3",
- "QUANTUM FIREBALLP LM20.5",
- NULL
-};
-
static u8 max_dma_rate(struct pci_dev *pdev)
{
u8 mode;
@@ -200,19 +188,6 @@ static u8 pdcnew_cable_detect(ide_hwif_t *hwif)
return ATA_CBL_PATA80;
}
-static void pdcnew_quirkproc(ide_drive_t *drive)
-{
- const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
-
- for (list = pdc_quirk_drives; *list != NULL; list++)
- if (strstr(m, *list) != NULL) {
- drive->quirk_list = 2;
- return;
- }
-
- drive->quirk_list = 0;
-}
-
static void pdcnew_reset(ide_drive_t *drive)
{
/*
@@ -473,7 +448,6 @@ static struct pci_dev * __devinit pdc20270_get_dev2(struct pci_dev *dev)
static const struct ide_port_ops pdcnew_port_ops = {
.set_pio_mode = pdcnew_set_pio_mode,
.set_dma_mode = pdcnew_set_dma_mode,
- .quirkproc = pdcnew_quirkproc,
.resetproc = pdcnew_reset,
.cable_detect = pdcnew_cable_detect,
};
diff --git a/drivers/ide/pdc202xx_old.c b/drivers/ide/pdc202xx_old.c
index 248a54b..ed5df32 100644
--- a/drivers/ide/pdc202xx_old.c
+++ b/drivers/ide/pdc202xx_old.c
@@ -23,18 +23,6 @@
#define PDC202XX_DEBUG_DRIVE_INFO 0
-static const char *pdc_quirk_drives[] = {
- "QUANTUM FIREBALLlct08 08",
- "QUANTUM FIREBALLP KA6.4",
- "QUANTUM FIREBALLP KA9.1",
- "QUANTUM FIREBALLP LM20.4",
- "QUANTUM FIREBALLP KX13.6",
- "QUANTUM FIREBALLP KX20.5",
- "QUANTUM FIREBALLP KX27.3",
- "QUANTUM FIREBALLP LM20.5",
- NULL
-};
-
static void pdc_old_disable_66MHz_clock(ide_hwif_t *);
static void pdc202xx_set_mode(ide_drive_t *drive, const u8 speed)
@@ -151,19 +139,6 @@ static void pdc_old_disable_66MHz_clock(ide_hwif_t *hwif)
outb(clock & ~(hwif->channel ? 0x08 : 0x02), clock_reg);
}
-static void pdc202xx_quirkproc(ide_drive_t *drive)
-{
- const char **list, *m = (char *)&drive->id[ATA_ID_PROD];
-
- for (list = pdc_quirk_drives; *list != NULL; list++)
- if (strstr(m, *list) != NULL) {
- drive->quirk_list = 2;
- return;
- }
-
- drive->quirk_list = 0;
-}
-
static void pdc202xx_dma_start(ide_drive_t *drive)
{
if (drive->current_speed > XFER_UDMA_2)
@@ -311,13 +286,11 @@ static void __devinit pdc202ata4_fixup_irq(struct pci_dev *dev,
static const struct ide_port_ops pdc20246_port_ops = {
.set_pio_mode = pdc202xx_set_pio_mode,
.set_dma_mode = pdc202xx_set_mode,
- .quirkproc = pdc202xx_quirkproc,
};
static const struct ide_port_ops pdc2026x_port_ops = {
.set_pio_mode = pdc202xx_set_pio_mode,
.set_dma_mode = pdc202xx_set_mode,
- .quirkproc = pdc202xx_quirkproc,
.resetproc = pdc202xx_reset,
.cable_detect = pdc2026x_cable_detect,
};
diff --git a/include/linux/ide.h b/include/linux/ide.h
index ff65fff..fa8ffe0 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -474,6 +474,7 @@ enum {
IDE_DFLAG_NICE1 = (1 << 5),
/* device is physically present */
IDE_DFLAG_PRESENT = (1 << 6),
+ IDE_DFLAG_NIEN_QUIRK = (1 << 7),
/* id read from device (synthetic if not set) */
IDE_DFLAG_ID_READ = (1 << 8),
IDE_DFLAG_NOPROBE = (1 << 9),
@@ -543,7 +544,6 @@ struct ide_drive_s {
u8 waiting_for_dma; /* dma currently in progress */
u8 dma; /* atapi dma flag */
- u8 quirk_list; /* considered quirky, set for a specific host */
u8 init_speed; /* transfer rate set at boot */
u8 current_speed; /* current transfer rate set */
u8 desired_speed; /* desired transfer rate set */
@@ -1109,7 +1109,7 @@ void ide_fix_driveid(u16 *);
extern void ide_fixstring(u8 *, const int, const int);
-int ide_busy_sleep(ide_hwif_t *, unsigned long, int);
+int ide_busy_sleep(ide_drive_t *, unsigned long, int);
int ide_wait_stat(ide_startstop_t *, ide_drive_t *, u8, u8, unsigned long);
@@ -1464,6 +1464,7 @@ static inline void ide_acpi_set_state(ide_hwif_t *hwif, int on) {}
void ide_register_region(struct gendisk *);
void ide_unregister_region(struct gendisk *);
+void ide_check_nien_quirk_list(ide_drive_t *);
void ide_undecoded_slave(ide_drive_t *);
void ide_port_apply_params(ide_hwif_t *);
^ permalink raw reply related
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 15:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910905200817w20a812bcy14481255fefd011f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
> > - /* FIXME: EEPROM */
> > + eeprom@52 {
> > + compatible = "at24,24c32";
> > + reg = <0x52>;
> > + };
>
> Grant suggested this earlier...
> eeprom@52 {
> compatible = "atmel,24c32", "eeprom";
> reg = <0x52>;
> };
Can you give me a pointer? I just found this thread
http://ozlabs.org/pipermail/devicetree-discuss/2008-July/000008.html
but not the result you proposed.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Jon Smirl @ 2009-05-20 16:10 UTC (permalink / raw)
To: Wolfram Sang, Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20090520155346.GG29102@pengutronix.de>
On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
>> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* FIXME: EEPROM */
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatib=
le =3D "at24,24c32";
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D =
<0x52>;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>>
>> Grant suggested this earlier...
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =
=3D "atmel,24c32", "eeprom";
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <0x5=
2>;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>
> Can you give me a pointer? I just found this thread
Grant, what do you want here?
> http://ozlabs.org/pipermail/devicetree-discuss/2008-July/000008.html
>
> but not the result you proposed.
>
> Regards,
>
> =A0 Wolfram
>
> --
> Pengutronix e.K. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Wo=
lfram Sang =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
> Industrial Linux Solutions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | http://www.p=
engutronix.de/ =A0|
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkoUJ4oACgkQD27XaX1/VRsSbwCgo1o//DG1wjKGR7BY1lkRxOAi
> 8kIAoJghKuhKMNBDXUhA4sWj/vRfDoDV
> =3DBmoy
> -----END PGP SIGNATURE-----
>
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 16:15 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910905200910r5342c087pa4ebc579b37c8671@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 949 bytes --]
On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> >> > - /* FIXME: EEPROM */
> >> > + eeprom@52 {
> >> > + compatible = "at24,24c32";
> >> > + reg = <0x52>;
> >> > + };
> >>
> >> Grant suggested this earlier...
> >> eeprom@52 {
> >> compatible = "atmel,24c32", "eeprom";
> >> reg = <0x52>;
> >> };
> >
> > Can you give me a pointer? I just found this thread
>
>
> Grant, what do you want here?
I fear an answer like: "a properly working at24" ;)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Grant Likely @ 2009-05-20 16:25 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <20090520161511.GH29102@pengutronix.de>
On Wed, May 20, 2009 at 10:15 AM, Wolfram Sang <w.sang@pengutronix.de> wrot=
e:
> On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
>> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang <w.sang@pengutronix.de> w=
rote:
>> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* FIXME: EEPROM */
>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compa=
tible =3D "at24,24c32";
>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =
=3D <0x52>;
>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>> >>
>> >> Grant suggested this earlier...
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatibl=
e =3D "atmel,24c32", "eeprom";
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <=
0x52>;
>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>> >
>> > Can you give me a pointer? I just found this thread
>>
>>
>> Grant, what do you want here?
>
> I fear an answer like: "a properly working at24" ;)
>
BWAHAHAHAHA!
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Grant Likely @ 2009-05-20 16:36 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905200925o763179c7r27c12f7659560807@mail.gmail.com>
On Wed, May 20, 2009 at 10:25 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, May 20, 2009 at 10:15 AM, Wolfram Sang <w.sang@pengutronix.de> wr=
ote:
>> On Wed, May 20, 2009 at 12:10:59PM -0400, Jon Smirl wrote:
>>> On Wed, May 20, 2009 at 11:53 AM, Wolfram Sang <w.sang@pengutronix.de> =
wrote:
>>> >> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* FIXME: EEPROM */
>>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 comp=
atible =3D "at24,24c32";
>>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =
=3D <0x52>;
>>> >> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>>> >>
>>> >> Grant suggested this earlier...
>>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 eeprom@52 {
>>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatib=
le =3D "atmel,24c32", "eeprom";
>>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D =
<0x52>;
>>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 };
>>> >
>>> > Can you give me a pointer? I just found this thread
>>>
>>>
>>> Grant, what do you want here?
>>
>> I fear an answer like: "a properly working at24" ;)
>>
>
> BWAHAHAHAHA!
Now that I've got that out of the way...
As the other thread states, "eeprom" is far too vague, and it is
certainly not documented, and does not say anything meaningful about
the protocol used to talk to the eeprom. Sure, most i2c eeproms use
the same protocol, but an assumption cannot be made that that will
always be the case. Plus, the namespace will collide with non-i2c
eeproms. "i2c-eeprom" is better, but not great. Before a value like
"i2c-eeprom" can be acceptable, it must be documented and reviewed as
to exactly what it means, and even then I'm uncomfortable with it.
However, on the other point, Jon is correct. The first value in the
list should be "atmel,24c32", not "at24,24c32".
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-20 16:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910905200829o423bf483h5b0b6dd202367872@mail.gmail.com>
> On Wed, May 20, 2009 at 9:42 AM, Eric Millbrandt
> <emillbrandt@dekaresearch.com> wrote:
>>> > I am able to reproduce the error using 2.6.29.2-rt11. I was able =
to
>>> > mitigate the problem by raising the priority of the transmit irq.
>>> > However when running an NFS server on the pcm030 under high cpu =
load I
>>> > now get
>>> >
>>> > [ 132.477503] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ 132.892329] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ 133.884109] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> > [ 134.876059] net eth0: FEC_IEVENT_RFIFO_ERROR
>>> >
>>> > Raising the priority of the rx irq does not seem to fix this =
problem
>>> > though.
>>>
>>> Hi Eric,
>>>
>>> This error has been seen before in non-rt kernels. I haven't had =
the
>>> chance to track it down and kill it yet. I believe there are =
locking
>>> issues associated with it.
>>
>> Uuuh, I recall this message. Kept me busy for some time :(
>>
>> You might try this patch which helped in our situation.
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> Subject: Enable XLB pipelining for MPC5200B
>> From: Wolfram Sang <w.sang@pengutronix.de>
>>
>> Enable pipelining as it helps getting rid of FEC problems.
>> Not intended for upstream, this must be dealt differently there.
>>
>> This patch is disabled by default. The bootloader should enable this =
feature.
>> So, this patch is only intended to be used where the bootloader does =
it in a
>> wrong manner and can't be replaced.
>>
>> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
>> Acked-by: Juergen Beisert <j.beisert@pengutronix.de>
>>
>> ---
>> arch/powerpc/platforms/52xx/mpc52xx_common.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> Index: arch/powerpc/platforms/52xx/mpc52xx_common.c
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> --- arch/powerpc/platforms/52xx/mpc52xx_common.c.orig
>> +++ arch/powerpc/platforms/52xx/mpc52xx_common.c
>> @@ -107,6 +107,13 @@ mpc5200_setup_xlb_arbiter(void)
>> */
>> if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) =3D=3D MPC5200_SVR)
>> out_be32(&xlb->config, in_be32(&xlb->config) | =
MPC52xx_XLB_CFG_PLDIS);
>> +#if 0
>> + /*
>> + * Enable pipelining, fixes FEC problems. The previous =
workaround is not
>> + * needed, as we have an MPC5200B (not A).
>> + */
>> + out_be32(&xlb->config, in_be32(&xlb->config) & =
~MPC52xx_XLB_CFG_PLDIS);
>> +#endif
>>
>> iounmap(xlb);
>> }
>>
>> --
>> Pengutronix e.K. | Wolfram Sang =
|
>> Industrial Linux Solutions | =
http://www.pengutronix.de/ |
>>
>> Wolfram,
>>
>> Thanks, but no luck with this patch. It was already setup correctly =
by U-Boot.
>
>
> I don't see where this gets enabled in the u-boot source. Have you
> added it locally?
>
> These are the only two I see:
> cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << =
13);
> cpu/mpc5xxx/cpu_init.c: *(vu_long *)(MPC5XXX_XLBARB + 0x40) |=3D (1 << =
15);
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
> If you look a few more lines down you should see
> # if defined(CFG_XLB_PIPELINING)
> /* Enable piplining */
> *(vu_long *)(MPC5XXX_XLBARB + 0x40) &=3D ~(1 << 31);
> # endif
>
> I obtained the u-boot sources directly from phytec, for my phyCore, so =
I am not sure if they added it.
It is ok in main u-boot source. I just missed the lower section.
--=20
Jon Smirl
jonsmirl@gmail.com
It looks like the phy is never getting reset properly after the =
FEC_IEVENT_RFIFO_ERROR. I threw some printk's into the fec mdio driver
/drivers/net/fec_mpc52xx_phy.c
25 static int mpc52xx_fec_mdio_transfer(struct mii_bus *bus, int =
phy_id,
26 int reg, u32 value)
27 {
28 struct mpc52xx_fec_mdio_priv *priv =3D bus->priv;
29 struct mpc52xx_fec __iomem *fec;
30 int tries =3D 100;
31=20
32 value |=3D (phy_id << FEC_MII_DATA_PA_SHIFT) & =
FEC_MII_DATA_PA_MSK;
33 value |=3D (reg << FEC_MII_DATA_RA_SHIFT) & =
FEC_MII_DATA_RA_MSK;
34=20
35 fec =3D priv->regs;
36 out_be32(&fec->ievent, FEC_IEVENT_MII);
37 out_be32(&priv->regs->mii_data, value);
38=20
39 /* wait for it to finish, this takes about 23 us on =
lite5200b */
40 while (!(in_be32(&fec->ievent) & FEC_IEVENT_MII) && =
--tries)
41 udelay(5);
42=20
43 if (!tries) {
44 printk("Unable to reset phy\n");
45 return -ETIMEDOUT;
46 }
47=20
48 return value & FEC_MII_DATA_OP_RD ?
49 in_be32(&priv->regs->mii_data) & =
FEC_MII_DATA_DATAMSK : 0;
50 }
and got this
[ 127.085632] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 127.093401] Resetting FEC
[ 127.096620] Unable to reset phy
[ 127.322224] Unable to reset phy
[ 128.321987] PHY: f0003000:00 - Link is Down
[ 129.221034] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 129.228165] Resetting FEC
[ 129.231384] Unable to reset phy
[ 129.322286] Unable to reset phy
[ 132.885863] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 132.893002] Resetting FEC
[ 132.896176] Unable to reset phy
[ 133.322202] Unable to reset phy
[ 135.684793] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 135.691969] Resetting FEC
[ 135.695192] Unable to reset phy
[ 136.322530] Unable to reset phy
[ 138.490805] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 138.497963] Resetting FEC
[ 138.501135] Unable to reset phy
[ 139.334200] Unable to reset phy
I guess I have to spend some quality time with the 5200 manual.
_________________________________________________________________________=
________________
This e-mail and the information, including any attachments, it contains =
are intended to be a confidential communication only to the person or =
entity to whom it is addressed and may contain information that is =
privileged. If the reader of this message is not the intended recipient, =
you are hereby notified that any dissemination, distribution or copying =
of this communication is strictly prohibited. If you have received this =
communication in error, please immediately notify the sender and destroy =
the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* no rx interrupts on mpc8272-based board
From: Landau, Bracha @ 2009-05-20 16:40 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
I have ported Linux-2-6-29 to my MPC8272 based board, very similar to the MPC8272ADS. I am using a cuImage.
Things seem to be working ok except that I am not getting any FEC interrupts (on IRQ5).
I see that I am transmitting ok.
Any ideas where the problem could be?
________________________________
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the postmaster@nds.com and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.
To protect the environment please do not print this e-mail unless necessary.
NDS Limited Registered Office: One London Road, Staines,Middlesex TW18 4EX, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00
[-- Attachment #2: Type: text/html, Size: 2225 bytes --]
^ permalink raw reply
* Re: mpc5200 fec error
From: Grant Likely @ 2009-05-20 16:49 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEC0@dekaexchange.deka.local>
On Wed, May 20, 2009 at 10:41 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
> It looks like the phy is never getting reset properly after the FEC_IEVEN=
T_RFIFO_ERROR. =A0I threw some printk's into the fec mdio driver
Yes, that sounds familiar. Most likely, the value of the MDIO bus
control register got clobbered and not reset when the FEC was reset.
Try adding this line to the beginning of mpc52xx_fec_mdio_transfer():
out_be32(&fec->mii_speed, 0x7e);
It's a dirty ugly hack, but it should help. If that works, then I can
come up with a better solution. Part of the problem is that the MDIO
handling in the current code really isn't very good. I've got changes
queued up in -next which cleans it up quite a bit which should make it
easier to fix properly.
g.
>
> /drivers/net/fec_mpc52xx_phy.c
> =A025 static int mpc52xx_fec_mdio_transfer(struct mii_bus *bus, int phy_i=
d,
> =A026 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int reg, u32 value)
> =A027 {
> =A028 =A0 =A0 =A0 =A0 struct mpc52xx_fec_mdio_priv *priv =3D bus->priv;
> =A029 =A0 =A0 =A0 =A0 struct mpc52xx_fec __iomem *fec;
> =A030 =A0 =A0 =A0 =A0 int tries =3D 100;
> =A031
> =A032 =A0 =A0 =A0 =A0 value |=3D (phy_id << FEC_MII_DATA_PA_SHIFT) & FEC_=
MII_DATA_PA_MSK;
> =A033 =A0 =A0 =A0 =A0 value |=3D (reg << FEC_MII_DATA_RA_SHIFT) & FEC_MII=
_DATA_RA_MSK;
> =A034
> =A035 =A0 =A0 =A0 =A0 fec =3D priv->regs;
> =A036 =A0 =A0 =A0 =A0 out_be32(&fec->ievent, FEC_IEVENT_MII);
> =A037 =A0 =A0 =A0 =A0 out_be32(&priv->regs->mii_data, value);
> =A038
> =A039 =A0 =A0 =A0 =A0 /* wait for it to finish, this takes about 23 us on=
lite5200b */
> =A040 =A0 =A0 =A0 =A0 while (!(in_be32(&fec->ievent) & FEC_IEVENT_MII) &&=
--tries)
> =A041 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 udelay(5);
> =A042
> =A043 =A0 =A0 =A0 =A0 if (!tries) {
> =A044 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk("Unable to reset phy\n");
> =A045 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ETIMEDOUT;
> =A046 =A0 =A0 =A0 =A0 }
> =A047
> =A048 =A0 =A0 =A0 =A0 return value & FEC_MII_DATA_OP_RD ?
> =A049 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in_be32(&priv->regs->mii_data) & FE=
C_MII_DATA_DATAMSK : 0;
> =A050 }
>
> and got this
>
> [ =A0127.085632] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0127.093401] Resetting FEC
> [ =A0127.096620] Unable to reset phy
> [ =A0127.322224] Unable to reset phy
> [ =A0128.321987] PHY: f0003000:00 - Link is Down
> [ =A0129.221034] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0129.228165] Resetting FEC
> [ =A0129.231384] Unable to reset phy
> [ =A0129.322286] Unable to reset phy
> [ =A0132.885863] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0132.893002] Resetting FEC
> [ =A0132.896176] Unable to reset phy
> [ =A0133.322202] Unable to reset phy
> [ =A0135.684793] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0135.691969] Resetting FEC
> [ =A0135.695192] Unable to reset phy
> [ =A0136.322530] Unable to reset phy
> [ =A0138.490805] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ =A0138.497963] Resetting FEC
> [ =A0138.501135] Unable to reset phy
> [ =A0139.334200] Unable to reset phy
>
> I guess I have to spend some quality time with the 5200 manual.
>
>
> _________________________________________________________________________=
________________
>
> This e-mail and the information, including any attachments, it contains a=
re intended to be a confidential communication only to the person or entity=
to whom it is addressed and may contain information that is privileged. If=
the reader of this message is not the intended recipient, you are hereby n=
otified that any dissemination, distribution or copying of this communicati=
on is strictly prohibited. If you have received this communication in error=
, please immediately notify the sender and destroy the original message.
>
> Thank you.
>
> Please consider the environment before printing this email.
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [net-next-2.6 PATCH] can: SJA1000: generic OF platform bus driver
From: Wolfgang Grandegger @ 2009-05-20 17:06 UTC (permalink / raw)
To: Linux Netdev List; +Cc: linuxppc-dev, devicetree-discuss
This patch adds a generic driver for SJA1000 chips on the OpenFirmware
platform bus found on embedded PowerPC systems. You need a SJA1000 node
definition in your flattened device tree source (DTS) file similar to:
can@3,100 {
compatible = "philips,sja1000";
reg = <3 0x100 0x80>;
clock-frequency = <8000000>;
cdr-reg = <0x48>;
ocr-reg = <0x0a>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
};
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
drivers/net/can/Kconfig | 9 +
drivers/net/can/sja1000/Makefile | 1
drivers/net/can/sja1000/sja1000_of_platform.c | 215 ++++++++++++++++++++++++++
3 files changed, 225 insertions(+)
Index: net-next-2.6/drivers/net/can/Kconfig
===================================================================
--- net-next-2.6.orig/drivers/net/can/Kconfig
+++ net-next-2.6/drivers/net/can/Kconfig
@@ -51,6 +51,15 @@ config CAN_SJA1000_PLATFORM
boards from Phytec (http://www.phytec.de) like the PCM027,
PCM038.
+config CAN_SJA1000_OF_PLATFORM
+ depends on CAN_SJA1000 && PPC_OF
+ tristate "Generic OF Platform Bus based SJA1000 driver"
+ ---help---
+ This driver adds support for the SJA1000 chips connected to
+ the OpenFirmware "platform bus" found on embedded systems with
+ OpenFirmware bindings, e.g. if you have a PowerPC based system
+ you may want to enable this option.
+
config CAN_EMS_PCI
tristate "EMS CPC-PCI and CPC-PCIe Card"
depends on PCI && CAN_SJA1000
Index: net-next-2.6/drivers/net/can/sja1000/Makefile
===================================================================
--- net-next-2.6.orig/drivers/net/can/sja1000/Makefile
+++ net-next-2.6/drivers/net/can/sja1000/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_CAN_SJA1000) += sja1000.o
obj-$(CONFIG_CAN_SJA1000_PLATFORM) += sja1000_platform.o
+obj-$(CONFIG_CAN_SJA1000_OF_PLATFORM) += sja1000_of_platform.o
obj-$(CONFIG_CAN_EMS_PCI) += ems_pci.o
obj-$(CONFIG_CAN_KVASER_PCI) += kvaser_pci.o
Index: net-next-2.6/drivers/net/can/sja1000/sja1000_of_platform.c
===================================================================
--- /dev/null
+++ net-next-2.6/drivers/net/can/sja1000/sja1000_of_platform.c
@@ -0,0 +1,215 @@
+/*
+ * Driver for SJA1000 CAN controllers on the OpenFirmware platform bus
+ *
+ * Copyright (C) 2008-2009 Wolfgang Grandegger <wg@grandegger.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the version 2 of the GNU General Public License
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/* This is a generic driver for SJA1000 chips on the OpenFirmware platform
+ * bus found on embedded PowerPC systems. You need a SJA1000 CAN node
+ * definition in your flattened device tree source (DTS) file similar to:
+ *
+ * can@3,100 {
+ * compatible = "philips,sja1000";
+ * reg = <3 0x100 0x80>;
+ * clock-frequency = <8000000>;
+ * cdr-reg = <0x48>;
+ * ocr-reg = <0x0a>;
+ * interrupts = <2 0>;
+ * interrupt-parent = <&mpic>;
+ * };
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/netdevice.h>
+#include <linux/delay.h>
+#include <linux/can.h>
+#include <linux/can/dev.h>
+
+#include <linux/of_platform.h>
+#include <asm/prom.h>
+
+#include "sja1000.h"
+
+#define DRV_NAME "sja1000_of_platform"
+
+MODULE_AUTHOR("Wolfgang Grandegger <wg@grandegger.com>");
+MODULE_DESCRIPTION("Socket-CAN driver for SJA1000 on the OF platform bus");
+MODULE_LICENSE("GPL v2");
+
+#define SJA1000_OFP_CAN_CLOCK (16000000 / 2)
+
+#define SJA1000_OFP_OCR OCR_TX0_PULLDOWN
+#define SJA1000_OFP_CDR (CDR_CBP | CDR_CLK_OFF)
+
+static u8 sja1000_ofp_read_reg(const struct net_device *dev, int reg)
+{
+ return in_8((void __iomem *)(dev->base_addr + reg));
+}
+
+static void sja1000_ofp_write_reg(const struct net_device *dev, int reg, u8 val)
+{
+ out_8((void __iomem *)(dev->base_addr + reg), val);
+}
+
+static int __devexit sja1000_ofp_remove(struct of_device *ofdev)
+{
+ struct net_device *dev = dev_get_drvdata(&ofdev->dev);
+ struct device_node *np = ofdev->node;
+ struct resource res;
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ unregister_sja1000dev(dev);
+ free_sja1000dev(dev);
+ iounmap((void __iomem *)dev->base_addr);
+ irq_dispose_mapping(dev->irq);
+
+ of_address_to_resource(np, 0, &res);
+ release_mem_region(res.start, resource_size(res));
+
+ return 0;
+}
+
+static int __devinit sja1000_ofp_probe(struct of_device *ofdev,
+ const struct of_device_id *id)
+{
+ struct device_node *np = ofdev->node;
+ struct net_device *dev;
+ struct sja1000_priv *priv;
+ struct resource res;
+ const u32 *prop;
+ int err, irq, res_size, prop_size;
+ void __iomem *base;
+
+ err = of_address_to_resource(np, 0, &res);
+ if (err) {
+ dev_err(&ofdev->dev, "invalid address\n");
+ return err;
+ }
+
+ res_size = resource_size(res);
+
+ if (!request_mem_region(res.start, res_size, DRV_NAME)) {
+ dev_err(&ofdev->dev, "couldn't request %#x..%#x\n",
+ res.start, res.end);
+ return -EBUSY;
+ }
+
+ base = ioremap_nocache(res.start, res_size);
+ if (!base) {
+ dev_err(&ofdev->dev, "couldn't ioremap %#x..%#x\n",
+ res.start, res.end);
+ err = -ENOMEM;
+ goto exit_release_mem;
+ }
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ dev_err(&ofdev->dev, "no irq found\n");
+ err = -ENODEV;
+ goto exit_unmap_mem;
+ }
+
+ dev = alloc_sja1000dev(0);
+ if (!dev) {
+ err = -ENOMEM;
+ goto exit_dispose_irq;
+ }
+
+ priv = netdev_priv(dev);
+
+ priv->read_reg = sja1000_ofp_read_reg;
+ priv->write_reg = sja1000_ofp_write_reg;
+
+ prop = of_get_property(np, "clock-frequency", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ priv->can.clock.freq = *prop;
+ else
+ priv->can.clock.freq = SJA1000_OFP_CAN_CLOCK;
+
+ prop = of_get_property(np, "ocr-reg", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ priv->ocr = (u8)*prop;
+ else
+ priv->ocr = SJA1000_OFP_OCR;
+
+ prop = of_get_property(np, "cdr-reg", &prop_size);
+ if (prop && (prop_size == sizeof(u32)))
+ priv->cdr = (u8)*prop;
+ else
+ priv->cdr = SJA1000_OFP_CDR;
+
+ priv->irq_flags = IRQF_SHARED;
+
+ dev->irq = irq;
+ dev->base_addr = (unsigned long)base;
+
+ dev_info(&ofdev->dev,
+ "base=0x%lx irq=%d clock=%d ocr=0x%02x cdr=0x%02x\n",
+ dev->base_addr, dev->irq, priv->can.clock.freq,
+ priv->ocr, priv->cdr);
+
+ dev_set_drvdata(&ofdev->dev, dev);
+ SET_NETDEV_DEV(dev, &ofdev->dev);
+
+ err = register_sja1000dev(dev);
+ if (err) {
+ dev_err(&ofdev->dev, "registering %s failed (err=%d)\n",
+ DRV_NAME, err);
+ goto exit_free_sja1000;
+ }
+
+ return 0;
+
+exit_free_sja1000:
+ free_sja1000dev(dev);
+exit_dispose_irq:
+ irq_dispose_mapping(irq);
+exit_unmap_mem:
+ iounmap(base);
+exit_release_mem:
+ release_mem_region(res.start, res_size);
+
+ return err;
+}
+
+static struct of_device_id __devinitdata sja1000_ofp_table[] = {
+ {.compatible = "philips,sja1000"},
+ {.compatible = "nxp,sja1000"},
+ {},
+};
+
+static struct of_platform_driver sja1000_ofp_driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
+ .probe = sja1000_ofp_probe,
+ .remove = __devexit_p(sja1000_ofp_remove),
+ .match_table = sja1000_ofp_table,
+};
+
+static int __init sja1000_ofp_init(void)
+{
+ return of_register_platform_driver(&sja1000_ofp_driver);
+}
+module_init(sja1000_ofp_init);
+
+static void __exit sja1000_ofp_exit(void)
+{
+ return of_unregister_platform_driver(&sja1000_ofp_driver);
+};
+module_exit(sja1000_ofp_exit);
^ permalink raw reply
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-20 17:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905200949q1fbeee8fy4b3a06d8e44d7c6b@mail.gmail.com>
-----Original Message-----
From: Grant Likely [mailto:grant.likely@secretlab.ca]=20
Sent: Wednesday, May 20, 2009 12:49
To: Eric Millbrandt
Cc: Jon Smirl; Wolfram Sang; linuxppc-dev@ozlabs.org
Subject: Re: mpc5200 fec error
On Wed, May 20, 2009 at 10:41 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
> It looks like the phy is never getting reset properly after the =
FEC_IEVENT_RFIFO_ERROR. I threw some printk's into the fec mdio driver
Yes, that sounds familiar. Most likely, the value of the MDIO bus
control register got clobbered and not reset when the FEC was reset.
Try adding this line to the beginning of mpc52xx_fec_mdio_transfer():
out_be32(&fec->mii_speed, 0x7e);
It's a dirty ugly hack, but it should help. If that works, then I can
come up with a better solution. Part of the problem is that the MDIO
handling in the current code really isn't very good. I've got changes
queued up in -next which cleans it up quite a bit which should make it
easier to fix properly.
g.
That worked! I'm still getting the fifo receive errors, but at least =
now the fec recovers.
[ 127.761365] net eth0: FEC_IEVENT_RFIFO_ERROR=20
[ 129.274341] PHY: f0003000:00 - Link is Down
[ 130.274266] PHY: f0003000:00 - Link is Up - 100/Full
[ 134.955324] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 136.273959] PHY: f0003000:00 - Link is Down
[ 137.274090] PHY: f0003000:00 - Link is Up - 100/Full
[ 140.521462] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 142.273955] PHY: f0003000:00 - Link is Down
[ 143.273954] PHY: f0003000:00 - Link is Up - 100/Full
[ 148.471582] net eth0: FEC_IEVENT_RFIFO_ERROR
[ 150.273984] PHY: f0003000:00 - Link is Down
[ 151.273901] PHY: f0003000:00 - Link is Up - 100/Full
Thanks Grant.
_________________________________________________________________________=
________________
This e-mail and the information, including any attachments, it contains =
are intended to be a confidential communication only to the person or =
entity to whom it is addressed and may contain information that is =
privileged. If the reader of this message is not the intended recipient, =
you are hereby notified that any dissemination, distribution or copying =
of this communication is strictly prohibited. If you have received this =
communication in error, please immediately notify the sender and destroy =
the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: mpc5200 fec error
From: Grant Likely @ 2009-05-20 17:41 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <A88094362DE0AE49A118AB9B4EB3612403F9DEC1@dekaexchange.deka.local>
[ed: quoting repaired]
On Wed, May 20, 2009 at 11:26 AM, Eric Millbrandt
<emillbrandt@dekaresearch.com> wrote:
> Grant Likely wrote:
> > Yes, that sounds familiar. =A0Most likely, the value of the MDIO bus
> > control register got clobbered and not reset when the FEC was reset.
> > Try adding this line to the beginning of mpc52xx_fec_mdio_transfer():
> >
> > out_be32(&fec->mii_speed, 0x7e);
> >
> > It's a dirty ugly hack, but it should help. =A0If that works, then I ca=
n
> > come up with a better solution. =A0Part of the problem is that the MDIO
> > handling in the current code really isn't very good. =A0I've got change=
s
> > queued up in -next which cleans it up quite a bit which should make it
> > easier to fix properly.
>
> That worked! =A0I'm still getting the fifo receive errors, but at least n=
ow the fec recovers.
Okay, I'll see if I can work that into a cleaner patch. In fact, I
should look into reworking it so that the PHY doesn't get reset on a
FIFO error. It shouldn't need to be reset at all AFAIKT. That way
even when FIFO errors occur, they should not cause an expensive
renegotiate time.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: mpc5200 fec error
From: Wolfram Sang @ 2009-05-20 17:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <fa686aa40905200949q1fbeee8fy4b3a06d8e44d7c6b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 866 bytes --]
> Yes, that sounds familiar. Most likely, the value of the MDIO bus
> control register got clobbered and not reset when the FEC was reset.
I recall that I wondered about the RFIFO-error case back then. The manual states
===
Receive FIFO Error - indicates error occurred within the RX FIFO. When
RFIFO_ERROR bit is set, ECNTRL.ETHER_EN is cleared, halting FEC frame
processing. When this occurs, software must ensure both the FIFO Controller and
BestComm are soft-reset.
===
It does not say that the whole FEC needs to be reset. (BTW doing a full FEC
reset in IRQ context caused OOPSes back then, have to dig up details, as it
doesn't seem to happen here...)
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-20 19:24 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <1242802267.16901.187.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 20 May 2009 16:51:07 +1000
> On Tue, 2009-05-19 at 22:51 -0700, David Miller wrote:
>> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Date: Wed, 20 May 2009 13:01:30 +1000
>>
>> > For example, some of the OF parsing bits may fail to convert memory
>> > addresses to IO addresses if the PCI host bridges have not been
>> > discovered yet, potentially causing issues with matching of resources
>> > between the early serial stuff and the generic serial driver (if you
>> > use an IO driven UART, the PCI 8250 driver may not properly figure out
>> > that what it's finding in its IO BARs is actually the same port as
>> > what it gets from the platform code as the later will end up with
>> > memory addresses rather than IO ones). That's one example.
>>
>> FWIW, I never run into this issue on sparc64 exactly because I
>> fully resolve all resources when I populate the OF device tree
>> in the kernel.
>
> What do you mean by fully resolve ? IE. The issue above is specific to
> IO space, which you can resolve both as MMIO, or as "IO" which in linux
> means going through the special mapping for IO which allows the use of
> the inX/outX instructions...
I mean that all OF devices have fully resolved MMIO resources. So
very early serial devices that sit in I/O space on sparc64 end
up being OF device drivers. See for example, drivers/net/sunsu.c
which is simply a 8250 chip that sits behind Sun's I/O space bus
that sits on PCI and provides things normally found via ISA on
x86 machines. Another example is drivers/serial/sunsab.c
> One of the issues we may have here on powerpc is that our very early
> probe of serial ports (so we get some debug output early) may get to
> those resources while the serial driver later sees the actual
> IORESOURCE_IO resources coming from the PCI probe, and is unable to
> figure that they are the same things.
I would make these device drivers OF device drivers.
Another option is to make use of the "address" property if present.
You can bypass all of the hassle of figuring out what the 'reg'
property resolves to by using that and if the device is the
console it is pretty reliable to expect OF to provide that "address"
property.
Of course this doesn't work well for non-console devices.
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: David Miller @ 2009-05-20 19:26 UTC (permalink / raw)
To: a.beregalov; +Cc: linuxppc-dev, netdev
In-Reply-To: <1242821902-16836-1-git-send-email-a.beregalov@gmail.com>
From: Alexander Beregalov <a.beregalov@gmail.com>
Date: Wed, 20 May 2009 16:18:22 +0400
> Fix this build error:
> drivers/built-in.o: In function `phy_state_machine':
> drivers/net/phy/phy.c:893: undefined reference to 'netif_carrier_off'
> drivers/net/phy/phy.c:854: undefined reference to 'netif_carrier_on'
>
> Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
This isn't right. Otherwise no networking driver would build
with NET_SCHED disabled.
net/sched/sch_generic.c is always built when NET is enabled
and that's where netif_carrier_off() is defined.
As you can see in net/sched/Makefile, sch_generic.o is
"obj-y", did you even check? :-)
^ permalink raw reply
* Re: Weird 5200/mtd-ram problem
From: Albrecht Dreß @ 2009-05-20 19:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A14124D.4090200@mlbassoc.com>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Am 20.05.09 16:23 schrieb(en) Gary Thomas:
> > In Linux, when I write the file to /dev/mtdx, the last dword of
> each block is broken, e.g. when running "dd if=pattern of=/dev/mtd5
> bs=512" the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa
> (instead of 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc,
> ... show this value, if I use bs=4096 the dword at 0xffc shows this
> value, etc. I looked at the CS/WR lines with a scope, and I couldn't
> see anything special. The timing should be fine, as u-boot uses the
> same as Linux.
> >
> > Any idea what goes wrong here? I guessed I missed something in the
> LPB setup...
>
> Check your cache setup - the BDI is most certainly not accessing this
> via the Data cache whereas Linux probably will be.
Hmm, yes - I didn't touch the vanilla Lite5200B Linux setup there,
which has a flash chip at cs1...
If it is really a cache problem (I'm away now from my test board) -
isn't a sync sufficient after doing the copy to the external ram
(lpb/cs1)? What is the proper approach for devices attached to the
localbus?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Weird 5200/mtd-ram problem
From: Gary Thomas @ 2009-05-20 19:59 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <1242848213.3432.0@antares>
Albrecht Dreß wrote:
> Am 20.05.09 16:23 schrieb(en) Gary Thomas:
>> > In Linux, when I write the file to /dev/mtdx, the last dword of each
>> block is broken, e.g. when running "dd if=pattern of=/dev/mtd5 bs=512"
>> the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of
>> 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc, ... show
>> this value, if I use bs=4096 the dword at 0xffc shows this value,
>> etc. I looked at the CS/WR lines with a scope, and I couldn't see
>> anything special. The timing should be fine, as u-boot uses the same
>> as Linux.
>> >
>> > Any idea what goes wrong here? I guessed I missed something in the
>> LPB setup...
>>
>> Check your cache setup - the BDI is most certainly not accessing this
>> via the Data cache whereas Linux probably will be.
>
> Hmm, yes - I didn't touch the vanilla Lite5200B Linux setup there, which
> has a flash chip at cs1...
>
> If it is really a cache problem (I'm away now from my test board) -
> isn't a sync sufficient after doing the copy to the external ram
> (lpb/cs1)? What is the proper approach for devices attached to the
> localbus?
Based on the behaviour, it's probably a timing problem with
multi-beat transfers. When the PowerPC does cache flushes,
the chip activity is very different than the single beat accesses
used by the BDI.
Try to access this without using the cache. If it works properly
then you'll need to look at the timing setup (the local bus registers)
to see why it fails with the multi-beat accesses.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: Weird 5200/mtd-ram problem
From: Wolfram Sang @ 2009-05-20 20:01 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <14558983.1242828785546.JavaMail.ngmail@webmail10.arcor-online.net>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
> For the test I created a "pattern file" which is filled with the unsigned
> long 0x0055aaff. Using the Abatron BDI3000, I can write the pattern file to
> the ram and re-read it without problems. The same applies to u-boot (write
> ram via tftp, dump contents).
Does it work with byte, word and long accesses?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-20 20:06 UTC (permalink / raw)
To: David Miller; +Cc: thunderbird2k, John.Linn, linuxppc-dev
In-Reply-To: <20090520.122453.169463011.davem@davemloft.net>
On Wed, May 20, 2009 at 1:24 PM, David Miller <davem@davemloft.net> wrote:
>> What do you mean by fully resolve ? IE. The issue above is specific to
>> IO space, which you can resolve both as MMIO, or as "IO" which in linux
>> means going through the special mapping for IO which allows the use of
>> the inX/outX instructions...
>
> I mean that all OF devices have fully resolved MMIO resources. =A0So
> very early serial devices that sit in I/O space on sparc64 end
> up being OF device drivers. =A0See for example, drivers/net/sunsu.c
> which is simply a 8250 chip that sits behind Sun's I/O space bus
> that sits on PCI and provides things normally found via ISA on
> x86 machines. =A0Another example is drivers/serial/sunsab.c
Unfortunately in the embedded powerpc case we don't actually have real
OF. We've only got the flattened device tree which usually doesn't
itemize the devices behind the PCI bus. Instead we rely on the kernel
probing for them.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox