* Re: TEST: Sleep patch #6
From: Colin Leroy @ 2004-12-02 11:08 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
In-Reply-To: <1101877409.5672.2.camel@gaston>
On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
Hi,
> This one fixes finally the cache flush problem that made cpufreq (on machines
> using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> corruption would occur on some CPUs at least). It improves bits here or there
> too, and adds the sungem wake-on-lan feature.
By the way, I noticed a problem when the laptop is put to sleep by closing lid:
wake-on-lan still works, but as soon as the laptop's awake, pbbuttonsd sleeps
it again. Combined with the fact that a closed iBook G4 not sleeping shutdowns
by itself, it would be nice if sungem could disable wol when suspending and the
lid is closed - if such info is available.
Or maybe such a thing should be done in the pbbuttonsd scripts by calling
ethtool?
--
Colin
^ permalink raw reply
* Re: [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Gerhard Jaeger @ 2004-12-02 8:25 UTC (permalink / raw)
To: Kumar Gala; +Cc: Embedded PPC Linux list
In-Reply-To: <349C6BAC-443A-11D9-ADCD-000393DBC2E8@freescale.com>
On Thursday 02 December 2004 09:14, Kumar Gala wrote:
> Fun with mailers. Try this url:
>=20
> http://tinyurl.com/6skww
Thanks that works (I mean the URL ;)
I have not tested, but this might will work, as I noticed, that when addidi=
onally
CONFIG_RARP is enabled, there are also no problems.
Anyway, I'll test ASAP and will tell you the results.
Thanx so far,
Gerhard
>=20
> - kumar
>=20
> On Dec 2, 2004, at 2:07 AM, Gerhard Jaeger wrote:
>=20
> > Hi,
> >
> > On Wednesday 01 December 2004 23:19, Kumar Gala wrote:
> > > There is some belief that the following patch should fix the issue:
> > >
> > > http://linux.bkbits.net:8080/linux-2.5/cset@1.2249.2.2?=20
> > nav=3Dindex.html|ChangeSet@-3d
> > >
> > > I would be interested to know if this helps w/o your patch.
> >
> > I'd like to cross-check this, but are you sure, you're referencing the=
=20
> > correct
> > changeset? Currently I only got:
> > Error 500
> > Unable to find revision 1.2249.2.2
> >
> > Gerhard
> >
> > >
> > > - kumar
> > >
> > > On Dec 1, 2004, at 10:07 AM, Gerhard Jaeger wrote:
> > >
> > > > Hi,
> > > >
> > > > this patch fixes an issue, that occurs on my MPC8541CDS, when=20
> > trying to
> > > >=A0 use bootp to get the IP parameters. It seems, that the patch=20
> > only=A0
> > > > cures
> > > >=A0 the symptom but obviously not the cause ;)
> > > >
> > > > Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
> > > >
> > > > --- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig=A0=A0=A0=A0=20
> > 2004-11-15=A0
> > > > 02:26:34.000000000 +0100
> > > >=A0 +++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c=A0 2004-12-01=A0
> > > > 17:00:19.000000000 +0100
> > > >=A0 @@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
> > > >=A0 =A0=A0=A0=A0=A0=A0=A0 struct gfar_private *priv =3D netdev_priv=
(dev);
> > > > =A0=A0=A0=A0=A0=A0=A0 int result =3D 0;
> > > >=A0 =A0
> > > >=A0 +=A0=A0=A0=A0=A0=A0 if( !priv->mii_info->phyinfo )
> > > >=A0 +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 return;
> > > >=A0 +
> > > >=A0 =A0=A0=A0=A0=A0=A0=A0 /* Delay to give the PHY a chance to chan=
ge the
> > > >=A0 =A0=A0=A0=A0=A0=A0=A0=A0 * register state */
> > > >=A0 =A0=A0=A0=A0=A0=A0=A0 msleep(1);
> > >
> > >
>=20
>=20
^ permalink raw reply
* Re: [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Kumar Gala @ 2004-12-02 8:14 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Embedded PPC Linux list
In-Reply-To: <200412020907.44778.g.jaeger@sysgo.com>
Fun with mailers. Try this url:
http://tinyurl.com/6skww
- kumar
On Dec 2, 2004, at 2:07 AM, Gerhard Jaeger wrote:
> Hi,
>
> On Wednesday 01 December 2004 23:19, Kumar Gala wrote:
> > There is some belief that the following patch should fix the issue:
> >
> > http://linux.bkbits.net:8080/linux-2.5/cset@1.2249.2.2?=20
> nav=3Dindex.html|ChangeSet@-3d
> >
> > I would be interested to know if this helps w/o your patch.
>
> I'd like to cross-check this, but are you sure, you're referencing the=20=
> correct
> changeset? Currently I only got:
> Error 500
> Unable to find revision 1.2249.2.2
>
> Gerhard
>
> >
> > - kumar
> >
> > On Dec 1, 2004, at 10:07 AM, Gerhard Jaeger wrote:
> >
> > > Hi,
> > >
> > > this patch fixes an issue, that occurs on my MPC8541CDS, when=20
> trying to
> > >=A0 use bootp to get the IP parameters. It seems, that the patch=20=
> only=A0
> > > cures
> > >=A0 the symptom but obviously not the cause ;)
> > >
> > > Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
> > >
> > > --- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig=A0=A0=A0=A0=20=
> 2004-11-15=A0
> > > 02:26:34.000000000 +0100
> > >=A0 +++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c=A0 2004-12-01=A0
> > > 17:00:19.000000000 +0100
> > >=A0 @@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
> > >=A0 =A0=A0=A0=A0=A0=A0=A0 struct gfar_private *priv =3D =
netdev_priv(dev);
> > > =A0=A0=A0=A0=A0=A0=A0 int result =3D 0;
> > >=A0 =A0
> > >=A0 +=A0=A0=A0=A0=A0=A0 if( !priv->mii_info->phyinfo )
> > >=A0 +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 return;
> > >=A0 +
> > >=A0 =A0=A0=A0=A0=A0=A0=A0 /* Delay to give the PHY a chance to =
change the
> > >=A0 =A0=A0=A0=A0=A0=A0=A0=A0 * register state */
> > >=A0 =A0=A0=A0=A0=A0=A0=A0 msleep(1);
> >
> >
^ permalink raw reply
* Re: [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Gerhard Jaeger @ 2004-12-02 8:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: Embedded PPC Linux list
In-Reply-To: <0429B8F6-43E7-11D9-A6C5-000393DBC2E8@freescale.com>
Hi,
On Wednesday 01 December 2004 23:19, Kumar Gala wrote:
> There is some belief that the following patch should fix the issue:
>=20
> http://linux.bkbits.net:8080/linux-2.5/cset@1.2249.2.2? nav=3Dindex.html|=
ChangeSet@-3d
>=20
> I would be interested to know if this helps w/o your patch.
I'd like to cross-check this, but are you sure, you're referencing the corr=
ect
changeset? Currently I only got:
Error 500
Unable to find revision 1.2249.2.2
Gerhard
>=20
> - kumar
>=20
> On Dec 1, 2004, at 10:07 AM, Gerhard Jaeger wrote:
>=20
> > Hi,
> >
> > this patch fixes an issue, that occurs on my MPC8541CDS, when trying to
> > use bootp to get the IP parameters. It seems, that the patch only =20
> > cures
> > the symptom but obviously not the cause ;)
> >
> > Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
> >
> > --- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig=A0=A0=A0=A0 2004-11=
=2D15 =20
> > 02:26:34.000000000 +0100
> > +++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c=A0 2004-12-01 =20
> > 17:00:19.000000000 +0100
> > @@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
> > =A0=A0=A0=A0=A0=A0=A0 struct gfar_private *priv =3D netdev_priv(dev);
> > =A0=A0=A0=A0=A0=A0=A0 int result =3D 0;
> > =A0
> > +=A0=A0=A0=A0=A0=A0 if( !priv->mii_info->phyinfo )
> > +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 return;
> > +
> > =A0=A0=A0=A0=A0=A0=A0 /* Delay to give the PHY a chance to change the
> > =A0=A0=A0=A0=A0=A0=A0=A0 * register state */
> > =A0=A0=A0=A0=A0=A0=A0 msleep(1);
>=20
>=20
^ permalink raw reply
* [micropatch]mpc852t
From: "김 창식" @ 2004-12-02 2:13 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 2250 bytes --]
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Timo Reimerdes @ 2004-12-02 0:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: fedora-ppc, gentoo-ppc-user, linuxppc-dev list, debian-ppc
In-Reply-To: <1101877409.5672.2.camel@gaston>
Ok,
I mentioned those weird problems about the computer not falling asleep?
It keeps happening. I compiled a kernel with the config from Alexander
Wirt and tried alot of combinations.
The logs really wont help a lot.
USB-Mouse plugged in/out wont change anything, AC plugged in/out wont
change anything, restarting X wont fix it.
Is there a possibility that pbbuttonsd is somehow related to that
problem? I wonder. Might check that out later.
This problem I must fix before I can call sleep working. It's really
annoying.
Do you have any hint on "what needs to be running" or "needs to be set
to X" or anything I could look for?
There are two things I do get during boot:
_________________________________________________
Dec 2 01:41:38 localhost kernel: pmac_zilog: 0.6 (Benjamin
Herrenschmidt <benh@kernel.crashing.org>)
Dec 2 01:41:38 localhost kernel: pmac_zilog: Error registering serial
device, disabling pmac_zilog.
Dec 2 01:41:38 localhost kernel: pmac_zilog: Did another serial driver
already claim the minors?
Dec 2 01:41:38 localhost kernel: RAMDISK driver initialized: 16 RAM
disks of 8192K size 1024 blocksize
Dec 2 01:41:38 localhost kernel: divert: not allocating divert_blk for
non-ethernet device lo
Dec 2 01:41:38 localhost kernel: MacIO PCI driver attached to Intrepid
chipset
Dec 2 01:41:38 localhost kernel: input: Macintosh mouse button
emulation
.
.
.
_________________________________________________
Dec 2 01:41:38 localhost kernel: device-mapper: 4.1.0-ioctl
(2003-12-10) initialised: dm@uk.sistina.com
Dec 2 01:41:38 localhost kernel: md: md driver 0.90.0 MAX_MD_DEVS=256,
MD_SB_DISKS=27
Dec 2 01:41:38 localhost kernel: hdc: packet command error: status=0x51
{ DriveReady SeekComplete Error }
Dec 2 01:41:38 localhost kernel: hdc: packet command error: error=0x54
Dec 2 01:41:38 localhost kernel: ide: failed opcode was 100
Dec 2 01:41:38 localhost kernel: cdrom: open failed.
Dec 2 01:41:38 localhost kernel: device-mapper: : dm-linear: Device
lookup failed
Dec 2 01:41:38 localhost kernel:
Dec 2 01:41:38 localhost kernel: device-mapper: error adding target to
table
Dec 2 01:41:38 localhost kernel: device-mapper: : dm-linear: Device
lookup failed
Dec 2 01:41:38 localhost kernel:
Dec 2 01:41:38 localhost kernel: device-mapper: error adding target to
table
.
. (20 times ".... failed"
.
Dec 2 01:41:38 localhost kernel: device-mapper: error adding target to
table
.
.
.
________________________________________________________
other than that my boot looks really clean and without any more errors.
If you could give me some hints I would really appreciate that.
Greetings
Timo Reimerdes
^ permalink raw reply
* Re: [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Kumar Gala @ 2004-12-01 22:19 UTC (permalink / raw)
To: Gerhard Jaeger; +Cc: Embedded PPC Linux list
In-Reply-To: <200412011707.14693.g.jaeger@sysgo.com>
There is some belief that the following patch should fix the issue:
http://linux.bkbits.net:8080/linux-2.5/cset@1.2249.2.2?=20
nav=3Dindex.html|ChangeSet@-3d
I would be interested to know if this helps w/o your patch.
- kumar
On Dec 1, 2004, at 10:07 AM, Gerhard Jaeger wrote:
> Hi,
>
> this patch fixes an issue, that occurs on my MPC8541CDS, when trying =
to
> use bootp to get the IP parameters. It seems, that the patch only =20
> cures
> the symptom but obviously not the cause ;)
>
> Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
>
> --- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig=A0=A0=A0=A0 =
2004-11-15 =20
> 02:26:34.000000000 +0100
> +++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c=A0 2004-12-01 =20
> 17:00:19.000000000 +0100
> @@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
> =A0=A0=A0=A0=A0=A0=A0 struct gfar_private *priv =3D netdev_priv(dev);
> =A0=A0=A0=A0=A0=A0=A0 int result =3D 0;
> =A0
> +=A0=A0=A0=A0=A0=A0 if( !priv->mii_info->phyinfo )
> +=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 return;
> +
> =A0=A0=A0=A0=A0=A0=A0 /* Delay to give the PHY a chance to change the
> =A0=A0=A0=A0=A0=A0=A0=A0 * register state */
> =A0=A0=A0=A0=A0=A0=A0 msleep(1);
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: David Woodhouse @ 2004-12-01 17:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: fedora-ppc, linuxppc-dev list
In-Reply-To: <1101877409.5672.2.camel@gaston>
On Wed, 2004-12-01 at 16:03 +1100, Benjamin Herrenschmidt wrote:
> (As usual, I'm cross posting several lists, please don't reply to all of them,
> and CC me as I'm not subscribed to all of them neither)
>
> Ok, here's the 6th version of the sleep patch for ATI based albooks &
> iBook G4. Other machine users, please test too as it may cause
> regressions (or improvements) as well.
kernel-2.6.9-1.691_FC3.dwmw2 in same place as before.
--
dwmw2
^ permalink raw reply
* [PATCH] MPC8xx Idle support for 2.4.28
From: Pantelis Antoniou @ 2004-12-01 17:01 UTC (permalink / raw)
To: Tom Rini, Conn Clark, Dan Malek, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
Hi there
The following patch implements idling support for the 8xx.
The patch works on the DUET family and the Normal Low mode
but could also work on other 8xxs easily; I just don't have
access to any other boards.
It's 2.4 for now since most people with 8xx's are on 2.4 still.
By using it on a 870 I see a power savings of ~400mW on a
133MHz/66MHz.
Regards
Pantelis
P.S. Many thanks to Mr. Conn Clark a.k.a. Obscene_CNN,
for it's only patch on an attempt.
P.S #2. There are alot of errata regarding PLPRCR for 8xx,
on older revisions of 8xx. Make sure you read them...
Signed-off-by: Pantelis Antoniou <panto@intracom.gr>
[-- Attachment #2: 8xx-idle.patch --]
[-- Type: text/plain, Size: 15584 bytes --]
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/8xx_io/Config.in linux-2.4-intracom/arch/ppc/8xx_io/Config.in
--- linux-2.4/arch/ppc/8xx_io/Config.in 2004-09-02 16:17:52 +03:00
+++ linux-2.4-intracom/arch/ppc/8xx_io/Config.in 2004-10-19 12:57:51 +03:00
@@ -4,10 +4,17 @@
mainmenu_option next_comment
comment 'MPC8xx Options'
+if [ "$CONFIG_8xx_SMC1" = "y" -o "$CONFIG_8xx_SMC2" = "y" -o \
+ "$CONFIG_8xx_SCC1" = "y" -o "$CONFIG_8xx_SCC2" = "y" -o \
+ "$CONFIG_8xx_SCC3" = "y" -o "$CONFIG_8xx_SCC4" = "y" ]; then
+ define_bool CONFIG_8xx_STD_SERIAL y
+fi
+
comment 'Generic MPC8xx Options'
bool 'Copy-Back Data Cache (else Writethrough)' CONFIG_8xx_COPYBACK
bool 'CPU6 Silicon Errata (860 Pre Rev. C)' CONFIG_8xx_CPU6
bool 'I2C/SPI Microcode Patch' CONFIG_UCODE_PATCH
+bool 'DUET support (87x/88x)' CONFIG_DUET
comment 'MPC8xx CPM Options'
if [ "$CONFIG_NET_ETHERNET" = "y" ]; then
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/config.in linux-2.4-intracom/arch/ppc/config.in
--- linux-2.4/arch/ppc/config.in 2004-09-02 16:17:52 +03:00
+++ linux-2.4-intracom/arch/ppc/config.in 2004-12-01 17:06:52 +02:00
@@ -55,6 +55,21 @@
define_bool CONFIG_PPC_STD_MMU y
fi
+if [ "$CONFIG_8xx" = "y" ]; then
+ bool 'MPC8xx CPU Idle Support' CONFIG_8xx_IDLE
+ if [ "$CONFIG_8xx_IDLE" = "y" ]; then
+ if [ "$CONFIG_DUET" != "y" ]; then
+ choice 'Idle method' \
+ "Normal-Low CONFIG_8xx_IDLE_NORMAL_LOW \
+ Doze-High CONFIG_8xx_IDLE_DOZE_HIGH \
+ Doze-Low CONFIG_8xx_IDLE_DOZE_LOW" CONFIG_8xx_IDLE_NORMAL_LOW
+ else
+ # DUET only supports NORMAL_LOW mode
+ define_bool CONFIG_8xx_IDLE_NORMAL_LOW y
+ fi
+ fi
+fi
+
if [ "$CONFIG_8260" = "y" ]; then
define_bool CONFIG_SERIAL_CONSOLE y
define_bool CONFIG_CPM2 y
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/kernel/Makefile linux-2.4-intracom/arch/ppc/kernel/Makefile
--- linux-2.4/arch/ppc/kernel/Makefile 2004-09-02 16:17:53 +03:00
+++ linux-2.4-intracom/arch/ppc/kernel/Makefile 2004-11-19 11:12:59 +02:00
@@ -40,7 +40,11 @@
semaphore.o syscalls.o setup.o \
cputable.o ppc_htab.o
ifneq ($(CONFIG_6xx),y)
-obj-y += idle_gen.o
+ ifeq ($(CONFIG_8xx_IDLE),y)
+ obj-y += idle_8xx.o
+ else
+ obj-y += idle_gen.o
+ endif
endif
obj-$(CONFIG_6xx) += l2cr.o cpu_setup_6xx.o
obj-$(CONFIG_MODULES) += ppc_ksyms.o
@@ -102,6 +106,7 @@
head_44x.o: head_44x.S ppc_defs.h
head_8xx.o: head_8xx.S ppc_defs.h
idle_6xx.o: idle_6xx.S ppc_defs.h
+idle_8xx.o: idle_8xx.S ppc_defs.h
ppc_defs.h: mk_defs.c ppc_defs.head \
$(TOPDIR)/include/asm/mmu.h \
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/kernel/cputable.c linux-2.4-intracom/arch/ppc/kernel/cputable.c
--- linux-2.4/arch/ppc/kernel/cputable.c 2004-10-19 09:29:02 +03:00
+++ linux-2.4-intracom/arch/ppc/kernel/cputable.c 2004-12-01 18:24:13 +02:00
@@ -408,7 +408,11 @@
{ /* 8xx */
0xffff0000, 0x00500000, "8xx",
/* CPU_FTR_CAN_DOZE is possible, if the 8xx code is there.... */
- CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB,
+ CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB
+#ifdef CONFIG_8xx_IDLE
+ | CPU_FTR_CAN_DOZE
+#endif
+ ,
PPC_FEATURE_32 | PPC_FEATURE_HAS_MMU,
16, 16,
__setup_cpu_8xx /* Empty */
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/kernel/head_8xx.S linux-2.4-intracom/arch/ppc/kernel/head_8xx.S
--- linux-2.4/arch/ppc/kernel/head_8xx.S 2004-09-02 16:17:53 +03:00
+++ linux-2.4-intracom/arch/ppc/kernel/head_8xx.S 2004-12-01 18:24:13 +02:00
@@ -667,11 +667,11 @@
SAVE_8GPRS(24, r21)
andi. r23,r23,MSR_PR
mfspr r23,SPRG3 /* if from user, fix up THREAD.regs */
- beq 2f
+ addi r2,r23,-THREAD /* set r2 to current */
+ beq 0f
addi r24,r1,STACK_FRAME_OVERHEAD
stw r24,PT_REGS(r23)
-2: addi r2,r23,-THREAD /* set r2 to current */
- tovirt(r2,r2)
+0: tovirt(r2,r2)
mflr r23
andi. r24,r23,0x3f00 /* get vector offset */
stw r24,TRAP(r21)
@@ -683,7 +683,13 @@
cmplw 1,r1,r24
crand 1,1,4
bgt- stack_ovf /* if r2 < r1 < r2+TASK_STRUCT_SIZE */
+
lwz r24,0(r23) /* virtual address of handler */
+#ifdef CONFIG_8xx_IDLE
+ mtctr r24 /* save to ctr */
+ lis r24,power_save_8xx_restore@h
+ ori r24,r24,power_save_8xx_restore@l
+#endif
lwz r23,4(r23) /* where to go when done */
mtspr SRR0,r24
mtspr SRR1,r20
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/kernel/idle_8xx.S linux-2.4-intracom/arch/ppc/kernel/idle_8xx.S
--- linux-2.4/arch/ppc/kernel/idle_8xx.S 1970-01-01 02:00:00 +02:00
+++ linux-2.4-intracom/arch/ppc/kernel/idle_8xx.S 2004-12-01 17:06:52 +02:00
@@ -0,0 +1,114 @@
+/*
+ * This file contains the power_save function for 8xx CPUs
+ * rewritten in assembler
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/threads.h>
+#include <asm/processor.h>
+#include <asm/page.h>
+#include <asm/cputable.h>
+#include <asm/ppc_asm.h>
+#include "ppc_defs.h"
+
+ .text
+
+#define CSRC 21
+#define LPM1 22
+#define LPM0 23
+
+#define CSRCM (1 << (31 - CSRC))
+#define LPM1M (1 << (31 - LPM1))
+#define LPM0M (1 << (31 - LPM0))
+
+#if defined(CONFIG_8xx_IDLE_NORMAL_LOW)
+#define SETMSK CSRCM
+#elif defined(CONFIG_8xx_IDLE_DOZE_HIGH)
+#define SETMSK LPM0M
+#elif defined(CONFIG_8xx_IDLE_DOZE_LOW)
+#define SETMSK (LPM0M | CSRCM)
+#else
+#error Not supported mode.
+#endif
+
+#define PLPRCRK 0x0384
+#define PLPRCR 0x0284
+
+/*
+ * Here is the power_save function. This could eventually be
+ * split into several functions & changing the function pointer
+ * depending on the various features.
+ */
+ .globl power_save
+power_save:
+ mfspr r5, IMMR
+ rlwinm r5, r5,0,0,15 /* only high 16 bits count */
+
+ /* Clear MSR:EE */
+ mfmsr r7
+ rlwinm r0,r7,0,17,15
+2: mtmsr r0
+
+ /* Check current->need_resched */
+ lwz r4,NEED_RESCHED(r2)
+ cmpi 0,r4,0
+ bne- 1f
+
+ /* enter low power */
+ lwz r4,PLPRCR(r5) /* load PLPRCR */
+ andi. r4,r4,SETMSK
+ bne 0f
+ lis r4,0x55cc /* load key */
+ ori r4,r4,0xaa33
+ stw r4,PLPRCRK(r5) /* unlock PLPRCR register */
+ lwz r4,PLPRCR(r5) /* load PLPRCR */
+ rlwinm r24,r24,0,23+1,16-1
+ ori r4,r4,SETMSK /* set these bits */
+ stw r4,PLPRCR(r5) /* store PLPRCR */
+ li r4,0
+ stw r4,PLPRCRK(r5) /* lock PLPRCR register */
+
+0: mtmsr r7 /* enable interrupts */
+ b 2b /* and test again */
+
+ /* leave low power */
+1: lwz r4,PLPRCR(r5) /* load PLPRCR */
+ andi. r4,r4,SETMSK /* test if already out */
+ beq 0f
+ lis r4,0x55cc /* load key */
+ ori r4,r4,0xaa33
+ stw r4,PLPRCRK(r5) /* unlock PLPRCR register */
+ lwz r4,PLPRCR(r5) /* load PLPRCR */
+ rlwinm r24,r24,0,23+1,16-1
+ stw r4,PLPRCR(r5) /* store PLPRCR */
+ li r4,0
+ stw r4,PLPRCRK(r5) /* lock PLPRCR register */
+
+ /* and we're out */
+0: mtmsr r7
+ blr
+
+ /**************************************/
+
+ .globl power_save_8xx_restore
+power_save_8xx_restore:
+ mfspr r20,IMMR
+ rlwinm r20,r20,0,0,15 /* only high 16 bits count */
+ lwz r24,PLPRCR(r20) /* load PLPRCR */
+ andi. r24,r24,SETMSK
+ beqctr /* jump if not low power */
+ lis r24,0x55cc /* load key */
+ ori r24,r24,0xaa33
+ stw r24,PLPRCRK(r20)/* unlock PLPRCR register */
+ lwz r24,PLPRCR(r20) /* load PLPRCR */
+ rlwinm r24,r24,0,23+1,16-1
+ stw r24,PLPRCR(r20) /* store PLPRCR */
+ li r24,0
+ stw r24,PLPRCRK(r20)/* lock PLPRCR register */
+ bctr /* jump to handler */
+
diff -Nur --exclude=RCS --exclude=CVS --exclude=SCCS --exclude=BitKeeper --exclude=ChangeSet linux-2.4/arch/ppc/kernel/m8xx_setup.c linux-2.4-intracom/arch/ppc/kernel/m8xx_setup.c
--- linux-2.4/arch/ppc/kernel/m8xx_setup.c 2004-09-02 16:17:53 +03:00
+++ linux-2.4-intracom/arch/ppc/kernel/m8xx_setup.c 2004-12-01 18:24:13 +02:00
@@ -118,6 +118,73 @@
printk ("timebase_interrupt()\n");
}
+#ifdef CONFIG_8xx_IDLE
+
+/* these are the DUET defines */
+#define PLPRCR_MFN_MSK 0xF8000000 /* Multiplication factor numerator bits */
+#define PLPRCR_MFN_SHIFT 27 /* Multiplication factor numerator shift*/
+#define PLPRCR_MFD_MSK 0x07C00000 /* Multiplication factor denominator bits */
+#define PLPRCR_MFD_SHIFT 22 /* Multiplication factor denominator shift*/
+#define PLPRCR_S_MSK 0x00300000 /* Multiplication factor integer bits */
+#define PLPRCR_S_SHIFT 20 /* Multiplication factor integer shift */
+#define PLPRCR_MFI_MSK 0x000F0000 /* Multiplication factor integer bits */
+#define PLPRCR_MFI_SHIFT 16 /* Multiplication factor integer shift */
+
+#define PLPRCR_PDF_MSK 0x0000001E /* Predivision Factor bits */
+#define PLPRCR_PDF_SHIFT 1 /* Predivision Factor shift value */
+
+#define PLPRCR_val(a) ((((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr & \
+ PLPRCR_ ## a ## _MSK) >> PLPRCR_ ## a ## _SHIFT)
+
+/* max GCLK as of this writing */
+#define MAX_GCLK 133333333
+#define MAX_MULT (((unsigned int)-1) / MAX_GCLK)
+#define RPREC 2 /* bits of rounding precision */
+#define RPRECHALF (1 << (RPREC - 1))
+
+#ifdef CONFIG_DUET
+
+/* XXX it could overflow; be sure to check */
+int get_tbclk(int gclk)
+{
+ unsigned int xin, mfi, mfd, mfn, s, pdf, mult;
+ unsigned int num, denum;
+
+ mfi = PLPRCR_val(MFI);
+ mfd = PLPRCR_val(MFD);
+ mfn = PLPRCR_val(MFN);
+ s = PLPRCR_val(S);
+ pdf = PLPRCR_val(PDF);
+
+ if (mfn == 0) {
+ mult = (pdf + 1) << s;
+ denum = mfi;
+ } else {
+ mult = ((mfd + 1) * (pdf + 1)) << s;
+ denum = (mfi * mfd + mfi + mfn);
+ }
+
+ /* printk(KERN_INFO "gclk = %u, pdf=%u, mfi=%u, mfd=%u, mfn=%u, s=%u\n",
+ gclk, pdf, mfi, mfd, mfn, s); */
+
+ num = gclk * mult;
+ xin = (((num << RPREC) / denum) + RPRECHALF) >> RPREC;
+
+ printk(KERN_INFO "Calculated XIN %u\n", xin);
+
+ if (gclk >= 66666666)
+ return xin / 4;
+ return xin / 16;
+}
+
+#else
+
+#error Supply the get_tbclk clock function
+
+#endif
+
+#endif
+
/* The decrementer counts at the system (internal) clock frequency divided by
* sixteen, or external oscillator divided by four. We force the processor
* to use system clock divided by sixteen.
@@ -125,22 +192,30 @@
void __init m8xx_calibrate_decr(void)
{
bd_t *binfo = (bd_t *)__res;
+ volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ imap->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
+ imap->im_clkrstk.cark_sccrk = KAPWR_KEY;
+#ifndef CONFIG_8xx_IDLE
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x02000000;
+ imap->im_clkrst.car_sccr |= 0x02000000;
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
fp = binfo->bi_intfreq / 16;
- freq = fp*60; /* try to make freq/1e6 an integer */
+#else
+ /* we must use the XIN freq as base */
+ imap->im_clkrst.car_sccr = (imap->im_clkrst.car_sccr & ~0x02000000) | 0x00800000;
+ fp = get_tbclk(binfo->bi_intfreq);
+#endif
+
+ freq = fp * 60; /* try to make freq/1e6 an integer */
divisor = 60;
- printk("Decrementer Frequency = %d/%d\n", freq, divisor);
+ printk(KERN_INFO "Decrementer Frequency = %d/%d\n", freq, divisor);
tb_ticks_per_jiffy = freq / HZ / divisor;
tb_to_us = mulhwu_scale_factor(freq / divisor, 1000000);
@@ -159,28 +234,24 @@
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = KAPWR_KEY;
+ imap->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
+ imap->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
+ imap->im_sitk.sitk_tbk = ~KAPWR_KEY;
+ imap->im_sitk.sitk_tbscrk = KAPWR_KEY;
+ imap->im_sitk.sitk_rtcsck = KAPWR_KEY;
+ imap->im_sitk.sitk_tbk = KAPWR_KEY;
/* Disable the RTC one second and alarm interrupts. */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc &=
- ~(RTCSC_SIE | RTCSC_ALE);
+ imap->im_sit.sit_rtcsc &= ~(RTCSC_SIE | RTCSC_ALE);
/* Enable the RTC */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc |=
- (RTCSC_RTF | RTCSC_RTE);
+ imap->im_sit.sit_rtcsc |= (RTCSC_RTF | RTCSC_RTE);
/* Enabling the decrementer also enables the timebase interrupts
* (or from the other point of view, to get decrementer interrupts
* we have to enable the timebase). The decrementer interrupt
* is wired into the vector table, nothing to do here for that.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_tbscr =
- ((mk_int_int_mask(DEC_INTERRUPT) << 8) |
- (TBSCR_TBF | TBSCR_TBE));
+ imap->im_sit.sit_tbscr = ((mk_int_int_mask(DEC_INTERRUPT) << 8) | (TBSCR_TBF | TBSCR_TBE));
if (request_irq(DEC_INTERRUPT, timebase_interrupt, 0, "tbint",
NULL) != 0)
@@ -201,9 +272,11 @@
static int
m8xx_set_rtc_time(unsigned long time)
{
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtc = time;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = ~KAPWR_KEY;
+ volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
+
+ imap->im_sitk.sitk_rtck = KAPWR_KEY;
+ imap->im_sit.sit_rtc = time;
+ imap->im_sitk.sitk_rtck = ~KAPWR_KEY;
return(0);
}
@@ -218,10 +291,14 @@
m8xx_restart(char *cmd)
{
__volatile__ unsigned char dummy;
+ volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
uint msr;
cli();
- ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr |= 0x00000080;
+
+ /* someone must unlock */
+ imap->im_clkrstk.cark_plprcrk = KAPWR_KEY;
+ imap->im_clkrst.car_plprcr |= 0x00000080;
/* Clear the ME bit in MSR to cause checkstop on machine check
*/
@@ -229,7 +306,7 @@
msr &= ~0x1000;
__asm__("mtmsr %0" : : "r" (msr) );
- dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
+ dummy = imap->im_clkrst.res[0];
printk("Restart failed\n");
while(1);
}
@@ -246,7 +323,6 @@
m8xx_restart(NULL);
}
-
static int
m8xx_show_percpuinfo(struct seq_file *m, int i)
{
@@ -254,9 +330,16 @@
bp = (bd_t *)__res;
- seq_printf(m, "clock\t\t: %dMHz\n"
- "bus clock\t: %dMHz\n",
+ seq_printf(m, "clock\t\t: %ldMHz\n"
+ "bus clock\t: %ldMHz\n",
bp->bi_intfreq / 1000000,
bp->bi_busfreq / 1000000);
+ seq_printf(m, "features\t:");
+#ifdef CONFIG_8xx_IDLE
+ if (cur_cpu_spec[0]->cpu_features & CPU_FTR_CAN_DOZE)
+ seq_printf(m, " CAN_DOZE");
+#endif
+ seq_printf(m, "\n");
+
return 0;
}
^ permalink raw reply
* [PATCH][PPC32] Fix gianfar netdriver oops when using bootp...
From: Gerhard Jaeger @ 2004-12-01 16:07 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
this patch fixes an issue, that occurs on my MPC8541CDS, when trying to
use bootp to get the IP parameters. It seems, that the patch only cures
the symptom but obviously not the cause ;)
Signed-off-by: Gerhard Jaeger <gjaeger@sysgo.com>
--- linux-2.6.10-rc2-mm4/drivers/net/gianfar.c.orig 2004-11-15 02:26:34.000000000 +0100
+++ linux-2.6.10-rc2-mm4/drivers/net/gianfar.c 2004-12-01 17:00:19.000000000 +0100
@@ -1477,6 +1477,9 @@ static void gfar_phy_change(void *data)
struct gfar_private *priv = netdev_priv(dev);
int result = 0;
+ if( !priv->mii_info->phyinfo )
+ return;
+
/* Delay to give the PHY a chance to change the
* register state */
msleep(1);
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Colin Leroy @ 2004-12-01 13:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1101877409.5672.2.camel@gaston>
On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
Hi,
> Ok, here's the 6th version of the sleep patch for ATI based albooks &
> iBook G4. Other machine users, please test too as it may cause
> regressions (or improvements) as well.
Works ok here on iBook G4.
--
Colin
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Benjamin Herrenschmidt @ 2004-12-01 9:22 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list
In-Reply-To: <20041201101130.05f71600@pirandello>
On Wed, 2004-12-01 at 10:11 +0100, Colin Leroy wrote:
> On 01 Dec 2004 at 20h12, Benjamin Herrenschmidt wrote:
>
> Hi,
>
> > > Compiling that. btw, you didn't add the "&& !wol" before sungem's suspend call...
> >
> > What do you mean ? the whole code block is now in !wol...
>
> I'm just being stupid, i didn't see that :)
> So much for trying to read patches before having had my coffee...
>
> > Note that I'm still having problems with the cache ... I'm asking
> > Moto/Freescale...
>
> With which CPUs? I did notice zero problems with patch #5 (without freq scaling).
On my 7455 rev 3.3 at least. cpufreq on mine uses the PMU as well, thus
approx. the same code path as sleep. By doing freq. switches in a loop
from a shell script, I can make it crash in a few iterations. It seem to
be solid if I add an ugly displacement flush before the cache flush
code, but that should not be necessary and thus makes me think something
is wrong with the code.
Ben.
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Colin Leroy @ 2004-12-01 9:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1101891934.5592.0.camel@gaston>
On 01 Dec 2004 at 20h12, Benjamin Herrenschmidt wrote:
Hi,
> > Compiling that. btw, you didn't add the "&& !wol" before sungem's suspend call...
>
> What do you mean ? the whole code block is now in !wol...
I'm just being stupid, i didn't see that :)
So much for trying to read patches before having had my coffee...
> Note that I'm still having problems with the cache ... I'm asking
> Moto/Freescale...
With which CPUs? I did notice zero problems with patch #5 (without freq scaling).
--
Colin
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Benjamin Herrenschmidt @ 2004-12-01 9:05 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list
In-Reply-To: <20041201083617.5b72a115@pirandello>
On Wed, 2004-12-01 at 08:36 +0100, Colin Leroy wrote:
> On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
>
> Hi Ben,
>
> > This one fixes finally the cache flush problem that made cpufreq (on machines
> > using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> > corruption would occur on some CPUs at least). It improves bits here or there
> > too, and adds the sungem wake-on-lan feature.
>
> Compiling that. btw, you didn't add the "&& !wol" before sungem's suspend call...
What do you mean ? the whole code block is now in !wol...
Note that I'm still having problems with the cache ... I'm asking
Moto/Freescale...
Ben.
^ permalink raw reply
* Re: USB driver for ISP1362 very slow
From: Jörg Huwig @ 2004-12-01 8:44 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20041130162456.5D24AC1430@atlas.denx.de>
Hi Wolfgang,
I tried different USB memory sticks but the result was always the same.
Also there were no error messages in the log file.=20
After trying to understand the driver, I found two defines which seem to =
be
responsible for the slow transmission.
In hcd-1161.c: #define ATL_DONE_DELAY 10
and in hcd-1161.h: #define ATL_BLOCK_SZ 64
with this defines the host controller handles every 11 ms one 64Byte ATL
block, which of cause is very slow.=20
I have changed the ALT_BLOCK_SZ from 64 to 512 and reduced the=20
ATL_DONE_DELAY from 10 to 2. With this changes the driver works much =
faster.
Is it OK to change these constants in that way or could this cause =
trouble?
Best regards,
Joerg Huwig
-----Urspr=FCngliche Nachricht-----
Von: wd@denx.de [mailto:wd@denx.de]=20
Gesendet: Dienstag, 30. November 2004 17:25
An: J=F6rg Huwig
Cc: Linuxppc-embedded@ozlabs.org
Betreff: Re: USB driver for ISP1362 very slow=20
Hello,
in message <04113016200014900@intec-isdn.de> you wrote:
>=20
> I'm using an ISP1362 as an USB host controller connected to a MPC880=20
> running under Linux 2.4.25.
> The Driver seems to work fine as I can mount an USB memory stick.=20
> But the performance is very bad. To copy a 1MByte big file from the=20
> USB memory stick to the RAM disk takes about 3 minutes.
Are there any error messages in the log files? Did you try another =
USB
memory stick, especially any USB 2.0 stick?
> Does anyone has experience with the ISP1362 driver in Kernel 2.4.25??
Sure. We implemented it and tested it with mass storage devices, USB
modems, network adapters and in combination with RNDIS on Windoze.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "I
find this a nice feature but it is not according to the documen-
tation. Or is it a BUG?" "Let's call it an accidental feature. :-)"
- Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* Re: G3 iBook LCD brightness in X under kernel 2.4.25 and 2.6.8
From: murphyf+xfree86 @ 2004-12-01 8:25 UTC (permalink / raw)
To: Frank Murphy, Christof Petig, Benjamin Herrenschmidt,
Frank Murphy
Cc: linuxppc-dev list, debian-x
In-Reply-To: <1101805500.29811.209722800@webmail.messagingengine.com>
OK, works for me here as well. I think I'm seeing some weird color
artifacts, but I'll bring it up with the guy who's doing all the Mach64
work. There seems to be a lot in 2.6.10.
Frank
On Tue, 30 Nov 2004 10:05:00 +0100, "Frank Murphy"
<murphyf+xfree86@f-m.fm> said:
>
> On Tue, 30 Nov 2004 09:02:52 +0100, "Christof Petig"
> <lists@petig-baender.de> said:
> > I can confirm that everything works well with Linus' 2.6.10-rc2-bk6. So
> > consider the problem as solved (writing from said version).
> >
> > snooze and the brightness keys work well.
>
> Well *that's* good news. I'll retry here as well and confirm.
>
> Frank
^ permalink raw reply
* Re: TEST: Sleep patch #6
From: Colin Leroy @ 2004-12-01 7:36 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1101877409.5672.2.camel@gaston>
On 01 Dec 2004 at 16h12, Benjamin Herrenschmidt wrote:
Hi Ben,
> This one fixes finally the cache flush problem that made cpufreq (on machines
> using the PMU for the switch) and sleep/wake unreliable occasionally (memory
> corruption would occur on some CPUs at least). It improves bits here or there
> too, and adds the sungem wake-on-lan feature.
Compiling that. btw, you didn't add the "&& !wol" before sungem's suspend call...
--
Colin
^ permalink raw reply
* TEST: Sleep patch #6
From: Benjamin Herrenschmidt @ 2004-12-01 5:03 UTC (permalink / raw)
To: debian-powerpc@lists.debian.org, linuxppc-dev list,
gentoo-ppc-user, fedora-ppc
(As usual, I'm cross posting several lists, please don't reply to all of them,
and CC me as I'm not subscribed to all of them neither)
Ok, here's the 6th version of the sleep patch for ATI based albooks &
iBook G4. Other machine users, please test too as it may cause
regressions (or improvements) as well.
This one fixes finally the cache flush problem that made cpufreq (on machines
using the PMU for the switch) and sleep/wake unreliable occasionally (memory
corruption would occur on some CPUs at least). It improves bits here or there
too, and adds the sungem wake-on-lan feature.
There are still pending issues, like cpufreq on some machines will
"think" it's running at full speed on wakeup while it's in fact running
at slow speed (thankfully not the opposite). I don't think I'll fix this one
in 2.6.9, but rather in 2.6.10.
http://gate.crashing.org/~benh/albook-ibookg4-sleep-6.diff
I'll post a 2.6.10-rc2-bk* based version of the patch soon.
Ben.
^ permalink raw reply
* question on USB disk
From: zhonglei @ 2004-12-01 2:10 UTC (permalink / raw)
To: linuxppc-dev
hi
My system is Lite5200 with DENX Embedded Linux running on it.I want to use an USB disk on Lite5200.
What driver should I set to enable my USB disk? And how can I mount the content of the USB disk to my kernel directory?
BestRards
zhonglei
^ permalink raw reply
* Re: Implementing PowerManagment for a ppc target
From: Hollis Blanchard @ 2004-11-30 23:35 UTC (permalink / raw)
To: Linux PPC Dev
In-Reply-To: <41ACE8B0.8090307@246tNt.com>
On Nov 30, 2004, at 3:40 PM, Sylvain Munaut wrote:
>
> I'm trying to implement Deep Sleep support for a ppc platform based on
> 5200 and I have some questions :
>
> - How should I "integrate" it to linux, what the proper way ? I've
> been trying #defining CONFIG_PM and
> using the set_pm_ops operation but my call backs never get called
> when doing a echo standby > /sys/power/state
> [...]
> I've been trying to look at Documentation/ and the sources but still
> I'm not sure ...
>
>
> - How can I ensure that one of my function runs out of I Cache ? Some
> pieces of assembler needs to not
> acces memory when the last 'orders' are sent. Does just keeping it
> small and aligned enough ?
You can see an example of the icache code in the linuxppc-2.4 tree,
arch/ppc/platforms/ibm405lp_pmasm.S, after
"_GLOBAL(ibm405lp_pm_command)". (You probably won't need to save and
restore all CPU state though; that was needed because the 405LP was
*really* powered down, not just paused.)
You can also see how that code is triggered from ibm405lp_pm.c . I
don't think that's integrated with any laptop-style sleep work that's
been done in the past 1.5 years, but it works with /proc/sys/sleep
anyways (see Documentation/powerpc/405LP-sleep.txt).
-Hollis
^ permalink raw reply
* status of pcmcia in recent kernels / lots of troubles
From: Armando Di Cianno @ 2004-11-30 23:41 UTC (permalink / raw)
To: linuxppc-dev
Hello all.
I can't seem to get any PC cards (16-bit or 32-bit Carbus) working
properly in my Aluminum Powerbook G4 1.5Ghz. I've tried in-kernel and
module compilation for a variety of kernel versions, but my main
testing has been with 2.6.9 (gentoo-dev-sources + benh's sleep patch
version 5). Things used to work, iirc in versions <= 2.6.6, which I'm
no longer really able to run (especially now that sleep works, among
many other fixes).
According to this page: http://pcmcia.arm.linux.org.uk/ , the PCMCIA
subsystem is undergoing changes, and a few times it vaguely mentions
troubles happening "on some laptops, we don't know why these and not
others".
The relevant portion of `lspci -vv` is this:
0001:10:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus
Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, cache line size 08
Interrupt: pin A routed to IRQ 53
Region 0: Memory at a0004000 (32-bit, non-prefetchable)
Bus: primary=10, secondary=11, subordinate=14, sec-latency=176
Memory window 0: 90000000-9ffff000 (prefetchable)
Memory window 1: f3000000-f31ff000
I/O window 0: 00001000-000010ff
I/O window 1: 00001400-000014ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+
PostWrite+
16-bit legacy interface ports at 0001
However, _none_ of the lines in there with the word 'memory' seem to
offer any usable memory regions for pcmcia-cs.
My current /etc/pcmcia/config.opts includes this:
include port 0x1000-0x10ff
include port 0x1400-0x14ff
include memory 0x80100000-0x80ffffff
That memory range is the only range I've been able to find that
doesn't throw errors in some way. I've tried "include memory
0x80000000-0x80ffffff" (example on the net), "include memory
0xa0004000-0xa0004fff", "include memory 0x90000000-0x9ffff000", and
"include memory 0xf3000000-0xf31ff000" (not sure if those last two
matter at all, just trying anything at this point).
When I use my current config.ops, the kernel orinoco_cs driver reports
this:
Nov 30 04:53:40 [cardmgr] watching 1 socket
Nov 30 04:53:40 [cardmgr] could not adjust resource: irq 53: Invalid
argument
Nov 30 04:53:40 [kernel] cs: IO port probe 0x1000-0x10ff: clean.
Nov 30 04:53:40 [kernel] cs: IO port probe 0x1400-0x14ff: clean.
Nov 30 04:53:48 [cardmgr] exiting
Nov 30 04:54:12 [cardmgr] watching 1 socket
Nov 30 04:54:12 [kernel] cs: IO port probe 0x1000-0x10ff: clean.
Nov 30 04:54:12 [kernel] cs: IO port probe 0x1400-0x14ff: clean.
Nov 30 04:54:25 [kernel] cs: pcmcia_socket0: voltage interrogation
timed out.
Nov 30 04:54:26 [cardmgr] socket 0: Orinoco or Intersil Prism 2
Wireless
Nov 30 04:54:26 [kernel] cs: memory probe 0x80100000-0x80ffffff: clean.
Nov 30 04:54:26 [kernel] orinoco_cs: GetNextTuple(): No matching CIS
configuration. Maybe you need the ignore_cis_vcc=1 parameter.
Nov 30 04:54:27 [cardmgr] get dev info on socket 0 failed: Resource
temporarily
unavailable
Nov 30 04:54:44 [cardmgr] socket 0: Orinoco or Intersil Prism 2
Wireless
Nov 30 04:54:45 [cardmgr] get dev info on socket 0 failed: Resource
temporarily
unavailable
When I use the linux-wlan-ng driver (yeah, i know, but shooting in the
dark here), similar Vcc errors get thown, only different in wording,
not in numbers or otherwise. Note that whenever I test with
linux-wlan-ng drivers, I always rebuild my /lib/modules/<version>
directly, and clean out /etc/pcmcia completely, and then reinstall
pcmcia-cs, so that linux-wlan-ng doens't "poison" it unknowingly.
I've tried both with two different orinoco based cards, just in case
one was bad. I've also tried a prism54 card (with firmware available
and ready) (and which works in another computer fine) with these
results:
Nov 30 14:25:51 [kernel] prism54: request_firmware() failed for
'isl3890'
... and yet the other computer is set up identically software-wise
(Compaq laptop) and works with this card/firmware.
I've even tried include ISA support in-kernel as the README for the
downloadable / updated orinico drivers (v 15_rc2) say that the 16-bit
cards need it, but that didn't change anything.
I've also tried to add "reserve 0xa0004000,0x2000" to the kernel
command line as /proc/iomem reports this:
90000000-9fffffff : PCI CardBus #11
a0000000-a00000ff : 0001:10:1b.2
a0000000-a00000ff : ehci_hcd
a0001000-a0001fff : 0001:10:1b.1
a0001000-a0001fff : ohci_hcd
a0002000-a0002fff : 0001:10:1b.0
a0002000-a0002fff : ohci_hcd
a0003000-a0003fff : 0001:10:1a.0
a0003000-a0003fff : ohci_hcd
a0004000-a0004fff : 0001:10:13.0 <--- this one, right?
a0004000-a0004fff : yenta_socket
a0006000-a0007fff : 0001:10:12.0
b0000000-bfffffff : /pci@f0000000
I've reached that head-bashing-on-desk point. Any hints or mistakes
pointed out would be greatly appreciated. Thanks,
__Armando Di Cianno
^ permalink raw reply
* Re: [PATCH][PPC32] Performance Monitor/Oprofile support for e500
From: Andrew Morton @ 2004-11-30 23:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0411301517300.15307@linen.sps.mot.com>
Kumar Gala <galak@linen.sps.mot.com> wrote:
>
> Andrew,
>
> Adds oprofile support for the e500 PowerPC core.
- arch/ppc/kernel/perfmon_fsl_booke.c has prototypes for init_pmc_stop()
and friends, but those prototypes are already in
include/asm-ppc/perfmon.h
- please don't put prototypes and extern declarations in .c files. Ever.
It defeats typechecking. Put them in a header file which is visible to
all callers/users as well as to the implementation.
- Do these need to be exported to modules?
+EXPORT_SYMBOL(init_pmc_stop);
+EXPORT_SYMBOL(set_pmc_event);
+EXPORT_SYMBOL(set_pmc_user_kernel);
+EXPORT_SYMBOL(set_pmc_marked);
+EXPORT_SYMBOL(pmc_start_ctr);
+EXPORT_SYMBOL(pmc_start_ctrs);
+EXPORT_SYMBOL(pmc_stop_ctrs);
+EXPORT_SYMBOL(dump_pmcs);
and if so, does an EXPORT_SYMBOL_GPL() not suffice?
- This:
+extern void (*perf_irq)(struct pt_regs *);
should be in a header file.
I'll queue the patch up. Fixups relative to this patch would be
appreciated, thanks.
^ permalink raw reply
* Re: Implementing PowerManagment for a ppc target
From: Benjamin Herrenschmidt @ 2004-11-30 22:53 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-dev list
In-Reply-To: <41ACE8B0.8090307@246tNt.com>
On Tue, 2004-11-30 at 22:40 +0100, Sylvain Munaut wrote:
> Hi,
>
> I'm trying to implement Deep Sleep support for a ppc platform based on
> 5200 and I have some questions :
>
> - How should I "integrate" it to linux, what the proper way ? I've been
> trying #defining CONFIG_PM and
> using the set_pm_ops operation but my call backs never get called
> when doing a echo standby > /sys/power/state
>
> It justs says :
>
> $ echo standby >
> /sys/power/state
>
> Stopping tasks:
> ===
Looks like a kernel thread isn't properly stopping ... note that on
pmac, I don't call that PM core, I do my own salad which does not
involve stopping tasks...
> stopping tasks failed (2 tasks
> remaining)
> Restarting tasks...<6> Strange, init not
> stopped
> Strange, sh not
> stopped
>
> done
>
> Stopping tasks:
> ===
>
> stopping tasks failed (2 tasks
> remaining)
> Restarting tasks...<6> Strange, init not
> stopped
> Strange, sh not
> stopped
>
> done
>
> I've been trying to look at Documentation/ and the sources but still I'm
> not sure ...
>
>
> - How can I ensure that one of my function runs out of I Cache ? Some
> pieces of assembler needs to not
> acces memory when the last 'orders' are sent. Does just keeping it
> small and aligned enough ?
Can you explain more precisely why and what are your precise
requirements ? (You can catch me on irc eventually)
>
> Thanks,
>
> Sylvain Munaut
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: Mounting usb pendrive
From: Isidoro Reyes de Zuloaga @ 2004-11-30 21:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200411301206.44403.isidoro@qassessorament.net>
Thanks for your help,=20
i recompiled the kenel with the old scsi driver and i works fine.
cheers.
isidoro
El Martes 30 Noviembre 2004 12:06, Isidoro Reyes de Zuloaga escribi=F3:
> Hi folks,
> I'm trying to mount my usb pendrive device and i'm getty a strange error
> message. I compiled my kernel with the scsi modules and all the stuff, and
> i can mount it on my x86, but in the powerbook i can't.
> this is the /var/log/messages:
>
> Nov 30 12:01:18 yoda kernel: usb 2-1.1: new full speed USB device using
> address 11
> Nov 30 12:01:18 yoda kernel: usb 2-1.1: new full speed USB device using
> address 12
> Nov 30 12:02:04 yoda kernel: ohci_hcd 0001:10:1b.1: wakeup
> Nov 30 12:02:04 yoda kernel: usb 3-1: new full speed USB device using
> address 5
> Nov 30 12:02:05 yoda kernel: uba: device 5 capacity nsec 50 bsize 512
> Nov 30 12:02:05 yoda kernel: uba: made changed
> Nov 30 12:02:05 yoda kernel: uba: device 5 capacity nsec 50 bsize 512
> Nov 30 12:02:05 yoda kernel: uba: device 5 capacity nsec 50 bsize 512
> Nov 30 12:02:05 yoda kernel: /dev/ub/a:end_request: I/O error, dev uba,
> sector 0
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 2
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 4
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 6
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 6
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 4
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 2
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 0
> Nov 30 12:02:05 yoda kernel: unable to read partition table
> Nov 30 12:02:05 yoda kernel: /dev/ub/a:end_request: I/O error, dev uba,
> sector 2
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 4
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 6
> Nov 30 12:02:05 yoda kernel: end_request: I/O error, dev uba, sector 0
> Nov 30 12:02:05 yoda kernel: unable to read partition table
> Nov 30 12:02:05 yoda usb.agent[4698]: ub: already loaded
>
> I don't know what's happening, it's the same when i try to mount the ipod.
> my modules are:
> usb_storage 107772 0
> scsi_mod 69856 3 sd_mod,sg,usb_storage
> usbhid 46592 0
> hci_usb 11104 2
> bluetooth 44100 7 rfcomm,l2cap,hci_usb
> usbcore 105204 9
> ehci_hcd,ub,ohci_hcd,usb_storage,uhci_hcd,usbhid,hci_usb
>
>
> Everything seems to be right, uh??
> Thanks for your help.
> isidoro
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Keyboad blacklight on new powerbook
From: Isidoro Reyes de Zuloaga @ 2004-11-30 21:40 UTC (permalink / raw)
To: linuxppc-dev list
Hi folks,
I'm trying to get the blacklight on my new powerbook. I installed pbbuttonsd
and also powerprefs. The sound and the light of the LCD screen works fine,
but i can get the blacklight working.
I've doing some research at google and it seems that the new powerbooks (I
bought it two months ago) are different than the others.
Does anyone know how to enable the keyboard light??? Also, the powerprefs
(last version), don't let me to change anything about this. I mean, the
blacklighting part is grey, like i can't edit.
Anyway, i edited the pbbuttonsd.conf (quite simple) but is not working. On the
macOS works fine.
Any clues?
Thanks in advance.
isidoro
^ 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