LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/6] [WATCHDOG] mpc83xx_wdt: convert to the OF platform driver
From: Stephen Rothwell @ 2008-05-13 23:32 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080513141454.GA15717@polina.dev.rtsoft.ru>

[-- Attachment #1: Type: text/plain, Size: 777 bytes --]

Hi Anton,

On Tue, 13 May 2008 18:14:54 +0400 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> +static struct of_platform_driver mpc83xx_wdt_driver = {
> +	.name		= "mpc83xx_wdt",
> +	.match_table	= mpc83xx_wdt_match,
>  	.probe		= mpc83xx_wdt_probe,
>  	.remove		= __devexit_p(mpc83xx_wdt_remove),
> -	.driver		= {
> -		.name	= "mpc83xx_wdt",
> -		.owner	= THIS_MODULE,
> -	},

You should leave this as it was because the name and owner fields are
being removed from struct of_platform_driver in favour of those embedded in
the .driver.

Maybe I should add a comment to the structure definition.  Or maybe it is
time to actually remove them.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* mpc86xx - couple of questions...
From: Siva Prasad @ 2008-05-14  1:22 UTC (permalink / raw)
  To: linuxppc-dev

Hi,

I took the latest tree from linux/kernel/git/galak/powerpc.git
(2.6.26-rc2), and the latest dtc from linux/kernel/git/galak/dtc.git.

After compiling, I am having couple of questions.

1) Doesn't the latest dtc support /memreserve/ on the top before or
after /dts-v1/? This used to work fine for previous compiler and this is
giving an error now.

2) When I compiled and started booting the new kernel, I am getting a
kernel crash (copy pasted below) in hash_page routine when it executes
the assembly instruction "lwarx   r6,0,r8". Can some one throw light at
this?

Kernel command line: root=3D/dev/ram rw console=3DttyS0,115200
mpic: Setting up MPIC " MPIC     " version 1.2 at ff740000, max 2 CPUs
mpic: ISU size: 88, shift: 7, mask: 7f
mpic: Initializing for 88 sources
PID hash table entries: 4096 (order: 12, 16384 bytes)
time_init: decrementer frequency =3D 150.000000 MHz
time_init: processor frequency   =3D 1572.864000 MHz
clocksource: timebase mult[1aaaaab] shift[22] registered
clockevent: decrementer mult[2666] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 262144k
Memory: 1028816k/1048576k available (4308k kernel code, 18904k reserved,
108k data, 168k bss, 188k init)
SLUB: Genslabs=3D12, HWalign=3D32, Order=3D0-3, MinObjects=3D0, =
CPUs=3D2, Nodes=3D1
Calibrating delay loop... 299.00 BogoMIPS (lpj=3D149504)
Mount-cache hash table entries: 512
mpic: requesting IPIs ...=20
Machine check in kernel mode.
Caused by (from SRR1=3D141000): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=3D2 Bivio's Odessa
Modules linked in:
NIP: 00015860 LR: 000003b0 CTR: 00000000
REGS: ef82bcc0 TRAP: 0200   Not tainted  (2.6.26-rc2)
MSR: 00141000 <ME>  CR: 8202202c  XER: 20000000
TASK =3D ef830000[-1073742352] 'swapper' THREAD: ef82a000 CPU: =
1919248243
GPR00: 00000102 ef82bd70 ef830000 00000005 89dbb8b0 0001189c 82c10068
40000000=20
GPR08: 834106ec 00001032 40000000 2f82bd70 c000e66c 00000061 00000000
00000004=20
GPR16: 00000080 c0000000 0000000e 00007a2c 00100000 00000000 c0430000
c0460000=20
GPR24: c0430000 00000002 ef82be60 c0460000 00000001 ef82a000 c046318c
c0460000=20
NIP [00015860] 0x15860
LR [000003b0] 0x3b0
Call Trace:
[ef82bd70] [00001032] 0x1032 (unreliable)
--- Exception: 466f3c at 0xef82bec0
    LR =3D ret_from_except+0x0/0x14
[ef82be50] [c0011d7c] ret_from_except+0x0/0x14
--- Exception: 901 at __delay+0x30/0x74
    LR =3D __cpu_up+0x144/0x1b4
[ef82bf10] [c0428978] __cpu_up+0xa4/0x1b4 (unreliable)
[ef82bf30] [c04291cc] cpu_up+0x108/0x1c4
[ef82bf70] [c0406204] kernel_init+0xd0/0x310
Instruction dump:
3ca0c043 XXXXXXXX XXXXXXXX XXXXXXXX 5085653a XXXXXXXX XXXXXXXX XXXXXXXX=20
5088b53a XXXXXXXX XXXXXXXX XXXXXXXX 7c653079 XXXXXXXX XXXXXXXX XXXXXXXX=20
---[ end trace 31fd0ba7d8756001 ]---

Thanks
Siva

^ permalink raw reply

* Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Stephen Rothwell @ 2008-05-14  1:45 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080513141459.GC15717@polina.dev.rtsoft.ru>

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Tue, 13 May 2008 18:14:59 +0400 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> Rename the driver because now we support some MPC86xx processors.
> 
> There are no changes to the mpc83xx_wdt.c file, yet. When possible, we do
> file renames and changes separately (because Linus once asked so, because
> it helps git to track the renamed files).
> 
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
>  drivers/watchdog/Kconfig       |    4 +-
>  drivers/watchdog/Makefile      |    2 +-
>  drivers/watchdog/mpc83xx_wdt.c |  273 ----------------------------------------
>  drivers/watchdog/mpc8xxx_wdt.c |  273 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 276 insertions(+), 276 deletions(-)
>  delete mode 100644 drivers/watchdog/mpc83xx_wdt.c
>  create mode 100644 drivers/watchdog/mpc8xxx_wdt.c

Doing this status with "git diff -M --stat" would show us if the file was
just renamed or if there were some changes as well ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Stephen Rothwell @ 2008-05-14  1:48 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080514114523.ae20b0da.sfr@canb.auug.org.au>

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

Hi Anton,

On Wed, 14 May 2008 11:45:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Doing this status with "git diff -M --stat" would show us if the file was
> just renamed or if there were some changes as well ...

Not that I don't trust you, just for future reference.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply

* Re: mpc86xx - couple of questions...
From: Jon Loeliger @ 2008-05-14  1:56 UTC (permalink / raw)
  To: Siva Prasad; +Cc: linuxppc-dev
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D702315472@corpexc01.corp.networkrobots.com>

> Hi,
> 
> I took the latest tree from linux/kernel/git/galak/powerpc.git
> (2.6.26-rc2), and the latest dtc from linux/kernel/git/galak/dtc.git.

Hmm.  galak, good.  Or paulus.  But the latest DTC is
found on jdl.com still.

> After compiling, I am having couple of questions.
> 
> 1) Doesn't the latest dtc support /memreserve/ on the top before or
> after /dts-v1/?

/dts-v1/ is first as it sets the framework for the
rest of the source file.

> This used to work fine for previous compiler and this is
> giving an error now.

Can you show us the source and the compiler output?

jdl

^ permalink raw reply

* Re: mpc86xx - couple of questions...
From: David Gibson @ 2008-05-14  2:47 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: linuxppc-dev, Siva Prasad
In-Reply-To: <E1Jw6EC-0005sE-3W@jdl.com>

On Tue, May 13, 2008 at 08:56:24PM -0500, Jon Loeliger wrote:
> > Hi,
> > 
> > I took the latest tree from linux/kernel/git/galak/powerpc.git
> > (2.6.26-rc2), and the latest dtc from linux/kernel/git/galak/dtc.git.
> 
> Hmm.  galak, good.  Or paulus.  But the latest DTC is
> found on jdl.com still.
> 
> > After compiling, I am having couple of questions.
> > 
> > 1) Doesn't the latest dtc support /memreserve/ on the top before or
> > after /dts-v1/?
> 
> /dts-v1/ is first as it sets the framework for the
> rest of the source file.

Including the format of the /memreserve/ entries themselves.  If
/dts-v1/ appears, it *must* be the first token in the file, anything
else is a syntax error.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

^ permalink raw reply

* linux 2.6 hangs at __delay function on Viretx 4 board
From: swamydp @ 2008-05-14  3:29 UTC (permalink / raw)
  To: linuxppc-embedded



I am trying to boot linux 2.6 on HITECH virtex 4(fx60) board. Linux hangs at
address 0xc00045ec which is in the __udelay function. I am using EDK 9.2i
and gcc version 4.0.2 for compiling the kernel. The following is the boot
message from the bootloader. 

