* Re: [PATCH] make ams work with latest kernels
From: Pavel Machek @ 2006-05-27 20:34 UTC (permalink / raw)
To: Stelian Pop
Cc: Andrew Morton, linuxppc-dev list, Johannes Berg,
Linux Kernel list
In-Reply-To: <1148761919.3132.1.camel@deep-space-9.dsnet>
On So 27-05-06 22:31:58, Stelian Pop wrote:
> Le samedi 27 mai 2006 ? 22:06 +0200, Johannes Berg a écrit :
> > 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.
>
> /sysfs interface also exports the 'z' coordinate, the input interface
> does not.
Can that be fixed? z coordinate should be useful for input, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [RFC] snd-aoa and interrupts (headphone detection etc)
From: Johannes Berg @ 2006-05-27 20:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1148679918.8089.166.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
On Sat, 2006-05-27 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > 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.
Yeah. That was my second option mostly.
> > 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.
Hmm, ok, good point, then we don't even need the complication of telling
the codec what is connected to it. Maybe that simplifies the code in
total... But the codecs will still need hardcoded numbers for the
various in- and outputs that the fabric needs to know.
I'll think about this a bit more, maybe experiment with the code a
bit :)
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: Stelian Pop @ 2006-05-27 20:31 UTC (permalink / raw)
To: Johannes Berg
Cc: Andrew Morton, linuxppc-dev list, Linux Kernel list, Pavel Machek
In-Reply-To: <1148760414.16989.59.camel@johannes.berg>
Le samedi 27 mai 2006 à 22:06 +0200, Johannes Berg a écrit :
> 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.
/sysfs interface also exports the 'z' coordinate, the input interface
does not.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply
* 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
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