* 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
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 21:56 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090520.122453.169463011.davem@davemloft.net>
> 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
Right. On Cell, we use the "normal" 8250 driver, via of_serial which
basically initializes it from the of device and associated resources.
It gets a bit messy because we -also- create a platform driver that can
be matched by 8250, in fact, we have a bit of generic powerpc code that
does that early at boot, initializes our low level very early udbg
thingy with it and creates the platform devices.
And then the serial port can -also- be detected by 8250_pci.c when it's
on a PCI based UART :-)
Now, generally thinks work fine even if you use all 3 drivers because
they have the same resources and 8250 has some smarts to figure that out
and not re-create ports. It somewhat fails in the case where we end up
with IO looking like MMIO on one side and looking like PCI IO on another
tho.
We -could- try to standardize on a single of those 3 methods of course.
The of_serial one has some appeal but I quite like the platform driver
approach at this stage because we have code to handle all sort of weirdo
special cases in there (more or less insane device-tree's, weird SoC's,
etc...) and still pump out something 8250_platform can grok, and that
code can run -very- early and provide a udbg backend for early debug and
xmon usage.
> 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.
Also we have various broken firmwares with non usable "address"
properties to deal with.
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 21:59 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, thunderbird2k, David Miller, John.Linn
In-Reply-To: <fa686aa40905201306j4ef96cafl8ac02736dbdf7e5@mail.gmail.com>
On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
> 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. 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
>
> 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.
We -can- itemize the PCI bus, it's up to you.
That leads to another interesting discussion...
On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
from the OF tree (avoiding the config space probing entirely). This is
very efficient and has some advantages such as avoiding touching the
BARs for sizing (which mean avoiding to temporarily disable access to
devices behind them, which can be useful when it's your serial port or
system controller there) etc...
It also have the advantage of avoiding a double PCI probe pass when the
FW already did it and since most FW do ...
I'm tempted to extract that code and stick it in a
drivers/pci/probe_of.c or something like that for more generic usage. We
also have a per-bus hook that allows to switch to "real" config space
probing at any point of the hierarchy (for example, you can setup things
so that only on-board devices are in OF and probed that away and
anything on your slot gets probed by linux using config space, that sort
of thing).
Cheers,
Ben.
^ permalink raw reply
* Re: Musings on PCI busses
From: Grant Likely @ 2009-05-20 22:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, thunderbird2k, David Miller, John.Linn
In-Reply-To: <1242856782.16901.203.camel@pasglop>
On Wed, May 20, 2009 at 3:59 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2009-05-20 at 14:06 -0600, Grant Likely wrote:
>> On Wed, May 20, 2009 at 1:24 PM, David Miller <davem@davemloft.net> wrot=
e:
>> >> What do you mean by fully resolve ? IE. The issue above is specific t=
o
>> >> IO space, which you can resolve both as MMIO, or as "IO" which in lin=
ux
>> >> means going through the special mapping for IO which allows the use o=
f
>> >> 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. =A0We've only got the flattened device tree which usually doesn't
>> itemize the devices behind the PCI bus. =A0Instead we rely on the kernel
>> probing for them.
>
> We -can- itemize the PCI bus, it's up to you.
Yes, we could. But I don't think it makes any sense to for the FDT
case. The firmware infrastructure is not in place to fill out the
device tree with the PCI bus layout for the off board devices.
>
> That leads to another interesting discussion...
>
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for sizing (which mean avoiding to temporarily disable access to
> devices behind them, which can be useful when it's your serial port or
> system controller there) etc...
>
> It also have the advantage of avoiding a double PCI probe pass when the
> FW already did it and since most FW do ...
>
> I'm tempted to extract that code and stick it in a
> drivers/pci/probe_of.c or something like that for more generic usage. We
> also have a per-bus hook that allows to switch to "real" config space
> probing at any point of the hierarchy (for example, you can setup things
> so that only on-board devices are in OF and probed that away and
> anything on your slot gets probed by linux using config space, that sort
> of thing).
That would be interesting.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Musings on PCI busses
From: David Miller @ 2009-05-20 22:41 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <1242856782.16901.203.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 21 May 2009 07:59:42 +1000
> On ppc64, we have code that can "create" the pci_bus & pci_dev hierarchy
> from the OF tree (avoiding the config space probing entirely). This is
> very efficient and has some advantages such as avoiding touching the
> BARs for sizing (which mean avoiding to temporarily disable access to
> devices behind them, which can be useful when it's your serial port or
> system controller there) etc...
>
> It also have the advantage of avoiding a double PCI probe pass when the
> FW already did it and since most FW do ...
>
> I'm tempted to extract that code and stick it in a
> drivers/pci/probe_of.c or something like that for more generic usage. We
> also have a per-bus hook that allows to switch to "real" config space
> probing at any point of the hierarchy (for example, you can setup things
> so that only on-board devices are in OF and probed that away and
> anything on your slot gets probed by linux using config space, that sort
> of thing).
This is exactly what sparc64 does as well, I took the powerpc code. :)
It also avoids a bunch of bugs that get unearthed as a result of
scanning the entire hierarchy with PCI config access "pokes". Some
PCI controllers hang when certain PCI config space addresses are
accessed, meanwhile some hypervisor versions don't generate the bus
timeout exception properly on PCI config accesses to nonexisting
devices, the list is endless.
And all of that went away when I imported the ppc64 code to do
this using the OF device tree.
So if you put this in a common place, let's consolidate the differences
accumulated in the sparc64 code so I can use it too :-)
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 22:49 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090520.154104.48737237.davem@davemloft.net>
On Wed, 2009-05-20 at 15:41 -0700, David Miller wrote:
> This is exactly what sparc64 does as well, I took the powerpc code. :)
>
> It also avoids a bunch of bugs that get unearthed as a result of
> scanning the entire hierarchy with PCI config access "pokes". Some
> PCI controllers hang when certain PCI config space addresses are
> accessed, meanwhile some hypervisor versions don't generate the bus
> timeout exception properly on PCI config accesses to nonexisting
> devices, the list is endless.
>
> And all of that went away when I imported the ppc64 code to do
> this using the OF device tree.
>
> So if you put this in a common place, let's consolidate the differences
> accumulated in the sparc64 code so I can use it too :-)
Allright, I'll give that a go asap, maybe tomorrow.
Cheers,
Ben.
^ permalink raw reply
* [PATCH V2] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 22:59 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905200936o63f47937rda28126ce0f46aad@mail.gmail.com>
Add a node for the i2c eeprom and delete the superflous gpio-example.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
---
Changes since V1: use vendor name in eeprom-node
arch/powerpc/boot/dts/pcm030.dts | 26 ++++----------------------
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8958347..30bfdc0 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -258,34 +258,16 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
- /* FIXME: EEPROM */
+ eeprom@52 {
+ compatible = "catalyst,24c32";
+ reg = <0x52>;
+ };
};
sram@8000 {
compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram";
reg = <0x8000 0x4000>;
};
-
- /* This is only an example device to show the usage of gpios. It maps all available
- * gpios to the "gpio-provider" device.
- */
- gpio {
- compatible = "gpio-provider";
-
- /* mpc52xx exp.con patchfield */
- gpios = <&gpio_wkup 0 0 /* GPIO_WKUP_7 11d jp13-3 */
- &gpio_wkup 1 0 /* GPIO_WKUP_6 14c */
- &gpio_wkup 6 0 /* PSC2_4 43c x5-11 */
- &gpio_simple 2 0 /* IRDA_1 24c x7-6 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpio_simple 3 0 /* IRDA_0 x8-5 set GPS_PORT_CONFIG[IRDA] = 0 */
- &gpt2 0 0 /* timer2 12d x4-4 */
- &gpt3 0 0 /* timer3 13d x6-4 */
- &gpt4 0 0 /* timer4 61c x2-16 */
- &gpt5 0 0 /* timer5 44c x7-11 */
- &gpt6 0 0 /* timer6 60c x8-15 */
- &gpt7 0 0 /* timer7 36a x17-9 */
- >;
- };
};
pci@f0000d00 {
--
1.6.2
^ permalink raw reply related
* How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-20 23:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Young, Andrew, Brown, Jeff
All,
First off, we turned SPE off completely in our build - so we=20
could debug a much deeper problem that seems to be occurring=20
in our application (before we try to find a potential test=20
case for corruption of GPR registers).
We have had this problem for 3 weeks, and just recently have=20
come down to a single test case that makes it fail (although=20
extremely complicated test case)...
Setup: =20
Master Blade (8548E) with Linux 2.6.23 (and custom BSP)
Slave Blade (8572E) with Linux 2.6.23 (and similar custom BSP).
The Master Blade works flawlessly (and also works in a slave=20
capacity too flawlessly). The single 'slave' 8572E blades=20
communicates with the 'master' blade over TCP/IP & PCI Express
(and is running a similar application)...
Running Single Core on slave 8572E (nosmp option on command line)=20
the application works in all conditions (from modestly loaded to=20
well oversubscribed/pegged CPU).
In Multi-core option, the application also works flawlessly. The=20
problem comes when we oversubscribe our application and push=20
this 'slave' blade to the extreme edge of processing (falling=20
behind in our processing...etc).=20
Eventually, sometime between 5-15 minutes, this board becomes=20
hung (where the console becomes completely unresponsive and=20
you cannot 'ping' the box).
I have a JTAG WindRiver ICE and connect to this blade after it=20
is hung, and it appears that both cores are running to some=20
extent:
Core 1 seems to be Idle loop - happily doing nothing=20
(and not servicing TCP and/or the console)...
Core 0 seems to be 'stuck' at the "InstructionStorage"=20
Exception. And it seems to be going 'nowhere' fast
SRR0 seems to point to this same spot (0xc00006C0)
SRR1 value is 0x00021200=20
I am at a loss to see how the kernel (and/or our kernel BSP)=20
cause this exception, and I am even more of a loss on figuring=20
out an application could cause this exception...
Anybody have any ideas - and/or ways to re-configure our=20
setup to obtain more data? Or does this sound familiar to=20
a bug somebody has already found in the kernel?
We are even having trouble defining a test program that can
cause (on purpose) the 'InstructionStorage' Exception (does=20
anybody have an simple 'c' (or ppc assembly) program that=20
causes this exception (so we can run in user application land
and see if the symptoms are similar))?
Thank you in advance for any / all help you can provide....
because I am completely stumped on even how to proceed!
Sincerely,
Tom Morrison
Principal Software Engineer
EMPIRIX=20
20 Crosby Drive - Bedford, MA 01730
p: 781.266.3567 f: 781.266.3670=20
email: tmorrison@empirix.com=20
www.empirix.com
^ permalink raw reply
* RE: RapidIO - general questions
From: Anderson, Trevor @ 2009-05-20 23:42 UTC (permalink / raw)
To: Jan Neskudla, ext Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242802800.9160.143.camel@demuxf9c>
With=20regards=20to=20your=20Oops:=20we=20sometimes=20find=20that,=20altho=
ugh=20a=20switch=20may
report=20a=20port=20being=20active,=20whenever
we=20try=20to=20discover=20what=20lies=20behind=20it,=20transfer=20errors=20=
occur=20that=20are
non-recoverable.
As=20a=20solution,=20on=20Freescale=20MPC8641D,=20we=20use=20a=20DMA=20tra=
nsfer=20to=20perform=20a
simple=20MAINT=20read=20on=20a=20new=20device,=20just=20to=20see=20if=20it=
=20responds.=20Transfer
errors=20may=20still=20happen,=20but=20they=20are=20recoverable=20in=20tha=
t=20case,=20and=20you
can=20train=20your=20code=20to=20avoid=20that=20port=20or=20try=20it=20lat=
er.=20(The=20DMA=20engine
will=20report=20the=20error,=20not=20the=20processor.)
>=20-----Original=20Message-----
>=20From:=20linuxppc-dev-bounces+tanderson=3Dcurtisswright.com@ozlabs.org
[mailto:linuxppc-dev-
>=20bounces+tanderson=3Dcurtisswright.com@ozlabs.org]=20On=20Behalf=20Of=20=
Jan
Neskudla
>=20Sent:=20Wednesday,=20May=2020,=202009=2012:00=20AM
>=20To:=20ext=20Li=20Yang
>=20Cc:=20linuxppc-dev;=20linux-kernel@vger.kernel.org
>=20Subject:=20Re:=20RapidIO=20-=20general=20questions
>=20
>=20n=20Fri,=202009-05-15=20at=2015:56=20+0800,=20ext=20Li=20Yang=20wrote:=
>=20>=20On=20Fri,=20May=2015,=202009=20at=203:33=20PM,=20Jan=20Neskudla
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>=20On=20Wed,=202009-05-13=20at=2018:57=20+0800,=20ext=20Li=20Yang=
=20wrote:
>=20>=20>>=20cc'ed=20LKML
>=20>=20>>
>=20>=20>>=20On=20Tue,=20May=2012,=202009=20at=205:17=20PM,=20Jan=20Neskud=
la
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>>=20>=20Hallo
>=20>=20>>=20>
>=20>=20>>=20>=20we'd=20likes=20to=20use=20a=20RapidIO=20as=20a=20general=20=
communication=20bus=20on
our=20new
>=20>=20>>=20>=20product,=20and=20so=20I=20have=20some=20questions=20about=
=20general=20design=20of
Linux=20RIO
>=20>=20>>=20>=20subsystem.=20I=20did=20not=20find=20any=20better=20mailin=
g=20list=20for=20RapidIO
>=20>=20>>=20>=20discussion.
>=20>=20>>=20>
>=20>=20>>=20>=20[1]=20-=20we'd=20like=20to=20implement=20following=20feat=
ures
>=20>=20>>=20>=20=20=20=20*=20Hot-plug=20(hot-insert/hot-remove)=20of=20de=
vices
>=20>=20>>=20>=20=20=20=20*=20Error=20handling=20(port-write=20packets=20-=
=20configuration,
handling=20of
>=20>=20>>=20>=20them)
>=20>=20>>=20>=20=20=20=20*=20Static=20ID=20configuration=20based=20on=20p=
ort=20numbers
>=20>=20>>=20>=20=20=20=20*=20Aux=20driver=20-=20basic=20driver,=20for=20s=
ending=20messages=20over
different
>=20>=20>>=20>=20mboxes,=20handling=20ranges=20of=20doorbells
>=20>=20>>=20>
>=20>=20>>=20>=20=20=20=20Is=20it=20here=20anyone=20who=20is=20working=20o=
n=20any=20improvement,=20or
anyone=20who
>=20>=20>>=20>=20knows=20the=20development=20plans=20for=20RapidIO=20subsy=
stem?
>=20>=20>>=20>
>=20>=20>>
>=20>=20>>=20AFAIK,=20there=20is=20no=20one=20currently=20working=20on=20t=
hese=20features=20for
Linux.
>=20>=20>>=20It=20will=20be=20good=20if=20you=20can=20add=20these=20useful=
=20features.
>=20>=20>=20Yes=20it=20looks=20like=20that,=20currently=20we=20are=20analy=
zing=20current=20rapidIO
>=20>=20>=20system,=20and=20how=20we=20can=20add=20these=20features.
>=20>=20>
>=20>=20>>
>=20>=20>>=20>=20[2]=20-=20I=20have=20a=20following=20problem=20with=20a=20=
current=20implementation
of
>=20>=20>>=20>=20loading=20drivers.=20The=20driver=20probe-function=20call=
=20is=20based=20on
comparison
>=20>=20>>=20>=20of=20VendorID=20(VID)=20and=20DeviceID=20(DID)=20only.=20=
Thus=20if=20I=20have=203
devices=20with
>=20>=20>>=20>=20same=20DID=20and=20VID=20connected=20to=20the=20same=20ne=
twork=20(bus),=20the
driver=20is
>=20>=20>>=20>=20loaded=203times,=20instead=20only=20once=20for=20the=20ac=
tual=20device=20Master
port.
>=20>=20>>
>=20>=20>>=20This=20should=20be=20the=20correct=20way=20as=20you=20actuall=
y=20have=203=20instances
of=20the=20device.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Rionet=20driver=20solved=20this=20by=20enabling=20to=20ca=
ll=20initialization
function
>=20>=20>>=20>=20just=20once,=20and=20it=20expect=20that=20this=20is=20the=
=20Master=20port.
>=20>=20>>
>=20>=20>>=20Rionet=20is=20kind=20of=20special.=20=20It's=20not=20working=20=
like=20a=20simple=20device
>=20>=20>>=20driver,=20but=20more=20like=20a=20customized=20protocol=20sta=
ck=20to=20support
multiple
>=20>=20>>=20ethernet=20over=20rio=20links.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Is=20it=20this=20correct=20behavior=20=20?=20It=20looks=20=
to=20me=20that=20RapidIO=20is
handled
>=20>=20>>=20>=20like=20a=20local=20bus=20(like=20PCI)
>=20>=20>>
>=20>=20>>=20This=20is=20correct=20behavior.=20=20All=20of=20them=20are=20=
using=20Linux
device/driver
>=20>=20>>=20infrastructure,=20but=20rionet=20is=20a=20special=20device.
>=20>=20>
>=20>=20>=20But=20I=20do=20not=20have=20a=203=20devices=20on=20one=20silic=
on.=20I=20am=20talking=20about=203
>=20>=20>=20devices=20(3=20x=20EP8548=20boards=20+=20IDT=20switch)=20conne=
cted=20over=20rapidIO
through
>=20>=20>=20the=20switch.=20And=20in=20this=20case=20I'd=20like=20to=20hav=
e=20only=20one=20driver
siting=20on
>=20>=20>=20the=20top=20of=20Linux=20RapidIO=20subsystem.=20I=20don't=20se=
e=20the=20advantage=20of
loading
>=20>
>=20>=20You=20are=20having=20one=20driver,=20but=20it=20probes=203=20times=
=20for=20each=20device
using
>=20>=20the=20driver.
>=20>
>=20>=20>=20a=20driver=20locally=20for=20remote=20device.=20Am=20I=20missi=
ng=20something=20=20?
>=20>
>=20>=20If=20you=20want=20to=20interact=20with=20the=20remote=20device,=20=
you=20need=20the=20driver
to
>=20>=20do=20the=20work=20locally.
>=20
>=20We=20are=20going=20to=20use=20a=20RapidIO=20as=20a=20bigger=20network=20=
of=20active=20devices,
and
>=20each=20will=20have=20each=20own=20driver=20(sitting=20on=20its=20own),=
=20and=20all=20the
>=20settings=20will=20be=20done=20over=20maintenance=20packets.
>=20
>=20May=20be=20it=20will=20be=20solved=20by=20the=20fact,=20that=20we=20ar=
e=20going=20to=20use=20a
>=20staticIDs,=20so=20there=20will=20be=20no=20discovery=20as=20it=20is=20=
now.=20And=20thus=20there
>=20will=20be=20only=20one=20device=20visible=20in=20the=20internal=20stru=
ctures=20of=20the
>=20subsystem,=20and=20thus=20only=20one=20drive=20will=20be=20loaded.
>=20
>=20>
>=20>=20>
>=20>=20>=20And=20one=20more=20think,=20I=20am=20getting=20so=20much=20Bus=
=20errors=20OOPSes.
Whenever
>=20>=20>=20there=20is=20a=20problem=20with=20a=20comunication=20over=20Ri=
o=20I=20get=20such=20a
kernel=20OPS.
>=20>=20>=20I=20had=20to=20add=20some=20delays=20into=20some=20function=20=
to=20be=20able=20to=20finish
the
>=20>=20>=20enum+discovery=20process.=20Did=20you=20have=20some=20experien=
ce=20with=20some
bigger
>=20>=20>=20rio=20network=20running=20under=20linux=20?
>=20>
>=20>=20It=20looks=20like=20an=20known=20issue=20for=20switched=20rio=20ne=
twork,=20but=20I=20don't
>=20>=20have=20the=20correct=20equipment=20to=20reproduce=20the=20problem=20=
here.=20=20Could=20you
>=20>=20do=20some=20basic=20debugging=20and=20share=20your=20findings?=20=20=
Thanks.
>=20
>=20I=20tried=20to=20acquired=20some=20info=20about=20the=20problem,=20I=20=
found=20that=20the=20OOPS
>=20always=20occur=20when=20there=20is=20no=20respond=20from=20the=20devic=
e=20or=20the=20respond
is
>=20too=20slow.=20I=20always=20got=20that=20error=20during=20function=20ca=
ll
>=20rio_get_host_deviceid_lock=20when=20it=20tries=20to=20access=20a=20rem=
ote=20device=20or
>=20switch.=20This=20function=20is=20the=20first=20call=20of=20the
rio_mport_read_config_32
>=20so=20is=20also=20first=20try=20of=20remote=20access=20to=20any=20devic=
e.
>=20
>=20It=20is=20a=20timing=20issue,=20and=20after=20placing=20a=20printk=20i=
nto=20the
>=20rio_get_host_deviceid_lock=20the=20OOPSing=20almost=20disappeared.
>=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20Jan
>=20
>=20>
>=20>=20-=20Leo
>=20
>=20_______________________________________________
>=20Linuxppc-dev=20mailing=20list
>=20Linuxppc-dev@ozlabs.org
>=20https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________________________________
This=20e-mail=20and=20any=20files=20transmitted=20with=20it=20are=20propri=
etary=20and=20intended=20solely=20for=20the=20use=20of=20the=20individual=20=
or=20entity=20to=20whom=20they=20are=20addressed.=20If=20you=20have=20reas=
on=20to=20believe=20that=20you=20have=20received=20this=20e-mail=20in=20er=
ror,=20please=20notify=20the=20sender=20and=20destroy=20this=20email=20and=
=20any=20attached=20files.=20Please=20note=20that=20any=20views=20or=20opi=
nions=20presented=20in=20this=20e-mail=20are=20solely=20those=20of=20the=20=
author=20and=20do=20not=20necessarily=20represent=20those=20of=20the=20Cur=
tiss-Wright=20Corporation=20or=20any=20of=20its=20subsidiaries.=20=20Docum=
ents=20attached=20hereto=20may=20contain=20technology=20subject=20to=20gov=
ernment=20export=20regulations.=20Recipient=20is=20solely=20responsible=20=
for=20ensuring=20that=20any=20re-export,=20transfer=20or=20disclosure=20of=
=20this=20information=20is=20in=20accordance=20with=20applicable=20governm=
ent=20export=20regulations.=20=20The=20recipient=20should=20check=20this=20=
e-mail=20and=20any=20attachments=20for=20the=20presence=20of=20viruses.=20=
Curtiss-Wright=20Corporation=20and=20its=20subsidiaries=20accept=20no=20li=
ability=20for=20any=20damage=20caused=20by=20any=20virus=20transmitted=20b=
y=20this=20e-mail.
^ 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