* Re: [PATCH] PowerMac: force only suspend-to-disk to be valid
From: Benjamin Herrenschmidt @ 2006-05-25 23:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1148566305.11759.35.camel@johannes.berg>
On Thu, 2006-05-25 at 16:11 +0200, Johannes Berg wrote:
> This patch adds the .valid callback to pm_ops on PowerMac so that only the
> suspend to disk state can be entered. Note that just returning 0 would
> suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
> handle it there regardless just in case that changes.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> --- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
> +++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
> @@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
> return 0;
> }
>
> +static int pmac_pm_valid(suspend_state_t state)
> +{
> + switch (state) {
> + case PM_SUSPEND_DISK:
> + return 1;
> + /* can't do any other states via generic mechanism yet */
> + default:
> + return 0;
> + }
> +}
> +
> static struct pm_ops pmac_pm_ops = {
> .pm_disk_mode = PM_DISK_SHUTDOWN,
> .prepare = pmac_pm_prepare,
> .enter = pmac_pm_enter,
> .finish = pmac_pm_finish,
> + .valid = pmac_pm_valid,
> };
>
> #endif /* CONFIG_SOFTWARE_SUSPEND */
>
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Benjamin Herrenschmidt @ 2006-05-25 23:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060525070558.2b7e24cd.akpm@osdl.org>
> It looks like a 2.6.17 patch to me. If someone wants to send it over with
> changelog, signed-off-by, etc I can take care of it.
Yup, it's good, I must have forgotten to ack it (too much travel & other
things lately)
Ben.
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Segher Boessenkool @ 2006-05-25 23:07 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1148593014.15517.32.camel@basalt.austin.ibm.com>
>> Care to redo the patch?
>
> After some offline discussion, I think we're in agreement that these
> properties are fine, since Linux's device tree code can't handle
> multiple ranges. Right Segher?
Not fine, but good enough for now, will need more work elsewhere
before we can do "the right thing" here.
> Hollis Blanchard
> IBM Linux Technology Center
>
> Due to a firmware device tree bug, RTC and NVRAM accesses (including
> halt/reboot) on Maple have been broken since January, when an untested
> build fix went in. This code patches the device tree in Linux.
>
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-25 23:02 UTC (permalink / raw)
To: Ken Moffat; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060525224905.GA28647@deepthought.linux.bogus>
On Thu, 2006-05-25 at 23:49 +0100, Ken Moffat wrote:
> > > CC [M] /home/ken/snd-aoa/soundbus/core.o
> > > In file included from /home/ken/snd-aoa/soundbus/soundbus.h:12,
> > > from /home/ken/snd-aoa/soundbus/core.c:12:
> > > include/sound/pcm.h:59: warning: =E2=80=98struct snd_pcm_substream=E2=
=80=99 declared
> > > inside parameter list
> > > include/sound/pcm.h:59: warning: its scope is only this definition
> > > or declaration, which is probably not what you want
> > > include/sound/pcm.h:60: warning: =E2=80=98struct snd_pcm_substream=E2=
=80=99 declared
> > > inside parameter list
> >=20
> > Nah, those should not happen. What kernel are you building against?
> >=20
> 2.6.17-rc5. I had similar messages when I first tried snd-aoa,
> which would have been around 2.6.16.5.
Hm, ok, I'm currently testing against 2.6.17-rc4 so that ought to be
fine unless they had a large alsa code drop which can't really be
between -rc4 and -rc5 :)
> Must be the headers causing the problem then. I wonder if it's
> somehow using userspace headers - I might have had some 'unvalidated'
> headers in /usr/include/sound [1]. Will take a look tomorrow,
> although I've installed alsa lib after building snd-aoa, so that
> probably updated the headers.
Very strange, I don't think it should be trying to include *anything*
from /usr/include for userspace. And the line numbers match the kernel
line numbers.
But looking at the header file again, I don't quite understand why it
should even work at all.
It (pcm.h) first uses struct snd_pcm_substream:
struct snd_pcm_ops {
int (*open)(struct snd_pcm_substream *substream);
int (*close)(struct snd_pcm_substream *substream);
(these are the lines that give the warnings above)
and then defines it much much later in line 344... Odd. I suppose gcc
4.1.0 is more struct. Try adding to pcm.h, around line 57, just the
definition like so:
struct snd_pcm_substream;
In any case, I don't think that's the actual problem. I think the point
is that your machine isn't supported yet, can you try the patch below?
But please let me know if _noheadphones is correct, it probably isn't
and you need to tell me what connectors you have on the outside of the
box.
johannes
--- snd-aoa.orig/aoa/fabrics/snd-aoa-fabric-layout.c 2006-05-26 01:01:17.18=
9771119 +0200
+++ snd-aoa/aoa/fabrics/snd-aoa-fabric-layout.c 2006-05-26 01:01:42.8197711=
19 +0200
@@ -80,6 +80,8 @@ struct layout {
=20
MODULE_ALIAS("sound-layout-82");
MODULE_ALIAS("sound-layout-45");
+MODULE_ALIAS("sound-layout-60");
+MODULE_ALIAS("sound-layout-61");
MODULE_ALIAS("sound-layout-64");
MODULE_ALIAS("sound-layout-65");
MODULE_ALIAS("sound-layout-68");
@@ -161,6 +163,21 @@ static struct layout layouts[] =3D {
.connections =3D NULL /* TBD */,
},
},
+ /* PowerMac9,1 */
+ { .layout_id =3D 60,
+ .flags =3D LAYOUT_FLAG_COMBO_LINEOUT_SPDIF,
+ .codecs[0] =3D {
+ .name =3D "onyx",
+ .connections =3D onyx_connections_noheadphones,
+ },
+ },
+ /* PowerMac9,1 */
+ { .layout_id =3D 61,
+ .codecs[0] =3D {
+ .name =3D "topaz",
+ .connections =3D NULL, /* TBD */
+ },
+ },
/* PowerBook5,7 */
{ .layout_id =3D 64,
.flags =3D LAYOUT_FLAG_COMBO_LINEOUT_SPDIF,
^ permalink raw reply
* [PATCH 0/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:15 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
There are five patches required to use the WRS SBC8265 board (with PCI).
The biggest issue was the earlier cleanup/replacement of m8260_pci with
m82xx_pci -- in the process it became specific to the PQ2FADS.
I've booted on 2.6.17rc3, and they still apply to 17rc4-git12 snapshot,
but I wouldn't be surprised if the CPM UART changes in rc3 --> rc4 break
sbc82xx CPM serial as I see Vitaly is still working on that.
Paul.
----
patch1: sbc82xx-diff0
- replace NR_SIU_INTS with NR_CPM_INTS
patch2: sbc82xx-PCI-diff1
- allow m82xx_pci.c to be used by other platforms that have
their own map_irq
patch3: sbc82xx-CONFIG.diff1
- add CONFIG_SBC82xx alongside CONFIG_PQ2FADS where required.
patch4: sbc82xx-mchk-pci9.diff1
- restore machine check disable for PCI9 that was in earlier
m8260_pci.c
patch5: fcc_enet-mac-addr.diff1
- restore proper collection of mac addr data in obsolete FCC
driver by replacing mix of #ifdef and if() with case
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-25 22:24 UTC (permalink / raw)
To: Ken Moffat; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060525221111.GB27181@deepthought.linux.bogus>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Thu, 2006-05-25 at 23:11 +0100, Ken Moffat wrote:
> it seemed to build fine with this morning's git. There were some
> messages during the build which might be important (I'm using
> gcc-4.1.0) but I guess they are probably standard alsa things :
>
> CC [M] /home/ken/snd-aoa/soundbus/core.o
> In file included from /home/ken/snd-aoa/soundbus/soundbus.h:12,
> from /home/ken/snd-aoa/soundbus/core.c:12:
> include/sound/pcm.h:59: warning: ‘struct snd_pcm_substream’ declared
> inside parameter list
> include/sound/pcm.h:59: warning: its scope is only this definition
> or declaration, which is probably not what you want
> include/sound/pcm.h:60: warning: ‘struct snd_pcm_substream’ declared
> inside parameter list
Nah, those should not happen. What kernel are you building against?
> i2sbus: !!!!! WARNING !!!!!
> i2sbus: control: couldn't allocate resource
> i2sbus: going ahead anyway
That's fine. Everyone gets it :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: BDI 2000 and MPC 8250 Problem
From: Evan Cofsky @ 2006-05-25 21:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <00f901c67de2$865e0f70$6501a8c0@CHUCK2>
[-- Attachment #1: Type: text/plain, Size: 16060 bytes --]
On 05/22 16:58, Mark Chambers wrote:
> Type, or are you setting IMMR to 0xf0000000 ?
I reverted the configuration file back to the one provided by A&M, and
now the following messages are displayed, and the BDI 2000 resets the
board endlessly:
- CONFIG: loading configuration file passed
- CONFIG: loading register definition passed
- TARGET: processing user reset request
- BDI asserts HRESET
- Reset JTAG controller passed
- Bypass check: 0x00000001 => 0x00000001
- JTAG exists check passed
- COP status is 0x01
- Check running state passed
- BDI scans COP freeze command
- BDI removes HRESET
- Target PVR is 0x80811014
- COP status is 0x01
- Check stopped state failed
- TARGET: Break at boot vector failed, freeze forced
- TARGET: Target PVR is 0x80811014
- TARGET: resetting target passed
- TARGET: processing target startup ....
- COP status is 0xF1
- Target PVR is 0x80811014
- BDI tries to resynch TAP
- COP status is 0x01
- Target PVR is 0x80811014
*** TARGET: processing target startup failed
# PPC: timeout while waiting for freeze
- TARGET: target will be restarted in 10 sec
The configuration file is:
;bdiGDB configuration file for rattler
; ------------------------------------------------------
;
[INIT]
;WREG MSR 0x00001002 ; set up MSR
;WSPR 1008 0 ; turn off caches
WM32 0x000101A8 0x00f00000 ; IMMR == 0xFF000000
WM32 0xff010004 0xFFFFFFC3 ; SYPCR == no watchdog
;WM32 0xFF010C80 0x00000001 ; SCCR == normal operations
;WM32 0xFF010000 0x0E240000 ; SIUMCR non PCI
;WM32 0xFF010000 0x0E640000 ; SIUMCR
;
;
; Memory controller
;
; These writes configure /CS0 to be the 2MB FLASH at 0xFFE0000
; and /CS6 to be the 2MB FLASH at 0xFFC0000
; These writes configure:
; CHIP SELECT BASE ADDRESS SIZE COMMENTS
; ----------- ------------ ---- --------
; /CS0 0WM16 0xFF010184 0x2000 ; MPTPR - PTP==0x20
;WM32 0xff010100 0x80001001 ; BR0
;WM32 0xFF010104 0xFF800E44 ; OR0
;WM32 0xff010104 0xFFC00E76 ; OR0
WM32 0xff010100 0xFE001001 ; BR0
WM32 0xff010104 0xFF800ED2 ; OR0
;
;
; Initialize the SDRAM on the 60x bus. /CS1
;FF
;
; operation
;
;
[TARGET]
CPUTYPE 8260 ;the CPU type (603EV,750,8240,8260)
JTAGCLOCK 0 ;use 16 MHz JTAG clock
WORKSPACE 0xff000000 ;workspace in target RAM for fast download
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT | GATEWAY)
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoints
;VECTOR CATCH 0 ;catch unhandled exceptions
DCACHE NOFLUSH ;data cache flushing (FLUSH | NOFLUSH)
BOOTADDR 0x00000100 ;boot address
REGLIST ALL
STEPMODE TRACE ; use hardware breakpoints to single step
MEMDELAY 4000 ;
;quit
;
[FLASH]
CHIPTYPE AM29BX16 ;Flash type (AM29F | AM29BX8 | AM29BX16 | I28BX8 | I28BX16)
CHIPSIZE 0x800000 ;641 8 Meg The size of one flash chip in bytes (e.g. AM29F010 = 0x20000)
BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32 | 64)
;
;
[HOST]
prompt 8250pci>
FORMAT SREC
LOAD MANUAL ;load code MANUAL or AUTO after reset
;
;
[REGS]
DMM1 0xff000000
FILE reg8260.def
The register definition file is:
;Register definition for MPC8260
;===============================
;
; name: user defined name of the register
; type: the type of the register
; GPR general purpose register
; SPR special purpose register
; MM memory mapped register
; DMMx direct memory mapped register with offset
; x = 1..4
; the base is defined in the configuration file
; e.g. DMM1 0x02200000
; addr: the number, adddress or offset of the register
; size the size of the register (8,16 or 32)
;
;name type addr size
;-------------------------------------------
;
sp GPR 1
;
xer SPR 1
lr SPR 8
ctr SPR 9
dsisr SPR 18
dar SPR 19
dec SPR 22
sdr1 SPR 25
srr0 SPR 26
srr1 SPR 27
;
tbl SPR 268
tbu SPR 269
sprg0 SPR 272
sprg1 SPR 273
sprg2 SPR 274
sprg3 SPR 275
ear SPR 282
pvr SPR 287
;
ibat0u SPR 528
ibat0l SPR 529
ibat1u SPR 530
ibat1l SPR 531
ibat2u SPR 532
ibat2l SPR 533
ibat3u SPR 534
ibat3l SPR 535
;
dbat0u SPR 536
dbat0l SPR 537
dbat1u SPR 538
dbat1l SPR 539
dbat2u SPR 540
dbat2l SPR 541
dbat3u SPR 542
dbat3l SPR 543
;
dmiss SPR 976
dcmp SPR 977
imiss SPR 980
icmp SPR 981
rpa SPR 982
;
hid0 SPR 1008
hid1 SPR 1009
hid2 SPR 1011
;
;
; DMM1 must be set to the internal memory base address
;
; General SIU
siumcr DMM1 0x10000 32
sypcr DMM1 0x10004 32
swsr DMM1 0x1000e 16
bcr DMM1 0x10024 32
ppc_acr DMM1 0x10028 8
ppc_alrh DMM1 0x1002c 32
ppc_alrl DMM1 0x10030 32
lcl_acr DMM1 0x10034 8
lcl_alrh DMM1 0x10038 32
lcl_alrl DMM1 0x1003c 32
tescr1 DMM1 0x10040 32
l_tescr1 DMM1 0x10048 32
l_tescr2 DMM1 0x1004c 32
pdtea DMM1 0x10050 32
pdtem DMM1 0x10054 8
ldtea DMM1 0x10058 32
ldtem DMM1 0x1005c 8
;
; Memory Controller
br0 DMM1 0x10100 32
or0 DMM1 0x10104 32
br1 DMM1 0x10108 32
or1 DMM1 0x1010c 32
br2 DMM1 0x10110 32
or2 DMM1 0x10114 32
br3 DMM1 0x10118 32
or3 DMM1 0x1011c 32
br4 DMM1 0x10120 32
or4 DMM1 0x10124 32
br5 DMM1 0x10128 32
or5 DMM1 0x1012c 32
br6 DMM1 0x10130 32
or6 DMM1 0x10134 32
br7 DMM1 0x10138 32
or7 DMM1 0x1013c 32
br8 DMM1 0x10140 32
or8 DMM1 0x10144 32
br9 DMM1 0x10148 32
or9 DMM1 0x1014c 32
br10 DMM1 0x10150 32
or10 DMM1 0x10154 32
br11 DMM1 0x10158 32
or11 DMM1 0x1015c 32
mar DMM1 0x10168 32
mamr DMM1 0x10170 32
mbmr DMM1 0x10174 32
mcmr DMM1 0x10178 32
mptpr DMM1 0x10184 16
mdr DMM1 0x10188 32
psdmr DMM1 0x10190 32
lsdmr DMM1 0x10194 32
purt DMM1 0x10198 8
psrt DMM1 0x1019c 8
lurt DMM1 0x101a0 8
lsrt DMM1 0x101a4 8
immr DMM1 0x101a8 32
;
; System Integration Timers
tmcntsc DMM1 0x10220 16
tmcnt DMM1 0x10224 32
tmcntal DMM1 0x1022c 32
piscr DMM1 0x10240 16
pitc DMM1 0x10244 32
pitr DMM1 0x10248 32
;
; Interrupt Controller
sicr DMM1 0x10c00 16
sivec DMM1 0x10c04 32
sipnr_h DMM1 0x10c08 32
sipnr_l DMM1 0x10c0c 32
siprr DMM1 0x10c10 32
scprr_h DMM1 0x10c14 32
scprr_l DMM1 0x10c18 32
simr_h DMM1 0x10c1c 32
simr_l DMM1 0x10c20 32
siexr DMM1 0x10c24 32
;
; Clocks and Reset
sccr DMM1 0x10c80 32
scmr DMM1 0x10c88 32
rsr DMM1 0x10c90 32
rmr DMM1 0x10c94 32
;
; Input/Output Port
pdira DMM1 0x10d00 32
ppara DMM1 0x10d04 32
psora DMM1 0x10d08 32
podra DMM1 0x10d0c 32
pdata DMM1 0x10d10 32
pdirb DMM1 0x10d20 32
pparb DMM1 0x10d24 32
psorb DMM1 0x10d28 32
podrb DMM1 0x10d2c 32
pdatb DMM1 0x10d30 32
pdirc DMM1 0x10d40 32
pparc DMM1 0x10d44 32
psorc DMM1 0x10d48 32
podrc DMM1 0x10d4c 32
pdatc DMM1 0x10d50 32
pdird DMM1 0x10d60 32
ppard DMM1 0x10d64 32
psord DMM1 0x10d68 32
podrd DMM1 0x10d6c 32
pdatd DMM1 0x10d70 32
;
; CPM Timers
tgcr1 DMM1 0x10d80 8
tgcr2 DMM1 0x10d84 8
tmr1 DMM1 0x10d90 16
tmr2 DMM1 0x10d92 16
trr1 DMM1 0x10d94 16
trr2 DMM1 0x10d96 16
tcr1 DMM1 0x10d98 16
tcr2 DMM1 0x10d9a 16
tcn1 DMM1 0x10d9c 16
tcn2 DMM1 0x10d9e 16
tmr3 DMM1 0x10da0 16
tmr4 DMM1 0x10da2 16
trr3 DMM1 0x10da4 16
trr4 DMM1 0x10da6 16
tcr3 DMM1 0x10da8 16
tcr4 DMM1 0x10daa 16
tcn3 DMM1 0x10dac 16
tcn4 DMM1 0x10dae 16
ter1 DMM1 0x10db0 16
ter2 DMM1 0x10db2 16
ter3 DMM1 0x10db4 16
ter4 DMM1 0x10db6 16
;
; SDMA-General
sdsr DMM1 0x11018 8
sdmr DMM1 0x1101c 8
;
; IDMA
idsr1 DMM1 0x11020 8
idmr1 DMM1 0x11024 8
idsr2 DMM1 0x11028 8
idmr2 DMM1 0x1102c 8
idsr3 DMM1 0x11030 8
idmr3 DMM1 0x11034 8
idsr4 DMM1 0x11038 8
idmr4 DMM1 0x1103c 8
;
; FCC1
gfmr1 DMM1 0x11300 32
fpsmr1 DMM1 0x11304 32
ftodr1 DMM1 0x11308 16
fdsr1 DMM1 0x1130c 16
fcce1 DMM1 0x11310 32
fccm1 DMM1 0x11314 32
fccs1 DMM1 0x11318 8
ftirr1_phy0 DMM1 0x1131c 8
ftirr1_phy1 DMM1 0x1131d 8
ftirr1_phy2 DMM1 0x1131e 8
ftirr1_phy3 DMM1 0x1131f 8
;
; FCC2
gfmr2 DMM1 0x11320 32
fpsmr2 DMM1 0x11324 32
ftodr2 DMM1 0x11328 16
fdsr2 DMM1 0x1132c 16
fcce2 DMM1 0x11330 32
fccm2 DMM1 0x11334 32
fccs2 DMM1 0x11338 8
ftirr2_phy0 DMM1 0x1133c 8
ftirr2_phy1 DMM1 0x1133d 8
ftirr2_phy2 DMM1 0x1133e 8
ftirr2_phy3 DMM1 0x1133f 8
;
; FCC3
gfmr3 DMM1 0x11340 32
fpsmr3 DMM1 0x11344 32
ftodr3 DMM1 0x11348 16
fdsr3 DMM1 0x1134c 16
fcce3 DMM1 0x11350 32
fccm3 DMM1 0x11354 32
fccs3 DMM1 0x11358 8
;
; BRGs 5-8
brgc5 DMM1 0x115f0 32
brgc6 DMM1 0x115f4 32
brgc7 DMM1 0x115f8 32
brgc8 DMM1 0x115fc 32
;
; I2C
i2mod DMM1 0x11860 8
i2add DMM1 0x11864 8
i2brg DMM1 0x11868 8
i2com DMM1 0x1186c 8
i2cer DMM1 0x11870 8
i2cmr DMM1 0x11874 8
;
; Communication Processor
cpcr DMM1 0x119c0 32
rccr DMM1 0x119c4 32
rter DMM1 0x119d6 16
rtmr DMM1 0x119da 16
rtscr DMM1 0x119dc 16
rtsr DMM1 0x119e0 32
;
; BRGs 1-4
brgc1 DMM1 0x119f0 32
brgc2 DMM1 0x119f4 32
brgc3 DMM1 0x119f8 32
brgc4 DMM1 0x119fc 32
;
; SCC1
gsmr_l1 DMM1 0x11a00 32
gsmr_h1 DMM1 0x11a04 32
psmr1 DMM1 0x11a08 16
todr1 DMM1 0x11a0c 16
dsr1 DMM1 0x11a0e 16
scce1 DMM1 0x11a10 16
sccm1 DMM1 0x11a14 16
sccs1 DMM1 0x11a17 8
;
; SCC2
gsmr_l2 DMM1 0x11a20 32
gsmr_h2 DMM1 0x11a24 32
psmr2 DMM1 0x11a28 16
todr2 DMM1 0x11a2c 16
dsr2 DMM1 0x11a2e 16
scce2 DMM1 0x11a30 16
sccm2 DMM1 0x11a34 16
sccs2 DMM1 0x11a37 8
;
; SCC3
gsmr_l3 DMM1 0x11a40 32
gsmr_h3 DMM1 0x11a44 32
psmr3 DMM1 0x11a48 16
todr3 DMM1 0x11a4c 16
dsr3 DMM1 0x11a4e 16
scce3 DMM1 0x11a50 16
sccm3 DMM1 0x11a54 16
sccs3 DMM1 0x11a57 8
;
; SCC4
gsmr_l4 DMM1 0x11a60 32
gsmr_h4 DMM1 0x11a64 32
psmr4 DMM1 0x11a68 16
todr4 DMM1 0x11a6c 16
dsr4 DMM1 0x11a6e 16
scce4 DMM1 0x11a70 16
sccm4 DMM1 0x11a74 16
sccs4 DMM1 0x11a77 8
;
; SMC1
smcmr1 DMM1 0x11a82 16
smce1 DMM1 0x11a86 8
smcm1 DMM1 0x11a8a 8
;
; SMC2
smcmr2 DMM1 0x11a92 16
smce2 DMM1 0x11a96 8
smcm2 DMM1 0x11a9a 8
;
; SPI
spmode DMM1 0x11aa0 16
spie DMM1 0x11aa6 8
spim DMM1 0x11aaa 8
spcom DMM1 0x11aad 8
;
; CPM Mux
cmxsi1cr DMM1 0x11b00 8
cmxsi2cr DMM1 0x11b02 8
cmxfcr DMM1 0x11b04 32
cmxscr DMM1 0x11b08 32
cmxsmr DMM1 0x11b0c 8
cmxuar DMM1 0x11b0e 16
;
; SI1 Registers
si1amr DMM1 0x11b20 16
si1bmr DMM1 0x11b22 16
si1cmr DMM1 0x11b24 16
si1dmr DMM1 0x11b26 16
si1gmr DMM1 0x11b28 8
si1cmdr DMM1 0x11b2a 8
si1str DMM1 0x11b2c 8
si1rsr DMM1 0x11b2e 16
;
; MCC1 Registers
mcce1 DMM1 0x11b30 16
mccm1 DMM1 0x11b34 16
mccf1 DMM1 0x11b38 8
;
; SI2 Registers
si2amr DMM1 0x11b40 16
si2bmr DMM1 0x11b42 16
si2cmr DMM1 0x11b44 16
si2dmr DMM1 0x11b46 16
si2gmr DMM1 0x11b48 8
si2cmdr DMM1 0x11b4a 8
si2str DMM1 0x11b4c 8
si2rsr DMM1 0x11b4e 16
;
; MCC2 Registers
mcce2 DMM1 0x11b50 16
mccm2 DMM1 0x11b54 16
mccf2 DMM1 0x11b58 8
;
Thanks, and help is certainly appreciated.
--
Evan Cofsky "The UNIX Man" <evan@theunixman.com>
See you space cowboy
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] fix RTC/NVRAM accesses on Maple
From: Hollis Blanchard @ 2006-05-25 21:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17516.64514.854281.64425@cargo.ozlabs.ibm.com>
On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
> Care to redo the patch?
After some offline discussion, I think we're in agreement that these
properties are fine, since Linux's device tree code can't handle
multiple ranges. Right Segher?
--
Hollis Blanchard
IBM Linux Technology Center
Due to a firmware device tree bug, RTC and NVRAM accesses (including
halt/reboot) on Maple have been broken since January, when an untested
build fix went in. This code patches the device tree in Linux.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
diff -r 5158eb8d85b7 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c Thu May 18 11:32:22 2006 +0700
+++ b/arch/powerpc/kernel/prom_init.c Thu May 25 16:30:10 2006 -0500
@@ -2057,10 +2057,45 @@ static void __init flatten_device_tree(v
}
-
-static void __init fixup_device_tree(void)
-{
+#ifdef CONFIG_PPC_MAPLE
+/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
+ * The values are bad, and it doesn't even have the right number of cells. */
+static void __init fixup_device_tree_maple(void)
+{
+ phandle isa;
+ u32 isa_ranges[6];
+
+ isa = call_prom("finddevice", 1, 1, ADDR("/ht@0/isa@4"));
+ if (!PHANDLE_VALID(isa))
+ return;
+
+ if (prom_getprop(isa, "ranges", isa_ranges, sizeof(isa_ranges))
+ == PROM_ERROR)
+ return;
+
+ if (isa_ranges[0] != 0x1 ||
+ isa_ranges[1] != 0xf4000000 ||
+ isa_ranges[2] != 0x00010000)
+ return;
+
+ prom_printf("fixing up bogus ISA range on Maple...\n");
+
+ isa_ranges[0] = 0x1;
+ isa_ranges[1] = 0x0;
+ isa_ranges[2] = 0x01002000; /* IO space; PCI device = 4 */
+ isa_ranges[3] = 0x0;
+ isa_ranges[4] = 0x0;
+ isa_ranges[5] = 0x00010000;
+ prom_setprop(isa, "/ht@0/isa@4", "ranges",
+ isa_ranges, sizeof(isa_ranges));
+}
+#else
+#define fixup_device_tree_maple()
+#endif
+
#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+static void __init fixup_device_tree_pmac(void)
+{
phandle u3, i2c, mpic;
u32 u3_rev;
u32 interrupts[2];
@@ -2097,9 +2132,16 @@ static void __init fixup_device_tree(voi
parent = (u32)mpic;
prom_setprop(i2c, "/u3@0,f8000000/i2c@f8001000", "interrupt-parent",
&parent, sizeof(parent));
-#endif
-}
-
+}
+#else
+#define fixup_device_tree_pmac()
+#endif
+
+static void __init fixup_device_tree(void)
+{
+ fixup_device_tree_maple();
+ fixup_device_tree_pmac();
+}
static void __init prom_find_boot_cpu(void)
{
^ permalink raw reply
* Re: [PATCH] Make cpufreq_transition_notifier a raw notifier
From: Alan Stern @ 2006-05-25 19:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev@ozlabs.org, cpufreq
In-Reply-To: <1148582489.11759.42.camel@johannes.berg>
On Thu, 25 May 2006, Johannes Berg wrote:
> On Thu, 2006-05-25 at 13:53 -0400, Alan Stern wrote:
>
> > Here's the patch Andrew asked for. I have no idea whether it will solve
> > any of these problems, and I'm certain that in the long run we shouldn't
> > keep it. Perhaps it will at least help stabilize 2.6.17.
> >
> > It's up to you guys to see if the patch helps at all and to decide whether
> > or not it should be applied.
>
> Maybe I should note that I don't actually have seen any problems because
> of this, the kernel just warns about it. I guess that's because the
> semaphore won't ever actually be contended at that point.
The problem isn't contention for the semaphore. The problem is that
down_read() will enable interrupts even when the semaphore is not in
contention, but parts of the cpufreq notifier chain need to execute with
interrupts disabled.
Alan Stern
^ permalink raw reply
* Re: VME driver problem on MVME6100
From: Konstantin Boyanov @ 2006-05-25 19:00 UTC (permalink / raw)
To: Ajit Prem, linuxppc-embedded
In-Reply-To: <007501c6801c$3b86fde0$0400a8c0@DLAPTOP>
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]
Hi again,
The problem persist even with the new driver for 2.6 ... :(
It is obvious that the driver cannot allocate memory for the window... It
fails that thing called __ioremap(), whatever it might be used for:
[mvme6100]# vme_setoutboundwin -h
vme_setoutboundwin
Usage: vme_setoutboundwin <options>
-w <window> window(where 0<=window<=6)
-m <mode> address mode (where 0=A16,1=A24,2=A32,3=A64,4=CRCSR)
-p <protocol> protocol (where
1=SCT,2=BLT,4=MBLT,8=2eVME,0x10=2eSST)
-a <VME addr> VME address
-d <data width> data width (8, 16, 32, 64)
-s <window size> window size (where 0 < window_size <=
0x400000)
-v Be more verbose
-h Give this (short) help
[mvme6100]# vme_setoutboundwin -w0 -m0 -p8 -a0x8800 -d16 -s400000 -v
window = 0, mode = 0 protocol 0x8 vme_addr = 0x8800 data width = 16
__ioremap(): phys addr 01000000 is RAM lr d100be34
vmedrv: No memory for outbound window
ioctl VME_IOCTL_SET_OUTBOUND failed.: Cannot allocate memory
While searching on the web for information about __ioremap I found this:
/*
* Remap an arbitrary physical address space into the kernel virtual
* address space. Needed when the kernel wants to access high addresses
* directly.
*
* NOTE! We need to allow non-page-aligned mappings too: we will obviously
* have to convert them into an offset in a page-aligned mapping, but the
* caller shouldn't need to know that small detail.
*/
And another thing - people should not be using __ioremap() unless they
have a _good_ _reason_ in their driver. They should be using ioremap()
instead. __ioremap() is an architecture implementation detail which
has no interface stability guarantees _at all_.
How's that? So it seems that the kernel can't translate the accesses to the
VME bus propperly. Any ideas how to fix that?
Actually I cant figure out why configuring a single outbound window is so
damn tough to achieve.e maybe I'm missing some crutial settings. I tried to
set up the window attribute register, and the outbound translation offset
register in the hope to fit in the needed size for the window, but again
failed. I'm trying to get frustrated about that...
Best regards,
Konstantin
[-- Attachment #2: Type: text/html, Size: 3220 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-25 18:47 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <60381eeb0605251044i79e155f2s62fb30b93432510e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Thu, 2006-05-25 at 20:44 +0300, Eddy Petrişor wrote:
> On 5/18/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote:
> >
> > > Any chance for 5,2 ? What is needed for it? Codec only?
> >
> > I don't know. If you try loading the modules, the kernel will tell you
> > something about an unhandled layout id. Alternatively, you can find the
> > layout-id file in your /proc/device-tree/ and tell me the number in it.
> > The rest I can figure out.
>
> I am not sure if you can make _now_ somethign out of this info, but I
> guess this is will not hurt:
Hrm, I keep forgetting that you don't have a layout-id property... I
need to sort some things, been doing so much other stuff that I lost
track. Sorry.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] Make cpufreq_transition_notifier a raw notifier
From: Johannes Berg @ 2006-05-25 18:41 UTC (permalink / raw)
To: Alan Stern; +Cc: Andrew Morton, linuxppc-dev@ozlabs.org, cpufreq
In-Reply-To: <Pine.LNX.4.44L0.0605251332260.8473-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Thu, 2006-05-25 at 13:53 -0400, Alan Stern wrote:
> Here's the patch Andrew asked for. I have no idea whether it will solve
> any of these problems, and I'm certain that in the long run we shouldn't
> keep it. Perhaps it will at least help stabilize 2.6.17.
>
> It's up to you guys to see if the patch helps at all and to decide whether
> or not it should be applied.
Maybe I should note that I don't actually have seen any problems because
of this, the kernel just warns about it. I guess that's because the
semaphore won't ever actually be contended at that point.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH 5/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:32 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch5: fcc_enet-mac-addr.diff1
- restore proper collection of mac addr data in obsolete FCC
driver by replacing mix of #ifdef and if() with case
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
--- linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c.orig 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16_rc5/arch/ppc/8260_io/fcc_enet.c 2006-02-27 18:01:45.000000000 -0500
@@ -1962,32 +1962,30 @@
* non-static part of the address.
*/
eap = (unsigned char *)&(ep->fen_paddrh);
- for (i=5; i>=0; i--) {
/*
* The EP8260 only uses FCC3, so we can safely give it the real
* MAC address.
*/
+ for (i=5; i>=0; i--) switch(i) {
+ case 5:
#ifdef CONFIG_SBC82xx
- if (i == 5) {
/* bd->bi_enetaddr holds the SCC0 address; the FCC
devices count up from there */
dev->dev_addr[i] = bd->bi_enetaddr[i] & ~3;
dev->dev_addr[i] += 1 + fip->fc_fccnum;
*eap++ = dev->dev_addr[i];
- }
-#else
-#ifndef CONFIG_RPX8260
- if (i == 3) {
+ break;
+#endif
+ case 3:
+#if !defined(CONFIG_RPX8260) && !defined(CONFIG_SBC82xx)
dev->dev_addr[i] = bd->bi_enetaddr[i];
dev->dev_addr[i] |= (1 << (7 - fip->fc_fccnum));
*eap++ = dev->dev_addr[i];
- } else
+ break;
#endif
- {
+ default:
*eap++ = dev->dev_addr[i] = bd->bi_enetaddr[i];
- }
-#endif
}
ep->fen_taddrh = 0;
^ permalink raw reply
* [PATCH 4/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:30 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch4: sbc82xx-mchk-pci9.diff1
- restore machine check disable for PCI9 that was in earlier
m8260_pci.c
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
--- linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c.orig 2006-02-27 15:02:01.000000000 -0500
+++ linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c 2006-02-27 16:05:20.000000000 -0500
@@ -227,6 +227,11 @@
immap->im_memctl.memc_pcibr1 = M82xx_PCI_SEC_WND_BASE | PCIBR_ENABLE;
#endif
+#ifdef CONFIG_8260_PCI9
+ /* Disable machine check on no response or target abort */
+ immap->im_pci.pci_emr = cpu_to_le32(0x1fe7);
+#endif
+
#if defined CONFIG_ADS8272
immap->im_siu_conf.siu_82xx.sc_siumcr =
(immap->im_siu_conf.siu_82xx.sc_siumcr &
^ permalink raw reply
* [PATCH 3/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:26 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch3: sbc82xx-CONFIG.diff1
- add CONFIG_SBC82xx alongside CONFIG_PQ2FADS where required.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
--- linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c.orig 2006-02-27 14:55:41.000000000 -0500
+++ linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c 2006-02-27 15:02:01.000000000 -0500
@@ -238,7 +238,7 @@
SIUMCR_APPC10 | SIUMCR_CS10PC00 |
SIUMCR_BCTLC00 | SIUMCR_MMR11 ;
-#elif defined CONFIG_PQ2FADS
+#elif defined(CONFIG_PQ2FADS) || defined(CONFIG_SBC82xx)
/*
* Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
* and local bus for PCI (SIUMCR [LBPC]).
@@ -292,7 +292,7 @@
#if defined CONFIG_ADS8272
/* PCI int highest prio */
immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x01236745;
-#elif defined CONFIG_PQ2FADS
+#elif defined(CONFIG_PQ2FADS) || defined(CONFIG_SBC82xx)
immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x03124567;
#endif
/* park bus on PCI */
@@ -380,7 +380,10 @@
IORESOURCE_IO | 1, "PCI I/O");
ppc_md.pci_exclude_device = pq2pci_exclude_device;
+
+#ifndef CONFIG_SBC82xx
hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+#endif
ppc_md.pci_map_irq = pq2pci_map_irq;
ppc_md.pcibios_fixup = NULL;
^ permalink raw reply
* [PATCH 2/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:25 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch2: sbc82xx-PCI-diff1
- allow m82xx_pci.c to be used by other platforms that have
their own map_irq
I'm open to doing this another way if desired -- I just went for the
minimal impact on the existing code with this.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09 16:20:35.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09 16:01:40.000000000 -0500
@@ -198,7 +198,7 @@
}
}
-static int sbc82xx_pci_map_irq(struct pci_dev *dev, unsigned char idsel,
+int pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel,
unsigned char pin)
{
static char pci_irq_table[][4] = {
@@ -247,7 +247,7 @@
callback_init_IRQ = ppc_md.init_IRQ;
ppc_md.init_IRQ = sbc82xx_init_IRQ;
- ppc_md.pci_map_irq = sbc82xx_pci_map_irq;
+ ppc_md.pci_map_irq = pq2pci_map_irq;
#ifdef CONFIG_GEN_RTC
ppc_md.time_init = NULL;
ppc_md.get_rtc_time = NULL;
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09 16:20:35.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09 16:35:05.000000000 -0500
@@ -24,6 +24,7 @@
#define BOOTROM_RESTART_ADDR ((uint)0x40000104)
+#define HAVE_OWN_PQ2PCI_IRQ
#define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
#define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
#define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
diff -ur orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c
--- orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-02-09 14:35:10.000000000 -0500
@@ -51,6 +51,10 @@
* Interrupt routing
*/
+#ifdef HAVE_OWN_PQ2PCI_IRQ
+extern int
+pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin);
+#else
static inline int
pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
{
@@ -172,6 +176,7 @@
setup_irq(PCI_INT_TO_SIU, &pq2pci_irqaction);
return;
}
+#endif /* HAVE_OWN_PQ2PCI_IRQ */
static int
pq2pci_exclude_device(u_char bus, u_char devfn)
^ permalink raw reply
* [PATCH 1/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:22 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch1: sbc82xx-diff0
- replace NR_SIU_INTS with NR_CPM_INTS
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-07 16:22:28.000000000 -0500
@@ -74,7 +74,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -88,7 +88,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -100,7 +100,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask &= ~(1 << irq_nr);
@@ -142,7 +142,7 @@
return IRQ_HANDLED;
}
}
- __do_IRQ(NR_SIU_INTS + irq, regs);
+ __do_IRQ(NR_CPM_INTS + irq, regs);
return IRQ_HANDLED;
}
@@ -173,7 +173,7 @@
}
/* Set up the interrupt handlers for the i8259 IRQs */
- for (i = NR_SIU_INTS; i < NR_SIU_INTS + 8; i++) {
+ for (i = NR_CPM_INTS; i < NR_CPM_INTS + 8; i++) {
irq_desc[i].handler = &sbc82xx_i8259_ic;
irq_desc[i].status |= IRQ_LEVEL;
}
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-07 14:48:03.000000000 -0500
@@ -24,13 +24,14 @@
#define BOOTROM_RESTART_ADDR ((uint)0x40000104)
-#define SBC82xx_PC_IRQA (NR_SIU_INTS+0)
-#define SBC82xx_PC_IRQB (NR_SIU_INTS+1)
-#define SBC82xx_MPC185_IRQ (NR_SIU_INTS+2)
-#define SBC82xx_ATM_IRQ (NR_SIU_INTS+3)
-#define SBC82xx_PIRQA (NR_SIU_INTS+4)
-#define SBC82xx_PIRQB (NR_SIU_INTS+5)
-#define SBC82xx_PIRQC (NR_SIU_INTS+6)
-#define SBC82xx_PIRQD (NR_SIU_INTS+7)
+#define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
+#define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
+#define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
+#define SBC82xx_ATM_IRQ (NR_CPM_INTS+3)
+
+#define SBC82xx_PIRQA (NR_CPM_INTS+4)
+#define SBC82xx_PIRQB (NR_CPM_INTS+5)
+#define SBC82xx_PIRQC (NR_CPM_INTS+6)
+#define SBC82xx_PIRQD (NR_CPM_INTS+7)
#endif /* __PPC_SBC82xx_H__ */
^ permalink raw reply
* [PATCH] Make cpufreq_transition_notifier a raw notifier
From: Alan Stern @ 2006-05-25 17:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev@ozlabs.org, johannes, cpufreq
In-Reply-To: <1148575497.24946.40.camel@cashmere.sps.mot.com>
The cpufreq code has problems with atomic vs. blocking notifier calls and
enabling vs. disabling interrupts (show up on pmac). As a temporary
band-aid, this patch (as697) makes the cpufreq_transition_notifier_list
into a raw notifier.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
---
On Thu, 25 May 2006, Jon Loeliger wrote:
> On Thu, 2006-05-25 at 09:44, Andrew Morton wrote:
>
> > > In essence, the problem seemed to be that the cpufreq notifier chain is
> > > sometimes expected to be blocking and sometimes expected to be atomic,
> > > based on the "val" code passed to notifier_call_chain. The cleanest
> > > solution would be to split the single notifier chain into two chains,
> > > one always blocking and the other always atomic.
> > >
> > > Somebody who knows more about cpufreq than I do will have to make that
> > > change.
> > >
> >
> > I wouldn't describe the cpufreq project as a teeming hive of frenetic
> > activity, and we need something pronto.
> >
> > We could go back to a raw_notifier and be as buggy as we used to be.
>
> It _is_ actively being pursued today for a cleaned up
> implementation. If there are issues or requirements
> here, we should really pass them on to the linux-pm list.
>
> Thanks,
> jdl
Here's the patch Andrew asked for. I have no idea whether it will solve
any of these problems, and I'm certain that in the long run we shouldn't
keep it. Perhaps it will at least help stabilize 2.6.17.
It's up to you guys to see if the patch helps at all and to decide whether
or not it should be applied.
Alan Stern
Index: usb-2.6/drivers/cpufreq/cpufreq.c
===================================================================
--- usb-2.6.orig/drivers/cpufreq/cpufreq.c
+++ usb-2.6/drivers/cpufreq/cpufreq.c
@@ -50,10 +50,9 @@ static void handle_update(void *data);
* validation process for a new CPU frequency policy; the
* "transition" list for kernel code that needs to handle
* changes to devices when the CPU clock speed changes.
- * The mutex locks both lists.
*/
static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
-static BLOCKING_NOTIFIER_HEAD(cpufreq_transition_notifier_list);
+static RAW_NOTIFIER_HEAD(cpufreq_transition_notifier_list);
static LIST_HEAD(cpufreq_governor_list);
@@ -263,14 +262,14 @@ void cpufreq_notify_transition(struct cp
freqs->old = policy->cur;
}
}
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_PRECHANGE, freqs);
adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
break;
case CPUFREQ_POSTCHANGE:
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
if (likely(policy) && likely(policy->cpu == freqs->cpu))
policy->cur = freqs->new;
@@ -1014,7 +1013,7 @@ static int cpufreq_suspend(struct sys_de
freqs.old = cpu_policy->cur;
freqs.new = cur_freq;
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_SUSPENDCHANGE, &freqs);
adjust_jiffies(CPUFREQ_SUSPENDCHANGE, &freqs);
@@ -1095,7 +1094,7 @@ static int cpufreq_resume(struct sys_dev
freqs.old = cpu_policy->cur;
freqs.new = cur_freq;
- blocking_notifier_call_chain(
+ raw_notifier_call_chain(
&cpufreq_transition_notifier_list,
CPUFREQ_RESUMECHANGE, &freqs);
adjust_jiffies(CPUFREQ_RESUMECHANGE, &freqs);
@@ -1141,7 +1140,7 @@ int cpufreq_register_notifier(struct not
switch (list) {
case CPUFREQ_TRANSITION_NOTIFIER:
- ret = blocking_notifier_chain_register(
+ ret = raw_notifier_chain_register(
&cpufreq_transition_notifier_list, nb);
break;
case CPUFREQ_POLICY_NOTIFIER:
@@ -1173,7 +1172,7 @@ int cpufreq_unregister_notifier(struct n
switch (list) {
case CPUFREQ_TRANSITION_NOTIFIER:
- ret = blocking_notifier_chain_unregister(
+ ret = raw_notifier_chain_unregister(
&cpufreq_transition_notifier_list, nb);
break;
case CPUFREQ_POLICY_NOTIFIER:
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-25 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147947784.15507.46.camel@johannes>
T24gNS8xOC8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBldHJpxZ9vciB3
cm90ZToKPgo+ID4gQW55IGNoYW5jZSBmb3IgNSwyID8gV2hhdCBpcyBuZWVkZWQgZm9yIGl0PyBD
b2RlYyBvbmx5Pwo+Cj4gSSBkb24ndCBrbm93LiBJZiB5b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVs
ZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+IHNvbWV0aGluZyBhYm91dCBhbiB1bmhhbmRs
ZWQgbGF5b3V0IGlkLiBBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIGZpbmQgdGhlCj4gbGF5b3V0LWlk
IGZpbGUgaW4geW91ciAvcHJvYy9kZXZpY2UtdHJlZS8gYW5kIHRlbGwgbWUgdGhlIG51bWJlciBp
biBpdC4KPiBUaGUgcmVzdCBJIGNhbiBmaWd1cmUgb3V0LgoKSSBhbSBub3Qgc3VyZSBpZiB5b3Ug
Y2FuIG1ha2UgX25vd18gc29tZXRoaWduIG91dCBvZiB0aGlzIGluZm8sIGJ1dCBJCmd1ZXNzIHRo
aXMgaXMgd2lsbCBub3QgaHVydDoKCmh0dHA6Ly9saXN0cy5kZWJpYW4ub3JnL2RlYmlhbi1wb3dl
cnBjLzIwMDYvMDQvbXNnMDAwNTkuaHRtbApodHRwOi8vbGlzdHMuZGViaWFuLm9yZy9kZWJpYW4t
cG93ZXJwYy8yMDA2LzA0L21zZzAwMDYzLmh0bWwKCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Jon Loeliger @ 2006-05-25 16:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: cpufreq, johannes, Alan Stern, linuxppc-dev@ozlabs.org
In-Reply-To: <20060525074412.19a03c22.akpm@osdl.org>
On Thu, 2006-05-25 at 09:44, Andrew Morton wrote:
> > In essence, the problem seemed to be that the cpufreq notifier chain is
> > sometimes expected to be blocking and sometimes expected to be atomic,
> > based on the "val" code passed to notifier_call_chain. The cleanest
> > solution would be to split the single notifier chain into two chains,
> > one always blocking and the other always atomic.
> >
> > Somebody who knows more about cpufreq than I do will have to make that
> > change.
> >
>
> I wouldn't describe the cpufreq project as a teeming hive of frenetic
> activity, and we need something pronto.
>
> We could go back to a raw_notifier and be as buggy as we used to be.
It _is_ actively being pursued today for a cleaned up
implementation. If there are issues or requirements
here, we should really pass them on to the linux-pm list.
Thanks,
jdl
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Andrew Morton @ 2006-05-25 14:44 UTC (permalink / raw)
To: Alan Stern; +Cc: cpufreq, johannes, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44L0.0605251005450.6990-100000@iolanthe.rowland.org>
Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 24 May 2006, Andrew Morton wrote:
>
> > > device_power_down should be called with interrupts off, thus the PMU
> > > driver is fine. It's a misnamed function, it calls the sysdev's suspend
> > > and those should be called with irq off. I think the problem is more due
> > > to some cpufreq or notifier change that somebody done to recent kernels
> > > and that added some might_sleep.... I wonder why.
> > >
> > > Andrew, what's up there ? What is this new
> > > "blocking_notifier_call_chain" thing ? notifiers use to not use
> > > semaphores and not be blocking... at least powermac implementation of
> > > cpufreq relies on that.
> >
> > notifiers used to be racy too - we just waddled across them without any
> > locking.
> >
> > Alan made a best-effort conversion of callers, and there have been a few
> > problems.
> >
> > Here, pmac has gone and unilaterally decided that device_power_down() is
> > atomic, even though device_power_down() _already_ calls suspend_device(),
> > which does down(). So I'd say you've gone and found a via-pmu bug here.
> >
> > A way of shutting up the warning would be to use an atomic notifier, but
> > it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> > to assume things which aren't true ;)
>
> Someone else had a problem with the cpufreq conversion earlier. I posted
> a message on the cpufreq mailing list but nobody ever responded to it.
> This may or may not be related to that earlier problem.
>
> In essence, the problem seemed to be that the cpufreq notifier chain is
> sometimes expected to be blocking and sometimes expected to be atomic,
> based on the "val" code passed to notifier_call_chain. The cleanest
> solution would be to split the single notifier chain into two chains,
> one always blocking and the other always atomic.
>
> Somebody who knows more about cpufreq than I do will have to make that
> change.
>
I wouldn't describe the cpufreq project as a teeming hive of frenetic
activity, and we need something pronto.
We could go back to a raw_notifier and be as buggy as we used to be.
^ permalink raw reply
* Re: [PATCH] PowerMac: force only suspend-to-disk to be valid
From: Andrew Morton @ 2006-05-25 14:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148566305.11759.35.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> This patch adds the .valid callback to pm_ops on PowerMac so that only the
> suspend to disk state can be entered. Note that just returning 0 would
> suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
> handle it there regardless just in case that changes.
That's the "what" - please provide the "why": what bug does this fix, and
what are the consequences of not having this patch?
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Alan Stern @ 2006-05-25 14:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: cpufreq, Johannes Berg, linuxppc-dev
In-Reply-To: <20060524215917.230af218.akpm@osdl.org>
On Wed, 24 May 2006, Andrew Morton wrote:
> > device_power_down should be called with interrupts off, thus the PMU
> > driver is fine. It's a misnamed function, it calls the sysdev's suspend
> > and those should be called with irq off. I think the problem is more due
> > to some cpufreq or notifier change that somebody done to recent kernels
> > and that added some might_sleep.... I wonder why.
> >
> > Andrew, what's up there ? What is this new
> > "blocking_notifier_call_chain" thing ? notifiers use to not use
> > semaphores and not be blocking... at least powermac implementation of
> > cpufreq relies on that.
>
> notifiers used to be racy too - we just waddled across them without any
> locking.
>
> Alan made a best-effort conversion of callers, and there have been a few
> problems.
>
> Here, pmac has gone and unilaterally decided that device_power_down() is
> atomic, even though device_power_down() _already_ calls suspend_device(),
> which does down(). So I'd say you've gone and found a via-pmu bug here.
>
> A way of shutting up the warning would be to use an atomic notifier, but
> it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> to assume things which aren't true ;)
Someone else had a problem with the cpufreq conversion earlier. I posted
a message on the cpufreq mailing list but nobody ever responded to it.
This may or may not be related to that earlier problem.
In essence, the problem seemed to be that the cpufreq notifier chain is
sometimes expected to be blocking and sometimes expected to be atomic,
based on the "val" code passed to notifier_call_chain. The cleanest
solution would be to split the single notifier chain into two chains,
one always blocking and the other always atomic.
Somebody who knows more about cpufreq than I do will have to make that
change.
Alan Stern
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-25 14:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20060525071013.21379ba8.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Thu, 2006-05-25 at 07:10 -0700, Andrew Morton wrote:
> Please also explain whether this fix is needed in 2.6.16.x.
Well, for a very long time, echoing 'standby' or 'mem'
into /sys/power/state has killed the machine on powerpc. This patch
fixes that. So I guess yes, it is applicable to 2.6.16.x
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH] PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-25 14:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered. Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
handle it there regardless just in case that changes.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
+++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
@@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
return 0;
}
+static int pmac_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_DISK:
+ return 1;
+ /* can't do any other states via generic mechanism yet */
+ default:
+ return 0;
+ }
+}
+
static struct pm_ops pmac_pm_ops = {
.pm_disk_mode = PM_DISK_SHUTDOWN,
.prepare = pmac_pm_prepare,
.enter = pmac_pm_enter,
.finish = pmac_pm_finish,
+ .valid = pmac_pm_valid,
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
^ 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