loaded at:     00400000 0054E19C
board data at: 0054C120 0054C19C
relocated to:  00404064 004040E0
zimage at:     00404E55 0054B5B4
avail ram:     0054F000 02000000

Linux/PPC load: console=ttyS0,9600 console=tty0 root=/dev/sda2
Uncompressing Linux...done.
Now booting the kernel

Any help is greatly appreciated. I have run out of ideas to fix this.

Thanks
swamy

-- 
View this message in context: http://www.nabble.com/linux-2.6-hangs-at-__delay-function-on-Viretx-4-board-tp17222725p17222725.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* RE: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Chen Gong @ 2008-05-14  3:53 UTC (permalink / raw)
  To: Stephen Rothwell, Anton Vorontsov
  Cc: Wood Scott, linuxppc-dev, Wim Van Sebroeck, Tabi Timur
In-Reply-To: <20080514114523.ae20b0da.sfr@canb.auug.org.au>

=20

> -----Original Message-----
> From: linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b11801=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Stephen Rothwell
> Sent: 2008?5?14? 9:45
> To: Anton Vorontsov
> Cc: Wood Scott; linuxppc-dev@ozlabs.org; Wim Van Sebroeck; Tabi Timur
> Subject: Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
>=20
> On Tue, 13 May 2008 18:14:59 +0400 Anton Vorontsov=20
> <avorontsov@ru.mvista.com> wrote:
> >
> > Rename the driver because now we support some MPC86xx processors.
What I want to know is that what about watchdog for booke(85xx) ?
> >=20
> > There are no changes to the mpc83xx_wdt.c file, yet. When=20
> possible, we=20
> > do file renames and changes separately (because Linus once=20
> asked so,=20
> > because it helps git to track the renamed files).
> >=20
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> >  drivers/watchdog/Kconfig       |    4 +-
> >  drivers/watchdog/Makefile      |    2 +-
> >  drivers/watchdog/mpc83xx_wdt.c |  273=20
> > ----------------------------------------
> >  drivers/watchdog/mpc8xxx_wdt.c |  273=20
> > ++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 276 insertions(+), 276 deletions(-)  delete mode=20
> > 100644 drivers/watchdog/mpc83xx_wdt.c  create mode 100644=20
> > drivers/watchdog/mpc8xxx_wdt.c
>=20
> Doing this status with "git diff -M --stat" would show us if=20
> the file was just renamed or if there were some changes as well ...
>=20
> --
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>=20

^ permalink raw reply

* Re: [PATCH 0/6] 16G and multi size hugetlb page support on powerpc
From: Nick Piggin @ 2008-05-14  4:25 UTC (permalink / raw)
  To: kniht
  Cc: linuxppc-dev, linux-kernel, Linux Memory Management List,
	Andi Kleen, Paul Mackerras, Nishanth Aravamudan
In-Reply-To: <4829CAC3.30900@us.ibm.com>

On Tue, May 13, 2008 at 12:07:15PM -0500, Jon Tollefson wrote:
> This patch set builds on Nick Piggin's patches for multi size and giant 
> hugetlb page support of April 22.  The following set of patches adds 
> support for 16G huge pages on ppc64 and support for multiple huge page 
> sizes at the same time on ppc64.  Thus allowing 64K, 16M, and 16G huge 
> pages given a POWER5+ or later machine.
> 
> New to this version of my patch is numerous bug fixes and cleanups, but 
> the biggest change is the support for multiple huge page sizes on power.
> 
> patch 1: changes to generic hugetlb to enable 16G pages on power
> patch 2: powerpc: adds function for allocating 16G pages
> patch 3: powerpc: setups 16G page locations found in device tree
> patch 4: powerpc: page definition support for 16G pages
> patch 5: check for overflow when user space is 32bit
> patch 6: powerpc: multiple huge page size support

Hi Jon,

Thanks very much. I'll put these at the end of my patchset and attempt
to keep them building if I make changes to the core code (have to spend
a bit of time catching up with the review comments from last round).

I'll send out another patchset for review in a day or so after I catch
up, and then hopefully get it merged in -mm for 2.6.27.

Thanks,
Nick

^ permalink raw reply

* [PATCH] Defer processing of interrupts when the CPU wakes from sleep mode
From: Paul Mackerras @ 2008-05-14  4:30 UTC (permalink / raw)
  To: linuxppc-dev

This provides a way to defer processing of an interrupt that wakes the
processor out of sleep mode.  On 32-bit platforms that use an
interrupt to wake the processor, we have to have interrupts enabled in
hardware at the point where we go to sleep, otherwise the processor
will never wake up.  However, because interrupts are logically
disabled at this point, we don't want to process the interrupt
straight away.

This is handled by setting the _TLF_SLEEPING flag.  When we get an
interrupt and _TLF_SLEEPING is set, we firstly clear the MSR_EE
(external interrupt enable) bit in the saved MSR value, and secondly
we then return to the address in the link register, like we do for
_TLF_NAPPING, but without actually handling the interrupt.

Note that this is handled somewhat differently on powerbooks, so this
new code will only be used on non-Apple machines.

Signed-off-by: Paul Mackerras <paulus@samba.org>
---

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 84c8686..162500f 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -146,6 +146,7 @@ transfer_to_handler:
 	lwz	r12,TI_LOCAL_FLAGS(r9)
 	mtcrf	0x01,r12
 	bt-	31-TLF_NAPPING,4f
+	bt-	31-TLF_SLEEPING,7f
 #endif /* CONFIG_6xx */
 	.globl transfer_to_handler_cont
 transfer_to_handler_cont:
@@ -163,6 +164,13 @@ transfer_to_handler_cont:
 4:	rlwinm	r12,r12,0,~_TLF_NAPPING
 	stw	r12,TI_LOCAL_FLAGS(r9)
 	b	power_save_6xx_restore
+
+7:	rlwinm	r12,r12,0,~_TLF_SLEEPING
+	stw	r12,TI_LOCAL_FLAGS(r9)
+	lwz	r9,_MSR(r11)		/* if sleeping, clear MSR.EE */
+	rlwinm	r9,r9,0,~MSR_EE
+	lwz	r12,_LINK(r11)		/* and return to address in LR */
+	b	fast_exception_return
 #endif
 
 /*
diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h
index d030f5c..1cd8c8f 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -147,8 +147,10 @@ static inline struct thread_info *current_thread_info(void)
 /* Bits in local_flags */
 /* Don't move TLF_NAPPING without adjusting the code in entry_32.S */
 #define TLF_NAPPING		0	/* idle thread enabled NAP mode */
+#define TLF_SLEEPING		1	/* suspend code enabled SLEEP mode */
 
 #define _TLF_NAPPING		(1 << TLF_NAPPING)
+#define _TLF_SLEEPING		(1 << TLF_SLEEPING)
 
 #endif /* __KERNEL__ */
 

^ permalink raw reply related

* Re: Compiling applications using cross compiler packs libc
From: David H. Lynch Jr. @ 2008-05-14  5:57 UTC (permalink / raw)
  To: ramkumarj2000; +Cc: linuxppc-embedded
In-Reply-To: <20080512102728.GA26806@mail.gnudd.com>


Alessandro Rubini wrote:
>> the glibc is also packed
>> up as a part of application though I never make any calls to the glibc
>> libraries.
>>     
>
> If however you really want to build an application without library, you
> should change the linker script. 
some or all of the following gcc flags might be useful if you are truly
compiling an OS independent very small application
-U__linux__
-nostdlib
-nostdinc
-mno-eabi
-fno-builtin
-nostartfiles
-nodefaultlibs
-nostdlib
Also as Alessandro pointed out you will likely need a link script.

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

^ permalink raw reply

* Re: mmap problem in device driver and application program.
From: Johan Borkhuis @ 2008-05-14  6:18 UTC (permalink / raw)
  To: MingLiu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-W368A781D323F0E5E4D0BF3B2CF0@phx.gbl>

MingLiu wrote:
> Dear Dave,
>   
>> If you are using memory that is not under the kernel's memory management> you will need to use something other than remap_pfn_range.> 
>>     
> Happenly and unfortunately we are using the memory space out of the control from the kernel. We have 2GB memory on the board and only 64(or 32) MB is reserved for the kernel. The rest large space is for the data buffering or LUT use. In my question, the LUT memory is located in the rest part rather than the kernel memory area. 
>  
> Any more suggestion on how to mmap this LUT area? Any idea will be valuable for a beginner like me. Thanks in advance. 
>   

