* Re: [PATCH] make ams work with latest kernels
From: Johannes Berg @ 2006-05-27 20:06 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Linux Kernel list, linuxppc-dev list
In-Reply-To: <20060526173908.GA3357@ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
On Fri, 2006-05-26 at 17:39 +0000, Pavel Machek wrote:
> > This driver also provides an absolute input class device, allowing
> > the laptop to act as a pinball machine-esque joystick.
>
> Is it useful to have /sysfs interface when we already have same data
> available as joystick?
Might be useful if you need to turn off the "joystick" because X gets
confused with it. Other than that, no.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] make ams work with latest kernels
From: Pavel Machek @ 2006-05-26 17:39 UTC (permalink / raw)
To: Stelian Pop
Cc: Andrew Morton, linuxppc-dev list, Johannes Berg,
Linux Kernel list
In-Reply-To: <1148465069.6723.26.camel@localhost.localdomain>
Hi!
> From: Stelian Pop <stelian@popies.net>
>
> This driver provides support for the Apple Motion Sensor (ams),
> which provides an accelerometer and other misc. data.
> Some Apple PowerBooks (the series the PowerBook5,6 falls into,
> later ones have a slightly different one the driver doesn't handle)
> are supported. The accelerometer data is readable via sysfs.
>
> This driver also provides an absolute input class device, allowing
> the laptop to act as a pinball machine-esque joystick.
Is it useful to have /sysfs interface when we already have same data
available as joystick?
--
Thanks for all the (sleeping) penguins.
^ permalink raw reply
* please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-05-27 13:17 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
There are 3 commits there: an update to MAINTAINERS, a fix for the
"Maple" PPC970FX evaluation boards, and a fix for the Freescale
embedded 8272 processor that is apparently needed for the console to
work on those chips. These fixes won't affect any other platforms and
are safe to go in for 2.6.17 IMO.
Thanks,
Paul.
MAINTAINERS | 4 +--
arch/powerpc/kernel/prom_init.c | 48 +++++++++++++++++++++++++++++--
arch/ppc/platforms/mpc8272ads_setup.c | 10 +++---
arch/ppc/syslib/pq2_devices.c | 16 +++++-----
arch/ppc/syslib/pq2_sys.c | 8 +++--
drivers/serial/cpm_uart/cpm_uart_core.c | 8 +++--
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +
7 files changed, 70 insertions(+), 26 deletions(-)
commit 54f4ee183aea859eb09f141dad3fc3c6f4fe0446
Author: Hollis Blanchard <hollisb@us.ibm.com>
Date: Thu May 25 16:36:53 2006 -0500
[PATCH] powerpc: fix RTC/NVRAM accesses on Maple
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>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 8e30a9a299ca30b6c4072c2182238d5f5dd1590d
Author: Vitaly Bordug <vbordug@ru.mvista.com>
Date: Wed May 24 21:40:18 2006 +0400
[PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 6d923f98fe0f31c174ace92f8b680d0d153663aa
Author: Arthur Othieno <apgo@patchbomb.org>
Date: Fri May 19 06:22:23 2006 -0400
[PATCH] powerpc: linuxppc64.org no more
http://linuxppc64.org has long been a redirect to the canonical
http://penguinppc.org/ppc64/ -- update all instances accordingly,
as ACKed by Hollis:
On Wed, Jan 18, 2006 at 09:48:08AM -0600, Hollis Blanchard wrote:
> On Wed, 2006-01-18 at 13:07 +0100, Olaf Hering wrote:
> > On Wed, Jan 18, Arthur Othieno wrote:
> > >
> > > What about the s/linuxppc64\.org/penguinppc\.org/g case? Or is
> > > penguinppc64.org preferable? Or am I just taking it too far? ;)
> >
> > They are redirected on DNS or HTTP level.
>
> HTTP level, but that doesn't answer his question.
>
> As the maintainer of that site, I would prefer to remove the
> linuxppc64.org reference.
Signed-off-by: Arthur Othieno <apgo@patchbomb.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH] force 64bit mode in system_reset_fwnmi for broken POWER4 firmware
From: Olaf Hering @ 2006-05-27 11:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17526.59069.781220.922878@cargo.ozlabs.ibm.com>
On Fri, May 26, Paul Mackeras wrote:
> Olaf Hering writes:
>
> > According to this change for EXCEPTION_PROLOG_COMMON, I get still into
> > decremeter_common, but its not fatal anymore because the cpu is now in
> > 64bit mode and the stack is forced to PACAKSAVE(r13).
> >
> > subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
> > beq- 1f; \
> > ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
> > -1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
> > +1: \
> > + cmpdi cr1,r29,0x42; \
>
> Ummm, what's r29 supposed to have in it here?
>
> > + bne cr1,2f; \
> > + li r29,2f@l; \
>
> And why are we setting it?
>
> Does it look like the SRR0 and SRR1 values are correct when we get
> this problem occurring? Is it just the MSR that is bogus?
I looked into this again, my debug patch was wrong. I cant rely on the
hello32, r29 has to be set in the system_reset path. This is the
register dump. It shows that the cpus are in 32bit mode, and that
system_reset_fwnmi calls system_reset_common correctly.
0:mon> r
R00 = 000000001000036c R16 = 0000000000000042
R01 = 00000000ffe96ad0 R17 = 0000000000000042
R02 = 000000001009b470 R18 = 0000000000000042
R03 = 0000000000000009 R19 = 0000000000000042
R04 = 000000001002228c R20 = 0000000000000042
R05 = 0000000040042082 R21 = 0000000000000042
R06 = 0000000000004000 R22 = 0000000000000042
R07 = 0000000010008af0 R23 = 0000000000000042
R08 = 0000000000000000 R24 = 0000000000000042
R09 = 0000000000000000 R25 = 0000000000000042
R10 = 8000000000001032 R26 = 0000000000000042
R11 = 00000000ffe96a50 R27 = 0000000000000042
R12 = 0000000020000082 R28 = 0000000000000042
R13 = 000000001009a410 R29 = 0000000000003220
R14 = 0000000000000042 R30 = 0000000000001002
R15 = 0000000000000042 R31 = a000000000001032
pc = 00000000100003b4
lr = 000000001000036c
msr = 000000000000d032 cr = 20000082
ctr = 0000000000032ddc xer = 00000000000fffff trap = 100
0:mon> c1
1:mon> r
R00 = 000000001000036c R16 = 0000000000000042
R01 = 00000000ffe96ad0 R17 = 0000000000000042
R02 = 000000001009b470 R18 = 0000000000000042
R03 = 0000000000000007 R19 = 0000000000000042
R04 = 000000001002228c R20 = 0000000000000042
R05 = 0000000040022082 R21 = 0000000000000042
R06 = 0000000000004000 R22 = 0000000000000042
R07 = 0000000010008af0 R23 = 0000000000000042
R08 = 0000000000000000 R24 = 0000000000000042
R09 = 0000000000000000 R25 = 0000000000000042
R10 = 8000000000001032 R26 = 0000000000000042
R11 = 00000000ffe96a50 R27 = 0000000000000042
R12 = 0000000020000082 R28 = 0000000000000042
R13 = 000000001009a410 R29 = 0000000000003220
R14 = 0000000000000042 R30 = 0000000000001002
R15 = 0000000000000042 R31 = a000000000001032
pc = 00000000100003b4
lr = 000000001000036c
msr = 000000000000d032 cr = 20000082
ctr = 0000000000032ddc xer = 00000000000fffff trap = 100
Index: linux-2.6/arch/powerpc/kernel/head_64.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/head_64.S
+++ linux-2.6/arch/powerpc/kernel/head_64.S
@@ -211,6 +211,31 @@ exception_marker:
ori reg,reg,(label)@l; /* virt addr of handler ... */
#endif
+#define EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(area, label) \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,area+EX_R9(r13); /* save r9 - r12 */ \
+ std r10,area+EX_R10(r13); \
+ std r11,area+EX_R11(r13); \
+ std r12,area+EX_R12(r13); \
+ mfspr r9,SPRN_SPRG1; \
+ std r9,area+EX_R13(r13); \
+ mfcr r9; \
+ clrrdi r12,r13,32; /* get high part of &label */ \
+ mfmsr r10; \
+ mr r30,r10; \
+ li r11,5; /* MSR_SF_LG|MSR_ISF_LG */ \
+ rldicr r11,r11,61,2; /* (5 << 61) */ \
+ or r10,r10,r11; \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label) \
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mr r31,r10; \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
#define EXCEPTION_PROLOG_PSERIES(area, label) \
mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
std r9,area+EX_R9(r13); /* save r9 - r12 */ \
@@ -269,7 +294,12 @@ exception_marker:
subi r1,r1,INT_FRAME_SIZE; /* alloc frame on kernel stack */ \
beq- 1f; \
ld r1,PACAKSAVE(r13); /* kernel stack to use */ \
-1: cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
+1: \
+ cmpdi cr1,r29,0x42; \
+ bne cr1,2f; \
+ li r29,2f@l; \
+2: ; \
+ cmpdi cr1,r1,0; /* check if r1 is in userspace */ \
bge- cr1,bad_stack; /* abort if it is */ \
std r9,_CCR(r1); /* save CR in stackframe */ \
std r11,_NIP(r1); /* save SRR0 in stackframe */ \
@@ -600,14 +630,15 @@ slb_miss_user_pseries:
system_reset_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common)
+ li r29,0x42
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXGEN, system_reset_common)
.globl machine_check_fwnmi
.align 7
machine_check_fwnmi:
HMT_MEDIUM
mtspr SPRN_SPRG1,r13 /* save r13 */
- EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common)
+ EXCEPTION_PROLOG_PSERIES_BROKEN_POWER4_FIRMWARE(PACA_EXMC, machine_check_common)
#ifdef CONFIG_PPC_ISERIES
/*** ISeries-LPAR interrupt handlers ***/
^ permalink raw reply
* [PATCH, 2.6.17-rc5-git3] ieee80211softmac_io.c: fix warning "defined but not used"
From: Toralf Förster @ 2006-05-27 9:04 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]
Got this compiler warning and Johannes Berg <johannes@sipsolutions.net> wrote:
Yeah, known 'bug', we have that code there but never use it. Feel free
to submit a patch (to John Linville, CC netdev and softmac-dev) to
remove it.
Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
--- src/net/ieee80211/softmac/ieee80211softmac_io.c_orig 2006-05-27 10:50:56.000000000 +0200
+++ src/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-27 10:51:45.000000000 +0200
@@ -440,47 +440,3 @@
return 0;
}
-
-/* Create an rts/cts frame */
-static u32
-ieee80211softmac_rts_cts(struct ieee80211_hdr_2addr **pkt,
- struct ieee80211softmac_device *mac, struct ieee80211softmac_network *net,
- u32 type)
-{
- /* Allocate Packet */
- (*pkt) = kmalloc(IEEE80211_2ADDR_LEN, GFP_ATOMIC);
- memset(*pkt, 0, IEEE80211_2ADDR_LEN);
- if((*pkt) == NULL)
- return 0;
- ieee80211softmac_hdr_2addr(mac, (*pkt), type, net->bssid);
- return IEEE80211_2ADDR_LEN;
-}
-
-
-/* Sends a control packet */
-static int
-ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
- struct ieee80211softmac_network *net, u32 type, u32 arg)
-{
- void *pkt = NULL;
- u32 pkt_size = 0;
-
- switch(type) {
- case IEEE80211_STYPE_RTS:
- case IEEE80211_STYPE_CTS:
- pkt_size = ieee80211softmac_rts_cts((struct ieee80211_hdr_2addr **)(&pkt), mac, net, type);
- break;
- default:
- printkl(KERN_DEBUG PFX "Unsupported Control Frame type: %i\n", type);
- return -EINVAL;
- }
-
- if(pkt_size == 0)
- return -ENOMEM;
-
- /* Send the packet to the ieee80211 layer for tx */
- ieee80211_tx_frame(mac->ieee, (struct ieee80211_hdr *) pkt, pkt_size);
-
- kfree(pkt);
- return 0;
-}
--
MfG/Sincerely
Toralf Förster
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Howto allocate non-cacheable memory
From: Muneeswaran P - TLS, Chennai @ 2006-05-27 5:38 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
How to allocate non-cacheable kernel memory ?
Pls help me.
I am writing device driver (kernel 2.6 ) for PCI-X card.
Pls clarify the following doubts:
1. DPRAM is memory mapped to PCI-X card.
2. I have to transfer data from main memory to DPRAM using bus
master concept and vice-versa.
3. How to make this memory area as non-cacheable one ?=20
4. Whether DMA mapping (pci_map_single() call ) should be done for
both DPRAM and main memory ?
4.a) I will get the physical address of DPRAM memory (memory
mapped to PCI-X card) from BAR-0 register. Can i use this physical =
addres
directly for data transer using bus master (without pci_map_single() =
call.)
?
4.b) How to make main memory area as non-cacheable one ?
Regards,
Munees.
DISCLAIMER=20
The contents of this e-mail and any attachment(s) are confidential and =
intended for the=20
named recipient(s) only. It shall not attach any liability on the =
originator or HCL or its=20
affiliates. Any views or opinions presented in this email are solely =
those of the author and=20
may not necessarily reflect the opinions of HCL or its affiliates. Any =
form of reproduction,=20
dissemination, copying, disclosure, modification, distribution and / or =
publication of this=20
message without the prior written consent of the author of this e-mail =
is strictly=20
prohibited. If you have received this email in error please delete it =
and notify the sender=20
immediately. Before opening any mail and attachments please check them =
for viruses and=20
defect.
^ permalink raw reply
* Re: [RFC] snd-aoa and interrupts (headphone detection etc)
From: Benjamin Herrenschmidt @ 2006-05-26 21:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1148055359.6228.20.camel@johannes.berg>
> The problematic part is things that the codec must control. Say we want
> line-in detection to automatically switch to line-in if microphone is
> selected (does anyone ever want this?). Then the problem is that the
> interrupt arrives at the GPIO layer, and I can easily make it seen in
> the fabric too. However, then propagating it to the codec is a bit
> harder. Or we don't have it in the fabric but have the codec register
> for that interrupt (through our GPIO layer). This is the first option.
No. I don't think the codecs should mess with the GPIOs directly. The
policy should be implemented in the fabric. If in some case you need to
change some codec settings, then the codec shall provide an accessor for
doing so.
> The second option is changing the whole in-/output control code that we
> have and moving it from the codec to the fabric layer. The fabric
> already knows what in- and outputs a codec has (in order to know what is
> connected), hence if we added a codec driver function to turn on/off any
> in- or output we could have the fabric control this. But then we'd also
> have to make known to the codec which of those are mutually exclusive,
> and generally make it more complicated.
We don't have to make known to the codec, we just turn on/off the right
ones.
> I currently favour the first option, the codec driver can know when it
> makes sense to try registering the interrupt (if it isn't present it
> fails anyway) and then do the appropriate stuff (possibly giving the
> user a choice).
I disagree :) But then, it's your code :)
Ben.
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Benjamin Herrenschmidt @ 2006-05-26 21:41 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, Johannes Berg, debian-powerpc
In-Reply-To: <60381eeb0605260902p4420757ai3669aba711122014@mail.gmail.com>
On Fri, 2006-05-26 at 19:02 +0300, Eddy Petrişor wrote:
> On 5/25/06, Johannes Berg <johannes@sipsolutions.net> wrote:
> > Hey,
>
> Hi,
>
> > [1] to find your layout-id, execute the following:
> >
> > find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
> >
> > If you get no output, you have no layout-id property. If you do get
>
> What are the plans for machines without layout-id, like the 5,2 model?
> Will there be any alsa/aoa support at some point?
There will be, but let's get the ones with layout-id first since
snd-powermac should work on the older ones.
Ben.
^ permalink raw reply
* 440gx dma transfer with no data change at dest
From: John Lange @ 2006-05-26 20:58 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi Kevin
I saw a posting from March where you were asking about problems doing
memory to memory DMA transfers with the ppc4xx_dma module of Linux. I'm
curious if you figured out that issue. Would you be kind enough to
share how you fixed the issue you were having? I would sure appreciate
a snippet of working example code if it's not proprietary.
Best regards,
John
[-- Attachment #2: Type: text/html, Size: 2267 bytes --]
^ permalink raw reply
* Re: [openib-general] [PATCH 06/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-26 20:06 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4468BD63.6070509@de.ibm.com>
> + for_each_online_cpu(cpu) {
> + task = create_comp_task(pool, cpu);
> + if (task) {
> + kthread_bind(task, cpu);
> + wake_up_process(task);
> + }
> + }
How does this creation of a thread pool work with respect to CPU
hotplug? What happens if a CPU goes away? How about if only one CPU
is running when the driver is loaded, and then 15 more are hot-added?
> + for (i = 0; i < NR_CPUS; i++) {
> + if (cpu_online(i))
> + destroy_comp_task(pool, i);
> + }
And it seems in the destroy function, you will possibly leak threads
or try to kill a non-existent thread if the set of online CPUs has
changed since the driver started...
- R.
^ permalink raw reply
* Re: [PATCH, 2.6.17-rc4-git10] ieee80211softmac_io.c: fix warning "defined but not used"
From: John W. Linville @ 2006-05-26 19:24 UTC (permalink / raw)
To: Toralf Förster; +Cc: netdev, linuxppc-dev
In-Reply-To: <200605231549.43430.toralf.foerster@gmx.de>
On Tue, May 23, 2006 at 03:49:40PM +0200, Toralf Förster wrote:
> Got this compiler warning today and Johannes Berg <johannes@sipsolutions.net> wrote:
>
> Yeah, known 'bug', we have that code there but never use it. Feel free
> to submit a patch (to John Linville, CC netdev and softmac-dev) to
> remove it.
>
> Signed-off-by: Toralf Foerster <toralf.foerster@gmx.de>
This patch is whitespace-damaged. Please teach your mailer not to
convert tabs to spaces and resubmit.
Thanks!
John
> --- linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c.old 2006-05-12 09:44:47.000000000 +0200
> +++ linux-2.6.17-rc4-git10-pcie-rme9652/net/ieee80211/softmac/ieee80211softmac_io.c 2006-05-23 15:16:38.000000000 +0200
> @@ -456,31 +456,3 @@
> return IEEE80211_2ADDR_LEN;
> }
>
> -
> -/* Sends a control packet */
> -static int
> -ieee80211softmac_send_ctl_frame(struct ieee80211softmac_device *mac,
> - struct ieee80211softmac_network *net, u32 type, u32 arg)
> -{
> - void *pkt = NULL;
> - u32 pkt_size = 0;
<snip>
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Andrew Morton @ 2006-05-26 16:49 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060526151214.GA5190@skynet.ie>
mel@csn.ul.ie (Mel Gorman) wrote:
>
> (Resending with Andrew's email address correct this time)
>
> For the last few -mm releases, kernels built for an old RS6000 failed to
> compile with the message;
>
> arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
> : undefined reference to `__udivdi3'
> make: *** [.tmp_vmlinux1] Error 1
A function with a name like that doesn't _deserve_ to compile.
But actually vrsqrtefp() doesn't call __udivdi3 - the error lies somewhere
else in the kernel and the toolchain gets it wrong, so we don't know where.
The way I usually hunt this problem down is to build the .s files (make
arch/powerpc/kernel/foo.s) and then grep around, find the offending C
function.
If the problem is specific to powerpc then a
diffstat 2.6.17.rc4-mm3 | grep powerpc
will narrow down the number of files to be searched by rather a lot.
> 2.6.17-rc5 is not affected but I didn't search for the culprit patch in
> -mm. The following patch adds an implementation of __udivdi3 for plain old
> ppc32. This may not be the correct fix as Google tells me that __udivdi3
> has been replaced by calls to do_div() in a number of cases. There was no
> obvious way to do that for vrsqrtefp, hence this workaround. The patch should
> be acked, rejected or replaced by a ppc expert.
Yes, we've traditionally avoided adding the 64-bit divide library functions.
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:25 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <44772B10.7040300@rtr.ca>
On Fri, May 26, 2006 at 12:21:36PM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
> >
> >>Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
> >>box here, and sata_mv seems to be behaving for me (thus far).
> >
> >Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering,
> >which
> >we don't have with a G3, so this may be the cause.
>
> MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
Ah, no, the G4 is a 32bit processor.
> The driver is a complete unknown (for me, at least) on 64-bit systems,
> as I don't have one (of any processor type) here yet.
I have an Xserve G5, which is a 64bit powerpc machine, and i could try it in
it. I need to get the fans to a usable level first though, as it sounds like
an airplan, and is sitting right beside my desk.
> >Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> >normal PC card, which is thus uninitialized ?
>
> The board claims to be "mac" compatible, so it probably has an OF bios on
> it, but I have not verified this yet.
Yes, probably. This could mean that the board gets initialized for you, but
not for me.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 16:21 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
Sven Luther wrote:
> On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
>
>> Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
>> box here, and sata_mv seems to be behaving for me (thus far).
>
> Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering, which
> we don't have with a G3, so this may be the cause.
MMmm.. is your G4 using a 64-bit kernel, or a 32-bit kernel?
The driver is a complete unknown (for me, at least) on 64-bit systems,
as I don't have one (of any processor type) here yet.
> Do you have a mac version of the board, with a forth/OF bios in it ? Or a
> normal PC card, which is thus uninitialized ?
The board claims to be "mac" compatible, so it probably has an OF bios on it,
but I have not verified this yet.
Cheers
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:15 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linuxppc-dev list, Yang Xin-Xin-r48390,
linux-kernel, linux-ide, Paul Mackerras, Mark Lord, Jeff Garzik
In-Reply-To: <20060526160156.GA11778@powerlinux.fr>
On Fri, May 26, 2006 at 06:01:56PM +0200, Sven Luther wrote:
> > Can you access the disk? Eg. hexdump -C /dev/sda
>
> Trying to partition the disk with parted yielded the last set of debug
> messages, and a :
Interesting. Using dd, i am able to write some stuff to disk :
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yields only 0s.
dd if=/dev/random of=/dev/sda count=4 (count = 4, because /dev/random outputs blocks of 128 bytes)
dd if=/dev/sda of=/tmp/blah count=1 -> hexdump /tmp/blah yield random non-0 content
Trying to write past the first block, seems to freeze the disk or someting, at
least dd doesn't come back without me ctr-c'ing it.
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 16:01 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <447722FF.9020202@rtr.ca>
On Fri, May 26, 2006 at 11:47:11AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
> >>Sven Luther wrote:
> >>>Ok. can i use this tree with a 2.6.16 base ?
> >>Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
> >>the sata_mv driver to the latest source. Completely untested,
> >>but it does compile.
> >>
> >>I will hopefully test it later today, but in the meanwhile, have a go at
> >>it.
> >
> >And here is attached my dmesg output. The last bit of mv_host_intr was
> >when i
> >tried to access the partition table of the disk with parted.
>
> I don't see anything particularly bad in that dmesg output,
> apart from all of the debug output --> did you enable that,
> or was it "on" by default?
Ah, yes, i enabled it on Jeff's suggestion.
> It finds one SATA drive, with no *known* partition table format.
Well, it is a blank disk indeed, so this is no suprise.
> Can you access the disk? Eg. hexdump -C /dev/sda
Trying to partition the disk with parted yielded the last set of debug
messages, and a :
Error: Unable to open /dev/sda - unrecognized disk label.
The same when trying to write a partition table to it, and naturally, there is
no partition afterward.
hexdump yielded only the debugmessages and nothing else.
> Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
> box here, and sata_mv seems to be behaving for me (thus far).
Mmm, this is a G3, while i have a G4. The G4 does some I/O reordering, which
we don't have with a G3, so this may be the cause.
Do you have a mac version of the board, with a forth/OF bios in it ? Or a
normal PC card, which is thus uninitialized ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Eddy Petrişor @ 2006-05-26 16:02 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
T24gNS8yNS8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gSGV5LAoKSGksCgo+IFsxXSB0byBmaW5kIHlvdXIgbGF5b3V0LWlkLCBleGVjdXRlIHRo
ZSBmb2xsb3dpbmc6Cj4KPiAgIGZpbmQgL3Byb2MvZGV2aWNlLXRyZWUvIC1uYW1lIGxheW91dC1p
ZCB8IHhhcmdzIGhleGR1bXAgLWUgJzEvNCAiMHgleFxuIicKPgo+IElmIHlvdSBnZXQgbm8gb3V0
cHV0LCB5b3UgaGF2ZSBubyBsYXlvdXQtaWQgcHJvcGVydHkuIElmIHlvdSBkbyBnZXQKCldoYXQg
YXJlIHRoZSBwbGFucyBmb3IgbWFjaGluZXMgd2l0aG91dCBsYXlvdXQtaWQsIGxpa2UgdGhlIDUs
MiBtb2RlbD8KV2lsbCB0aGVyZSBiZSBhbnkgYWxzYS9hb2Egc3VwcG9ydCBhdCBzb21lIHBvaW50
PwoKLS0gClJlZ2FyZHMsCkVkZHlQCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PQoiSW1hZ2luYXRpb24gaXMgbW9yZSBpbXBvcnRhbnQgdGhhbiBrbm93bGVkZ2Ui
IEEuRWluc3RlaW4K
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Mark Lord @ 2006-05-26 15:47 UTC (permalink / raw)
To: Sven Luther
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <20060526141535.GA7084@powerlinux.fr>
Sven Luther wrote:
> On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
>> Sven Luther wrote:
>>> Ok. can i use this tree with a 2.6.16 base ?
>> Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
>> the sata_mv driver to the latest source. Completely untested,
>> but it does compile.
>>
>> I will hopefully test it later today, but in the meanwhile, have a go at it.
>
> And here is attached my dmesg output. The last bit of mv_host_intr was when i
> tried to access the partition table of the disk with parted.
I don't see anything particularly bad in that dmesg output,
apart from all of the debug output --> did you enable that,
or was it "on" by default?
It finds one SATA drive, with no *known* partition table format.
Can you access the disk? Eg. hexdump -C /dev/sda
Meanwhile, I just booted 2.6.17-rc5-git1 (latest kernel.org) on my Mac G3
box here, and sata_mv seems to be behaving for me (thus far).
Cheers
^ permalink raw reply
* Re: Cell and new CPU feature bits
From: Olof Johansson @ 2006-05-26 15:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Arnd Bergmann, Steve Munroe, linuxppc-dev list, Paul Mackerras,
Olof Johansson, cbe-oss-dev
In-Reply-To: <1148628831.8089.107.camel@localhost.localdomain>
On Fri, May 26, 2006 at 05:33:51PM +1000, Benjamin Herrenschmidt wrote:
> > Do we see this likely to be used in "global userspace", or more likely
> > in the processor-specific glibc sections? If it's in the
> > processor-specific ones, maybe we should have a per-processor bitfield
> > with erratas/features instead of a global one. That'd make allocation
> > easier too.
>
> Do we have to deal with that many errata that affect userland ? It's
> generally an area where processors are fairly well validated... I don't
> think we need to scale up that much on this one.
Right, amount of erratas should be limited. BUt the amount of features
can be larger, especially as they grow over time and never go away.
> > > Yes, I think a new CPU feature bit for that too is needed. Not much of
> > > these left...
> >
> > Well, are these instructions architected in some later version past
> > 2.02? If so, the bit is only needed on the older processors -- yet again
> > a case for sub-feature/errata bitmasks.
>
> I have to check but I suspect it's still optional.
Ok. Features like that tend to be implementation-specific in the firt
processor they show up in, and later make it into the architecture.
That's why I'm asking. :-)
-Olof
^ permalink raw reply
* [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-26 15:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, linux-kernel
(Resending with Andrew's email address correct this time)
For the last few -mm releases, kernels built for an old RS6000 failed to
compile with the message;
arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1
2.6.17-rc5 is not affected but I didn't search for the culprit patch in
-mm. The following patch adds an implementation of __udivdi3 for plain old
ppc32. This may not be the correct fix as Google tells me that __udivdi3
has been replaced by calls to do_div() in a number of cases. There was no
obvious way to do that for vrsqrtefp, hence this workaround. The patch should
be acked, rejected or replaced by a ppc expert.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile 2006-05-25 02:50:17.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile 2006-05-26 13:17:15.000000000 +0100
@@ -4,7 +4,7 @@
ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o strcase.o
-obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
+obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o udivdi3.o
endif
obj-y += bitops.o
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c 2006-05-26 13:17:22.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c 2006-05-26 13:25:26.000000000 +0100
@@ -0,0 +1,15 @@
+/*
+ * Simple __udivdi3 function which doesn't use FPU.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm-generic/div64.h>
+
+u64 __udivdi3(u64 n, u64 d)
+{
+ if (d & ~0xffffffff)
+ panic("Need true 64-bit/64-bit division");
+ return __div64_32(&n, (u32)d);
+}
+
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3
From: Mel Gorman @ 2006-05-26 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: apkm, linux-kernel
For the last few -mm releases, kernels built for an old RS6000 failed to
compile with the message;
arch/powerpc/kernel/built-in.o(.init.text+0x77b4): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
arch/powerpc/kernel/built-in.o(.init.text+0x7800): In function `vrsqrtefp':
: undefined reference to `__udivdi3'
make: *** [.tmp_vmlinux1] Error 1
2.6.17-rc5 is not affected but I didn't search for the culprit patch in
-mm. The following patch adds an implementation of __udivdi3 for plain old
ppc32. This may not be the correct fix as Google tells me that __udivdi3
has been replaced by calls to do_div() in a number of cases. There was no
obvious way to do that for vrsqrtefp, hence this workaround. The patch should
be acked, rejected or replaced by a ppc expert.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/Makefile 2006-05-25 02:50:17.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/Makefile 2006-05-26 13:17:15.000000000 +0100
@@ -4,7 +4,7 @@
ifeq ($(CONFIG_PPC_MERGE),y)
obj-y := string.o strcase.o
-obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o
+obj-$(CONFIG_PPC32) += div64.o copy_32.o checksum_32.o udivdi3.o
endif
obj-y += bitops.o
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c
--- linux-2.6.17-rc5-clean/arch/powerpc/lib/udivdi3.c 2006-05-26 13:17:22.000000000 +0100
+++ linux-2.6.17-rc5-udivdi3_ppc/arch/powerpc/lib/udivdi3.c 2006-05-26 13:25:26.000000000 +0100
@@ -0,0 +1,15 @@
+/*
+ * Simple __udivdi3 function which doesn't use FPU.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <asm-generic/div64.h>
+
+u64 __udivdi3(u64 n, u64 d)
+{
+ if (d & ~0xffffffff)
+ panic("Need true 64-bit/64-bit division");
+ return __div64_32(&n, (u32)d);
+}
+
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* 2.6 (eldk) - I2C constants
From: Naru Sundar @ 2006-05-26 14:33 UTC (permalink / raw)
To: linuxppc-embedded
Hello folks, I'm porting a 2.4 driver over to 2.6 and noted some
weirdness in the I2C headers. I thought it was worth checking out here.
include/linux/i2c.h in 2.4 defined the following constants:
#define I2C_M_TEN 0x10 /* we have a ten bit chip address */
#define I2C_M_RD 0x01
#define I2C_M_WR 0x00 /* For readable code! */
#define I2C_M_NOSTART 0x4000
#define I2C_M_REV_DIR_ADDR 0x2000
in ELDK 2.6 source drop I have (2.6.15), the I2C_M_WR constant was removed.
Any thoughts? I can declare that constant locally in the driver, but
since these were standard I2C message constants I thought something
odd was up (or am I missing something obvious).
Thanks
--
Naru Sundar <nsundar@fulcrummicro.com>
Fulcrum Microsystems
http://www.fulcrummicro.com
^ permalink raw reply
* Re: [PATCH/2.6.17-rc4 10/10] bugs fix for marvell SATA on powerp c pl atform
From: Sven Luther @ 2006-05-26 14:15 UTC (permalink / raw)
To: Mark Lord
Cc: Alexandre.Bounine, linux-ide, linux-kernel, linuxppc-dev list,
Paul Mackerras, Yang Xin-Xin-r48390, Jeff Garzik
In-Reply-To: <44770065.8070907@rtr.ca>
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
On Fri, May 26, 2006 at 09:19:33AM -0400, Mark Lord wrote:
> Sven Luther wrote:
> >On Fri, May 26, 2006 at 07:41:24AM -0400, Mark Lord wrote:
> >>All of the relevant bits of "my work" are now in Jeff's upstream libata
> >>tree,
> >>from the recently posted sata_mv patches.
> >
> >Ok. can i use this tree with a 2.6.16 base ?
>
> Not as-is. Here (attached) is a patch for 2.6.16.17+ that updates
> the sata_mv driver to the latest source. Completely untested,
> but it does compile.
>
> I will hopefully test it later today, but in the meanwhile, have a go at it.
And here is attached my dmesg output. The last bit of mv_host_intr was when i
tried to access the partition table of the disk with parted.
Friendly,
Sven Luther
[-- Attachment #2: dmesg-2.6.16-mv_sata.gz --]
[-- Type: application/octet-stream, Size: 4002 bytes --]
^ permalink raw reply
* [RFC/PATCH] powersave_nap cleanup
From: Nathan Lynch @ 2006-05-26 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
[ Please consider for 2.6.18. ]
Instead of having the machdep_calls.power_save routines (such as
ppc6xx_idle and power4_idle) individually check the value of the
powersave_nap sysctl variable, we can have the newly-consolidated idle
loop check the value of powersave_nap when deciding whether to call
machdep_calls.power_save. In this way, a platform can implement a
machdep_calls.power_save method but still have threads go low-priority
when idle if the user has set powersave_nap to 0.
Rename machdep_calls.power_save to machdep_calls.powersave_nap to make
more apparent the connection with the powersave_nap sysctl.
Add some documentation to machdep_calls.powersave_nap to more
completely describe its intended use.
Change cpu_idle to call ppc_md.powersave_nap only when the
powersave_nap sysctl is set.
Remove tests of the powersave_nap variable from the ppc6xx_idle and
power4_idle routines.
Set powersave_nap to 1 by default on pSeries when the shared processor
firmware feature is present, preserving current behavior.
Remove a superfluous declaration of powersave_nap from
platforms/powermac/feature.c.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index d491052..09bd0cf 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -53,7 +53,7 @@ void cpu_idle(void)
while (!need_resched() && !cpu_should_die()) {
ppc64_runlatch_off();
- if (ppc_md.power_save) {
+ if (ppc_md.powersave_nap && powersave_nap) {
clear_thread_flag(TIF_POLLING_NRFLAG);
/*
* smp_mb is so clearing of TIF_POLLING_NRFLAG
@@ -64,7 +64,7 @@ void cpu_idle(void)
/* check again after disabling irqs */
if (!need_resched() && !cpu_should_die())
- ppc_md.power_save();
+ ppc_md.powersave_nap();
local_irq_enable();
set_thread_flag(TIF_POLLING_NRFLAG);
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index b45fa0e..c685a8d 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 6xx & 7xxx CPUs
+ * This file contains the powersave_nap function for 6xx & 7xxx CPUs
* rewritten in assembler
*
* Warning ! This code assumes that if your machine has a 750fx
@@ -74,11 +74,6 @@ BEGIN_FTR_SECTION
lwz r4,CPU_SPEC_FEATURES(r4)
andi. r0,r4,CPU_FTR_CAN_NAP
beq 1f
- /* Now check if user or arch enabled NAP mode */
- lis r4,powersave_nap@ha
- lwz r4,powersave_nap@l(r4)
- cmpwi 0,r4,0
- beq 1f
lis r3,HID0_NAP@h
1:
END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index d85c7c9..14e3c18 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -1,5 +1,5 @@
/*
- * This file contains the power_save function for 970-family CPUs.
+ * This file contains the powersave_nap function for 970-family CPUs.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -24,12 +24,6 @@ _GLOBAL(power4_idle)
BEGIN_FTR_SECTION
blr
END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
- /* Now check if user or arch enabled NAP mode */
- LOAD_REG_ADDRBASE(r3,powersave_nap)
- lwz r4,ADDROFF(powersave_nap)(r3)
- cmpwi 0,r4,0
- beqlr
-
/* Go to NAP now */
BEGIN_FTR_SECTION
DSSALL
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..57af9c4 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -142,7 +142,7 @@ void __init machine_init(unsigned long d
#ifdef CONFIG_6xx
if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
cpu_has_feature(CPU_FTR_CAN_NAP))
- ppc_md.power_save = ppc6xx_idle;
+ ppc_md.powersave_nap = ppc6xx_idle;
#endif
if (ppc_md.progress)
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index 24c0aef..eaa4c65 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -292,7 +292,7 @@ define_machine(maple_md) {
.get_rtc_time = maple_get_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = maple_progress,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
.machine_kexec_prepare = default_machine_kexec_prepare,
diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c
index a5063cd..b9a45df 100644
--- a/arch/powerpc/platforms/powermac/feature.c
+++ b/arch/powerpc/platforms/powermac/feature.c
@@ -53,7 +53,6 @@
extern int powersave_lowspeed;
#endif
-extern int powersave_nap;
extern struct device_node *k2_skiplist[2];
/*
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 4d15e39..66e6a21 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -740,7 +740,7 @@ define_machine(powermac) {
.progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
- .power_save = power4_idle,
+ .powersave_nap = power4_idle,
.enable_pmcs = power4_enable_pmcs,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 5f79f01..d094e9d 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -236,11 +236,13 @@ static void __init pSeries_setup_arch(vo
vpa_init(boot_cpuid);
if (get_lppaca()->shared_proc) {
printk(KERN_INFO "Using shared processor idle loop\n");
- ppc_md.power_save = pseries_shared_idle_sleep;
+ ppc_md.powersave_nap = pseries_shared_idle_sleep;
} else {
printk(KERN_INFO "Using dedicated idle loop\n");
- ppc_md.power_save = pseries_dedicated_idle_sleep;
+ ppc_md.powersave_nap = pseries_dedicated_idle_sleep;
}
+ /* We want this on by default. */
+ powersave_nap = 1;
} else {
printk(KERN_INFO "Using default idle loop\n");
}
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 0f9254c..721fbe2 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -160,10 +160,11 @@ struct machdep_calls {
void (*idle_loop)(void);
/*
- * Function for waiting for work with reduced power in idle loop;
- * called with interrupts disabled.
+ * Function for waiting for work with reduced power and/or cpu
+ * utilization in idle loop; called with interrupts disabled.
+ * Can be overriden by the powersave_nap sysctl.
*/
- void (*power_save)(void);
+ void (*powersave_nap)(void);
/* Function to enable performance monitor counters for this
platform, called once per cpu. */
^ permalink raw reply related
* Re: Help Needed: floating point used in kernel (task=c0398410, pc=3184)
From: sandeep malik @ 2006-05-26 14:00 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded
In-Reply-To: <200605260949.48627.roger.larsson@norran.net>
Hi Roger,
The kernel is not linked with uClibc/glibc its user
application only which is linked with uClibc/glibc....
What i am able to conclude is that the library
internall might be using floating point operations and
might be genrating some floating point instructions
which are not handled by our board....and that might
be the reason....or this error might be mapped in a
generic way such that it is getting flashed in some
particular scenarios.....
I might be wrong but as of now i don't have any other
explaination as now after linking with glibs the
application is working fine.....
Regards,
Malik
--- Roger Larsson <roger.larsson@norran.net> wrote:
> On fredag 26 maj 2006 09.38, you wrote:
> > Hi Roger,
> >
> > The problem has been resolved...the issue was in
> the make
> > file.....actually we were cpmiling the code with
> gclibc and linking it with
> > uClibc which was causing the problem.....But this
> was real test i faced
> > till now as all the tricks realted to the message
> were failed.....any ways
> > thanks for ur help....
> > Regards,
> > Malik
>
> Now I am confused!
>
> How could this cause
> "floating point used in kernel (task=c0398410,
> pc=3184)"
>
> Both uClibc and gclibc are user land libraries. They
> should not be able to
> cause an kernel floating point operation. No user
> land code should be able
> to do this!
>
> Or is it your kernel linked with uClibc/gclibc? I do
> not think that is the
> right thing to do...
>
> /RogerL
>
Send instant messages to your online friends http://in.messenger.yahoo.com
^ 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