* 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 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: 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: 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: 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: [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
* 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: 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
* 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: Weird 5200/mtd-ram problem
From: Gary Thomas @ 2009-05-20 14:23 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: linuxppc-dev
In-Reply-To: <14558983.1242828785546.JavaMail.ngmail@webmail10.arcor-online.net>
Albrecht Dreß wrote:
> Hi all,
>
> I ran into a weird problem when I tried to access a static (NV) ram attached to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock 2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. the of entry reads
>
> nvram@1,0 {
> compatible = "mtd-ram";
> reg = <1 0x0 0x00080000>; // 512 kB
> bank-width = <2>;
> device-width = <2>;
> #size-cells = <1>;
> #address-cells = <1>;
> };
>
> 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).
>
> 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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Weird 5200/mtd-ram problem
From: Albrecht Dreß @ 2009-05-20 14:13 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I ran into a weird problem when I tried to access a static (NV) ram attache=
d to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock =
2.6.29.1 kernel). The 512k ram chip is connected in 16-bit mode to cs1. t=
he of entry reads
nvram@1,0 {
=09compatible =3D "mtd-ram";
=09reg =3D <1 0x0 0x00080000>; // 512 kB
=09bank-width =3D <2>;
=09device-width =3D <2>;
=09#size-cells =3D <1>;
=09#address-cells =3D <1>;
=09};
For the test I created a "pattern file" which is filled with the unsigned l=
ong 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 (writ=
e ram via tftp, dump contents).
In Linux, when I write the file to /dev/mtdx, the last dword of each block =
is broken, e.g. when running "dd if=3Dpattern of=3D/dev/mtd5 bs=3D512" the =
dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of 0x0055aaff),=
if I use bs=3D1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I u=
se bs=3D4096 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 sho=
uld be fine, as u-boot uses the same as Linux.
Any idea what goes wrong here? I guessed I missed something in the LPB set=
up...
Thanks in advance,
Albrecht.
Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus =FCber 80 Spielen w=E4hlen!
http://www.arcor.de/footer-gaming/
^ permalink raw reply
* RE: mpc5200 fec error
From: Eric Millbrandt @ 2009-05-20 13:42 UTC (permalink / raw)
To: Wolfram Sang, Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20090520064218.GA29102@pengutronix.de>
> > 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.
>=20
> Hi Eric,
>=20
> 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
=20
iounmap(xlb);
}
--=20
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.
Eric
_________________________________________________________________________=
________________
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: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Kumar Gala @ 2009-05-20 13:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list, Li Yang, Wolfgang Denk, LKML List
In-Reply-To: <20090513194249.BA7D9832E416@gemini.denx.de>
On May 13, 2009, at 2:42 PM, Wolfgang Denk wrote:
> Dear Li Yang,
>
> In message <2a27d3730905130328m27743852w2d68a62ebc32ce31@mail.gmail.com
> > you wrote:
>>
>> Although 8MB seems to be the common size used. It can be very easy
>> changed as a pluggable module. It might be better to make the code
>> working for any reasonable flash sizes.
>
> You either have to provide a correct device tree for your board, or
> use a boot loader / boot wrapper that fixes the flash base address and
> size.
>
> At the moment, U-Boot does not contain any code yet to do that
> (patches welcome :-), and as far as I understand the cuImage wrapper
> works just the other way round: it adjusts the mappings to the
> settings in the device tree, which may or may not match the actual
> hardware. This may work, but at least gives you a different flash
> memory map in Linux than what you had before in U-Boot, so it's not
> really nice either.
>
>
> Hm... it seems the majority of MPC8272ADS boards seems to come indeed
> with 8 MB NOR flash, so I wonder if the patch should actually go in?
>
> Best regards,
>
> Wolfgang Denk
Scott, any feedback if our boards have 8M or 32M flash modules?
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Kumar Gala @ 2009-05-20 13:27 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev list, Alexander Beregalov, Netdev
In-Reply-To: <alpine.LRH.2.00.0905201425540.5871@vixen.sonytel.be>
On May 20, 2009, at 7:27 AM, Geert Uytterhoeven wrote:
> On Wed, 20 May 2009, Alexander Beregalov wrote:
>> 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>
>> ---
>> arch/powerpc/platforms/82xx/Kconfig | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/
>> platforms/82xx/Kconfig
>> index 7c7df40..36a3e58 100644
>> --- a/arch/powerpc/platforms/82xx/Kconfig
>> +++ b/arch/powerpc/platforms/82xx/Kconfig
>> @@ -31,6 +31,9 @@ config EP8248E
>> select 8260
>> select FSL_SOC
>> select PHYLIB
>> + select NET
>> + select NETDEVICE
>> + select NET_SCHED
>> select MDIO_BITBANG
>> help
>> This enables support for the Embedded Planet EP8248E board.
>
> Why is there a `select PHYLIB' at the platform level? Shouldn't it
> be in
> drivers/net/Kconfig, near the appropriate network driver? That way
> people can
> build kernels without networking support, if they want.
I agree w/you however the initial reason it was:
commit ff21f23648d33649fcf3e1e99d03e245f0e1acf8
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Wed Jul 16 17:47:54 2008 -0500
powerpc/ep8248e: Unconditionally select PHYLIB for mdio_bitbang
Its possible to build the phylib as a module, however this breaks
the
board code because alloc_mdio_bitbang and mdiobus_register are not
available if we build as a module. These are needed by the board
code
since it implements the low level mdio bitbang ops.
So we unconditionally select PHYLIB to ensure its built into the
kernel
if we are building in EP8248E support.
Long term we should look at moving the mdio_ops into its own file
so it
can be built as a module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
so maybe it should:
select PHYLIB if NET
- k
^ permalink raw reply
* Re: [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Geert Uytterhoeven @ 2009-05-20 12:27 UTC (permalink / raw)
To: Alexander Beregalov; +Cc: linuxppc-dev, netdev
In-Reply-To: <1242821902-16836-1-git-send-email-a.beregalov@gmail.com>
On Wed, 20 May 2009, Alexander Beregalov wrote:
> 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>
> ---
> arch/powerpc/platforms/82xx/Kconfig | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
> index 7c7df40..36a3e58 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -31,6 +31,9 @@ config EP8248E
> select 8260
> select FSL_SOC
> select PHYLIB
> + select NET
> + select NETDEVICE
> + select NET_SCHED
> select MDIO_BITBANG
> help
> This enables support for the Embedded Planet EP8248E board.
Why is there a `select PHYLIB' at the platform level? Shouldn't it be in
drivers/net/Kconfig, near the appropriate network driver? That way people can
build kernels without networking support, if they want.
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [PATCH] powerpc/ep8248e: phylib needs NET_SCHED to build
From: Alexander Beregalov @ 2009-05-20 12:18 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: netdev, Alexander Beregalov
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>
---
arch/powerpc/platforms/82xx/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 7c7df40..36a3e58 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -31,6 +31,9 @@ config EP8248E
select 8260
select FSL_SOC
select PHYLIB
+ select NET
+ select NETDEVICE
+ select NET_SCHED
select MDIO_BITBANG
help
This enables support for the Embedded Planet EP8248E board.
--
1.6.2.4
^ permalink raw reply related
* [FTRACE] 2.6.30-rc6-git5 : Badness at kernel/trace/ftrace.c:444
From: Sachin Sant @ 2009-05-20 9:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rostedt
[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]
While booting 2.6.30-rc6-git5 kernel came across this badness message.
ftrace: allocating 18134 entries in 107 pages
------------[ cut here ]------------
Badness at kernel/trace/ftrace.c:444
NIP: c00000000011e754 LR: c0000000001210fc CTR: 0000000000000000
REGS: c000000000edba40 TRAP: 0700 Not tainted (2.6.30-rc6-git5)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000082 XER: 00000000
TASK = c000000000e2d650[0] 'swapper' THREAD: c000000000ed8000 CPU: 0
GPR00: 0000000000000001 c000000000edbcc0 c000000000ed8830 ffffffffffffffea
GPR04: c000000000500000 0000000000000004 0000000000000000 0000000000000080
GPR08: 0000000000000000 c000000000fe6c80 f0000000013bc5c0 001bd7a20f0eb79e
GPR12: 0000000048000088 c000000000f1f380 0000000000382400 0000000000000000
GPR16: 0000000001100000 0000000001550a00 0000000001550898 0000000008000000
GPR20: 00000000031cae90 c0000000008f3d88 0000000000000000 c000000000500000
GPR24: 0000000000000000 0000000000000000 0000000004a47270 0000000000000001
GPR28: c000000000fe6c80 c000000000500000 c000000000e670f0 c000000000edbcc0
NIP [c00000000011e754] .ftrace_bug+0x98/0x218
LR [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
Call Trace:
[c000000000edbcc0] [600000000012bf5c] 0x600000000012bf5c (unreliable)
[c000000000edbd60] [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
[c000000000edbe30] [c000000000929b8c] .ftrace_init+0x158/0x17c
[c000000000edbee0] [c0000000008fdca4] .start_kernel+0x47c/0x4a8
[c000000000edbf90] [c000000000008408] .start_here_common+0x2c/0xa4
Instruction dump:
41be0010 e93e8010 38000001 90090018 e93e8000 e81e8008 e87e80b0 48000138
8009001c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41be0010 e93e8010
ftrace failed to modify [<c000000000500000>] .uhci_activate_qh+0x34/0x220
actual: 00:00:10:10
irq: irq 2 on host null mapped to virtual irq 16
Observed similar problem with git4 as well. This doesn't seem to be a
widespread problem
and currently observing this on one out of 3 power6 machines.
Complete dmesg and .config(gzipped) attached.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: ftrace_dmesg_log --]
[-- Type: text/plain, Size: 16532 bytes --]
Phyp-dump disabled at boot time
Using pSeries machine description
Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24
Using 1TB segments
Found initrd at 0xc000000001e00000:0xc000000002182400
console [udbg0] enabled
Partition configured for 8 cpus.
CPU maps initialized for 2 threads per core
(thread shift is 1)
Starting Linux PPC64 #1 SMP Wed May 20 11:51:20 IST 2009
-----------------------------------------------------
ppc64_pft_size = 0x1a
physicalMemorySize = 0xa0000000
htab_hash_mask = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.30-rc6-git5 (root@mjs22lp1) (gcc version 4.4.0 20090307 (Red Hat 4.4.0-0.23) (GCC) ) #1 SMP Wed May 20 11:51:20 IST 2009
[boot]0012 Setup Arch
Node 0 Memory: 0x8000000-0x5c000000
Node 1 Memory: 0x0-0x8000000 0x5c000000-0xa0000000
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Using shared processor idle loop
Zone PFN ranges:
DMA 0x00000000 -> 0x000a0000
Normal 0x000a0000 -> 0x000a0000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
1: 0x00000000 -> 0x00008000
0: 0x00008000 -> 0x0005c000
1: 0x0005c000 -> 0x000a0000
On node 0 totalpages: 344064
DMA zone: 4704 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 339360 pages, LIFO batch:31
On node 1 totalpages: 311296
DMA zone: 8960 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 302336 pages, LIFO batch:31
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 641696
Policy zone: DMA
Kernel command line: ro console=hvc0 rhgb quiet root=UUID=9448b379-7842-486c-8bc8-22a1427c4462
NR_IRQS:512
[boot]0020 XICS Init
[boot]0021 XICS Done
pic: no ISA interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
time_init: decrementer frequency = 512.000000 MHz
time_init: processor frequency = 4005.000000 MHz
clocksource: timebase mult[7d0000] shift[22] registered
clockevent: decrementer mult[8312] shift[16] cpu[0]
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
allocated 26214400 bytes of page_cgroup
please try cgroup_disable=memory option if you don't want
freeing bootmem node 0
freeing bootmem node 1
Memory: 2514952k/2621440k available (14120k kernel code, 137064k reserved, 1076k data, 1310k bss, 4916k init)
SLUB: Genslabs=14, HWalign=128, Order=0-3, MinObjects=0, CPUs=8, Nodes=16
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux: Initializing.
SELinux: Starting in permissive mode
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
ftrace: allocating 18134 entries in 107 pages
------------[ cut here ]------------
Badness at kernel/trace/ftrace.c:444
NIP: c00000000011e754 LR: c0000000001210fc CTR: 0000000000000000
REGS: c000000000edba40 TRAP: 0700 Not tainted (2.6.30-rc6-git5)
MSR: 8000000000021032 <ME,CE,IR,DR> CR: 28000082 XER: 00000000
TASK = c000000000e2d650[0] 'swapper' THREAD: c000000000ed8000 CPU: 0
GPR00: 0000000000000001 c000000000edbcc0 c000000000ed8830 ffffffffffffffea
GPR04: c000000000500000 0000000000000004 0000000000000000 0000000000000080
GPR08: 0000000000000000 c000000000fe6c80 f0000000013bc5c0 001bd7a20f0eb79e
GPR12: 0000000048000088 c000000000f1f380 0000000000382400 0000000000000000
GPR16: 0000000001100000 0000000001550a00 0000000001550898 0000000008000000
GPR20: 00000000031cae90 c0000000008f3d88 0000000000000000 c000000000500000
GPR24: 0000000000000000 0000000000000000 0000000004a47270 0000000000000001
GPR28: c000000000fe6c80 c000000000500000 c000000000e670f0 c000000000edbcc0
NIP [c00000000011e754] .ftrace_bug+0x98/0x218
LR [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
Call Trace:
[c000000000edbcc0] [600000000012bf5c] 0x600000000012bf5c (unreliable)
[c000000000edbd60] [c0000000001210fc] .ftrace_convert_nops+0x20c/0x308
[c000000000edbe30] [c000000000929b8c] .ftrace_init+0x158/0x17c
[c000000000edbee0] [c0000000008fdca4] .start_kernel+0x47c/0x4a8
[c000000000edbf90] [c000000000008408] .start_here_common+0x2c/0xa4
Instruction dump:
41be0010 e93e8010 38000001 90090018 e93e8000 e81e8008 e87e80b0 48000138
8009001c 7c000034 5400d97e 78000020 <0b000000> 2fa00000 41be0010 e93e8010
ftrace failed to modify [<c000000000500000>] .uhci_activate_qh+0x34/0x220
actual: 00:00:10:10
irq: irq 2 on host null mapped to virtual irq 16
clockevent: decrementer mult[8312] shift[16] cpu[1]
Processor 1 found.
clockevent: decrementer mult[8312] shift[16] cpu[2]
Processor 2 found.
clockevent: decrementer mult[8312] shift[16] cpu[3]
Processor 3 found.
clockevent: decrementer mult[8312] shift[16] cpu[4]
Processor 4 found.
clockevent: decrementer mult[8312] shift[16] cpu[5]
Processor 5 found.
clockevent: decrementer mult[8312] shift[16] cpu[6]
Processor 6 found.
clockevent: decrementer mult[8312] shift[16] cpu[7]
Processor 7 found.
Brought up 8 CPUs
Node 0 CPUs: 0-7
Node 1 CPUs:
CPU0 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 0 1
domain 1: span 0-7 level CPU
groups: 0-1 2-3 4-5 6-7
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU1 attaching sched-domain:
domain 0: span 0-1 level SIBLING
groups: 1 0
domain 1: span 0-7 level CPU
groups: 0-1 2-3 4-5 6-7
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU2 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 2 3
domain 1: span 0-7 level CPU
groups: 2-3 4-5 6-7 0-1
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU3 attaching sched-domain:
domain 0: span 2-3 level SIBLING
groups: 3 2
domain 1: span 0-7 level CPU
groups: 2-3 4-5 6-7 0-1
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU4 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 4 5
domain 1: span 0-7 level CPU
groups: 4-5 6-7 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU5 attaching sched-domain:
domain 0: span 4-5 level SIBLING
groups: 5 4
domain 1: span 0-7 level CPU
groups: 4-5 6-7 0-1 2-3
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU6 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 6 7
domain 1: span 0-7 level CPU
groups: 6-7 0-1 2-3 4-5
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
CPU7 attaching sched-domain:
domain 0: span 6-7 level SIBLING
groups: 7 6
domain 1: span 0-7 level CPU
groups: 6-7 0-1 2-3 4-5
domain 2: span 0-7 level NODE
groups: 0-7 (__cpu_power = 4096)
net_namespace: 1952 bytes
regulator: core version 0.5
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware done
bio: create slab <bio-0> at 0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 3
Switched to high resolution mode on CPU 4
Switched to high resolution mode on CPU 5
Switched to high resolution mode on CPU 1
Switched to high resolution mode on CPU 6
Switched to high resolution mode on CPU 2
Switched to high resolution mode on CPU 7
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 524288 bind 65536)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3593k freed
irq: irq 655360 on host null mapped to virtual irq 17
irq: irq 655362 on host null mapped to virtual irq 18
IOMMU table initialized, virtual merging enabled
irq: irq 655364 on host null mapped to virtual irq 19
irq: irq 655365 on host null mapped to virtual irq 20
irq: irq 589825 on host null mapped to virtual irq 21
RTAS daemon started
audit: initializing netlink socket (disabled)
type=2000 audit(1242803832.218:1): initialized
RTAS: event: 20, Type: Platform Error, Severity: 2
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 4919
SELinux: Registering netfilter hooks
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
vio_register_driver: driver hvc_console registering
HVSI: registered 0 devices
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
TX39/49 Serial driver version 1.11
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver
ide-gd driver 1.18
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
mice: PS/2 mouse device common for all mice
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
Running MSI bitmap self-tests ...
PM: Resume from disk failed.
registered taskstats version 1
Initalizing network drop monitor service
Freeing unused kernel memory: 4916k freed
vio_register_driver: driver ibmvscsi registering
ibmvscsi 30000002: SRP_VERSION: 16.a
scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
ibmvscsi 30000002: partner initialization complete
ibmvscsi 30000002: sent SRP login
ibmvscsi 30000002: SRP_LOGIN succeeded
ibmvscsi 30000002: host srp version: 16.a, host partition 06-1C12A (1), OS 3, max io 1048576
scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
scsi: waiting for bus probes to complete ...
sd 0:0:1:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: [sda] 147324928 512-byte hardware sectors: (75.4 GB/70.2 GiB)
sd 0:0:1:0: [sda] Write Protect is off
sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sd 0:0:1:0: [sda] Cache data unavailable
sd 0:0:1:0: [sda] Assuming drive cache: write through
sda:<7>sr 0:0:2:0: Attached scsi CD-ROM sr0
sr 0:0:2:0: Attached scsi generic sg1 type 5
sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
sd 0:0:1:0: [sda] Attached SCSI disk
EXT4-fs: barriers enabled
kjournald2 starting: pid 129, dev sda3:8, commit interval 5 seconds
EXT4-fs: delayed allocation enabled
EXT4-fs: file extents enabled
EXT4-fs: mballoc enabled
EXT4-fs: mounted filesystem sda3 with ordered data mode
type=1404 audit(1242803833.068:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295
SELinux: 8192 avtab hash slots, 117789 rules.
SELinux: 8192 avtab hash slots, 117789 rules.
SELinux: 8 users, 13 roles, 2653 types, 121 bools, 1 sens, 1024 cats
SELinux: 74 classes, 117789 rules
SELinux: Completing initialization.
SELinux: Setting up existing superblocks.
SELinux: initialized (dev sda3, type ext4), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev anon_inodefs, type anon_inodefs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
type=1403 audit(1242803833.425:3): policy loaded auid=4294967295 ses=4294967295
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
udev: starting version 139
drivers/net/ibmveth.c: ibmveth: IBM i/pSeries Virtual Ethernet Driver 1.03
vio_register_driver: driver ibmveth registering
eth0 (ibmveth): not using net_device_ops yet
eth1 (ibmveth): not using net_device_ops yet
IBM eHEA ethernet device driver (Release EHEA_0101)
irq: irq 590080 on host null mapped to virtual irq 256
ehea: eth0: Jumbo frames are enabled
ehea: eth0 -> logical port id #3
ehea: eth2: Jumbo frames are enabled
ehea: eth2 -> logical port id #4
udev: renamed network interface eth1 to eth3
udev: renamed network interface eth0_rename to eth1
device-mapper: multipath: version 1.0.5 loaded
EXT4 FS on sda3, internal journal on sda3:8
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda2, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
SELinux: initialized (dev sda2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
Adding 3068372k swap on /dev/sda8. Priority:-1 extents:1 across:3068372k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.13
Bluetooth: L2CAP socket layer initialized
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
virbr0: starting userspace STP failed, starting kernel STP
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
lo: Disabled Privacy Extensions
SELinux: initialized (dev proc, type proc), uses genfs_contexts
eth3: no IPv6 routers present
eth1: no IPv6 routers present
virbr0: no IPv6 routers present
ehea: eth0: Physical port up
ehea: External switch port is backup port
irq: irq 777 on host null mapped to virtual irq 265
irq: irq 778 on host null mapped to virtual irq 266
eth0: no IPv6 routers present
[-- Attachment #3: config_ftrace.gz --]
[-- Type: application/x-gzip, Size: 23592 bytes --]
^ permalink raw reply
* AMCC 405ex memory size issue
From: konamo @ 2009-05-20 8:55 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
we are using u-boot 2009.01, linux-2.6.25-rc2, 1GB DDR2 memory(2Gbit * 4,
1 rank), AMCC powerpc 405ex, both 1G and 512MB memory works fine under
u-boot, but linux boot fails in 1G memory, if we limit mem=512M, linux could
boot. Could anyone pls help us how to find the root cause? thanks
--
View this message in context: http://www.nabble.com/AMCC-405ex-memory-size-issue-tp23631525p23631525.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] powerpc/pcm030.dts: add i2c eeprom and delete cruft
From: Wolfram Sang @ 2009-05-20 8:07 UTC (permalink / raw)
To: w.sang; +Cc: linuxppc-dev
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
---
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..33ce488 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 = "at24,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
* Re: [PATCH] powerpc/5200: beyond ARRAY_SIZE of mpc52xx_uart_{ports, nodes}
From: Wolfram Sang @ 2009-05-20 7:11 UTC (permalink / raw)
To: Roel Kluin; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <4A134EC4.3000805@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Wed, May 20, 2009 at 02:28:52AM +0200, Roel Kluin wrote:
> Do not go beyond ARRAY_SIZE of mpc52xx_uart_{ports,nodes}
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
> ---
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index 7f72f8c..b3feb61 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -988,7 +988,7 @@ mpc52xx_console_setup(struct console *co, char *options)
> pr_debug("mpc52xx_console_setup co=%p, co->index=%i, options=%s\n",
> co, co->index, options);
>
> - if ((co->index < 0) || (co->index > MPC52xx_PSC_MAXNUM)) {
> + if ((co->index < 0) || (co->index >= MPC52xx_PSC_MAXNUM)) {
> pr_debug("PSC%x out of range\n", co->index);
> return -EINVAL;
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
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: [RFC][PATCH] powerpc/pci: Pull ppc32 code we need in ppc64
From: Benjamin Herrenschmidt @ 2009-05-20 7:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <A254D12F-2709-48BB-8E7B-2F82D45D1372@kernel.crashing.org>
On Wed, 2009-05-20 at 00:57 -0500, Kumar Gala wrote:
> Ben,
>
> Comments on the pmac case?
Not yet :-) Give me a day. Was tracking a bug today.
Cheers,
Ben.
> - k
>
> On Apr 29, 2009, at 3:49 PM, Kumar Gala wrote:
>
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > ---
> >
> > Ben,
> >
> > My question is if we think fake_pci_bus will always get a valid
> > hose().
> > The users of EARLY_PCI_OP are fsl/8xxx, 4xx, and pmac. I verified
> > that
> > fsl/8xxx & 4xx pass a valid hose. Do we think pmac does?
> >
> > - k
> >
> > arch/powerpc/include/asm/machdep.h | 6 +-
> > arch/powerpc/include/asm/pci-bridge.h | 35 +++++++---------
> > arch/powerpc/kernel/pci-common.c | 70 ++++++++++++++++++++++++
> > ++++++++
> > arch/powerpc/kernel/pci_32.c | 71
> > ---------------------------------
> > 4 files changed, 89 insertions(+), 93 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/
> > include/asm/machdep.h
> > index 0efdb1d..1b389ff 100644
> > --- a/arch/powerpc/include/asm/machdep.h
> > +++ b/arch/powerpc/include/asm/machdep.h
> > @@ -205,14 +205,14 @@ struct machdep_calls {
> > /*
> > * optional PCI "hooks"
> > */
> > - /* Called in indirect_* to avoid touching devices */
> > - int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> > unsigned char);
> > -
> > /* Called at then very end of pcibios_init() */
> > void (*pcibios_after_init)(void);
> >
> > #endif /* CONFIG_PPC32 */
> >
> > + /* Called in indirect_* to avoid touching devices */
> > + int (*pci_exclude_device)(struct pci_controller *, unsigned char,
> > unsigned char);
> > +
> > /* Called after PPC generic resource fixup to perform
> > machine specific fixups */
> > void (*pcibios_fixup_resources)(struct pci_dev *);
> > diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/
> > include/asm/pci-bridge.h
> > index 48f58aa..8b371df 100644
> > --- a/arch/powerpc/include/asm/pci-bridge.h
> > +++ b/arch/powerpc/include/asm/pci-bridge.h
> > @@ -77,9 +77,7 @@ struct pci_controller {
> >
> > int first_busno;
> > int last_busno;
> > -#ifndef CONFIG_PPC64
> > int self_busno;
> > -#endif
> >
> > void __iomem *io_base_virt;
> > #ifdef CONFIG_PPC64
> > @@ -104,7 +102,6 @@ struct pci_controller {
> > unsigned int __iomem *cfg_addr;
> > void __iomem *cfg_data;
> >
> > -#ifndef CONFIG_PPC64
> > /*
> > * Used for variants of PCI indirect handling and possible quirks:
> > * SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
> > @@ -128,7 +125,6 @@ struct pci_controller {
> > #define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x00000010
> > #define PPC_INDIRECT_TYPE_BROKEN_MRM 0x00000020
> > u32 indirect_type;
> > -#endif /* !CONFIG_PPC64 */
> > /* Currently, we limit ourselves to 1 IO range and 3 mem
> > * ranges since the common pci_bus structure can't handle more
> > */
> > @@ -146,21 +142,6 @@ struct pci_controller {
> > #endif /* CONFIG_PPC64 */
> > };
> >
> > -#ifndef CONFIG_PPC64
> > -
> > -static inline struct pci_controller *pci_bus_to_host(const struct
> > pci_bus *bus)
> > -{
> > - return bus->sysdata;
> > -}
> > -
> > -static inline int isa_vaddr_is_ioport(void __iomem *address)
> > -{
> > - /* No specific ISA handling on ppc32 at this stage, it
> > - * all goes through PCI
> > - */
> > - return 0;
> > -}
> > -
> > /* These are used for config access before all the PCI probing
> > has been done. */
> > extern int early_read_config_byte(struct pci_controller *hose, int
> > bus,
> > @@ -182,6 +163,22 @@ extern int early_find_capability(struct
> > pci_controller *hose, int bus,
> > extern void setup_indirect_pci(struct pci_controller* hose,
> > resource_size_t cfg_addr,
> > resource_size_t cfg_data, u32 flags);
> > +
> > +#ifndef CONFIG_PPC64
> > +
> > +static inline struct pci_controller *pci_bus_to_host(const struct
> > pci_bus *bus)
> > +{
> > + return bus->sysdata;
> > +}
> > +
> > +static inline int isa_vaddr_is_ioport(void __iomem *address)
> > +{
> > + /* No specific ISA handling on ppc32 at this stage, it
> > + * all goes through PCI
> > + */
> > + return 0;
> > +}
> > +
> > #else /* CONFIG_PPC64 */
> >
> > /*
> > diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/
> > pci-common.c
> > index 9c69e7e..cae4ee1 100644
> > --- a/arch/powerpc/kernel/pci-common.c
> > +++ b/arch/powerpc/kernel/pci-common.c
> > @@ -1620,3 +1620,73 @@ void __devinit
> > pcibios_setup_phb_resources(struct pci_controller *hose)
> >
> > }
> >
> > +/*
> > + * Null PCI config access functions, for the case when we can't
> > + * find a hose.
> > + */
> > +#define NULL_PCI_OP(rw, size, type) \
> > +static int \
> > +null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> > val) \
> > +{ \
> > + return PCIBIOS_DEVICE_NOT_FOUND; \
> > +}
> > +
> > +static int
> > +null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > + int len, u32 *val)
> > +{
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +}
> > +
> > +static int
> > +null_write_config(struct pci_bus *bus, unsigned int devfn, int
> > offset,
> > + int len, u32 val)
> > +{
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +}
> > +
> > +static struct pci_ops null_pci_ops =
> > +{
> > + .read = null_read_config,
> > + .write = null_write_config,
> > +};
> > +
> > +/*
> > + * These functions are used early on before PCI scanning is done
> > + * and all of the pci_dev and pci_bus structures have been created.
> > + */
> > +static struct pci_bus *
> > +fake_pci_bus(struct pci_controller *hose, int busnr)
> > +{
> > + static struct pci_bus bus;
> > +
> > + if (hose == 0) {
> > + printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> > + }
> > + bus.number = busnr;
> > + bus.sysdata = hose;
> > + bus.ops = hose? hose->ops: &null_pci_ops;
> > + return &bus;
> > +}
> > +
> > +#define EARLY_PCI_OP(rw, size, type) \
> > +int early_##rw##_config_##size(struct pci_controller *hose, int
> > bus, \
> > + int devfn, int offset, type value) \
> > +{ \
> > + return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> > + devfn, offset, value); \
> > +}
> > +
> > +EARLY_PCI_OP(read, byte, u8 *)
> > +EARLY_PCI_OP(read, word, u16 *)
> > +EARLY_PCI_OP(read, dword, u32 *)
> > +EARLY_PCI_OP(write, byte, u8)
> > +EARLY_PCI_OP(write, word, u16)
> > +EARLY_PCI_OP(write, dword, u32)
> > +
> > +extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> > int devfn, int cap);
> > +int early_find_capability(struct pci_controller *hose, int bus, int
> > devfn,
> > + int cap)
> > +{
> > + return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> > +}
> > diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/
> > pci_32.c
> > index d473634..32fbadb 100644
> > --- a/arch/powerpc/kernel/pci_32.c
> > +++ b/arch/powerpc/kernel/pci_32.c
> > @@ -497,75 +497,4 @@ long sys_pciconfig_iobase(long which, unsigned
> > long bus, unsigned long devfn)
> > return result;
> > }
> >
> > -/*
> > - * Null PCI config access functions, for the case when we can't
> > - * find a hose.
> > - */
> > -#define NULL_PCI_OP(rw, size, type) \
> > -static int \
> > -null_##rw##_config_##size(struct pci_dev *dev, int offset, type
> > val) \
> > -{ \
> > - return PCIBIOS_DEVICE_NOT_FOUND; \
> > -}
> > -
> > -static int
> > -null_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
> > - int len, u32 *val)
> > -{
> > - return PCIBIOS_DEVICE_NOT_FOUND;
> > -}
> > -
> > -static int
> > -null_write_config(struct pci_bus *bus, unsigned int devfn, int
> > offset,
> > - int len, u32 val)
> > -{
> > - return PCIBIOS_DEVICE_NOT_FOUND;
> > -}
> > -
> > -static struct pci_ops null_pci_ops =
> > -{
> > - .read = null_read_config,
> > - .write = null_write_config,
> > -};
> >
> > -/*
> > - * These functions are used early on before PCI scanning is done
> > - * and all of the pci_dev and pci_bus structures have been created.
> > - */
> > -static struct pci_bus *
> > -fake_pci_bus(struct pci_controller *hose, int busnr)
> > -{
> > - static struct pci_bus bus;
> > -
> > - if (hose == 0) {
> > - hose = pci_bus_to_hose(busnr);
> > - if (hose == 0)
> > - printk(KERN_ERR "Can't find hose for PCI bus %d!\n", busnr);
> > - }
> > - bus.number = busnr;
> > - bus.sysdata = hose;
> > - bus.ops = hose? hose->ops: &null_pci_ops;
> > - return &bus;
> > -}
> > -
> > -#define EARLY_PCI_OP(rw, size, type) \
> > -int early_##rw##_config_##size(struct pci_controller *hose, int
> > bus, \
> > - int devfn, int offset, type value) \
> > -{ \
> > - return pci_bus_##rw##_config_##size(fake_pci_bus(hose, bus), \
> > - devfn, offset, value); \
> > -}
> > -
> > -EARLY_PCI_OP(read, byte, u8 *)
> > -EARLY_PCI_OP(read, word, u16 *)
> > -EARLY_PCI_OP(read, dword, u32 *)
> > -EARLY_PCI_OP(write, byte, u8)
> > -EARLY_PCI_OP(write, word, u16)
> > -EARLY_PCI_OP(write, dword, u32)
> > -
> > -extern int pci_bus_find_capability (struct pci_bus *bus, unsigned
> > int devfn, int cap);
> > -int early_find_capability(struct pci_controller *hose, int bus, int
> > devfn,
> > - int cap)
> > -{
> > - return pci_bus_find_capability(fake_pci_bus(hose, bus), devfn, cap);
> > -}
> > --
> > 1.6.0.6
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Musings on PCI busses
From: Benjamin Herrenschmidt @ 2009-05-20 6:51 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, thunderbird2k, John.Linn
In-Reply-To: <20090519.225118.58497608.davem@davemloft.net>
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...
The later can only be done after we have established the special mapping
in question for a given PCI bus IO space, at which point, we know what
IO "base" corresponds to the IO space of that bridge. So in the
meantime, all we have is an MMIO resource, which is "resolved" in the
sense that it does contain all the right bits to get the serial ports
(address translation etc...) but isn't an IORESOURCE_IO type resource
and thus doesn't contain a magic token we can pass to inX/outX.
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.
Currently, we do a pass of "conversion" over those early resolved
resources just after the PCI bridges have been discovered to check if
they happen to land into the IO space of a bridge and then turn them
into IORESOURCE_IO tokens.
If we delay the probing of PCI bridges, things can get fishy there.
Cheers,
Ben.
^ permalink raw reply
* Re: RapidIO - general questions
From: Jan Neskudla @ 2009-05-20 7:00 UTC (permalink / raw)
To: ext Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2a27d3730905150056m7298b66ckb9db92f9432953d6@mail.gmail.com>
n Fri, 2009-05-15 at 15:56 +0800, ext Li Yang wrote:
> On Fri, May 15, 2009 at 3:33 PM, Jan Neskudla <jan.neskudla.ext@nsn.com> wrote:
> > On Wed, 2009-05-13 at 18:57 +0800, ext Li Yang wrote:
> >> cc'ed LKML
> >>
> >> On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla <jan.neskudla.ext@nsn.com> wrote:
> >> > Hallo
> >> >
> >> > we'd likes to use a RapidIO as a general communication bus on our new
> >> > product, and so I have some questions about general design of Linux RIO
> >> > subsystem. I did not find any better mailing list for RapidIO
> >> > discussion.
> >> >
> >> > [1] - we'd like to implement following features
> >> > * Hot-plug (hot-insert/hot-remove) of devices
> >> > * Error handling (port-write packets - configuration, handling of
> >> > them)
> >> > * Static ID configuration based on port numbers
> >> > * Aux driver - basic driver, for sending messages over different
> >> > mboxes, handling ranges of doorbells
> >> >
> >> > Is it here anyone who is working on any improvement, or anyone who
> >> > knows the development plans for RapidIO subsystem?
> >> >
> >>
> >> AFAIK, there is no one currently working on these features for Linux.
> >> It will be good if you can add these useful features.
> > Yes it looks like that, currently we are analyzing current rapidIO
> > system, and how we can add these features.
> >
> >>
> >> > [2] - I have a following problem with a current implementation of
> >> > loading drivers. The driver probe-function call is based on comparison
> >> > of VendorID (VID) and DeviceID (DID) only. Thus if I have 3 devices with
> >> > same DID and VID connected to the same network (bus), the driver is
> >> > loaded 3times, instead only once for the actual device Master port.
> >>
> >> This should be the correct way as you actually have 3 instances of the device.
> >>
> >> >
> >> > Rionet driver solved this by enabling to call initialization function
> >> > just once, and it expect that this is the Master port.
> >>
> >> Rionet is kind of special. It's not working like a simple device
> >> driver, but more like a customized protocol stack to support multiple
> >> ethernet over rio links.
> >>
> >> >
> >> > Is it this correct behavior ? It looks to me that RapidIO is handled
> >> > like a local bus (like PCI)
> >>
> >> This is correct behavior. All of them are using Linux device/driver
> >> infrastructure, but rionet is a special device.
> >
> > But I do not have a 3 devices on one silicon. I am talking about 3
> > devices (3 x EP8548 boards + IDT switch) connected over rapidIO through
> > the switch. And in this case I'd like to have only one driver siting on
> > the top of Linux RapidIO subsystem. I don't see the advantage of loading
>
> You are having one driver, but it probes 3 times for each device using
> the driver.
>
> > a driver locally for remote device. Am I missing something ?
>
> If you want to interact with the remote device, you need the driver to
> do the work locally.
We are going to use a RapidIO as a bigger network of active devices, and
each will have each own driver (sitting on its own), and all the
settings will be done over maintenance packets.
May be it will be solved by the fact, that we are going to use a
staticIDs, so there will be no discovery as it is now. And thus there
will be only one device visible in the internal structures of the
subsystem, and thus only one drive will be loaded.
>
> >
> > And one more think, I am getting so much Bus errors OOPSes. Whenever
> > there is a problem with a comunication over Rio I get such a kernel OPS.
> > I had to add some delays into some function to be able to finish the
> > enum+discovery process. Did you have some experience with some bigger
> > rio network running under linux ?
>
> It looks like an known issue for switched rio network, but I don't
> have the correct equipment to reproduce the problem here. Could you
> do some basic debugging and share your findings? Thanks.
I tried to acquired some info about the problem, I found that the OOPS
always occur when there is no respond from the device or the respond is
too slow. I always got that error during function call
rio_get_host_deviceid_lock when it tries to access a remote device or
switch. This function is the first call of the rio_mport_read_config_32
so is also first try of remote access to any device.
It is a timing issue, and after placing a printk into the
rio_get_host_deviceid_lock the OOPSing almost disappeared.
Jan
>
> - Leo
^ permalink raw reply
* Re: mpc5200 fec error
From: Wolfram Sang @ 2009-05-20 6:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <fa686aa40905191636u6f4a23d0xc8c6c13904a65b8e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
> > 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.
===========
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
===================================================================
--- 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) == 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/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Initialize DBCR0 for PPC440 targets
From: srikanth krishnakar @ 2009-05-20 6:14 UTC (permalink / raw)
To: srikanth krishnakar, Linuxppc-dev
In-Reply-To: <20090520060014.GL6333@yookeroo.seuss>
Hi David,
Just to correct the statements : How the DBCR0 is initialized on
targets that don't use boot loaders ?
-Srikant
On Wed, May 20, 2009 at 11:30 AM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
>> Hi David,
>>
>> I am not sure how the IDM behaves on few of PPC440 targets which don't
>> have boot loaders. I have a reference for your question:
>>
>> http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td2304=
9044.html
>>
>> Without this fix (given patch) I am facing problems with GDB, and
>> further target hangs while running gdbserver !
>
> That doesn't answer my question. =A0It's not enough to say "this fixes a
> problem" you need to explain *how* it fixes the problem.
>
> And I don't see why IDM would have any effect on *software*
> breakpoints.
>
>> On Wed, May 20, 2009 at 5:23 AM, David Gibson
>> <david@gibson.dropbear.id.au> wrote:
>> > On Tue, May 19, 2009 at 06:38:53PM +0530, srikanth krishnakar wrote:
>> >> Hi,
>> >>
>> >> kernel- 2.6.29
>> >> Debug technique: KGDB
>> >>
>> >> The PowerPC kernel does not initialize the PPC440 DBCR0 register. Thi=
s
>> >> prevents the use of software breakpoints in case of internal debug
>> >> mode. Looking into head_fsl_booke.S for initialization of DBCR0 is
>> >> used by boot-loaders.
>> >> It seems head_44x.S lacks this step of DBCR0 register initialization.
>> >> So fixing this with initializing the DBCR0 register as shown below :
>> >>
>> >> Subject: [PATCH] powerpc: 44x: Initialize DBCR0 for targets not havin=
g
>> >> bootloader
>> >>
>> >> The kernel does not initialize the PPC440 DBCR0 register.
>> >> This prevents (among other things) the use of software
>> >> breakpoints with GDB. The boot loaders probably do initialize
>> >> this but few targets run without a boot loader
>> >
>> > Um.. how does this prevent the use of software breakpoints with gdb?
>> > The trap instructions still work with IDM=3D=3D0.
>
> --
> David Gibson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| I'll have my music =
baroque, and my code
> david AT gibson.dropbear.id.au =A0| minimalist, thank you. =A0NOT _the_ _=
other_
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| _way_ _a=
round_!
> http://www.ozlabs.org/~dgibson
>
--=20
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
^ 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