* Re: TI_LOCAL_FLAGS definition wrong?
From: Guennadi Liakhovetski @ 2006-05-28 22:34 UTC (permalink / raw)
To: Linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0605212033480.11693@poirot.grange>
On Sun, 21 May 2006, Guennadi Liakhovetski wrote:
> Is this define in arch/ppc/kernel/asm-offsets.c (as of 2.6.17-rc3):
>
> DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
>
> correct? Or should it be local_flags? Or is it already fixed in later
> versions?
I think, putting LOCAL_FLAGS on flags as above causes oopses on strace as
below. local_flags fixes it. It's on 2.6.17-rc3. Will double-check on rc5
tomorrow, but looks like it hasn't changed.
Thanks
Guennadi
---
Guennadi Liakhovetski
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C020DE40 LR: C020DE2C CTR: 00000000
REGS: c5821d80 TRAP: 0300 Not tainted (2.6.17-rc3-kuroboxHG)
MSR: 00009032 <EE,ME,IR,DR> CR: 22000082 XER: 00000000
DAR: 0000000C, DSISR: 20000000
TASK = c7d307d0[1791] 'buttond' THREAD: c5820000
GPR00: 00000000 C5821E30 C7D307D0 00000000 C000B720 00000000 00001154 00000000
GPR08: 005FB283 C02C6240 22020488 00001032 0000ED12 100424C0 10010000 7FF6FC70
GPR16: 10040000 10040000 100C9BC8 C02D0000 C02C0000 C02C6240 C5820000 C7D308D8
GPR24: 000086E2 C02C6240 00000075 000000B6 C02B1060 C02B1C60 00000000 00800000
NIP [C020DE40] schedule+0x318/0x62c
LR [C020DE2C] schedule+0x304/0x62c
Call Trace:
[C5821E30] [C020DE2C] schedule+0x304/0x62c (unreliable)
[C5821E70] [C00235E0] ptrace_stop+0x98/0xf4
[C5821E80] [C00236AC] ptrace_notify+0x70/0x90
[C5821F20] [C0008D74] do_syscall_trace+0x28/0x68
[C5821F30] [C0008DF0] do_syscall_trace_enter+0x3c/0x4c
[C5821F40] [C0004344] syscall_dotrace+0x5c/0xc8
Instruction dump:
4bdf54c9 801e007c 2f800000 419e0280 7fc3f378 7fe4fb78 4bdfd8d1 7c7e1b78
38000000 39346240 80690028 90090028 <83fe000c> 7c0000a6 60008000 7c000124
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C020DE38 LR: C020DE2C CTR: 00000000
REGS: c62fdd90 TRAP: 0300 Not tainted (2.6.17-rc3-kuroboxHG)
MSR: 00009032 <EE,ME,IR,DR> CR: 22000082 XER: 00000000
DAR: 10046268, DSISR: 20000000
TASK = c7c4b770[1764] 'dump' THREAD: c62fc000
GPR00: 00000000 C62FDE40 C7C4B770 00000000 C000B720 00000000 000010E6 00000000
GPR08: 00000000 10046240 22020488 00001032 0000B39D 100424C0 10010000 7FCB5C70
GPR16: 10040000 10040000 100C9148 00000000 10040000 300269E8 00000000 00000000
GPR24: 30013890 7FBF0AA0 30026EC8 30026D34 00000215 00000005 00000000 00000000
NIP [C020DE38] schedule+0x310/0x62c
LR [C020DE2C] schedule+0x304/0x62c
Call Trace:
[C62FDE40] [C020DE2C] schedule+0x304/0x62c (unreliable)
[C62FDE80] [C00235E0] ptrace_stop+0x98/0xf4
[C62FDE90] [C00236AC] ptrace_notify+0x70/0x90
[C62FDF30] [C0008D74] do_syscall_trace+0x28/0x68
[C62FDF40] [C00044CC] syscall_exit_work+0x11c/0x120
Instruction dump:
419e00d4 809d0024 4bdf54c9 801e007c 2f800000 419e0280 7fc3f378 7fe4fb78
4bdfd8d1 7c7e1b78 38000000 39346240 <80690028> 90090028 83fe000c 7c0000a6
Oops: kernel access of bad area, sig: 11 [#2]
NIP: C020DE40 LR: C020DE2C CTR: 00000000
REGS: c62fdd80 TRAP: 0300 Not tainted (2.6.17-rc3-kuroboxHG)
MSR: 00009032 <EE,ME,IR,DR> CR: 22000082 XER: 00000000
DAR: 0000000C, DSISR: 20000000
TASK = c7c4b770[1766] 'dump' THREAD: c62fc000
GPR00: 00000000 C62FDE30 C7C4B770 00000000 C000B720 00000000 00001082 00000000
GPR08: 0059BDF5 C02C6240 22020488 00001032 0000B488 100424C0 10010000 7FA17C70
GPR16: 10040000 10040000 100C9608 C02D0000 C02C0000 C02C6240 C62FC000 C7C4B878
GPR24: 00008594 C02C6240 00000076 00000068 C78A93A0 C6E743A0 00000000 00800000
NIP [C020DE40] schedule+0x318/0x62c
LR [C020DE2C] schedule+0x304/0x62c
Call Trace:
[C62FDE30] [C020DE2C] schedule+0x304/0x62c (unreliable)
[C62FDE70] [C00235E0] ptrace_stop+0x98/0xf4
[C62FDE80] [C00236AC] ptrace_notify+0x70/0x90
[C62FDF20] [C0008D74] do_syscall_trace+0x28/0x68
[C62FDF30] [C0008DF0] do_syscall_trace_enter+0x3c/0x4c
[C62FDF40] [C0004344] syscall_dotrace+0x5c/0xc8
Instruction dump:
4bdf54c9 801e007c 2f800000 419e0280 7fc3f378 7fe4fb78 4bdfd8d1 7c7e1b78
38000000 39346240 80690028 90090028 <83fe000c> 7c0000a6 60008000 7c000124
^ permalink raw reply
* please pull powerpc.git 'merge' branch again
From: Paul Mackerras @ 2006-05-28 22:50 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, Guennadi Liakhovetski
Linus,
Please do another pull from the "merge" branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
Guennadi Liakhovetski pointed out a typo in arch/ppc/kernel/asm-offsets.c
that really should be fixed for 2.6.17, so here is a commit to fix
it. The patch and commit message are below.
Thanks,
Paul.
commit b82e8005af14b51600714971e0c6420c4e334a50
Author: Paul Mackerras <paulus@samba.org>
Date: Mon May 29 08:42:34 2006 +1000
ppc: Fix typo in TI_LOCAL_FLAGS definition
A typo crept in with commit ea1e847cc202e805769c3c46ba5e5c53714068a1
which defined TI_LOCAL_FLAGS to be the offset of the `flags' field
of struct thread_info, rather than the `local_flags' field. This
fixes it. The typo was pointed out by Guennadi Liakhovetski.
Signed-off-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/ppc/kernel/asm-offsets.c b/arch/ppc/kernel/asm-offsets.c
index cc7c4ae..2f5c5e1 100644
--- a/arch/ppc/kernel/asm-offsets.c
+++ b/arch/ppc/kernel/asm-offsets.c
@@ -134,7 +134,7 @@ #endif /* CONFIG_SPE */
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_EXECDOMAIN, offsetof(struct thread_info, exec_domain));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
- DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, flags));
+ DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, local_flags));
DEFINE(TI_CPU, offsetof(struct thread_info, cpu));
DEFINE(TI_PREEMPT, offsetof(struct thread_info, preempt_count));
^ permalink raw reply related
* snd-aoa: Sound gone after snd-aoa updates, on PB5,8
From: Wolfgang Pfeiffer @ 2006-05-29 2:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
Hi
After some updates from http://johannes.sipsolutions.net/snd-aoa.git/
in the last few hours/minutes sound's gone here. Without changing
sound settings intentionally here.
$ cat /proc/cpuinfo
processor : 0
cpu : 7447A, altivec supported
clock : 833.333000MHz
revision : 0.5 (pvr 8003 0105)
bogomips : 16.57
timebase : 8320000
platform : PowerMac
machine : PowerBook5,8
motherboard : PowerBook5,8 MacRISC3 Power Macintosh
detected as : 287 (PowerBook G4 15")
pmac flags : 00000019
L2 cache : 512K unified
pmac-generation : NewWorld
/var/log/boot:
Mon May 29 03:08:52 2006: ^[[9;0]^[[14;0]Setting up ALSA...warning: 'alsactl restore' failed with error message 'ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: alsactl: set_controls:1088: snd_ctl_open error: No such file or directory'...ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: ALSA lib control.c:816:(snd_ctl_open_noupdate) Invalid CTL hw:0
Mon May 29 03:08:52 2006: amixer: Mixer attach hw:0 error: No such file or directory
Mon May 29 03:08:52 2006: done.
Excerpts from /var/log/kern.log:
--------------------------------------
May 29 03:08:54 debby1-6 kernel: [ 24.296157] i2sbus: !!!!! WARNING !!!!!
May 29 03:08:54 debby1-6 kernel: [ 24.305857] i2sbus: control: couldn't allocate resource
May 29 03:08:54 debby1-6 kernel: [ 24.315558] i2sbus: going ahead
anyway
May 29 03:08:54 debby1-6 kernel: [ 25.140174] snd-aoa-fabric-layout: found bus with layout 82 (using)
May 29 03:08:54 debby1-6 kernel: [ 34.230912] snd-aoa-codec-onyx: found pcm3052
May 29 03:08:54 debby1-6 kernel: [ 34.232445] snd-aoa-fabric-layout: can use this codec
May 29 03:08:54 debby1-6 kernel: [ 34.307453] snd-aoa-codec-onyx: attached to onyx codec via i2c
May 29 03:08:54 debby1-6 kernel: [ 34.318072] snd-aoa-codec-onyx: created and attached onyx instance
May 29 03:08:54 debby1-6 kernel: [ 34.318080] PowerMac i2c bus mac-io 0 registered
May 29 03:08:54 debby1-6 kernel: [ 34.336045] PowerMac i2c bus uni-n 0 registered
-------------------------------------
After the first errors (that is: No sound at all), I removed
asound.conf and asound.names in /etc/ completely, just to make sure I
have no mistakes in these files - to no avail so far. Kernel is
still the same as all the last 2 weeks or so, where alsa/snd-aoa
worked.
uname -a
Linux debby1-6 2.6.17-rc3-gf358166a-dirty #1 Fri May 12 01:13:36 CEST
2006 ppc GNU/Linux
# modinfo snd-aoa
filename: /lib/modules/2.6.17-rc3-gf358166a-dirty/kernel/sound/aoa/snd-aoa.ko
description: Apple Onboard Audio Sound Driver
author: Johannes Berg <johannes@sipsolutions.net>
license: GPL..
vermagic: 2.6.17-rc3-gf358166a-dirty mod_unload gcc-4.1
depends: sndation.
srcversion: 2944C7BBEA1A2A72E3A8183
/etc/modprobe.d/sound:
-----------------
alias snd-card-0 i2sbus
#alias snd-card-0 snd-powermac
#options snd-powermac index=0
-------------------
Hints?
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* [Done] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5,8
From: Wolfgang Pfeiffer @ 2006-05-29 2:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <20060529020027.GA3107@localhost>
On Mon, May 29, 2006 at 04:00:27AM +0200, Wolfgang Pfeiffer wrote:
>
> Hi
>
> After some updates from http://johannes.sipsolutions.net/snd-aoa.git/
> in the last few hours/minutes sound's gone here. Without changing
> sound settings intentionally here.
>
>
On Debian/unstable:
After downgrading libasound2 from 1.0.11-6 to 1.0.11-3 I have sound
again: 1.0.11-6 was, IINM, installed a few hours ago, which
- as it seems - broke sound here.
HTH
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: [Done] Re: snd-aoa: Sound gone after snd-aoa updates, on PB5,8
From: Benjamin Herrenschmidt @ 2006-05-29 2:28 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <20060529021756.GB3107@localhost>
On Mon, 2006-05-29 at 04:17 +0200, Wolfgang Pfeiffer wrote:
> On Mon, May 29, 2006 at 04:00:27AM +0200, Wolfgang Pfeiffer wrote:
> >
> > Hi
> >
> > After some updates from http://johannes.sipsolutions.net/snd-aoa.git/
> > in the last few hours/minutes sound's gone here. Without changing
> > sound settings intentionally here.
> >
> >
>
> On Debian/unstable:
> After downgrading libasound2 from 1.0.11-6 to 1.0.11-3 I have sound
> again: 1.0.11-6 was, IINM, installed a few hours ago, which
> - as it seems - broke sound here.
Have you tested that it wasn't just the renaming/re-ordering of some
controls ? Alsa is pretty bad with that, you may just have to go back to
alsamixer and reset some controls after updating the driver.
Ben.
^ permalink raw reply
* compact flash driver
From: John Wu @ 2006-05-30 3:48 UTC (permalink / raw)
To: linuxppc-embedded
Dear sir
Do you have compact flash card driver supported in u-boot.I need it.If
you don't have it .Can you tell me how the CF card initialize if you
know how to initialize it?
^ permalink raw reply
* Re: compact flash driver
From: KokHow Teh @ 2006-05-29 4:45 UTC (permalink / raw)
To: John Wu <jwu; +Cc: linuxppc-embedded
>Dear sir
>Do you have compact flash card driver supported in u-boot.I need it.If
^^^^^^
You have posted your question to the wrong list.
>you don't have it .Can you tell me how the CF card initialize if you
>know how to initialize it?
Ask more specific question as to what hardware platform you are using.
Specifically, which CF controller....
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 7:07 UTC (permalink / raw)
To: Dan Malek; +Cc: jourdan, linuxppc-embedded
In-Reply-To: <38D2D5EE-A581-42A4-B3E7-FEEBBA67D311@embeddedalley.com>
>
> On May 24, 2006, at 12:54 PM, jourdan@enib.fr wrote:
>
>> I have a MPC8260 processor card with a Coral-P evaluation board
>> (rev 4.0).
>
> Are you sure?
>
> The 8260 does not have a PCI bus and the Coral-P
> is a PCI card :-)
>
Yes indeed my mistake it's a 8270 !
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 7:34 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: jourdan, linuxppc-embedded
In-Reply-To: <20060524195747.0CE6E353BFD@atlas.denx.de>
> In message <3799.194.3.133.184.1148489640.squirrel@webmail.enib.fr> you
> wrote:
>>
>> I have a MPC8260 processor card with a Coral-P evaluation board (rev
>> 4.0).
>> My system do not have keyboard nor mouse (i use the serial console).
>>
>> I use linux kernel 2.4.25 & 2.6.9.
>
> We have instructions on our web site; did you read these?
Yes I did. I use the same jumper configuration (for board rev 4.0) as the
pictures on your web site.
>> I'm trying to get the framebuffer driver to work. During the boot the
>> driver loads fine but the monitor remains blank (no video signal). If i
>> try to `cat /dev/urandom > /dev/fb/0` nothing happens.
>
> Are you using devfs? Don't! Use /dev/fb0
Without devfs, I have /dev/fb0.
During boot sequence, the driver loads fine (built-in, not module) :
...
MB86290: fb_init called.
MB86290: initialize called.
MB86290: GDC base phys address: 0x8c000000
MB86290: GDC base virt address: 0xc5000000
Console: switching to frame buffer device
MB86290: dmamem: GFP success.
MB86290: fb_init finished
...
In /proc I have :
# more /proc/fb
0 MB86290
This seems ok to me but I don't have any video signal. My screen remains
blank.
>> I compiled an Xserver (Release 6.9), and the x11 drivers for the coralp.
>> When I start X, it says that it can not open tty0 (indeed it doesn't
>> exists).
>
> Well, you got an error message (tty0 cannot be opened), you verified
> that it is valid (tty0 does not exist), so fix the problem...
>
Without devfs, I have ttys :
# ls -al tty*
crw-rw-rw- 1 root root 5, 0 May 29 2006 tty
crw--w--w- 1 root 5 4, 0 May 29 2006 tty0
crw-rw---- 1 root 5 4, 1 May 29 2006 tty1
crw-rw---- 1 root 5 4, 2 May 29 2006 tty2
crw-rw---- 1 root 14 4, 64 May 29 2006 ttyS0
crw-rw---- 1 root 14 4, 65 May 29 2006 ttyS1
crw-rw---- 1 root 14 4, 66 May 29 2006 ttyS2
crw-rw---- 1 root 14 4, 67 May 29 2006 ttyS3
crw-rw-rw- 1 root 5 3, 0 May 29 2006 ttyp0
crw-rw-rw- 1 root 5 3, 1 May 29 2006 ttyp1
crw-rw-rw- 1 root 5 3, 2 May 29 2006 ttyp2
crw-rw-rw- 1 root 5 3, 3 May 29 2006 ttyp3
crw-rw-rw- 1 root 5 3, 4 May 29 2006 ttyp4
crw-rw-rw- 1 root 5 3, 5 May 29 2006 ttyp5
crw-rw-rw- 1 root 5 3, 6 May 29 2006 ttyp6
crw-rw-rw- 1 root 5 3, 7 May 29 2006 ttyp7
crw-rw-rw- 1 root 5 3, 8 May 29 2006 ttyp8
crw-rw-rw- 1 root 5 3, 9 May 29 2006 ttyp9
Major and minor codes are ok but when I start X :
...
Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
...
I have to start X from a serial console. There are no keyboard or mouse
connectors on my board. This is maybe the source of my problems ?
Thanks for your help.
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: Wolfgang Denk @ 2006-05-29 9:12 UTC (permalink / raw)
To: jourdan; +Cc: linuxppc-embedded
In-Reply-To: <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr>
In message <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr> you wrote:
>
> This seems ok to me but I don't have any video signal. My screen remains
> blank.
What's your boot arguments? Where is your console device, on the
serial port or on the frame buffer?
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> ...
Did you enable all of the following options in your kernel config?
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_MB86290=y
CONFIG_FBCON_ADVANCED=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
My guess is that CONFIG_VT and/or CONFIG_VT_CONSOLE might be missing.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"There is no distinctly American criminal class except Congress."
- Mark Twain
^ permalink raw reply
* Re: Can't get CoralP drivers to work
From: jourdan @ 2006-05-29 10:19 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060529091257.686CB3525D9@atlas.denx.de>
> In message <1402.194.3.133.184.1148888040.squirrel@webmail.enib.fr> you
> wrote:
>>
>> This seems ok to me but I don't have any video signal. My screen remains
>> blank.
>
> What's your boot arguments? Where is your console device, on the
> serial port or on the frame buffer?
My boot arguments :
# more /proc/cmdline
console=tty0 console=ttyS1,9600 devfs=mount ip=bootp root=/dev/nfs rw
My console is on the serial port (ttyS1 on SMC2).
>> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
>> ...
>
> Did you enable all of the following options in your kernel config?
>
> CONFIG_FB=y
> CONFIG_DUMMY_CONSOLE=y
> CONFIG_FB_MB86290=y
> CONFIG_FBCON_ADVANCED=y
> CONFIG_FBCON_CFB16=y
> CONFIG_FBCON_FONTS=y
> CONFIG_FONT_8x8=y
> CONFIG_FONT_8x16=y
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
>
> My guess is that CONFIG_VT and/or CONFIG_VT_CONSOLE might be missing.
All those options are enabled.
^ permalink raw reply
* Re: [Alsa-devel] [RFC 2/7] snd-aoa: add aoa core
From: Takashi Iwai @ 2006-05-29 10:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190124.579130000@johannes.berg>
At Sun, 28 May 2006 21:00:28 +0200,
Johannes Berg wrote:
> --- /dev/null
> +++ b/sound/aoa/core/snd-aoa-alsa.c
> @@ -0,0 +1,91 @@
> +/*
> + * Apple Onboard Audio Alsa helpers
> + *
> + * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
> + *
> + * GPL v2, can be found in COPYING.
> + */
> +#include <linux/module.h>
> +#include "snd-aoa-alsa.h"
> +
> +static struct aoa_card *aoa_card;
> +
> +int aoa_alsa_init(char *name, struct module *mod)
> +{
> + struct snd_card *alsa_card;
> + int err;
> +
> + if (aoa_card)
> + /* cannot be EEXIST due to usage in aoa_fabric_register */
> + return -EBUSY;
> +
> + alsa_card = snd_card_new(-1, name, mod, sizeof(struct aoa_card));
Usually the first argument here is the index module option so that
user may specify the card order (e.g. secondary card) independent from
the order of module loading.
> + if (!alsa_card)
> + return -ENOMEM;
> + aoa_card = alsa_card->private_data;
> + aoa_card->alsa_card = alsa_card;
> + strncpy(alsa_card->driver, "AppleOnbdAudio", sizeof(alsa_card->driver));
> + strncpy(alsa_card->shortname, name, sizeof(alsa_card->shortname));
> + strncpy(alsa_card->longname, name, sizeof(alsa_card->longname));
> + strncpy(alsa_card->mixername, name, sizeof(alsa_card->mixername));
strlcpy is safer. Also, longname usually contains more verbose info.
> --- /dev/null
> +++ b/sound/aoa/core/snd-aoa-core.c
(snip)
> + err = aoa_alsa_init(new_fabric->name, new_fabric->owner);
> + if (err) {
> + return err;
> + }
Remove braces.
Takashi
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-29 10:59 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Ronen Shitrit, Rita Shtern, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Hi,
Attached...
-----Original Message-----
From: Mark A. Greer [mailto:mgreer@mvista.com]
Sent: Wednesday, May 24, 2006 1:35 AM
To: Assaf Hoffman
Cc: Mark A. Greer; linuxppc-embedded@ozlabs.org; Rita Shtern; Ronen
Shitrit
Subject: Re: Setting I&D cache enable in the same mtspr instruction
On Tue, May 23, 2006 at 12:55:46PM +0300, Assaf Hoffman wrote:
> Attached.
> Thanks.
Er, how about a *patch* place inline (as in, not as an attachment).
Thanks,
Mark
[-- Attachment #2: cpu_setup_6xx.patch --]
[-- Type: application/octet-stream, Size: 827 bytes --]
--- ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx_patch.S 2006-05-29 13:53:07.000000000 +0300
+++ ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx.S 2005-08-29 19:55:27.000000000 +0300
@@ -79,19 +79,17 @@
/* Enable caches for 603's, 604, 750 & 7400 */
setup_common_caches:
mfspr r11,SPRN_HID0
- ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
+ ori r11,r11,HID0_ICE|HID0_DCE
+ ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
sync
- ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
- isync
- sync
- mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
+ mtspr SPRN_HID0,r11 /* enable caches */
sync
-
+ isync
blr
/* 604, 604e, 604ev, ...
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Michael Schmitz @ 2006-05-29 11:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Johannes Berg, debian-powerpc,
Eddy Petrişor
In-Reply-To: <1148679703.8089.162.camel@localhost.localdomain>
> > > 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.
It sure does (5,5 at least).
Michael
^ permalink raw reply
* Re: [Alsa-devel] [RFC 4/7] snd-aoa: add codecs
From: Takashi Iwai @ 2006-05-29 12:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190125.927852000@johannes.berg>
At Sun, 28 May 2006 21:00:30 +0200,
Johannes Berg wrote:
> --- /dev/null
> +++ b/sound/aoa/codecs/snd-aoa-codec-onyx.c
> +/* both return 0 if all ok, else on error */
> +static int onyx_read_register(struct onyx *onyx, u8 reg, u8 *value)
> +{
> + s32 v;
> +
> + if (reg != ONYX_REG_CONTROL) {
> + *value = onyx->cache[reg-FIRSTREGISTER];
> + return 0;
> + }
> + v = i2c_smbus_read_byte_data(&onyx->i2c, reg);
> + if (v < 0)
> + return -1;
> + *value = (u8)v;
> + onyx->cache[ONYX_REG_CONTROL-FIRSTREGISTER] = *value;
Isn't it "reg - FIRSTREGISTER" ?
> + return 0;
> +}
> +
> +static int onyx_write_register(struct onyx *onyx, u8 reg, u8 value)
> +{
> + int result;
> +
> + result = i2c_smbus_write_byte_data(&onyx->i2c, reg, value);
> + if (!result)
> + onyx->cache[reg-FIRSTREGISTER] = value;
> + return result;
> +}
> +
> +/* alsa stuff */
> +
> +static int onyx_dev_register(struct snd_device *dev)
> +{
> + return 0;
> +}
> +
> +static struct snd_device_ops ops = {
> + .dev_register = onyx_dev_register,
> +};
> +
> +static int onyx_snd_vol_info(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_info *uinfo)
> +{
> + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
> + uinfo->count = 2;
> + uinfo->value.integer.min = -128+128;
> + uinfo->value.integer.max = -1+128;
I'd define a constant for 128.
> + return 0;
> +}
> +
> +static int onyx_snd_vol_get(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct onyx *onyx = snd_kcontrol_chip(kcontrol);
> + s8 l,r;
> +
> + mutex_lock(&onyx->mutex);
> + onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, &l);
> + onyx_read_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, &r);
> + mutex_unlock(&onyx->mutex);
> +
> + ucontrol->value.integer.value[0] = l+128;
> + ucontrol->value.integer.value[1] = r+128;
> +
> + return 0;
> +}
> +
> +static int onyx_snd_vol_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct onyx *onyx = snd_kcontrol_chip(kcontrol);
> +
> + mutex_lock(&onyx->mutex);
> + onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_LEFT, ucontrol->value.integer.value[0]-128);
> + onyx_write_register(onyx, ONYX_REG_DAC_ATTEN_RIGHT, ucontrol->value.integer.value[1]-128);
Fold lines to fit with 80 columns (heh, blaming other one's code is
easy :)
> + /* FIXME: we could be checking if anything changed */
> + mutex_unlock(&onyx->mutex);
> +
> + return 1;
The put callback is supposed to return 0 if the values are unchanged
(although most apps ignore the return value).
(snip)
> +static u8 register_map[] = {
> + ONYX_REG_DAC_ATTEN_LEFT,
> + ONYX_REG_DAC_ATTEN_RIGHT,
> + ONYX_REG_CONTROL,
> + ONYX_REG_DAC_CONTROL,
> + ONYX_REG_DAC_DEEMPH,
> + ONYX_REG_DAC_FILTER,
> + ONYX_REG_DAC_OUTPHASE,
> + ONYX_REG_ADC_CONTROL,
> + ONYX_REG_ADC_HPF_BYPASS,
> + ONYX_REG_DIG_INFO1,
> + ONYX_REG_DIG_INFO2,
> + ONYX_REG_DIG_INFO3,
> + ONYX_REG_DIG_INFO4
> +};
> +
> +static u8 initial_values[] = {
Should have ARRAY_SIZE(register_map) since this size must be identical
with register_map.
> + 0x80, 0x80, /* muted */
> + ONYX_MRST | ONYX_SRST, /* but handled specially! */
> + ONYX_MUTE_LEFT | ONYX_MUTE_RIGHT,
> + 0, /* no deemphasis */
> + ONYX_DAC_FILTER_ALWAYS,
> + ONYX_OUTPHASE_INVERTED,
> + (-1 /*dB*/ + 8) & 0xF, /* line in selected, -1 dB gain*/
> + ONYX_ADC_HPF_ALWAYS,
> + (1<<2), /* pcm audio */
> + 2, /* category: pcm coder */
> + 0, /* sampling frequency 44.1 kHz, clock accuracy level II */
> + 1 /* 24 bit depth */
> +};
> +
> +/* reset registers of chip, either to initial or to previous values */
> +static int onyx_register_init(struct onyx *onyx)
> +{
> + int i;
> + u8 val;
> + u8 regs[sizeof(initial_values)];
> +
> + if (!onyx->initialised) {
> + memcpy(regs, initial_values, sizeof(initial_values));
> + if (onyx_read_register(onyx, ONYX_REG_CONTROL, &val))
> + return -1;
> + val &= ~ONYX_SILICONVERSION;
> + val |= initial_values[3];
> + regs[3] = val;
> + } else {
> + for (i=0; i<sizeof(register_map); i++)
> + regs[i] = onyx->cache[register_map[i]-FIRSTREGISTER];
> + }
> +
> + for (i=0; i<sizeof(register_map); i++) {
> + if (onyx_write_register(onyx, register_map[i], regs[i]))
> + return -1;
> + }
> + onyx->initialised = 1;
> + return 0;
> +}
> +
> +static struct transfer_info onyx_transfers[] = {
> + /* this is first so we can skip it if no input is present...
> + * No hardware exists with that, but it's here as an example
> + * of what to do :) */
> + {
> + /* analog input */
> + .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
Too long lines ;)
(snip)
> + if (onyx->codec.soundbus_dev->attach_codec(onyx->codec.soundbus_dev,
> + aoa_get_card(),
> + ci, onyx)) {
> + printk(KERN_ERR PFX "error creating onyx pcm\n");
> + return -ENODEV;
> + }
> +#define ADDCTL(n) \
> + do { \
> + ctl = snd_ctl_new1(&n, onyx); \
> + if (ctl) { \
> + ctl->id.device = \
> + onyx->codec.soundbus_dev->pcm->device; \
> + aoa_snd_ctl_add(ctl); \
No error check?
> + /* we try to read from register ONYX_REG_CONTROL
> + * to check if the codec is present */
> + if (onyx_read_register(onyx, ONYX_REG_CONTROL, &dummy) != 0) {
> + i2c_detach_client(&onyx->i2c);
> + printk(KERN_ERR PFX "failed to read control register\n");
> + goto fail;
> + }
> +
> + strncpy(onyx->codec.name, "onyx", MAX_CODEC_NAME_LEN);
Use strlcpy, or MAX_CODEC_NAME_LEN-1. Similar lines are found in
tas driver too.
> --- /dev/null
> +++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
> @@ -0,0 +1,669 @@
(snip)
> +struct tas {
> + u32 primary_magic;
> + struct aoa_codec codec;
> + /* see comment at top of file */
> + u32 secondary_magic;
> + struct aoa_codec secondary;
> + struct i2c_client i2c;
> + u32 muted_l:1, muted_r:1,
> + controls_created:1;
> + u8 cached_volume_l, cached_volume_r;
> + u8 mixer_l[3], mixer_r[3];
> + u8 acr;
> +};
> +
> +static struct tas *codec_to_tas(struct aoa_codec *codec)
> +{
> + u32 *tmp = (u32*)codec;
> + switch (*(tmp-1)) {
> + case TAS_PRIMARY_MAGIC:
> + return container_of(codec, struct tas, codec);
> + case TAS_SECONDARY_MAGIC:
> + return container_of(codec, struct tas, secondary);
> + default:
> + return NULL;
> + }
> +}
Looks a bit too hacky. IMO, it's better to define a struct
struct tas_codec {
struct aoa_codec codec;
struct tas *tas;
}
to make the above simpler like:
static struct tas *codec_to_tas(struct aoa_codec *codec)
{
return ((struct tas_codec *)codec)->tas;
}
The tas struct becomes:
struct as {
struct tas_codec primary;
struct tas_codec secondary;
...
}
and is initialized like:
tas->primary.tas = tas;
tas->secondary.tas = tas;
> +static int tas_snd_capture_source_info(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_info *uinfo)
> +{
> + static char* texts[] = { "Line-In", "Microphone" };
char *texts[]
> +static int tas_reset_init(struct tas *tas)
> +{
> + u8 tmp;
> +/*
> + char write[8];
> + union i2c_smbus_data read = { 0 };
> + int r1, r2;
> +*/
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 0);
> + msleep(1);
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 1);
> + msleep(1);
> + tas->codec.gpio->methods->set_hw_reset(tas->codec.gpio, 0);
> + msleep(1);
> +
> + tas->acr &= ~TAS_ACR_ANALOG_PDOWN;
> + tas->acr |= TAS_ACR_B_MONAUREAL | TAS_ACR_B_MON_SEL_RIGHT;
> + if (tas_write_reg(tas, TAS_REG_ACR, 1, &tas->acr))
> + return -ENODEV;
> +
> + tmp = TAS_MCS_SCLK64 | TAS_MCS_SPORT_MODE_I2S | TAS_MCS_SPORT_WL_24BIT;
> + if (tas_write_reg(tas, TAS_REG_MCS, 1, &tmp))
> + return -ENODEV;
> +
> + tmp = 0;
> + if (tas_write_reg(tas, TAS_REG_MCS2, 1, &tmp))
> + return -ENODEV;
> +/* I need help here!
Use ifdef. Nested comments are bad.
> + /* This is a bit tricky, but serves to detect if there really
> + * is a tas codec present.
> + * First, we set the volume register to 00,00,01 (on both channels).
> + * This is almost muted. Then, we read back the last 6 bytes we
> + * wrote to the chip, and check if they are the same.
> + *
> + write[0] = 7;
> + write[1] = TAS_REG_VOL;
> + write[2] = write[3] = 0;
> + write[4] = 1;
> + write[5] = write[6] = 0;
> + write[7] = 1;
> + r1 = tas_write_reg(tas, TAS_REG_VOL, 6, &write[1]);
> + /* Hmm, how am I supposed to do the i2c sequence that
> + * is mentioned on page 45 of the tas3004 datasheet?
> + * This doesn't cut it: *
> + read.block[0] = 7;
> + r2 = i2c_smbus_xfer(tas->i2c.adapter, tas->i2c.addr, tas->i2c.flags,
> + I2C_SMBUS_READ, TAS_REG_VOL,
> + I2C_SMBUS_BLOCK_DATA, &read);
> +
> + printk(KERN_DEBUG "r1 = %d, r2 = %d, read=%x %x %x %x %x %x %x %x\n", r1, r2, read.block[0], read.block[1], read.block[2], read.block[3], read.block[4], read.block[5], read.block[6], read.block[7]);
> +
> + if (r1 || r2 || memcmp(write, read.block, 8))
> + return -ENODEV;
> +*/
> +
> + return 0;
> +}
> +static int tas_init_codec(struct aoa_codec *codec)
> +{
(snip)
> + aoa_snd_ctl_add(snd_ctl_new1(&volume_control, tas));
Error checks please.
Takashi
^ permalink raw reply
* Re: [Alsa-devel] [RFC 5/7] snd-aoa: add layout-id fabric
From: Takashi Iwai @ 2006-05-29 12:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <20060528190129.503400000@johannes.berg>
At Sun, 28 May 2006 21:00:31 +0200,
Johannes Berg wrote:
>
> The 'fabric' is the thing that pulls all of snd-aoa together, this patch
> adds the 'layout' or 'layout-id' fabric that keys off the 'layout-id'
> property in the device-tree to pull in the proper modules. It itself loads
> if an i2sbus is present with a layout-id (exported in modalias) that it can
> use.
(snip)
> +static void use_layout(struct layout *l)
> +{
> + int i;
> +
> + for (i=0; i<MAX_CODECS_PER_BUS; i++) {
> + if (l->codecs[i].name) {
> + request_module("snd-aoa-codec-%s", l->codecs[i].name);
Just from curiosity: Does this work properly?
I remember that there was a deadlock when you call request_module()
during module probe.
Takashi
^ permalink raw reply
* Re: Setting I&D cache enable in the same mtspr instruction
From: Roger Larsson @ 2006-05-29 12:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <B9FFC3F97441D04093A504CEA31B7C41A62B2F@msilexch01.marvell.com>
Is the patch reversed?
diff -Naur old new > patch
And what about comments, are they all still valid?
"enable and invalidate caches" is now only Data cache...
In cases when I am writing code like this I try to
include the reason why it is not "optimized" together
in one write... (or soon someone will do that optimization).
/RogerL
^ permalink raw reply
* RE: Setting I&D cache enable in the same mtspr instruction
From: Assaf Hoffman @ 2006-05-29 12:37 UTC (permalink / raw)
To: Roger Larsson, linuxppc-embedded; +Cc: Ronen Shitrit
[-- Attachment #1: Type: text/plain, Size: 879 bytes --]
Hi,
Attached...
-----Original Message-----
From: linuxppc-embedded-bounces+hoffman=marvell.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+hoffman=marvell.com@ozlabs.org] On
Behalf Of Roger Larsson
Sent: Monday, May 29, 2006 3:15 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Setting I&D cache enable in the same mtspr instruction
Importance: Low
Is the patch reversed?
diff -Naur old new > patch
And what about comments, are they all still valid?
"enable and invalidate caches" is now only Data cache...
In cases when I am writing code like this I try to
include the reason why it is not "optimized" together
in one write... (or soon someone will do that optimization).
/RogerL
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: cpu_setup_6xx.patch --]
[-- Type: application/octet-stream, Size: 1114 bytes --]
--- ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx_patch.S 2006-05-29 15:31:24.000000000 +0300
+++ ../downloads/kernels/linux-2.6.12.6/arch/ppc/kernel/cpu_setup_6xx.S 2005-08-29 19:55:27.000000000 +0300
@@ -77,29 +77,19 @@
blr
/* Enable caches for 603's, 604, 750 & 7400 */
-
-/*
- * HID0[ICFI] and HID0[DCFI] must NOT both be set with the same mtspr
- * instruction, due to the synchronization requirements
- */
-
setup_common_caches:
mfspr r11,SPRN_HID0
- ori r8,r11,HID0_DCE
andi. r0,r11,HID0_DCE
+ ori r11,r11,HID0_ICE|HID0_DCE
+ ori r8,r11,HID0_ICFI
bne 1f /* don't invalidate the D-cache */
ori r8,r8,HID0_DCI /* unless it wasn't enabled */
1: sync
mtspr SPRN_HID0,r8 /* enable and invalidate caches */
- sync
- ori r8,r11,HID0_ICE|HID0_DCE|HID0_ICFI
- isync /* An isync must precede the setting */
- /* of the HID0[ICFI] in order for the */
- /* setting to take effect. */
sync
- mtspr SPRN_HID0,r8 /* enable and invalidate Instruction cache */
+ mtspr SPRN_HID0,r11 /* enable caches */
sync
-
+ isync
blr
/* 604, 604e, 604ev, ...
^ permalink raw reply
* Re: Re: PPC exception 0x320
From: jeanwelly @ 2006-05-29 14:22 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <4819ACC0-1281-487B-B290-C55071E1EC27@freescale.com>
SGkgQmVja3kgQnJ1Y2UsDQpTb3JyeSBmb3IgbGF0ZSByZXNwb25zZS4gSSBnb3QgbWFpbCB0cmFm
ZmljLi4uDQoNCkkgZW5jb3VudGVyZWQgdGhlIGV4Y2VwdGlvbiAweDMyMCB3aGljaCBjYXVzZWQg
dGhlIFBQQyBjYXJkIGNyYXNoLiBCYXNlZCBvbiBteSB1bmRlcnN0YW5kaW5nLCBJIHRoaW5rIGV4
Y2VwdGlvbiBpcyBhIEhXIGJlaGF2aW91ciwgc28gSSBndWVzcyB0aGVyZSBtYXliZSBleGlzdCBz
b21lIHJlZmVyZW5jZSBvbiBhbGwgdGhlIHN1cHBvcnRlZCBleGNlcHRpb25zIG9mIHNvbWUgdmVy
c2lvbiBvZiBQUEMuIERvIHlvdSBrbm93IHRoaXM/DQoNCk15IHN5c3RlbSB0YWtlIHRoYXQgZXhj
ZXB0aW9uIGFzIGFuICJ1bmtub3duIGV4Y2VwdGlvbiIgYW5kIGNyYXNoIHRoZSBjYXJkLiBTbywg
SSB0aGluayB0aGUgZXhjZXB0aW9uIGlzIGZyb20gdGhlIFBQQyBDUFUsIGJ1dCBkb24ndCB0aGUg
Y29uY3JldGUgbWVhbmluZ3MuDQoNCkFwcHJlY2lhdGUgeW91ciBzdWdnZXN0aW9ucy4NCi0tLQ0K
SmVhbndlbGx5DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K
PklzIHRoZXJlIHNvbWUgZXJyb3IgbWVzc2FnZSB5b3UgY2FuIHNob3cgbWU/DQo+DQo+LUINCj4N
Cj5PbiBBcHIgMjUsIDIwMDYsIGF0IDEwOjAzIEFNLCBqZWFud2VsbHkgd3JvdGU6DQo+DQo+PiBI
aSBCZWNreSBCcnVjZSwNCj4+IEknbSB1c2luZyBQUEMgNzUwLi4uIEp1c3QgYXMgeW91IHNhaWQs
IDB4MzAwIGlzIGZvciBEU0ksIGFuZCBJICANCj4+IGd1ZXNzIHRoZXkgYXJlIGEgc2V0IG9mIGV4
Y2VwdGlvbnMsIG5vdCBqdXN0IG9uZS4gQW5kIDB4MzIwIGlzIG9uZSAgDQo+PiBvZiB0aGVtLg0K
Pj4gSSBnb3QgYSBib2FyZCBjcmFzaCwgYW5kIFBQQyBhbGFybWVkIGV4Y2VwdGlvbiAweDMyMC4g
Q291bGQgeW91ICANCj4+IHNob3cgbWUgdGhlIG1lY2hhbmlzbSBvZiBoYW5kbGluZyBvZiBhIHNw
ZWNpYWwgZXhjZXB0aW9uIG5vdCBvbmUgc2V0Lg0KPj4gCQ0KPj4NCj4+ID09PT09PT0gMjAwNi0w
NC0yNSAwMjo1MzozNSDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KPj4NCj4+PiBDb3VsZCB5b3Ug
dHJ5IHRvIGJlIG1vcmUgc3BlY2lmaWM/ICBXaGF0IHByb2Nlc3NvciBkbyB5b3UgaGF2ZSwgd2hh
dA0KPj4+IGxpbnV4IHZlcnNpb24gYXJlIHlvdSBydW5uaW5nLCBhbmQgd2hhdCBkbyB5b3UgbWVh
biBleGFjdGx5IHdoZW4geW91DQo+Pj4gc2F5IHlvdSAiZW5jb3VudGVyZWQgUFBDIGV4Y2VwdGlv
biAweDMyMCI/ICBBcyBmYXIgYXMgSSBrbm93LCB0aGUNCj4+PiBwb3dlcnBjIGFyY2hpdGVjdHVy
ZSBkb2VzIG5vdCBkZWZpbmUgYW4gZXhjZXB0aW9uIDB4MzIwLiAgMHgzMDAgaXMNCj4+PiB1c3Vh
bGx5IERTSSBvbiBjbGFzc2ljIHBvd2VycGMgcGFydHMuICBCb29rRSBwYXJ0cyBoYW5kbGUgdGhp
bmdzDQo+Pj4gZGlmZmVyZW50bHkuDQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gLUJlY2t5DQo+Pj4N
Cj4+PiBPbiBBcHIgMjQsIDIwMDYsIGF0IDg6NTEgQU0sIGplYW53ZWxseSB3cm90ZToNCj4+Pg0K
Pj4+PiBIaSwNCj4+Pj4gSSBlbmNvdW50ZXJlZCBQUEMgZXhjZXB0aW9uIDB4MzIwLCBidXQgZG9u
J3Qga25vdyB3aGF0IGl0IGZvci4gQW55DQo+Pj4+IG9uZSBjb3VsZCBoZWxwIG1lIG9uIHRoaXM/
DQo+Pj4+IFRoYW5rcyENCj4+Pj4gIAkJCQkNCj4+Pj4NCj4+Pj4goaGhoaGhoaGhoaGhoaGhoWpl
YW53ZWxseQ0KPj4+PiChoaGhoaGhoaGhoaGhoaGhamVhbndlbGx5QDEyNi5jb20NCj4+Pj4goaGh
oaGhoaGhoaGhoaGhoaGhoaEyMDA2LTA0LTI0DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IExpbnV4cHBjLWVtYmVkZGVkIG1haWxpbmcg
bGlzdA0KPj4+PiBMaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQo+Pj4+IGh0dHBzOi8vb3ps
YWJzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4cHBjLWVtYmVkZGVkDQo+Pj4NCj4+Pg0KPj4+
IC4NCj4+DQo+PiA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCj4+IAkJ
CQ0KPj4NCj4+IKGhoaGhoaGhoaGhoaGhoaHWwg0KPj4gwPGjoQ0KPj4NCj4+IAkJCQkNCj4+IKGh
oaGhoaGhoaGhoaGhoaFqZWFud2VsbHkNCj4+IKGhoaGhoaGhoaGhoaGhoaFqZWFud2VsbHlAMTI2
LmNvbQ0KPj4goaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA2LTA0LTI1DQo+Pg0KPg0KPg0KPi4NCg0K
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQoJCQkNCg0KoaGhoaGhoaGh
oaGhoaGhodbCDQrA8aOhDQogDQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoWplYW53ZWxseQ0KoaGh
oaGhoaGhoaGhoaGhoWplYW53ZWxseUAxMjYuY29tDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDYt
MDUtMjkNCg0K
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-29 15:49 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <20060526094924.10efc515.akpm@osdl.org>
On (26/05/06 09:49), Andrew Morton didst pronounce:
> 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.
>
heh
> 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.
>
It explains why I couldn't find where vrsqrtefp() was.
> 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.
>
That was a good idea, thanks. It showed that check_for_io_childs() in
arch/powerpc/kernel/pci_32.c was the real problem. A quick look showed
that is was doing divisions on resource_type_t which was 64 bits with my
.config. Selecting CONFIG_RESOURCES_32BIT made the problem go away. This
option is introduced by the kconfigurable-resources-* patches so I've cc'd
Vivek Goyal to comment on the potential fixes below.
> > 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.
Understandable. The fixes are obvious in this case. Easiest is for users to
set CONFIG_RESOURCES_32BIT manually although the kernel build error is not
very obvious. A fairly easy bodge is to default CONFIG_RESOURCES_32BIT to Y
when building PPC32 but a determined user may still fail to build a kernel. A
slightly riskier option is this patch that replaces a potential 64 bit divide
with a do_div call. The patch has been successfully boot-tested on a RS6000.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c
--- linux-2.6.17-rc4-mm3-clean/arch/powerpc/kernel/pci_32.c 2006-05-29 15:55:52.000000000 +0100
+++ linux-2.6.17-rc4-mm3-resources-32/arch/powerpc/kernel/pci_32.c 2006-05-29 15:53:43.000000000 +0100
@@ -1115,7 +1115,9 @@ check_for_io_childs(struct pci_bus *bus,
int rc = 0;
#define push_end(res, size) do { unsigned long __sz = (size) ; \
- res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
+ resource_size_t farEnd = (res->end + __sz); \
+ do_div(farEnd, (__sz + 1)); \
+ res->end = farEnd * (__sz + 1) + __sz; \
} while (0)
list_for_each_entry(dev, &bus->devices, bus_list) {
^ permalink raw reply
* Linux kernel thread with Linux 2.6.x
From: Laurent Lagrange @ 2006-05-29 15:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000001c65d85$5e699890$5201a8c0@GEG2400>
Hello everybody,
I'm writing a custom network driver based on a MPC8260 FCC device for a
2.6.9 linux kernel.
In this driver, I need to use specific buffer allocation functions which use
down and up semaphore functions.
As the interrupt handler can't be scheduled, I have made a kernel thread
which waits forever on a semaphore.
This semaphore is set when a received packet interrupt occured. All that
mechanism works but the performances
are very poor.
Is there any solution to increase the kthread priority in the scheduler ?
Is there another solution than the semaphore to quickly wake up a kthread ?
Thanks a lot for your help.
Laurent
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Segher Boessenkool @ 2006-05-29 16:22 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <20060529154923.GA9025@skynet.ie>
>>> 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.
Would vector_reciprocal_square_root_estimate_floating_point() be any
better...
Anyway, this is just a machine insn mnemonic, so the function name is
fine
I believe.
> #define push_end(res, size) do { unsigned long __sz = (size) ; \
> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
> + resource_size_t farEnd = (res->end + __sz); \
> + do_div(farEnd, (__sz + 1)); \
> + res->end = farEnd * (__sz + 1) + __sz; \
> } while (0)
Size here is a) a misnomer (size + 1 is the actual size) and b) always
a power
of two minus one. So instead, do
#define push_end(res, mask) res->end = -(-res->end & ~(unsigned
long)mask)
(with a do { } while(0) armour if you prefer).
Segher
^ permalink raw reply
* Re: Linux kernel thread with Linux 2.6.x
From: Thiago Galesi @ 2006-05-29 17:13 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000201c68335$7c594b90$5201a8c0@GEG2400>
>
> As the interrupt handler can't be scheduled, I have made a kernel thread
> which waits forever on a semaphore.
> This semaphore is set when a received packet interrupt occured.
You should look into tasklets for this. Not that your system is not
OK, but, as you said it, it's not fast enough.
Note that you still have some limitations using tasklets, but it's
more flexible than Interrupt handlers.
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-05-29 17:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <2ebd96e4a7ea753273b2c5f856ba8c7a@kernel.crashing.org>
On Mon, 29 May 2006, Segher Boessenkool wrote:
>>>> 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.
>
> Would vector_reciprocal_square_root_estimate_floating_point() be any
> better...
> Anyway, this is just a machine insn mnemonic, so the function name is fine
> I believe.
>
>> #define push_end(res, size) do { unsigned long __sz = (size) ; \
>> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
>> + resource_size_t farEnd = (res->end + __sz); \
>> + do_div(farEnd, (__sz + 1)); \
>> + res->end = farEnd * (__sz + 1) + __sz; \
>> } while (0)
>
> Size here is a) a misnomer (size + 1 is the actual size) and b) always a
> power
> of two minus one. So instead, do
>
> #define push_end(res, mask) res->end = -(-res->end & ~(unsigned long)mask)
>
> (with a do { } while(0) armour if you prefer).
>
It's not doing the same as the old code so is your suggested fix a correct
replacement?
For example, given 0xfff for size the current code rounds res->end to the
next 0x1000 boundary and adds 0xfff. Your propose fix just rounds it to
the next 0x1000 if I'm reading it correctly but is what the code was meant
to do in the first place? Using masks, the equivilant of the current code
is something like;
#define push_end(res, mask) do { \
res->end = -(-res->end & ~(unsigned long)mask); \
res->end += mask; \
} while (0)
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Segher Boessenkool @ 2006-05-29 17:56 UTC (permalink / raw)
To: Mel Gorman; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0605291825500.11234@skynet.skynet.ie>
>>> #define push_end(res, size) do { unsigned long __sz = (size) ; \
>>> - res->end = ((res->end + __sz) / (__sz + 1)) * (__sz + 1) + __sz; \
>>> + resource_size_t farEnd = (res->end + __sz); \
>>> + do_div(farEnd, (__sz + 1)); \
>>> + res->end = farEnd * (__sz + 1) + __sz; \
>>> } while (0)
>>
>> Size here is a) a misnomer (size + 1 is the actual size) and b)
>> always a power
>> of two minus one. So instead, do
>>
>> #define push_end(res, mask) res->end = -(-res->end & ~(unsigned
>> long)mask)
>>
>> (with a do { } while(0) armour if you prefer).
>>
>
> It's not doing the same as the old code so is your suggested fix a
> correct replacement?
>
> For example, given 0xfff for size the current code rounds res->end to
> the next 0x1000 boundary and adds 0xfff. Your propose fix just rounds
> it to the next 0x1000 if I'm reading it correctly but is what the code
> was meant to do in the first place? Using masks, the equivilant of the
> current code is something like;
>
> #define push_end(res, mask) do { \
> res->end = -(-res->end & ~(unsigned long)mask); \
> res->end += mask; \
> } while (0)
Yeah forgot a bit, this looks fine.
Segher
^ 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