If this is physical memory that is not controlled by the kernel you
could also use the /dev/mem device. You could do something like:

memFd = open("/dev/mem", O_RDWR);
memBuf = mmap(0, <Memory size>, PROT_READ | PROT_WRITE, MAP_SHARED,
memFd, <Physical address of memory);

which maps the physical memory into user space, without the need for a
special device driver or mmap implementation.

Kind regards,
Johan Borkhuis

^ permalink raw reply

* Re: smc911x: how to call the driver?
From: Peter Korsgaard @ 2008-05-14  7:07 UTC (permalink / raw)
  To: Jens Gehrlein; +Cc: linuxppc-embedded Mailinglist
In-Reply-To: <4829BC19.5000909@tqs.de>

>>>>> "Jens" == Jens Gehrlein <sew_s@tqs.de> writes:

 Jens> Hi,
 Jens> on our board a SMSC LAN9215i is connected to an i.MX31 ARM
 Jens> processor. My hope is to get the smc911x driver run on this chip. The
 Jens> LAN921x data sheets say that existing 911x drivers should work.

Why are you asking this in a powerpc list?

 Jens> My next problem is:
 Jens> Where and when get the functions smc911x_drv_probe() and
 Jens> smc911x_init() called? Any hints?

You need to register a struct platform_device in your platform code,
E.G. something like:

static struct resource smc911x_resources[] = {
        [0] = {
                .start  = 0x8e000000,
                .end    = 0x8e0000ff,
                .flags  = IORESOURCE_MEM,
        },
        [1] = {
                .start  = 4,
                .end    = 4,
                .flags  = IORESOURCE_IRQ,
        },
};

static struct platform_device thinlite_eth = {
        .name                   = "smc911x",
        .id                     = 0,
        .num_resources          = ARRAY_SIZE(smc911x_resources),
        .resource               = smc911x_resources,
};

And then do a platform_add_devices with it.

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* Re: smc911x: how to call the driver?
From: Jens Gehrlein @ 2008-05-14  8:04 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: linuxppc-embedded Mailinglist
In-Reply-To: <87hcd1749f.fsf@macbook.be.48ers.dk>

Hi Peter,

thank you for responding.

Peter Korsgaard schrieb:
>>>>>> "Jens" == Jens Gehrlein <sew_s@tqs.de> writes:
> 
>  Jens> Hi,
>  Jens> on our board a SMSC LAN9215i is connected to an i.MX31 ARM
>  Jens> processor. My hope is to get the smc911x driver run on this chip. The
>  Jens> LAN921x data sheets say that existing 911x drivers should work.
> 
> Why are you asking this in a powerpc list?

Uuh, sorry. In the haste I just read "embedded". Actually, my question 
isn't processor related. Rather it's (network) device driver related.
Could you recommend a mailing list for this?

>  Jens> My next problem is:
>  Jens> Where and when get the functions smc911x_drv_probe() and
>  Jens> smc911x_init() called? Any hints?
> 
> You need to register a struct platform_device in your platform code,
> E.G. something like:
> 
> static struct resource smc911x_resources[] = {
>         [0] = {
>                 .start  = 0x8e000000,
>                 .end    = 0x8e0000ff,
>                 .flags  = IORESOURCE_MEM,
>         },
>         [1] = {
>                 .start  = 4,
>                 .end    = 4,
>                 .flags  = IORESOURCE_IRQ,
>         },
> };
> 
> static struct platform_device thinlite_eth = {
>         .name                   = "smc911x",
>         .id                     = 0,
>         .num_resources          = ARRAY_SIZE(smc911x_resources),
>         .resource               = smc911x_resources,
> };
> 
> And then do a platform_add_devices with it.

Mmmh, this is all new to me. I'll try to get through it and perhaps 
we'll meet on the other mailinglist again.

Thank you very much so far.

Best Regards,
Jens

^ permalink raw reply

* Re: smc911x: how to call the driver?
From: Peter Korsgaard @ 2008-05-14  8:19 UTC (permalink / raw)
  To: Jens Gehrlein; +Cc: linuxppc-embedded Mailinglist
In-Reply-To: <482A9CF0.7050600@tqs.de>

>>>>> "Jens" == Jens Gehrlein <sew_s@tqs.de> writes:

Hi,

 Jens> on our board a SMSC LAN9215i is connected to an i.MX31 ARM
 Jens> processor. My hope is to get the smc911x driver run on this chip. The
 Jens> LAN921x data sheets say that existing 911x drivers should work.
 >> 
 >> Why are you asking this in a powerpc list?

 Jens> Uuh, sorry. In the haste I just read "embedded". Actually, my question
 Jens> isn't processor related. Rather it's (network) device driver related.
 Jens> Could you recommend a mailing list for this?

netdev@vger.kernel.org (see http://vger.kernel.org/vger-lists.html).

-- 
Bye, Peter Korsgaard

^ permalink raw reply

* [PATCH] cell: fix section mismatch warnings
From: Kou Ishizaki @ 2008-05-14  9:05 UTC (permalink / raw)
  To: paulus; +Cc: linuxppc-dev

Fix following warnings:
WARNING: arch/powerpc/platforms/cell/built-in.o(.devinit.text+0x9c): Section mismatch in reference from the function .cell_setup_phb() to the function .init.text:.iowa_register_bus()
WARNING: arch/powerpc/platforms/cell/built-in.o(.devinit.text+0xa4): Section mismatch in reference from the function .cell_setup_phb() to the function .init.text:.io_workaround_init()

Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
---
 arch/powerpc/platforms/cell/io-workarounds.c |    6 +++---
 arch/powerpc/platforms/cell/io-workarounds.h |    6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/cell/io-workarounds.c b/arch/powerpc/platforms/cell/io-workarounds.c
index 3b84e8b..b5f84e8 100644
--- a/arch/powerpc/platforms/cell/io-workarounds.c
+++ b/arch/powerpc/platforms/cell/io-workarounds.c
@@ -118,7 +118,7 @@ static void iowa_##name at					\
 #undef DEF_PCI_AC_RET
 #undef DEF_PCI_AC_NORET
 
-static struct ppc_pci_io __initdata iowa_pci_io = {
+static const struct ppc_pci_io __devinitconst iowa_pci_io = {
 
 #define DEF_PCI_AC_RET(name, ret, at, al, space, aa)	.name = iowa_##name,
 #define DEF_PCI_AC_NORET(name, at, al, space, aa)	.name = iowa_##name,
@@ -146,7 +146,7 @@ static void __iomem *iowa_ioremap(unsigned long addr, unsigned long size,
 }
 
 /* Regist new bus to support workaround */
-void __init iowa_register_bus(struct pci_controller *phb,
+void __devinit iowa_register_bus(struct pci_controller *phb,
 			struct ppc_pci_io *ops,
 			int (*initfunc)(struct iowa_bus *, void *), void *data)
 {
@@ -173,7 +173,7 @@ void __init iowa_register_bus(struct pci_controller *phb,
 }
 
 /* enable IO workaround */
-void __init io_workaround_init(void)
+void __devinit io_workaround_init(void)
 {
 	static int io_workaround_inited;
 
diff --git a/arch/powerpc/platforms/cell/io-workarounds.h b/arch/powerpc/platforms/cell/io-workarounds.h
index 79d8ed3..6efc778 100644
--- a/arch/powerpc/platforms/cell/io-workarounds.h
+++ b/arch/powerpc/platforms/cell/io-workarounds.h
@@ -31,9 +31,9 @@ struct iowa_bus {
 	void   *private;
 };
 
-void __init io_workaround_init(void);
-void __init iowa_register_bus(struct pci_controller *, struct ppc_pci_io *,
-			      int (*)(struct iowa_bus *, void *), void *);
+void __devinit io_workaround_init(void);
+void __devinit iowa_register_bus(struct pci_controller *, struct ppc_pci_io *,
+				 int (*)(struct iowa_bus *, void *), void *);
 struct iowa_bus *iowa_mem_find_bus(const PCI_IO_ADDR);
 struct iowa_bus *iowa_pio_find_bus(unsigned long);
 
-- 
1.5.4.1

^ permalink raw reply related

* How to test the DDR memory with burst visit mode?
From: 郭劲 @ 2008-05-14 11:25 UTC (permalink / raw)
  To: linuxppc-embedded

Hi,friends,
   I designed my MPC8360E board with 1GBytes DDR-1 memory, I built two demo
boards, one is 533/266/400, the other is 660/330/400. The lower frequancy board is
no problem for our program, but the higher frequency board is always problem about
the data transmit on ethernet. 
   I want to test 1GBytes DDR-1 memory, I want to know whether or not the DDR is
stable and accuracy. Could you tell me a simple way that test my DDR memory? 

^ permalink raw reply

* RE: [PATCH] Defer processing of interrupts when the CPU wakes from sleepmode
From: Liu Dave @ 2008-05-14 12:03 UTC (permalink / raw)
  To: Paul Mackerras, linuxppc-dev
In-Reply-To: <18474.27384.524310.787499@cargo.ozlabs.ibm.com>

<snip>

> This provides a way to defer processing of an interrupt that wakes the
> processor out of sleep mode.  On 32-bit platforms that use an
> interrupt to wake the processor, we have to have interrupts enabled in
> hardware at the point where we go to sleep, otherwise the processor
> will never wake up.  However, because interrupts are logically
> disabled at this point, we don't want to process the interrupt
> straight away.
>=20
> This is handled by setting the _TLF_SLEEPING flag.  When we get an
> interrupt and _TLF_SLEEPING is set, we firstly clear the MSR_EE
> (external interrupt enable) bit in the saved MSR value, and secondly
> we then return to the address in the link register, like we do for
> _TLF_NAPPING, but without actually handling the interrupt.
>=20
> Note that this is handled somewhat differently on powerbooks, so this
> new code will only be used on non-Apple machines.

Thanks Paul for this patch. The patch looks like very nice.
But the users have to be aware of the LINK register (LR) not corrupted.

So, does power management patch from Scott Wood need to respin?

BTW, why the fast_exception_return does *not* need clear the reservation
with stwcx.?

Thanks,
Dave

^ permalink raw reply

* Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Anton Vorontsov @ 2008-05-14 12:25 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Scott Wood, linuxppc-dev, Wim Van Sebroeck, Timur Tabi
In-Reply-To: <20080514114805.61e1d50f.sfr@canb.auug.org.au>

On Wed, May 14, 2008 at 11:48:05AM +1000, Stephen Rothwell wrote:
> Hi Anton,
> 
> On Wed, 14 May 2008 11:45:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Doing this status with "git diff -M --stat" would show us if the file was
> > just renamed or if there were some changes as well ...
> 
> Not that I don't trust you, just for future reference.

I use git-format-patch. And -M option would generate the whole
patch in the "git patch format", which you can not apply with patch(1)
(I also recalling that there was someone protesting wrt sending the
patches in the git patch format, since not everybody use git).

Though, you can still check me if you want to, git generates useful
headers in the patch itself:

diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
deleted file mode 100644
index 3534ae0..0000000
....
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
new file mode 100644
index 0000000..3534ae0

The index stuff are hashes. They match. ;-)

But sure, it would be great if git-format-patch could generate
diffstat in the git format and leave the patch itself patch(1)-compatible.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

^ permalink raw reply

* ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)
From: Takashi Iwai @ 2008-05-14 12:26 UTC (permalink / raw)
  To: Gerhard Pircher; +Cc: alsa-devel, cjg, linuxppc-dev
In-Reply-To: <20080506091622.269180@gmx.net>

At Tue, 06 May 2008 11:16:22 +0200,
Gerhard Pircher wrote:
> 
> -------- Original-Nachricht --------
> > Datum: Tue, 06 May 2008 18:48:39 +1000
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org, Takashi Iwai <tiwai@suse.de>, cjg@cruxppc.org, galak@kernel.crashing.org
> > Betreff: Re: [PATCH] Sam440ep support
> 
> > 
> > On Tue, 2008-05-06 at 09:51 +0200, Gerhard Pircher wrote:
> > > Takashi Iwai posted a preliminary patch a long time ago. I tested it
> > > on my machine and it failed with non coherent scatter-gather DMA
> > > allocations (I guess almost all ALSA PCI drivers use SG DMA?).
> > 
> > How does Alsa allocate such SG ?
> I can't answer this question. *ducked* :-) Takashi?
> 
> FYI: I posted the results of the test with Takashi's dma_mmap_coherent
> patch here:
> http://ozlabs.org/pipermail/linuxppc-dev/2006-June/024078.html
> 
> On the other side it looks like this problem does not only affect ALSA.
> As far as I can tell also some V4L(2) drivers have a problem with mmaping
> non coherent DMA allocations, but I'm not sure (it's a long time since I
> did some tests with video cards on my AmigaOne).
> 
> Naturally I can do some tests, if you or Takashi come up with a new
> patch.

OK, here is another patch for testing.  Since I lost my old patch
somewhere (and it's not worth to dig the archive), I wrote it up
quickly from scratch.  This version should cover both SG and non-SG
buffers.  It's against the latest git tree.

The patch adds a hackish verison of dma_mmap_coherent() for some
architectures in sound/core/pcm_native.c.  I'm not sure whether this
works.  I just tested it on X86.  It'd be appreciated if someone can
test this.

Also, this disables HDSPM driver for non-X86/IA64 since the driver has
own copy and silence methods that are incompatible with the new
SG-buffer data.


And, yes, I know we need to clean up huge messes in ALSA memory
handling routines.  But, let's fix obvious bugs before starting a big
rewrite...


thanks,

Takashi

---

diff --git a/include/sound/memalloc.h b/include/sound/memalloc.h
index ae2921d..ccf3dfa 100644
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -62,6 +62,18 @@ struct snd_dma_buffer {
 	void *private_data;	/* private for allocator; don't touch */
 };
 
+/* needs to use dma_mmap_coherent() for pages allocated via
+ * dma_alloc_coherent()
+ */
+#ifdef CONFIG_HAS_DMA
+#if (defined(CONFIG_PPC32) && !defined(CONFIG_CONFIG_NOT_COHERENT_CACHE)) || \
+	defined(CONFIG_ARM) || \
+	defined(CONFIG_MIPS) || \
+	defined(CONFIG_PARISC)
+#define SND_NEEDS_DMA_MMAP_COHERENT
+#endif /* archs */
+#endif /* CONFIG_HAS_DMA */
+
 /*
  * Scatter-Gather generic device pages
  */
@@ -75,7 +87,9 @@ struct snd_sg_buf {
 	int pages;	/* allocated pages */
 	int tblsize;	/* allocated table size */
 	struct snd_sg_page *table;	/* address table */
+#ifndef SND_NEEDS_DMA_MMAP_COHERENT
 	struct page **page_table;	/* page table (for vmap/vunmap) */
+#endif
 	struct device *dev;
 };
 
diff --git a/include/sound/pcm.h b/include/sound/pcm.h
index 51d58cc..2e68420 100644
--- a/include/sound/pcm.h
+++ b/include/sound/pcm.h
@@ -969,10 +969,25 @@ int snd_pcm_lib_preallocate_pages_for_all(struct snd_pcm *pcm,
 int snd_pcm_lib_malloc_pages(struct snd_pcm_substream *substream, size_t size);
 int snd_pcm_lib_free_pages(struct snd_pcm_substream *substream);
 
+/*
+ * SG-buffer
+ */
 #define snd_pcm_substream_sgbuf(substream) ((substream)->runtime->dma_buffer_p->private_data)
 #define snd_pcm_sgbuf_pages(size) snd_sgbuf_aligned_pages(size)
 #define snd_pcm_sgbuf_get_addr(sgbuf,ofs) snd_sgbuf_get_addr(sgbuf,ofs)
+
+#ifdef SND_NEEDS_DMA_MMAP_COHERENT
+int snd_pcm_sgbuf_ops_copy(struct snd_pcm_substream *substream,
+			   int channel, snd_pcm_uframes_t pos,
+			   void __user *buf, snd_pcm_uframes_t count);
+int snd_pcm_sgbuf_ops_silence(struct snd_pcm_substream *substream, int channel, 
+			      snd_pcm_uframes_t pos, snd_pcm_uframes_t count);
+#define snd_pcm_sgbuf_ops_page		NULL
+#else
+#define snd_pcm_sgbuf_ops_copy		NULL
+#define snd_pcm_sgbuf_ops_silence	NULL
 struct page *snd_pcm_sgbuf_ops_page(struct snd_pcm_substream *substream, unsigned long offset);
+#endif
 
 /* handle mmap counter - PCM mmap callback should handle this counter properly */
 static inline void snd_pcm_mmap_data_open(struct vm_area_struct *area)
diff --git a/sound/core/pcm_memory.c b/sound/core/pcm_memory.c
index ff07b4a..9e57032 100644
--- a/sound/core/pcm_memory.c
+++ b/sound/core/pcm_memory.c
@@ -306,6 +306,126 @@ int snd_pcm_lib_preallocate_pages_for_all(struct snd_pcm *pcm,
 
 EXPORT_SYMBOL(snd_pcm_lib_preallocate_pages_for_all);
 
+#ifdef SND_NEEDS_DMA_MMAP_COHERENT
+/*
+ * snd_pcm_sgbuf_ops_copy - copy callback for DMA SG-buffer
+ */
+int snd_pcm_sgbuf_ops_copy(struct snd_pcm_substream *substream,
+			   int channel, snd_pcm_uframes_t pos,
+			   void __user *buf, snd_pcm_uframes_t count)
+{
+	struct snd_sg_buf *sgbuf = snd_pcm_substream_sgbuf(substream);
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	unsigned int ofs, idx;
+	char *ptr;
+
+	if (channel < 0) {
+		pos = frames_to_bytes(runtime, pos);
+		count = frames_to_bytes(runtime, count);
+	} else {
+		pos = channel * (runtime->dma_bytes / runtime->channels) +
+			samples_to_bytes(runtime, pos);
+		count = samples_to_bytes(runtime, count);
+	}
+
+	idx = pos >> PAGE_SHIFT;
+	ofs = pos & (PAGE_SIZE - 1);
+	ptr = sgbuf->table[idx].buf + ofs;
+
+	for (;;) {
+		unsigned int size, ret;
+		size = count;
+		if (ofs + size > PAGE_SIZE)
+			size = PAGE_SIZE - ofs;
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			ret = copy_from_user(ptr, buf, size);
+		else
+			ret = copy_to_user(buf, ptr, size);
+		if (ret)
+			return -EFAULT;
+		count -= size;
+		if (!count)
+			return 0;
+		ofs = 0;
+		idx++;
+		ptr = sgbuf->table[idx].buf;
+		buf += size;
+	}
+}
+EXPORT_SYMBOL(snd_pcm_sgbuf_ops_copy);
+
+/*
+ * snd_pcm_sgbuf_ops_silence - fill with silence data
+ */
+int snd_pcm_sgbuf_ops_silence(struct snd_pcm_substream *substream, int channel, 
+			      snd_pcm_uframes_t pos, snd_pcm_uframes_t count)
+{
+	struct snd_sg_buf *sgbuf = snd_pcm_substream_sgbuf(substream);
+	struct snd_pcm_runtime *runtime = substream->runtime;
+	unsigned int idx, ofs, width;
+	const char *silence;
+	char *ptr;
+
+	if (channel < 0) {
+		pos = frames_to_bytes(runtime, pos);
+		count = frames_to_bytes(runtime, count);
+	} else {
+		pos = channel * (runtime->dma_bytes / runtime->channels) +
+			samples_to_bytes(runtime, pos);
+		count = samples_to_bytes(runtime, count);
+	}
+
+	idx = pos >> PAGE_SHIFT;
+	if (idx >= (unsigned int)sgbuf->pages)
+		return -EFAULT;
+	ofs = pos & (PAGE_SIZE - 1);
+	ptr = sgbuf->table[idx].buf + ofs;
+
+	width = snd_pcm_format_physical_width(runtime->format);
+	if (width < 8) {
+		count /= 2;
+		width = 8;
+	}
+	width /= 8;
+	silence = snd_pcm_format_silence_64(runtime->format);
+
+	if (PAGE_SIZE % width) {
+		unsigned int pat = 0;
+		for (;;) {
+			*ptr = silence[pat];
+			pat = (pat + 1) % width;
+			count--;
+			if (!count)
+				return 0;
+			ofs++;
+			if (ofs == PAGE_SIZE) {
+				ofs = 0;
+				idx++;
+				ptr = sgbuf->table[idx].buf;
+			} else
+				ptr++;
+		}
+	} else {
+		for (;;) {
+			unsigned int size, samples;
+			size = count;
+			if (ofs + size > PAGE_SIZE)
+				size = PAGE_SIZE - ofs;
+			samples = bytes_to_samples(runtime, size);
+			snd_pcm_format_set_silence(runtime->format, ptr,
+						   samples);
+			count -= size;
+			if (!count)
+				return 0;
+			ofs = 0;
+			idx++;
+			ptr = sgbuf->table[idx].buf;
+		}
+	}
+}
+EXPORT_SYMBOL(snd_pcm_sgbuf_ops_silence);
+
+#else /* !SND_NEEDS_DMA_MMAP_COHERENT */
 /**
  * snd_pcm_sgbuf_ops_page - get the page struct at the given offset
  * @substream: the pcm substream instance
@@ -323,9 +443,10 @@ struct page *snd_pcm_sgbuf_ops_page(struct snd_pcm_substream *substream, unsigne
 		return NULL;
 	return sgbuf->page_table[idx];
 }
-
 EXPORT_SYMBOL(snd_pcm_sgbuf_ops_page);
 
+#endif /* SND_NEEDS_DMA_MMAP_COHERENT */
+
 /**
  * snd_pcm_lib_malloc_pages - allocate the DMA buffer
  * @substream: the substream to allocate the DMA buffer to
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 61f5d42..e3f68d2 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3124,19 +3124,96 @@ static struct vm_operations_struct snd_pcm_vm_ops_data =
 {
 	.open =		snd_pcm_mmap_data_open,
 	.close =	snd_pcm_mmap_data_close,
+};
+
+static struct vm_operations_struct snd_pcm_vm_ops_data_fault =
+{
+	.open =		snd_pcm_mmap_data_open,
+	.close =	snd_pcm_mmap_data_close,
 	.fault =	snd_pcm_mmap_data_fault,
 };
 
+#ifdef SND_NEEDS_DMA_MMAP_COHERENT
+
+/*
+ * FIXME!!
+ * dma_mmap_coherent is missing on most architectures...
+ */
+#ifndef CONFIG_ARM
+static int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
+			     void *cpu_addr, dma_addr_t handle, size_t size)
+{
+#if defined(CONFIG_PPC32) && !defined(CONFIG_CONFIG_NOT_COHERENT_CACHE)
+	cpu_addr = bus_to_virt(handle);
+#elif defined(CONFIG_MIPS)
+	cpu_addr = phys_to_virt(plat_dma_addr_to_phys(handle));
+#elif defined(CONFIG_PARISC)
+	cpu_addr = __va(handle);
+#endif
+	return remap_pfn_range(vma, vma->vm_start,
+			       page_to_pfn(virt_to_page(cpu_addr)),
+			       size, vma->vm_page_prot);
+}
+#endif /* !ARM */
+
+/*
+ * snd_pcm_sgbuf_ops_mmap - mmap SG DMA pages
+ */
+static int snd_pcm_mmap_sgbuf(struct snd_pcm_substream *substream,
+			      struct vm_area_struct *area)
+{
+	struct snd_sg_buf *sgbuf = snd_pcm_substream_sgbuf(substream);
+	unsigned long start, offset, offset_saved, size;
+	int err = 0;
+
+	start = area->vm_start;
+	offset_saved = offset = area->vm_pgoff;
+	size = area->vm_end - area->vm_start;
+	size = PAGE_ALIGN(size);
+	while (size > 0) {
+		if (offset >= sgbuf->pages) {
+			err = -EFAULT;
+			break;
+		}
+		err = dma_mmap_coherent(sgbuf->dev, area,
+					sgbuf->table[offset].buf,
+					sgbuf->table[offset].addr,
+					PAGE_SIZE);
+		if (err < 0)
+			break;
+		offset++;
+		area->vm_start += PAGE_SIZE;
+		size -= PAGE_SIZE;
+	}
+	area->vm_start = start;
+	area->vm_pgoff = offset_saved;
+	return err;
+}
+#endif /* SND_NEEDS_DMA_MMAP_COHERENT */
+
 /*
  * mmap the DMA buffer on RAM
  */
 static int snd_pcm_default_mmap(struct snd_pcm_substream *substream,
 				struct vm_area_struct *area)
 {
-	area->vm_ops = &snd_pcm_vm_ops_data;
-	area->vm_private_data = substream;
 	area->vm_flags |= VM_RESERVED;
-	atomic_inc(&substream->mmap_count);
+#ifdef SND_NEEDS_DMA_MMAP_COHERENT
+	if (!substream->ops->page) {
+		switch (substream->dma_buffer.dev.type) {
+		case SNDRV_DMA_TYPE_DEV:
+			return dma_mmap_coherent(substream->dma_buffer.dev.dev,
+						 area,
+						 substream->runtime->dma_area,
+						 substream->runtime->dma_addr,
+						 area->vm_end - area->vm_start);
+		case SNDRV_DMA_TYPE_DEV_SG:
+			return snd_pcm_mmap_sgbuf(substream, area);
+		}
+	}
+#endif /* SND_NEEDS_DMA_MMAP_COHERENT */
+	/* mmap with fault handler */
+	area->vm_ops = &snd_pcm_vm_ops_data_fault;
 	return 0;
 }
 
@@ -3144,12 +3221,6 @@ static int snd_pcm_default_mmap(struct snd_pcm_substream *substream,
  * mmap the DMA buffer on I/O memory area
  */
 #if SNDRV_PCM_INFO_MMAP_IOMEM
-static struct vm_operations_struct snd_pcm_vm_ops_data_mmio =
-{
-	.open =		snd_pcm_mmap_data_open,
-	.close =	snd_pcm_mmap_data_close,
-};
-
 int snd_pcm_lib_mmap_iomem(struct snd_pcm_substream *substream,
 			   struct vm_area_struct *area)
 {
@@ -3159,8 +3230,6 @@ int snd_pcm_lib_mmap_iomem(struct snd_pcm_substream *substream,
 #ifdef pgprot_noncached
 	area->vm_page_prot = pgprot_noncached(area->vm_page_prot);
 #endif
-	area->vm_ops = &snd_pcm_vm_ops_data_mmio;
-	area->vm_private_data = substream;
 	area->vm_flags |= VM_IO;
 	size = area->vm_end - area->vm_start;
 	offset = area->vm_pgoff << PAGE_SHIFT;
@@ -3168,7 +3237,6 @@ int snd_pcm_lib_mmap_iomem(struct snd_pcm_substream *substream,
 				(substream->runtime->dma_addr + offset) >> PAGE_SHIFT,
 				size, area->vm_page_prot))
 		return -EAGAIN;
-	atomic_inc(&substream->mmap_count);
 	return 0;
 }
 
@@ -3185,6 +3253,7 @@ int snd_pcm_mmap_data(struct snd_pcm_substream *substream, struct file *file,
 	long size;
 	unsigned long offset;
 	size_t dma_bytes;
+	int err;
 
 	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 		if (!(area->vm_flags & (VM_WRITE|VM_READ)))
@@ -3210,10 +3279,15 @@ int snd_pcm_mmap_data(struct snd_pcm_substream *substream, struct file *file,
 	if (offset > dma_bytes - size)
 		return -EINVAL;
 
+	area->vm_ops = &snd_pcm_vm_ops_data;
+	area->vm_private_data = substream;
 	if (substream->ops->mmap)
-		return substream->ops->mmap(substream, area);
+		err = substream->ops->mmap(substream, area);
 	else
-		return snd_pcm_default_mmap(substream, area);
+		err = snd_pcm_default_mmap(substream, area);
+	if (!err)
+		atomic_inc(&substream->mmap_count);
+	return err;
 }
 
 EXPORT_SYMBOL(snd_pcm_mmap_data);
diff --git a/sound/core/sgbuf.c b/sound/core/sgbuf.c
index cefd228..67c6631 100644
--- a/sound/core/sgbuf.c
+++ b/sound/core/sgbuf.c
@@ -46,12 +46,14 @@ int snd_free_sgbuf_pages(struct snd_dma_buffer *dmab)
 		tmpb.bytes = PAGE_SIZE;
 		snd_dma_free_pages(&tmpb);
 	}
+#ifndef SND_NEEDS_DMA_MMAP_COHERENT
 	if (dmab->area)
 		vunmap(dmab->area);
+	kfree(sgbuf->page_table);
+#endif
 	dmab->area = NULL;
 
 	kfree(sgbuf->table);
-	kfree(sgbuf->page_table);
 	kfree(sgbuf);
 	dmab->private_data = NULL;
 	
@@ -77,9 +79,11 @@ void *snd_malloc_sgbuf_pages(struct device *device,
 	sgbuf->table = kcalloc(sgbuf->tblsize, sizeof(*sgbuf->table), GFP_KERNEL);
 	if (! sgbuf->table)
 		goto _failed;
+#ifndef SND_NEEDS_DMA_MMAP_COHERENT
 	sgbuf->page_table = kcalloc(sgbuf->tblsize, sizeof(*sgbuf->page_table), GFP_KERNEL);
 	if (! sgbuf->page_table)
 		goto _failed;
+#endif
 
 	/* allocate each page */
 	for (i = 0; i < pages; i++) {
@@ -91,14 +95,20 @@ void *snd_malloc_sgbuf_pages(struct device *device,
 		}
 		sgbuf->table[i].buf = tmpb.area;
 		sgbuf->table[i].addr = tmpb.addr;
+#ifndef SND_NEEDS_DMA_MMAP_COHERENT
 		sgbuf->page_table[i] = virt_to_page(tmpb.area);
+#endif
 		sgbuf->pages++;
 	}
 
 	sgbuf->size = size;
+#ifndef SND_NEEDS_DMA_MMAP_COHERENT
 	dmab->area = vmap(sgbuf->page_table, sgbuf->pages, VM_MAP, PAGE_KERNEL);
 	if (! dmab->area)
 		goto _failed;
+#else
+	dmab->area = sgbuf->table[0].buf;
+#endif
 	return dmab->area;
 
  _failed:
diff --git a/sound/pci/Kconfig b/sound/pci/Kconfig
index 7e47421..09af3f5 100644
--- a/sound/pci/Kconfig
+++ b/sound/pci/Kconfig
@@ -651,6 +651,7 @@ config SND_HDSP
 config SND_HDSPM
 	tristate "RME Hammerfall DSP MADI"
 	depends on SND
+	depends on X86 || ALPHA || IA64
 	select SND_HWDEP
 	select SND_RAWMIDI
 	select SND_PCM
diff --git a/sound/pci/au88x0/au88x0_pcm.c b/sound/pci/au88x0/au88x0_pcm.c
index f9a58b4..222e599 100644
--- a/sound/pci/au88x0/au88x0_pcm.c
+++ b/sound/pci/au88x0/au88x0_pcm.c
@@ -409,6 +409,8 @@ static struct snd_pcm_ops snd_vortex_playback_ops = {
 	.prepare = snd_vortex_pcm_prepare,
 	.trigger = snd_vortex_pcm_trigger,
 	.pointer = snd_vortex_pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
+	.silence = snd_pcm_sgbuf_ops_silence,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/bt87x.c b/sound/pci/bt87x.c
index 4ecdd63..49b8ebc 100644
--- a/sound/pci/bt87x.c
+++ b/sound/pci/bt87x.c
@@ -548,6 +548,7 @@ static struct snd_pcm_ops snd_bt87x_pcm_ops = {
 	.prepare = snd_bt87x_prepare,
 	.trigger = snd_bt87x_trigger,
 	.pointer = snd_bt87x_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/echoaudio/echoaudio.c b/sound/pci/echoaudio/echoaudio.c
index e16dc92..e2c3f3d 100644
--- a/sound/pci/echoaudio/echoaudio.c
+++ b/sound/pci/echoaudio/echoaudio.c
@@ -801,6 +801,8 @@ static struct snd_pcm_ops analog_playback_ops = {
 	.prepare = pcm_prepare,
 	.trigger = pcm_trigger,
 	.pointer = pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
+	.silence = snd_pcm_sgbuf_ops_silence,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 static struct snd_pcm_ops analog_capture_ops = {
@@ -812,6 +814,7 @@ static struct snd_pcm_ops analog_capture_ops = {
 	.prepare = pcm_prepare,
 	.trigger = pcm_trigger,
 	.pointer = pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 #ifdef ECHOCARD_HAS_DIGITAL_IO
@@ -825,6 +828,8 @@ static struct snd_pcm_ops digital_playback_ops = {
 	.prepare = pcm_prepare,
 	.trigger = pcm_trigger,
 	.pointer = pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
+	.silence = snd_pcm_sgbuf_ops_silence,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 #endif /* !ECHOCARD_HAS_VMIXER */
@@ -837,6 +842,7 @@ static struct snd_pcm_ops digital_capture_ops = {
 	.prepare = pcm_prepare,
 	.trigger = pcm_trigger,
 	.pointer = pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 #endif /* ECHOCARD_HAS_DIGITAL_IO */
diff --git a/sound/pci/emu10k1/emupcm.c b/sound/pci/emu10k1/emupcm.c
index cf9276d..2d72959 100644
--- a/sound/pci/emu10k1/emupcm.c
+++ b/sound/pci/emu10k1/emupcm.c
@@ -1323,6 +1323,8 @@ static struct snd_pcm_ops snd_emu10k1_playback_ops = {
 	.prepare =		snd_emu10k1_playback_prepare,
 	.trigger =		snd_emu10k1_playback_trigger,
 	.pointer =		snd_emu10k1_playback_pointer,
+	.copy =			snd_pcm_sgbuf_ops_copy,
+	.silence =		snd_pcm_sgbuf_ops_silence,
 	.page =			snd_pcm_sgbuf_ops_page,
 };
 
@@ -1347,6 +1349,8 @@ static struct snd_pcm_ops snd_emu10k1_efx_playback_ops = {
 	.prepare =		snd_emu10k1_efx_playback_prepare,
 	.trigger =		snd_emu10k1_efx_playback_trigger,
 	.pointer =		snd_emu10k1_efx_playback_pointer,
+	.copy =			snd_pcm_sgbuf_ops_copy,
+	.silence =		snd_pcm_sgbuf_ops_silence,
 	.page =			snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index b3a618e..e5ac9e1 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1461,6 +1461,8 @@ static struct snd_pcm_ops azx_pcm_ops = {
 	.prepare = azx_pcm_prepare,
 	.trigger = azx_pcm_trigger,
 	.pointer = azx_pcm_pointer,
+	.copy = snd_pcm_sgbuf_ops_copy,
+	.silence = snd_pcm_sgbuf_ops_silence,
 	.page = snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/riptide/riptide.c b/sound/pci/riptide/riptide.c
index 979f7da..7fcb3d7 100644
--- a/sound/pci/riptide/riptide.c
+++ b/sound/pci/riptide/riptide.c
@@ -1696,6 +1696,8 @@ static struct snd_pcm_ops snd_riptide_playback_ops = {
 	.hw_params = snd_riptide_hw_params,
 	.hw_free = snd_riptide_hw_free,
 	.prepare = snd_riptide_prepare,
+	.copy = snd_pcm_sgbuf_ops_copy,
+	.silence = snd_pcm_sgbuf_ops_silence,
 	.page = snd_pcm_sgbuf_ops_page,
 	.trigger = snd_riptide_trigger,
 	.pointer = snd_riptide_pointer,
@@ -1707,6 +1709,7 @@ static struct snd_pcm_ops snd_riptide_capture_ops = {
 	.hw_params = snd_riptide_hw_params,
 	.hw_free = snd_riptide_hw_free,
 	.prepare = snd_riptide_prepare,
+	.copy = snd_pcm_sgbuf_ops_copy,
 	.page = snd_pcm_sgbuf_ops_page,
 	.trigger = snd_riptide_trigger,
 	.pointer = snd_riptide_pointer,
diff --git a/sound/pci/trident/trident_main.c b/sound/pci/trident/trident_main.c
index bbcee2c..156e457 100644
--- a/sound/pci/trident/trident_main.c
+++ b/sound/pci/trident/trident_main.c
@@ -2081,6 +2081,8 @@ static struct snd_pcm_ops snd_trident_nx_playback_ops = {
 	.prepare =	snd_trident_playback_prepare,
 	.trigger =	snd_trident_trigger,
 	.pointer =	snd_trident_playback_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -2126,6 +2128,8 @@ static struct snd_pcm_ops snd_trident_nx_foldback_ops = {
 	.prepare =	snd_trident_foldback_prepare,
 	.trigger =	snd_trident_trigger,
 	.pointer =	snd_trident_playback_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c
index b585cc3..4a9f132 100644
--- a/sound/pci/via82xx.c
+++ b/sound/pci/via82xx.c
@@ -1304,6 +1304,8 @@ static struct snd_pcm_ops snd_via686_playback_ops = {
 	.prepare =	snd_via686_playback_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via686_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -1317,6 +1319,7 @@ static struct snd_pcm_ops snd_via686_capture_ops = {
 	.prepare =	snd_via686_capture_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via686_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -1330,6 +1333,8 @@ static struct snd_pcm_ops snd_via8233_playback_ops = {
 	.prepare =	snd_via8233_playback_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via8233_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -1343,6 +1348,8 @@ static struct snd_pcm_ops snd_via8233_multi_ops = {
 	.prepare =	snd_via8233_multi_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via8233_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -1356,6 +1363,7 @@ static struct snd_pcm_ops snd_via8233_capture_ops = {
 	.prepare =	snd_via8233_capture_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via8233_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
diff --git a/sound/pci/via82xx_modem.c b/sound/pci/via82xx_modem.c
index 31f64ee..1431b08 100644
--- a/sound/pci/via82xx_modem.c
+++ b/sound/pci/via82xx_modem.c
@@ -803,6 +803,8 @@ static struct snd_pcm_ops snd_via686_playback_ops = {
 	.prepare =	snd_via82xx_pcm_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via686_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
+	.silence =	snd_pcm_sgbuf_ops_silence,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 
@@ -816,6 +818,7 @@ static struct snd_pcm_ops snd_via686_capture_ops = {
 	.prepare =	snd_via82xx_pcm_prepare,
 	.trigger =	snd_via82xx_pcm_trigger,
 	.pointer =	snd_via686_pcm_pointer,
+	.copy =		snd_pcm_sgbuf_ops_copy,
 	.page =		snd_pcm_sgbuf_ops_page,
 };
 

^ permalink raw reply related

* Badness seen on 2.6.26-rc2 with lockdep enabled
From: Balbir Singh @ 2008-05-14 12:45 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: linux kernel mailing list, Paul Mackerras

I see the following error on my power box at boot up.

RTAS: event: 14, Type: Platform Error, Severity: 2
------------[ cut here ]------------
Badness at kernel/lockdep.c:2680
NIP: c0000000000ae538 LR: c0000000000ae51c CTR: 0000000000000000
REGS: c0000000e7b139a0 TRAP: 0700   Not tainted  (2.6.26-rc2-mm1)
MSR: 8000000000029032 <EE,ME,IR,DR>  CR: 24000042  XER: 20000000
TASK = c0000000e7644620[411] 'rtasd' THREAD: c0000000e7b10000 CPU: 1
GPR00: 0000000000000000 c0000000e7b13c20 c000000000a55ef0 0000000000000001
GPR04: 0000000000000001 c00000000004bfb8 2d37313000000000 2d37313031303438
GPR08: 3644442000000000 c000000000ea3018 0000000000000020 0000000000000001
GPR12: 3644442000000000 c000000000a94600 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 4000000001c00000 c00000000086f400
GPR20: 0000000000000000 0000000000000001 00000000000000e4 000000000246f400
GPR24: c000000000a9c498 0000000000000008 c00000000004bfb8 c00000000087a5d8
GPR28: c00000000092cd48 0000000000000001 c0000000009bb738 c0000000e7b13c20
NIP [c0000000000ae538] .check_flags+0x9c/0x174
LR [c0000000000ae51c] .check_flags+0x80/0x174
Call Trace:
[c0000000e7b13c20] [c00000000004bc70] .pSeries_log_error+0x5c/0x400 (unreliable)
[c0000000e7b13ca0] [c0000000000b35c0] .lock_release+0x80/0x204
[c0000000e7b13d50] [c0000000005cfcf8] ._spin_unlock_irqrestore+0x34/0x94
[c0000000e7b13de0] [c00000000004bfb8] .pSeries_log_error+0x3a4/0x400
[c0000000e7b13ef0] [c00000000004c218] .rtasd+0x98/0x100
[c0000000e7b13f90] [c00000000002848c] .kernel_thread+0x4c/0x68
Instruction dump:
e92d01b0 8009085c 2f800000 40be002c 481f1b9d 60000000 2fa30000 419e00c4
e93e80f8 80090000 2f800000 409e00b4 <0fe00000> 480000ac 78290464 80090014
possible reason: unannotated irqs-on.
irq event stamp: 30
hardirqs last  enabled at (29): [<c0000000000b1d98>] .trace_hardirqs_on+0x1c/0x3
0
hardirqs last disabled at (30): [<c0000000000aebac>] .trace_hardirqs_off+0x1c/0x
30
softirqs last  enabled at (28): [<c00000000008bd08>] .__do_softirq+0x180/0x1a8
softirqs last disabled at (21): [<c000000000028124>] .call_do_softirq+0x14/0x24


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL

^ permalink raw reply

* Re: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)
From: Gerhard Pircher @ 2008-05-14 12:50 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel, cjg
In-Reply-To: <s5hr6c5ax6a.wl%tiwai@suse.de>


-------- Original-Nachricht --------
> Datum: Wed, 14 May 2008 14:26:53 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: benh@kernel.crashing.org, galak@kernel.crashing.org, cjg@cruxppc.org, linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org
> Betreff: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)

> At Tue, 06 May 2008 11:16:22 +0200,
> Gerhard Pircher wrote:
> > 
> > Naturally I can do some tests, if you or Takashi come up with a new
> > patch.
> 
> OK, here is another patch for testing.  Since I lost my old patch
> somewhere (and it's not worth to dig the archive), I wrote it up
> quickly from scratch.  This version should cover both SG and non-SG
> buffers.  It's against the latest git tree.
Thanks a lot! I'll test it tonight, if I can get the lastest kernel
version running on my A1 (2.6.26-rc1 oopsed already on startup and
Kumar's fixmap patch for highmem seems to break dma-noncoherent.c).

regards,

Gerhard

-- 
249 Spiele für nur 1 Preis. Die GMX Spieleflatrate schon ab 9,90 Euro.
Neu: Asterix bei den Olympischen Spielen: http://flat.games.gmx.de

^ permalink raw reply

* [PATCH 1/1] ehea: Fix use after free on reboot
From: Brian King @ 2008-05-14 14:48 UTC (permalink / raw)
  To: jeff; +Cc: tklein, hering2, netdev, linuxppc-dev, raisch, brking


Fixes the following use after free oops:

ehea: Reboot: freeing all eHEA resources
Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6c5b
Faulting instruction address: 0xd000000000354488
cpu 0x0: Vector: 300 (Data Access) at [c00000002ec6f310]
    pc: d000000000354488: .ehea_shutdown_single_port+0x50/0x78 [ehea]
    lr: d00000000035447c: .ehea_shutdown_single_port+0x44/0x78 [ehea]
    sp: c00000002ec6f590
   msr: 8000000000009032
   dar: 6b6b6b6b6b6b6c5b
 dsisr: 40000000
  current = 0xc0000000281412e0
  paca    = 0xc0000000006df300
    pid   = 10930, comm = reboot
enter ? for help
[c00000002ec6f590] d00000000035d64c .ehea_remove+0x44/0x124 [ehea] (unreliable)
[c00000002ec6f630] c000000000319f88 .of_platform_device_remove+0x40/0x58
[c00000002ec6f6a0] c000000000291018 .__device_release_driver+0xb0/0xf0
[c00000002ec6f730] c000000000291120 .driver_detach+0xc8/0xfc
[c00000002ec6f7c0] c00000000028fe24 .bus_remove_driver+0xb4/0x114
[c00000002ec6f850] c000000000291768 .driver_unregister+0x54/0x74
[c00000002ec6f8e0] c00000000031a0c8 .of_unregister_driver+0x14/0x28
[c00000002ec6f950] c000000000023ba0 .ibmebus_unregister_driver+0x10/0x24
[c00000002ec6f9c0] d000000000354180 .ehea_reboot_notifier+0x30/0x4c [ehea]
[c00000002ec6fa40] c0000000003c95a8 .notifier_call_chain+0x5c/0xcc
[c00000002ec6fae0] c000000000082cd4 .__blocking_notifier_call_chain+0x70/0xb0
[c00000002ec6fb90] c000000000075cf8 .kernel_restart_prepare+0x24/0x58
[c00000002ec6fc10] c000000000075f0c .kernel_restart+0x20/0x6c
[c00000002ec6fc90] c000000000078674 .sys_reboot+0x1d4/0x290
[c00000002ec6fe30] c0000000000086ac syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff63a40
SP (ffceea50) is in userspace

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---

 linux-2.6-bjking1/drivers/net/ehea/ehea_main.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff -puN drivers/net/ehea/ehea_main.c~ehea_useafter_free_fix drivers/net/ehea/ehea_main.c
--- linux-2.6/drivers/net/ehea/ehea_main.c~ehea_useafter_free_fix	2008-05-14 09:38:10.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ehea/ehea_main.c	2008-05-14 09:38:10.000000000 -0500
@@ -3177,11 +3177,12 @@ out_err:
 
 static void ehea_shutdown_single_port(struct ehea_port *port)
 {
+	struct ehea_adapter *adapter = port->adapter;
 	unregister_netdev(port->netdev);
 	ehea_unregister_port(port);
 	kfree(port->mc_list);
 	free_netdev(port->netdev);
-	port->adapter->active_ports--;
+	adapter->active_ports--;
 }
 
 static int ehea_setup_ports(struct ehea_adapter *adapter)
_

^ permalink raw reply

* Re: 8xx: Work around CPU15 erratum.
From: Ben Gardiner @ 2008-05-14 14:52 UTC (permalink / raw)
  To: linuxppc-embedded

Hello,

This is my first post to the linuxppc-embedded list. Please forgive me 
for jumping in late onto the CPU15 workaround discussions, but my 
company is very interested in finding an efficient fix for this silicon 
errata on our devices.

I applied the patch submitted by Scott Wood to our patched denx 2.4.24 
tree and did some timing measurements to compare its effect on 
performance. We noted a worst case 37% slowdown -- this was during 
program load, where the PC is moving all over the place, so the penalty 
for all the tlbie's is felt heavily. This is solely anecdotal, I don't 
mean to imply that this fix will result in any particular slowdown on 
anyone else's systems.

I would like to start a discussion on the possibility of implementing a 
selective invalidation of pages on i-tlb miss. On July 20th, 2007 Scott 
Wood wrote:
 >The only lower-overhead workaround I know of requires compiler 
modifications (and I made it configurable to allow for that possibility).

So there likely are reasons why the following is not possible:
In the errata document from Freescale 
(http://www.freescale.com/files/32bit/doc/errata/MPC860CE.pdf?fpsp=1), 
they list an alternative to the "invalidate previous and next page" itlb 
miss handler (see pg 57), where they use the SPS/SH/CI bits of a L2 page 
entry to indicate whether: 1) a page is unchecked, 2) it does not 
contain a bad branch, 3) it does contain a bad branch, or 4) it has a 
previous page with a bad branch. These bits are zeroed before being 
written to MI_RPN. In loose terms the itlb miss handle does the 
following: If the page is unchecked, they check the last instruction the 
current page or the previous page and write the status bits to the L2 
entry accordingly. If the page has been checked the status bits are used 
to selectively invalidate the next or previous page as needed.

Since MI_RPN is always written with bits 24,25,26 and 27 set; could we 
use bits 24, 25 and 26 in memory to indicate the 4 possible page states 
and perform selective page invalidation as demonstrated in their example 
listing?

Regards,
Ben Gardiner

Nanometrics Inc.
250 Herzberg Rd.
Kanata ON
K2K 2A1
Telephone 613 592 6776 ext 239

^ permalink raw reply

* Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Kumar Gala @ 2008-05-14 15:03 UTC (permalink / raw)
  To: Chen Gong
  Cc: Stephen Rothwell, linuxppc-dev, Wim Van Sebroeck, Wood Scott,
	Tabi Timur
In-Reply-To: <58A20A281BAF1047B4EAE68DE5C0BDC2F16798@zch01exm21.fsl.freescale.net>


On May 13, 2008, at 10:53 PM, Chen Gong wrote:

>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+b11801=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+b11801=freescale.com@ozlabs.org]
>> On Behalf Of Stephen Rothwell
>> Sent: 2008?5?14? 9:45
>> To: Anton Vorontsov
>> Cc: Wood Scott; linuxppc-dev@ozlabs.org; Wim Van Sebroeck; Tabi Timur
>> Subject: Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to  
>> mpc8xxx_wdt
>>
>> On Tue, 13 May 2008 18:14:59 +0400 Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>>>
>>> Rename the driver because now we support some MPC86xx processors.
> What I want to know is that what about watchdog for booke(85xx) ?

what about it, its still there in the tree (booke_wdt.c).  This driver  
is for a SoC level watchdog that exists on 8xx, 83xx and 8610.

- k

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox