* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-19 13:05 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, linux-kernel,
Steven Rostedt
In-Reply-To: <48AAB7FF.4070502@extricom.com>
* Eran Liberty (liberty@extricom.com) wrote:
> Steven Rostedt wrote:
>> On Mon, 18 Aug 2008, Eran Liberty wrote:
>>
>>
>>> Steven Rostedt wrote:
>>>
>>>> Eran Liberty wrote:
>>>>
>>>>> After compiling a kernel with ftrace I started to experience all sorts
>>>>> of
>>>>> crashes.
>>>>>
>>>> Just to make sure...
>>>>
>>>> ftrace enables markers too, and RCU has tracing with the markers. This
>>>> may
>>>> not be the problem, but I just want to eliminate as many variables as
>>>> possible.
>>>> Could you disable ftrace, but keep the markers on too. Also, could you
>>>> enable ftrace again and turn on the FTRACE_STARTUP_TEST.
>>>>
>>> for the fun of it I took out all my propriety modules; so now its a non
>>> tainted kernel.
>>>
>>> Here is the matrix:
>>>
>>> !FTRACE x !MARKERS => stable
>>> !FTRACE x MARKERS => stable
>>> FTRACE x !MARKERS => n/a (FTRACE forces MARKERS)
>>> FTRACE x MARKERS => unstable
>>> FTRACE x FTRACE_STARTUP_TEST x MARKERS => unstable + tests passed
>>>
>>
>> Thanks
>>
>>
>>> Testing tracer sched_switch: PASSED
>>> Testing tracer ftrace: PASSED
>>> Testing dynamic ftrace: PASSED
>>>
>>> Oops: Exception in kernel mode, sig: 11 [#1]
>>> Exsw1600
>>> Modules linked in:
>>> NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
>>>
>>
>> Could you load this into gdb for me and show me the output of:
>>
>> gdb> li *0xc00bbb20
>>
>> (Assuming you compiled with debuginfo on)
>>
>> and...
>>
>> gdb> disass 0xc00bbb20
>>
>>
>>> REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2)
>>> MSR: 00029000 <EE,ME> CR: 24082282 XER: 20000000
>>> TASK = ddcce060[1707] 'find' THREAD: dd5b0000
>>> GPR00: 00000000 dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b
>>> 100234ec
>>> GPR08: c0800000 00019330 0000ffff dd5b1d20 24000288 100ad874 100936f8
>>> 1008a1d0
>>> GPR16: 10083f80 dd5b1e2c dd5b1d68 fffffff4 c0380000 dd5b1d60 dd5b1d58
>>> dd802084
>>> GPR24: dc3d7700 dd802018 dd5b1d68 c0380000 dd801180 dd5b1d68 00000000
>>> dd5b1d00
>>> NIP [c00bbb20] d_lookup+0x40/0x90
>>> LR [c00bbb20] d_lookup+0x40/0x90
>>> Call Trace:
>>> [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable)
>>> [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220
>>> [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54
>>> [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0
>>> [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c
>>> [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac
>>> [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74
>>> [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48
>>> [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c
>>> [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c
>>> Instruction dump:
>>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
>>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
>>>
>>
>> Ouch! we have a 00000000 instruction. I'm almost done with the new mcount
>> record for PPC (I have it done for ppc64, I'm just porting it to 32). I'm
>> thinking this new code may solve your issues too. I hate the daemon.
>>
>> -- Steve
>>
>>
>>
>
> I have attached ddd. Up on crashing it points on this line
>
> struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
> {
> struct dentry * dentry = NULL;
> unsigned long seq;
> do {
> seq = read_seqbegin(&rename_lock);
> dentry = __d_lookup(parent, name); <==== ddd marker
> if (dentry)
> break;
> } while (read_seqretry(&rename_lock, seq));
> return dentry;
> }
>
> (gdb) bt
> #0 d_lookup (parent=0xdd801180, name=0xd99b3d68) at fs/dcache.c:1361
> #1 0xc00ae7c8 in real_lookup (nd=<value optimized out>, name=<value
> optimized out>, parent=0xdd801180) at fs/namei.c:507
> #2 do_lookup (nd=0xd99b3e28, name=0xd99b3d68, path=0xd99b3d58) at
> fs/namei.c:825
> #3 0xc00b0684 in __link_path_walk (name=0xddc23009 "", nd=0xd99b3e28) at
> fs/namei.c:982
> #4 0xc00b0e8c in link_path_walk (nd=<value optimized out>, name=<value
> optimized out>) at fs/namei.c:570
> #5 path_walk (name=0xddc23000 "/proc/mtd", nd=0xd99b3e28) at
> fs/namei.c:1041
> #6 0xc00b0ffc in do_path_lookup (dfd=<value optimized out>,
> name=0xddc23000 "/proc/mtd", flags=<value optimized out>, nd=0xd99b3e28) at
> fs/namei.c:1091
> #7 0xc00b1cf8 in user_path_at (dfd=-100, name=<value optimized out>,
> flags=0, path=0xd99b3e98) at fs/namei.c:1334
> #8 0xc00a8c98 in vfs_lstat_fd (dfd=-578809472, name=0xd99b3d68 "",
> stat=0xd99b3ed8) at fs/stat.c:83
> #9 0xc00a8d6c in vfs_lstat (name=0xd99b3d68 "", stat=0xd99b3d58) at
> fs/stat.c:93
> #10 0xc00a8db4 in sys_lstat64 (filename=0xdd801180 "", statbuf=0xbfe285d8)
> at fs/stat.c:381
> #11 0xc0010554 in syscall_dotrace_cont ()
>
> both cp & lr points to 0xC00BB724
> (gdb) info registers
> r0 0x0 0
> r1 0xd99b3d00 3650829568
> r2 0xddccf2e0 3721196256
> r3 0xdd801180 3716157824
> r4 0xd99b3d68 3650829672
> r5 0xd99b3d58 3650829656
> r6 0xdd822a5b 3716295259
> r7 0x100234ec 268580076
> r8 0xc0800000 3229614080
> r9 0x19330 103216
> r10 0xffff 65535
> r11 0xd99b3d20 3650829600
> r12 0x24000288 603980424
> r13 0x100ad874 269146228
> r14 0x100936f8 269039352
> r15 0x1008a1d0 269001168
> r16 0x10083f80 268976000
> r17 0xd99b3e2c 3650829868
> r18 0xd99b3d68 3650829672
> r19 0xfffffff4 4294967284
> r20 0xc0380000 3224895488
> r21 0xd99b3d60 3650829664
> r22 0xd99b3d58 3650829656
> r23 0xdd802084 3716161668
> r24 0xdc3fb280 3695161984
> r25 0xdd802018 3716161560
> r26 0xd99b3d68 3650829672
> r27 0xc0380000 3224895488
> r28 0xdd801180 3716157824
> r29 0xd99b3d68 3650829672
> r30 0x0 0
> r31 0xd99b3d00 3650829568
> pc 0xc00bb724 3221993252
> cr 0x24082282 604512898
> lr 0xc00bb724 3221993252
> ctr 0x0 0
> xer 0x20000000 536870912
>
> (gdb) li *0xC00BB724
> Line 1361 of "fs/dcache.c" starts at address 0xc00bb724 <d_lookup+64> and
> ends at 0xc00bb728 <d_lookup+68>.
>
> (gdb) disassemble 0xC00BB724
> Dump of assembler code for function d_lookup:
> 0xc00bb6e4 <d_lookup+0>: mflr r0
> 0xc00bb6e8 <d_lookup+4>: stw r0,4(r1)
> 0xc00bb6ec <d_lookup+8>: nop
> 0xc00bb6f0 <d_lookup+12>: stwu r1,-32(r1)
> 0xc00bb6f4 <d_lookup+16>: mflr r0
> 0xc00bb6f8 <d_lookup+20>: stmw r27,12(r1)
> 0xc00bb6fc <d_lookup+24>: lis r27,-16328
> 0xc00bb700 <d_lookup+28>: mr r31,r1
> 0xc00bb704 <d_lookup+32>: stw r0,36(r1)
> 0xc00bb708 <d_lookup+36>: mr r28,r3
> 0xc00bb70c <d_lookup+40>: mr r29,r4
> 0xc00bb710 <d_lookup+44>: lwz r30,12960(r27)
> 0xc00bb714 <d_lookup+48>: andi. r0,r30,1
> 0xc00bb718 <d_lookup+52>: mr r3,r28
> 0xc00bb71c <d_lookup+56>: mr r4,r29
> 0xc00bb720 <d_lookup+60>: bnela- 0x2c
> 0xc00bb724 <d_lookup+64>: .long 0x0
> 0xc00bb728 <d_lookup+68>: cmpwi cr7,r3,0
> 0xc00bb72c <d_lookup+72>: bne- cr7,0xc00bb75c <d_lookup+120>
> 0xc00bb730 <d_lookup+76>: lwz r0,12960(r27)
> 0xc00bb734 <d_lookup+80>: cmpw cr7,r0,r30
> 0xc00bb738 <d_lookup+84>: beq- cr7,0xc00bb75c <d_lookup+120>
> 0xc00bb73c <d_lookup+88>: mr r30,r0
> 0xc00bb740 <d_lookup+92>: andi. r0,r30,1
> 0xc00bb744 <d_lookup+96>: mr r3,r28
> 0xc00bb748 <d_lookup+100>: mr r4,r29
> 0xc00bb74c <d_lookup+104>: beq+ 0xc00bb724 <d_lookup+64>
> 0xc00bb750 <d_lookup+108>: lwz r0,12960(r27)
> 0xc00bb754 <d_lookup+112>: mr r30,r0
> 0xc00bb758 <d_lookup+116>: b 0xc00bb740 <d_lookup+92>
> 0xc00bb75c <d_lookup+120>: lwz r11,0(r1)
> 0xc00bb760 <d_lookup+124>: lwz r0,4(r11)
> 0xc00bb764 <d_lookup+128>: lmw r27,-20(r11)
> 0xc00bb768 <d_lookup+132>: mtlr r0
> 0xc00bb76c <d_lookup+136>: mr r1,r11
> 0xc00bb770 <d_lookup+140>: blr
> End of assembler dump.
> (gdb)
>
> Hope this is helpfull
>
Can you also give us
objdump -S --start-address=0xC00BB724 vmlinux | head 20
?
Then we could compare the result with the OOPS instruction dump :
7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
Mathieu
> Liberty
>
>
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: Clock / Timebase / Bus Frequencies Help
From: surendranath.moilla @ 2008-08-19 13:52 UTC (permalink / raw)
To: richw; +Cc: linuxppc-dev
In-Reply-To: <48AAA42E.9040909@btconnect.com>
Hi Richard,
Thanks for your response,
i have fixed the problem. The problem was while U-boot is doing boardsetup
it is filling incorrect frequencies which causes the problem.
Regards
Surendra
> Hi,
>
> Is it really hanging?
> Or is it just sending console output somewhere else?
> Try pinging the board after you think its hung. Can you ssh in and dmesg
> to find out what went wrong?
> I've had two problems similar to this recently. The first was that the
> serial clock frequency was wrong in the dts file.
> The second was schoolboy error when the console was handed over to ttyS1
> when I was plugged in to ttyS0.
> If that all fails - put a scope on your serial port and see what its
> really doing.
> Good luck,
>
>
>
>
> Richard.
>
> surendranath.moilla@cmcltd.com wrote:
>> Hi,
>>
>> I have a similar problem with custom MPC8360 board.
>> I am able to boot Linux with the mpc836x_dts.dtb provided by freescale.
>> but when use dtb customised for my board i am unable to boot Linux.
>> It is hanging after the console handover to real console from boot
>> console.
>>
>> I am filling all the frequencies properly, can someone help me to fix
>> this
>> Where to set the baud rate in dts file.
>>
>> Here is the log:
>>
>>
>> => tftp $loadaddr /nfk684/vpm_test/uImage
>> Using FSL UEC0 device
>> TFTP from server 192.168.0.2; our IP address is 192.168.0.100
>> Filename '/nfk684/vpm_test/uImage'.
>> Load address: 0x200000
>> Loading:
>> #################################################################
>> ##########
>> done
>> Bytes transferred = 1095689 (10b809 hex)
>> => tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb
>> Using FSL UEC0 device
>> TFTP from server 192.168.0.2; our IP address is 192.168.0.100
>> Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'.
>> Load address: 0x400000
>> Loading: #
>> done
>> Bytes transferred = 12288 (3000 hex)
>> => bootm $loadaddr - $fdtaddr
>> ## Booting image at 00200000 ...
>> Image Name: Linux-2.6.22
>> Image Type: PowerPC Linux Kernel Image (gzip compressed)
>> Data Size: 1095625 Bytes = 1 MB
>> Load Address: 00000000
>> Entry Point: 00000000
>> Verifying Checksum ... OK
>> Uncompressing Kernel Image ... OK
>> Booting using the fdt at 0x400000
>> Probing machine type
>> Using MPC8360 VPM machine description
>> Linux version 2.6.22 (nfk684@ilec4411) (gcc version 4.0.0 (DENX ELDK 4.1
>> 4.0.0))
>> #17 Fri Aug 15 16:13:41 CDT 2008
>> setup_arch: bootmem
>> mpc8360_vpm_setup_arch()
>> Bad clock source for time stamp 1
>> Bad clock source for time stamp 2
>> arch: exit
>> Zone PFN ranges:
>> DMA 0 -> 65536
>> Normal 65536 -> 65536
>> early_node_map[1] active PFN ranges
>> 0: 0 -> 65536
>> Built 1 zonelists. Total pages: 65024
>> Kernel command line: root=/dev/ram rw console=ttyS1,115200
>> IPIC (128 IRQ sources) at fdefc700
>> QEIC (64 IRQ sources) at fdefb080
>> PID hash table entries: 1024 (order: 10, 4096 bytes)
>> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
>> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
>> Memory: 257280k/262144k available (2152k kernel code, 4624k reserved,
>> 96k
>> data,
>> 80k bss, 128k init)
>> Mount-cache hash table entries: 512
>> NET: Registered protocol family 16
>>
>> Generic PHY: Registered new driver
>> SCSI subsystem initialized
>> NET: Registered protocol family 2
>> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
>> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
>> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
>> TCP: Hash tables configured (established 8192 bind 8192)
>> TCP reno registered
>> JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
>> io scheduler noop registered
>> io scheduler anticipatory registered (default)
>> io scheduler deadline registered
>> io scheduler cfq registered
>> Generic RTC Driver v1.07
>> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
>> disabled
>> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
>> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
>> console handover: boot [udbg0] -> real [ttyS1]
>>
>> Regards
>> Surendra
>>
>>
>>
>>> On Mon, Aug 18, 2008 at 07:52:12AM -0400, richw@netcomuk.co.uk wrote:
>>>
>>>> We've got an 8347 based board very similar to the A&M asp8347. Core
>>>> clock
>>>> is 400MHz. Bus clock is 266666666Hz.
>>>> According to the data sheet for the 8347, the decrementer clock runs
>>>> at
>>>> a
>>>> quarter of the rate of the bus clock. I have two questions:
>>>> In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to
>>>> dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my
>>>> system clock runs approximately 4 times too fast.
>>>> Can anyone point me in the direction of an explanation for the div by
>>>> 16
>>>> rather than 4?
>>>>
>>> It's a bug, which I pointed out here:
>>> http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html
>>>
>>>
>>>> If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is
>>>> passed
>>>> in, then the clock runs more accurately. However, its still not
>>>> correct.
>>>> This gives a decrementer frequency of 66666666Hz, but if I hard code
>>>> the
>>>> value to 66000000Hz, the clock runs accurately.
>>>> Can anyone shed any light on why the value passed in by the boot
>>>> loader
>>>> (redboot) seems to be inaccurate.
>>>>
>>> Redboot probably has the wrong crystal frequency hardcoded.
>>>
>>> -Scott
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
>>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Eran Liberty @ 2008-08-19 14:21 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, linux-kernel,
Steven Rostedt
In-Reply-To: <20080819130533.GA18611@Krystal>
Mathieu Desnoyers wrote:
> Can you also give us
>
> objdump -S --start-address=0xC00BB724 vmlinux | head 20
>
> ?
>
> Then we could compare the result with the OOPS instruction dump :
>
> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
>
> Mathieu
>
>
to give you more context I have run:
> powerpc-linux-gnu-objdump -S --start-address=0xC00BB700 vmlinux |
head -n 60
the discrepancy starts at address:
c00bb720: 40 82 00 30 <=> 40 82 00 2f
c00bb724: 4b ff fe 61 <=> 00 00 00 00
vmlinux: file format elf32-powerpc
Disassembly of section .text:
c00bb700 <d_lookup+0x1c>:
* d_lookup() is protected against the concurrent renames in some unrelated
* directory using the seqlockt_t rename_lock.
*/
struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
{
c00bb700: 7c 3f 0b 78 mr r31,r1
c00bb704: 90 01 00 24 stw r0,36(r1)
c00bb708: 7c 7c 1b 78 mr r28,r3
c00bb70c: 7c 9d 23 78 mr r29,r4
c00bb710: 83 db 32 a0 lwz r30,12960(r27)
{
unsigned ret;
repeat:
ret = sl->sequence;
smp_rmb();
c00bb714: 73 c0 00 01 andi. r0,r30,1
struct dentry * dentry = NULL;
unsigned long seq;
do {
seq = read_seqbegin(&rename_lock);
dentry = __d_lookup(parent, name);
c00bb718: 7f 83 e3 78 mr r3,r28
c00bb71c: 7f a4 eb 78 mr r4,r29
if (unlikely(ret & 1)) {
c00bb720: 40 82 00 30 bne- c00bb750 <d_lookup+0x6c>
c00bb724: 4b ff fe 61 bl c00bb584 <__d_lookup>
if (dentry)
c00bb728: 2f 83 00 00 cmpwi cr7,r3,0
c00bb72c: 40 9e 00 30 bne- cr7,c00bb75c <d_lookup+0x78>
*
* If sequence value changed then writer changed data while in section.
*/
static __always_inline int read_seqretry(const seqlock_t *sl, unsigned
start)
{
smp_rmb();
c00bb730: 80 1b 32 a0 lwz r0,12960(r27)
break;
} while (read_seqretry(&rename_lock, seq));
c00bb734: 7f 80 f0 00 cmpw cr7,r0,r30
c00bb738: 41 9e 00 24 beq- cr7,c00bb75c <d_lookup+0x78>
/* Start of read calculation -- fetch last complete writer token */
static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
{
unsigned ret;
repeat:
c00bb73c: 7c 1e 03 78 mr r30,r0
ret = sl->sequence;
smp_rmb();
c00bb740: 73 c0 00 01 andi. r0,r30,1
struct dentry * dentry = NULL;
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-19 14:42 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, linux-kernel,
Steven Rostedt
In-Reply-To: <48AAD702.10700@extricom.com>
* Eran Liberty (liberty@extricom.com) wrote:
> Mathieu Desnoyers wrote:
>> Can you also give us
>>
>> objdump -S --start-address=0xC00BB724 vmlinux | head 20
>>
>> ?
>>
>> Then we could compare the result with the OOPS instruction dump :
>>
>> 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0
>> 73c00001 7f83e378 7fa4eb78 4082002f <00000000> 2f830000 409e0030 801b32a0
>>
>> Mathieu
>>
>>
>
> to give you more context I have run:
> > powerpc-linux-gnu-objdump -S --start-address=0xC00BB700 vmlinux | head -n
> 60
>
> the discrepancy starts at address:
> c00bb720: 40 82 00 30 <=> 40 82 00 2f
> c00bb724: 4b ff fe 61 <=> 00 00 00 00
>
Ah !
I think I see what could be wrong :
First we have :
static unsigned int ftrace_nop = 0x60000000;
We probably replace the original function call by this nop.
Then we do :
notrace unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static unsigned int op;
/*
* It would be nice to just use create_function_call, but that will
* update the code itself. Here we need to just return the
* instruction that is going to be modified, without modifying the
* code.
*/
addr = GET_ADDR(addr);
/* Set to "bl addr" */
op = 0x48000001 | (ftrace_calc_offset(ip, addr) & 0x03fffffc);
/*
* No locking needed, this must be called via kstop_machine
* which in essence is like running on a uniprocessor machine.
*/
return (unsigned char *)&op;
}
And I guess we must be doing a 0x48000001 | 0x0; or something ?
Also, we have to consider that POWERPC 64 functions are :
/* PowerPC64's functions are data that points to the functions */
And this does not seem to hold for ppc32. Therefore, it is strange to me
that the same code is used for the update.. are we updating the correct
site ?
Mathieu
> vmlinux: file format elf32-powerpc
>
> Disassembly of section .text:
>
> c00bb700 <d_lookup+0x1c>:
> * d_lookup() is protected against the concurrent renames in some unrelated
> * directory using the seqlockt_t rename_lock.
> */
>
> struct dentry * d_lookup(struct dentry * parent, struct qstr * name)
> {
> c00bb700: 7c 3f 0b 78 mr r31,r1
> c00bb704: 90 01 00 24 stw r0,36(r1)
> c00bb708: 7c 7c 1b 78 mr r28,r3
> c00bb70c: 7c 9d 23 78 mr r29,r4
> c00bb710: 83 db 32 a0 lwz r30,12960(r27)
> {
> unsigned ret;
>
> repeat:
> ret = sl->sequence;
> smp_rmb();
> c00bb714: 73 c0 00 01 andi. r0,r30,1
> struct dentry * dentry = NULL;
> unsigned long seq;
>
> do {
> seq = read_seqbegin(&rename_lock);
> dentry = __d_lookup(parent, name);
> c00bb718: 7f 83 e3 78 mr r3,r28
> c00bb71c: 7f a4 eb 78 mr r4,r29
> if (unlikely(ret & 1)) {
> c00bb720: 40 82 00 30 bne- c00bb750 <d_lookup+0x6c>
> c00bb724: 4b ff fe 61 bl c00bb584 <__d_lookup>
> if (dentry)
> c00bb728: 2f 83 00 00 cmpwi cr7,r3,0
> c00bb72c: 40 9e 00 30 bne- cr7,c00bb75c <d_lookup+0x78>
> *
> * If sequence value changed then writer changed data while in section.
> */
> static __always_inline int read_seqretry(const seqlock_t *sl, unsigned
> start)
> {
> smp_rmb();
> c00bb730: 80 1b 32 a0 lwz r0,12960(r27)
> break;
> } while (read_seqretry(&rename_lock, seq));
> c00bb734: 7f 80 f0 00 cmpw cr7,r0,r30
> c00bb738: 41 9e 00 24 beq- cr7,c00bb75c <d_lookup+0x78>
> /* Start of read calculation -- fetch last complete writer token */
> static __always_inline unsigned read_seqbegin(const seqlock_t *sl)
> {
> unsigned ret;
>
> repeat:
> c00bb73c: 7c 1e 03 78 mr r30,r0
> ret = sl->sequence;
> smp_rmb();
> c00bb740: 73 c0 00 01 andi. r0,r30,1
> struct dentry * dentry = NULL;
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH] powerpc/spufs: Remove invalid semicolon after if statement
From: Jeremy Kerr @ 2008-08-19 14:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Ilpo Järvinen, paulus, Christian Krafft
In-Reply-To: <Pine.LNX.4.64.0808190845570.4551@wrl-59.cs.helsinki.fi>
Hi Ilpo,
> - if (new_state == SPU_UTIL_USER);
> + if (new_state == SPU_UTIL_USER)
Thanks, good catch. applied to spufs.git.
Jeremy
^ permalink raw reply
* Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
From: Anton Vorontsov @ 2008-08-19 14:50 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Brownell, Greg Kroah-Hartman, linux-usb, linux-kernel,
linuxppc-dev, Li Yang, Timur Tabi
In-Reply-To: <200808191126.33133.laurentp@cse-semaphore.com>
On Tue, Aug 19, 2008 at 11:26:28AM +0200, Laurent Pinchart wrote:
[...]
> > I didn't say "SOC-specific". I said "SOC-model specific", which
> > means that the driver would be not portable even across QE chips
> > (i.e. MPC8323 vs. MPC8360, you can assume that the "CLK12" function
> > is having same PAR/ODR/DAT/DIR bits).
>
> If I'm not mistaken, the PAR bit is used to select between GPIO and
> dedicated mode by definition. It should be safe to assume that setting
> a GPIO in dedicated mode requires the PAR bit to be set. But as I
> stated above, we can ignore that for now until a hardware use case
> comes up.
One more thing: you're assuming that there is one par bit, but
there are two par bits for QE chips. Which one would you set in
set_dedicated()? ;-)
> > > > > If, for some
> > > > > reason (driver not loaded, ...), no GPIO user shows up for that
> > > > > pin, it will stay configured in dedicated mode.
> > > >
> > > > Yes.
> > > >
> > > > > It might be better to set the PAR bit unconditionally in
> > > >
> > > > Why it might be better?
> > >
> > > Because, as explained a few lines down, the board initialization code
> > > will be able to configure a pin in a known state (PAR not set) at boot
> > > time until a driver requests the pin to be switched to dedicated mode.
> >
> > You can do this as I described above. But prior to this, yes, you have
> > to configure the pins and let Linux save these values. There is no other
> > way to pass this information, unfortunately.
>
> Ok.
>
> I started implementing CPM2 dedicated mode support to be used in the
> CPM UART driver for RTS/CTS flow control, and soon realized there was
> a show stopper. The CPM UART driver is mostly CPM1/CPM2 agnostic.
> I can't use a function such as cpm2_gpio32_set_dedicated, as that
> wouldn't work on a CPM1 (at least not on all its ports). I could call
> the right function depending on which port the GPIO is on, but that's
> really hackish and would defeat the purpose of using GPIOs.
You can easily refactor cpm gpio code so that you'll have
common cpm structure with platform-specific "GPIO API extension"
callbacks. Something like this:
/*
* generic structure, does not know anything about cpm1/2/qe, or
* ports width.
*/
struct cpm_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
void (*set_dedicated)(unsigned int gpio);
};
struct cpm1_gpio16_chip {
struct cpm_gpio_chip cpgc;
/* shadowed data register to clear/set bits safely */
u16 cpdata;
};
void cpm_gpio_set_dedicated(unsigned int gpio)
{
struct gpio_chip *gc = gpio_to_chip(gpio);
struct of_gpio_chip *ofgc = to_of_gpio_chip(gc);
struct cpm_gpio_chip *cpgc = to_cpm_gpio_chip(ofgc);
if (cpgc->set_dedicated)
cpgc->set_dedicated(gc->base - gpio);
}
> What we
> really need there is a set_dedicated/set_option/set_whatever function
> in the GPIO API :-/
Won't happen. ;-)
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 0/9] Rework PowerPC 44x board support
From: Josh Boyer @ 2008-08-19 15:36 UTC (permalink / raw)
To: linuxppc-dev
The following patch series reworks the board support code for PowerPC 44x
platforms. It eliminates a number of redundant <board>.c files and add a
ppc44x_simple.c file that has an explicit list of boards that are supported
by it. This is the same mechanism that Grant Likely has used for MPC 5200
boards.
It also adds some more explicit support for Glacier and Yosemite boards, as
those boards were using a board level compatible property in their DTS files
that was a bit confusing.
Review would be appreciated. Tested on Sequoia, and I plan on testing on as
many boards as I can before committing to my tree.
josh
Josh Boyer (9):
powerpc/44x: Add PowerPC 44x simple platform support
powerpc/44x: Migrate Bamboo support to ppc44x_simple
powerpc/44x: Migrate Canyonlands support to ppc44x_simple
powerpc/44x: Migrate Katmai support to ppc44x_simple
powerpc/44x: Migrate Rainier support to ppc44x_simple
powerpc/44x: Migrate Sequoia support to ppc44x_simple
powerpc/44x: Migrate Taishan support to ppc44x_simple
powerpc/44x: Add explicit support for AMCC Glacier
powerpc/44x: Add explicit Yosemite support
arch/powerpc/boot/dts/glacier.dts | 2 +-
arch/powerpc/boot/dts/yosemite.dts | 2 +-
arch/powerpc/platforms/44x/Kconfig | 25 ++++++++
arch/powerpc/platforms/44x/Makefile | 8 +--
arch/powerpc/platforms/44x/bamboo.c | 62 ---------------------
arch/powerpc/platforms/44x/canyonlands.c | 63 ---------------------
arch/powerpc/platforms/44x/katmai.c | 62 ---------------------
arch/powerpc/platforms/44x/ppc44x_simple.c | 83 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/rainier.c | 62 ---------------------
arch/powerpc/platforms/44x/sequoia.c | 63 ---------------------
arch/powerpc/platforms/44x/taishan.c | 72 ------------------------
11 files changed, 111 insertions(+), 393 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/bamboo.c
delete mode 100644 arch/powerpc/platforms/44x/canyonlands.c
delete mode 100644 arch/powerpc/platforms/44x/katmai.c
create mode 100644 arch/powerpc/platforms/44x/ppc44x_simple.c
delete mode 100644 arch/powerpc/platforms/44x/rainier.c
delete mode 100644 arch/powerpc/platforms/44x/sequoia.c
delete mode 100644 arch/powerpc/platforms/44x/taishan.c
^ permalink raw reply
* [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
From: Josh Boyer @ 2008-08-19 15:25 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
This adds a common board file for almost all of the "simple" PowerPC 44x
boards that exist today. This is intended to be a single place to add
support for boards that do not differ in platform support from most of the
evaluation boards that are used as reference platforms. Boards that have
specific requirements or custom hardware setup should still have their own
board.c file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 7 +++
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/ppc44x_simple.c | 81 ++++++++++++++++++++++++++++
3 files changed, 89 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/ppc44x_simple.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 249ba01..97c634c 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -127,6 +127,13 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config PPC44x_SIMPLE
+ bool "Simple PowerPC 44x board support"
+ depends on 44x
+ default n
+ help
+ This option enables the simple PowerPC 44x platform support.
+
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 8d0b1a1..73c1df5 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_44x) := misc_44x.o idle.o
+obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
new file mode 100644
index 0000000..067cddb
--- /dev/null
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -0,0 +1,81 @@
+/*
+ * Generic PowerPC 44x platform support
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * This implements simple platform support for PowerPC 44x chips. This is
+ * mostly used for eval boards or other simple and "generic" 44x boards. If
+ * your board has custom functions or hardware, then you will likely want to
+ * implement your own board.c file to accommodate it.
+ */
+
+#include <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+
+static __initdata struct of_device_id ppc44x_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc44x_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc44x_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
+
+static char *board[] __initdata = {
+ "amcc,bamboo",
+ "amcc,cayonlands",
+ "ibm,ebony",
+ "amcc,katmai",
+ "amcc,rainier",
+ "amcc,sequoia",
+ "amcc,taishan",
+ NULL
+};
+
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(root, board[i]))
+ break;
+ i++;
+ }
+
+ if (board[i] != NULL) {
+ ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ return 1;
+ }
+
+ return 0;
+}
+
+define_machine(ppc44x_simple) {
+ .name = "PowerPC 44x Platform",
+ .probe = ppc44x_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/9] powerpc/44x: Migrate Bamboo support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Bamboo board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 2 +
arch/powerpc/platforms/44x/Makefile | 2 -
arch/powerpc/platforms/44x/bamboo.c | 62 -----------------------------------
3 files changed, 2 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/bamboo.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 97c634c..0958285 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -2,6 +2,7 @@ config BAMBOO
bool "Bamboo"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EP
select PCI
help
@@ -90,6 +91,7 @@ config YOSEMITE
bool "Yosemite"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EP
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 73c1df5..ca18a32 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -2,8 +2,6 @@ obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
-obj-$(CONFIG_BAMBOO) += bamboo.o
-obj-$(CONFIG_YOSEMITE) += bamboo.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
deleted file mode 100644
index cef169e..0000000
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Bamboo board specific routines
- *
- * Wade Farnsworth <wfarnsworth@mvista.com>
- * Copyright 2004 MontaVista Software Inc.
- *
- * Rewritten and ported to the merged powerpc tree:
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- * Copyright 2007 IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id bamboo_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init bamboo_device_probe(void)
-{
- of_platform_bus_probe(NULL, bamboo_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(bamboo, bamboo_device_probe);
-
-static int __init bamboo_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,bamboo"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(bamboo) {
- .name = "Bamboo",
- .probe = bamboo_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/9] powerpc/44x: Migrate Canyonlands support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Canyonlands board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/44x/Makefile | 1 -
arch/powerpc/platforms/44x/canyonlands.c | 63 ------------------------------
3 files changed, 1 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0958285..92ba2d8 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -81,6 +81,7 @@ config CANYONLANDS
bool "Canyonlands"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index ca18a32..0ab626d 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -8,5 +8,4 @@ obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
-obj-$(CONFIG_CANYONLANDS) += canyonlands.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
deleted file mode 100644
index 3949289..0000000
--- a/arch/powerpc/platforms/44x/canyonlands.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Canyonlands board specific routines
- *
- * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
- *
- * Based on the Katmai code by
- * Benjamin Herrenschmidt <benh@kernel.crashing.org>
- * Copyright 2007 IBM Corp.
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- * Copyright 2007 IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id canyonlands_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init canyonlands_device_probe(void)
-{
- of_platform_bus_probe(NULL, canyonlands_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(canyonlands, canyonlands_device_probe);
-
-static int __init canyonlands_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,canyonlands"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(canyonlands) {
- .name = "Canyonlands",
- .probe = canyonlands_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 4/9] powerpc/44x: Migrate Katmai support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Katmai board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/44x/Makefile | 1 -
arch/powerpc/platforms/44x/katmai.c | 62 -----------------------------------
3 files changed, 1 insertions(+), 63 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/katmai.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 92ba2d8..66d4499 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -49,6 +49,7 @@ config KATMAI
bool "Katmai"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440SPe
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 0ab626d..2eb1cbe 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,7 +4,6 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
-obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/katmai.c b/arch/powerpc/platforms/44x/katmai.c
deleted file mode 100644
index 44f4b3a..0000000
--- a/arch/powerpc/platforms/44x/katmai.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Katmai board specific routines
- *
- * Benjamin Herrenschmidt <benh@kernel.crashing.org>
- * Copyright 2007 IBM Corp.
- *
- * Based on the Bamboo code by
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- * Copyright 2007 IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id katmai_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init katmai_device_probe(void)
-{
- of_platform_bus_probe(NULL, katmai_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(katmai, katmai_device_probe);
-
-static int __init katmai_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,katmai"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(katmai) {
- .name = "Katmai",
- .probe = katmai_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 5/9] powerpc/44x: Migrate Rainier support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Rainier board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/44x/Makefile | 1 -
arch/powerpc/platforms/44x/rainier.c | 62 ----------------------------------
3 files changed, 1 insertions(+), 63 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/rainier.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 66d4499..89e7f1f 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -60,6 +60,7 @@ config RAINIER
bool "Rainier"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440GRX
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 2eb1cbe..c201af6 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -4,7 +4,6 @@ obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
-obj-$(CONFIG_RAINIER) += rainier.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/rainier.c b/arch/powerpc/platforms/44x/rainier.c
deleted file mode 100644
index 4f1ff84..0000000
--- a/arch/powerpc/platforms/44x/rainier.c
+++ /dev/null
@@ -1,62 +0,0 @@
-/*
- * Rainier board specific routines
- *
- * Valentine Barshak <vbarshak@ru.mvista.com>
- * Copyright 2007 MontaVista Software Inc.
- *
- * Based on the Bamboo code by
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- * Copyright 2007 IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id rainier_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init rainier_device_probe(void)
-{
- of_platform_bus_probe(NULL, rainier_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(rainier, rainier_device_probe);
-
-static int __init rainier_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,rainier"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(rainier) {
- .name = "Rainier",
- .probe = rainier_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 6/9] powerpc/44x: Migrate Sequoia support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Sequoia board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/44x/Makefile | 1 -
arch/powerpc/platforms/44x/sequoia.c | 63 ----------------------------------
3 files changed, 1 insertions(+), 64 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/sequoia.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 89e7f1f..84e2a70 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -31,6 +31,7 @@ config SEQUOIA
bool "Sequoia"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440EPX
help
This option enables support for the AMCC PPC440EPX evaluation board.
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index c201af6..a8a92c1 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
-obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
deleted file mode 100644
index 49eb73d..0000000
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Sequoia board specific routines
- *
- * Valentine Barshak <vbarshak@ru.mvista.com>
- * Copyright 2007 MontaVista Software Inc.
- *
- * Based on the Bamboo code by
- * Josh Boyer <jwboyer@linux.vnet.ibm.com>
- * Copyright 2007 IBM Corporation
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id sequoia_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init sequoia_device_probe(void)
-{
- of_platform_bus_probe(NULL, sequoia_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(sequoia, sequoia_device_probe);
-
-static int __init sequoia_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,sequoia"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(sequoia) {
- .name = "Sequoia",
- .probe = sequoia_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 7/9] powerpc/44x: Migrate Taishan support to ppc44x_simple
From: Josh Boyer @ 2008-08-19 15:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Migrate the AMCC Taishan board to use the ppc44x_simple platform file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/44x/Makefile | 1 -
arch/powerpc/platforms/44x/taishan.c | 72 ----------------------------------
3 files changed, 1 insertions(+), 73 deletions(-)
delete mode 100644 arch/powerpc/platforms/44x/taishan.c
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 84e2a70..e0bea83 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -40,6 +40,7 @@ config TAISHAN
bool "Taishan"
depends on 44x
default n
+ select PPC44x_SIMPLE
select 440GX
select PCI
help
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index a8a92c1..6981331 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,7 +1,6 @@
obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_PPC44x_SIMPLE) += ppc44x_simple.o
obj-$(CONFIG_EBONY) += ebony.o
-obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_WARP) += warp-nand.o
diff --git a/arch/powerpc/platforms/44x/taishan.c b/arch/powerpc/platforms/44x/taishan.c
deleted file mode 100644
index 49c78b2..0000000
--- a/arch/powerpc/platforms/44x/taishan.c
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Taishan board specific routines based off ebony.c code
- * original copyrights below
- *
- * Matt Porter <mporter@kernel.crashing.org>
- * Copyright 2002-2005 MontaVista Software Inc.
- *
- * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
- * Copyright (c) 2003-2005 Zultys Technologies
- *
- * Rewritten and ported to the merged powerpc tree:
- * Copyright 2007 David Gibson <dwg@au1.ibm.com>, IBM Corporation.
- *
- * Modified from ebony.c for taishan:
- * Copyright 2007 Hugh Blemings <hugh@au.ibm.com>, IBM Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- */
-
-#include <linux/init.h>
-#include <linux/of_platform.h>
-
-#include <asm/machdep.h>
-#include <asm/prom.h>
-#include <asm/udbg.h>
-#include <asm/time.h>
-#include <asm/uic.h>
-#include <asm/pci-bridge.h>
-#include <asm/ppc4xx.h>
-
-static __initdata struct of_device_id taishan_of_bus[] = {
- { .compatible = "ibm,plb4", },
- { .compatible = "ibm,opb", },
- { .compatible = "ibm,ebc", },
- {},
-};
-
-static int __init taishan_device_probe(void)
-{
- of_platform_bus_probe(NULL, taishan_of_bus, NULL);
-
- return 0;
-}
-machine_device_initcall(taishan, taishan_device_probe);
-
-/*
- * Called very early, MMU is off, device-tree isn't unflattened
- */
-static int __init taishan_probe(void)
-{
- unsigned long root = of_get_flat_dt_root();
-
- if (!of_flat_dt_is_compatible(root, "amcc,taishan"))
- return 0;
-
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
-
- return 1;
-}
-
-define_machine(taishan) {
- .name = "Taishan",
- .probe = taishan_probe,
- .progress = udbg_progress,
- .init_IRQ = uic_init_tree,
- .get_irq = uic_get_irq,
- .restart = ppc4xx_reset_system,
- .calibrate_decr = generic_calibrate_decr,
-};
--
1.5.5.1
^ permalink raw reply related
* [PATCH 8/9] powerpc/44x: Add explicit support for AMCC Glacier
From: Josh Boyer @ 2008-08-19 15:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Add explicit support for the AMCC Glacier eval board to Kconfig and the
ppc44x_simple file. Also removes the cayonlands compatible entry from the
DTS file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/glacier.dts | 2 +-
arch/powerpc/platforms/44x/Kconfig | 11 +++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
index 24cf0db..f3787a2 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -14,7 +14,7 @@
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,glacier";
- compatible = "amcc,glacier", "amcc,canyonlands";
+ compatible = "amcc,glacier";
dcr-parent = <&{/cpus/cpu@0}>;
aliases {
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index e0bea83..f8ef279 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -92,6 +92,17 @@ config CANYONLANDS
help
This option enables support for the AMCC PPC460EX evaluation board.
+config GLACIER
+ bool "Glacier"
+ depends on 44x
+ default n
+ select PPC44x_SIMPLE
+ select 460EX # Odd since it uses 460GT but the effects are the same
+ select PCI
+ select PPC4xx_PCI_EXPRESS
+ help
+ This option enables support for the AMCC PPC460GT evaluation board.
+
config YOSEMITE
bool "Yosemite"
depends on 44x
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 067cddb..4e78e04 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -43,6 +43,7 @@ machine_device_initcall(ppc44x_simple, ppc44x_device_probe);
static char *board[] __initdata = {
"amcc,bamboo",
"amcc,cayonlands",
+ "amcc,glacier",
"ibm,ebony",
"amcc,katmai",
"amcc,rainier",
--
1.5.5.1
^ permalink raw reply related
* [PATCH 9/9] powerpc/44x: Add explicit Yosemite support
From: Josh Boyer @ 2008-08-19 15:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
Add the Yosemite board to the explicitly supported list for ppc44x_simple
boards and remove the compatible entry for bamboo from the DTS file.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/yosemite.dts | 2 +-
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/yosemite.dts b/arch/powerpc/boot/dts/yosemite.dts
index e39422a..1fa3cb4 100644
--- a/arch/powerpc/boot/dts/yosemite.dts
+++ b/arch/powerpc/boot/dts/yosemite.dts
@@ -15,7 +15,7 @@
#address-cells = <2>;
#size-cells = <1>;
model = "amcc,yosemite";
- compatible = "amcc,yosemite","amcc,bamboo";
+ compatible = "amcc,yosemite";
dcr-parent = <&{/cpus/cpu@0}>;
aliases {
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 4e78e04..43b8db9 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -49,6 +49,7 @@ static char *board[] __initdata = {
"amcc,rainier",
"amcc,sequoia",
"amcc,taishan",
+ "amcc,yosemite",
NULL
};
--
1.5.5.1
^ permalink raw reply related
* [PATCH v2] powerpc, scc: duplicate SCC_UHC_USBCEN
From: roel kluin @ 2008-08-19 15:43 UTC (permalink / raw)
To: Kou Ishizaki; +Cc: paulus, linux-kernel, linuxppc-dev
In-Reply-To: <20080819.220200.-1300539182.kouish@swc.toshiba.co.jp>
Kou Ishizaki wrote:
>
> Roel,
>
>> untested, is it correct?
>
> Your patch is correct.
>
> Thanks for your pointing it out and sending the patch. I tested your
> patch and it works good.
>
> Fortunately, this bug is not fatal because it seems that the SCC-UHC
> sets SCC_UHC_USBEN and SCC_UHC_USBCEN at once.
>
>
> Your patch does not contain 'Signed-off-by' line. Could you re-post it
> with your sign?
Sorry for that and thanks for testing.
---
duplicate SCC_UHC_USBCEN
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_uhc.c b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
index d63b720..b086f33 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
@@ -31,7 +31,7 @@
static inline int uhc_clkctrl_ready(u32 val)
{
- const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
+ const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBEN;
return((val & mask) == mask);
}
^ permalink raw reply related
* [alsa-devel] [PATCH v2] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
From: roel kluin @ 2008-08-19 15:53 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Johannes Berg, alsa-devel, linux-kernel
In-Reply-To: <s5hbpzpxrfh.wl%tiwai@suse.de>
Takashi Iwai wrote:
> At Tue, 19 Aug 2008 08:15:05 +0200 (CEST),
> Johannes Berg wrote:
>> roel kluin wrote:
>>> untested, is it correct?
>> not a clue, do you know how long ago that was? :)
>> does the driver check endianness anywhere?
>
> AFAIK snd-aoa supports only bit-endian formats (at least in
> sound/aoa/soundbus/i2sbus-pcm.c), so this addition makes little
> sense.
>
> Better to drop the duplicated words there.
Thanks Johannes and Takashi,
FWIW this removes the duplicates.
---
Remove duplicate assignment of SNDRV_PCM_FMTBIT_S{16,24}_BE bits
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c b/sound/aoa/codecs/snd-aoa-codec-tas.c
index 7a16a33..6c515b2 100644
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
@@ -654,15 +654,13 @@ static struct snd_kcontrol_new bass_control = {
static struct transfer_info tas_transfers[] = {
{
/* input */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000,
.transfer_in = 1,
},
{
/* output */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000,
.transfer_in = 0,
},
^ permalink raw reply related
* Re: No output from SMC1 console with the 2.6.26 kernel (8xx based board)
From: Scott Wood @ 2008-08-19 16:13 UTC (permalink / raw)
To: Matvejchikov Ilya; +Cc: Ben Gardiner, linuxppc-embedded
In-Reply-To: <8496f91a0808190413y69817434v2e340454941f97a0@mail.gmail.com>
On Tue, Aug 19, 2008 at 03:13:54PM +0400, Matvejchikov Ilya wrote:
> Hi all,
>
> The problem was in incorrect (not full) brg-node definition. Instead of
> brg@119f0 {
> compatible = "fsl,cpm-brg", "fsl,cpm2-brg";
> reg = <119f0 10 115f0 10>;
> };
> there must be:
> brg@119f0 {
> compatible = "fsl,cpm-brg", "fsl,cpm2-brg";
> reg = <119f0 10 115f0 10>;
> clock-frequency = <my_clock_frequency>;
> };
>
> The PQ2 (and some others) DTS files needs to be updated.
No, the DTS files don't need to be updated -- u-boot (or whatever
firmware you use, or the bootwrapper) needs to fill in the frequency.
-Scott
^ permalink raw reply
* Re: [PATCH 4/5] powerpc: Make the 64-bit kernel as a position-independent executable
From: Geert Uytterhoeven @ 2008-08-19 16:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18594.15027.214064.283433@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2104 bytes --]
On Wed, 13 Aug 2008, Paul Mackerras wrote:
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -1163,7 +1163,9 @@ void __init early_init_devtree(void *params)
> parse_early_param();
>
> /* Reserve LMB regions used by kernel, initrd, dt, etc... */
> - lmb_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
> + lmb_reserve(0, __end_interrupts - _stext);
> + lmb_reserve(__pa(__end_interrupts),
> + klimit - (unsigned long)__end_interrupts);
> reserve_kdump_trampoline();
> reserve_crashkernel();
> early_reserve_mem();
This part broke ppc32:
| arch/powerpc/kernel/prom.c: In function 'early_init_devtree':
| arch/powerpc/kernel/prom.c:1166: error: '__end_interrupts' undeclared (first use in this function)
| arch/powerpc/kernel/prom.c:1166: error: (Each undeclared identifier is reported only once
| arch/powerpc/kernel/prom.c:1166: error: for each function it appears in.)
After applying the patch below, I was able to build and boot a kernel for the
Sequoia.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/kernel/prom.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1163,9 +1163,13 @@ void __init early_init_devtree(void *par
parse_early_param();
/* Reserve LMB regions used by kernel, initrd, dt, etc... */
+#ifdef CONFIG_PPC64
lmb_reserve(0, __end_interrupts - _stext);
lmb_reserve(__pa(__end_interrupts),
klimit - (unsigned long)__end_interrupts);
+#else
+ lmb_reserve(PHYSICAL_START, __pa(klimit) - PHYSICAL_START);
+#endif
reserve_kdump_trampoline();
reserve_crashkernel();
early_reserve_mem();
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-19 16:47 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Paul E. McKenney, linux-kernel, linuxppc-dev, Steven Rostedt,
Scott Wood, Eran Liberty
In-Reply-To: <20080819024707.GA22659@Krystal>
On Mon, 18 Aug 2008, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> >
> > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote:
> >
> > >
> > > > Hmm, this was originally copied from x86, where we did a cmpxchg, but that
> > > > is probably not needed since all of this is done in kstop_machine. Also,
> > > > only the "get" is needed. If we don't fault there, we wont fault on the
> > > > put (unless we have permissions wrong, and that would be a bug).
> > >
> > > Would it ? How do we make sure the kernel text is mapped writeable ?
> >
> > We map it writeable if FTRACE is enabled.
> >
>
> Argh. See text_poke(). It's there exactly for this purpose on x86.
>
OK, I just tried text_poke and it unfortunately fails. The problem is that
it requires that the text you are changing is aligned and fits on one
page. We have no control over that.
-- Steve
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Mathieu Desnoyers @ 2008-08-19 17:34 UTC (permalink / raw)
To: Steven Rostedt
Cc: Paul E. McKenney, linux-kernel, linuxppc-dev, Steven Rostedt,
Scott Wood, Eran Liberty
In-Reply-To: <alpine.DEB.1.10.0808191247001.28232@gandalf.stny.rr.com>
* Steven Rostedt (rostedt@goodmis.org) wrote:
>
>
> On Mon, 18 Aug 2008, Mathieu Desnoyers wrote:
>
> > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > >
> > > On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote:
> > >
> > > >
> > > > > Hmm, this was originally copied from x86, where we did a cmpxchg, but that
> > > > > is probably not needed since all of this is done in kstop_machine. Also,
> > > > > only the "get" is needed. If we don't fault there, we wont fault on the
> > > > > put (unless we have permissions wrong, and that would be a bug).
> > > >
> > > > Would it ? How do we make sure the kernel text is mapped writeable ?
> > >
> > > We map it writeable if FTRACE is enabled.
> > >
> >
> > Argh. See text_poke(). It's there exactly for this purpose on x86.
> >
>
> OK, I just tried text_poke and it unfortunately fails. The problem is that
> it requires that the text you are changing is aligned and fits on one
> page. We have no control over that.
>
> -- Steve
>
Ok, there are two cases where it's ok :
1 - in stop_machine, considering we are not touching code executed in
NMI handlers.
2 - when using my replace_instruction_safe() which uses a temporary
breakpoint when doing the instruction replacement.
In those cases you could use text_poke_early().
See
http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=arch/x86/kernel/immediate.c;h=7789e2c75bf03e645f15759d5dff0c1698493f92;hb=HEAD
For a use example. Basically it looks like :
360 pages[0] = virt_to_page((void *)bypass_eip);
361 vaddr = vmap(pages, 1, VM_MAP, PAGE_KERNEL);
362 BUG_ON(!vaddr);
363 text_poke_early(&vaddr[bypass_eip & ~PAGE_MASK],
364 (void *)addr, size);
365 /*
366 * Fill the rest with nops.
367 */
368 len = NR_NOPS - size;
369 add_nops((void *)
370 &vaddr[(bypass_eip & ~PAGE_MASK) + size],
371 len);
372 print_dbg_bytes("inserted nops",
373 &vaddr[(bypass_eip & ~PAGE_MASK) + size], len);
374 vunmap(vaddr);
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
From: Finn Thain @ 2008-08-19 17:23 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
When I build kernels with CONFIG_BOOTX_TEXT enabled I can't boot a PB 3400
with BootX. I get a black screen with "Welcome to Linux" at the top, then
it appears to hang. Debian kernels are configured this way and suffer the
same problem.
I don't know if Quik is affected. It is a bit of a hassle at install time
since the (mediabay) floppy drive can't co-exist with the (mediabay)
CDROM, so I'm using BootX to do the Debian install.
The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though
kernel.org 2.6.16 and later versions do.
Any ideas?
Tia,
Finn
^ permalink raw reply
* Re: qemu platform patches
From: Milton Miller @ 2008-08-19 17:51 UTC (permalink / raw)
To: Miklos Vajna; +Cc: ppcdev
In-Reply-To: <20080819021710.GK18960@genesis.frugalware.org>
On Aug 18, 2008, at 9:17 PM, Miklos Vajna wrote:
> Hi!
>
> I recently started to search for a solution to boot a Linux-2.6-based
> kernel in qemu-system-ppc.
>
> Google found two of your interesting patches:
> http://patchwork.ozlabs.org/linuxppc/patchcontent?id=13689
> http://patchwork.ozlabs.org/linuxppc/patchcontent?id=13690
...
> Sadly the build fails at your qemu.c, with:
>
> BOOTCC arch/powerpc/boot/qemu.o
> arch/powerpc/boot/qemu.c: In function 'tree_fixups':
> arch/powerpc/boot/qemu.c:203: warning: implicit declaration of
> function 'dt_find_initrd'
> arch/powerpc/boot/qemu.c: In function 'platform_init':
> arch/powerpc/boot/qemu.c:230: error: 'struct platform_ops' has no
> member named 'find_vmlinuz'
> make[1]: *** [arch/powerpc/boot/qemu.o] Error 1
> make: *** [zImage] Error 2
>
> Two questions:
>
> 1) Do you remember what was the exact commit you worked with, where
> qemu.c compiled fine? (In case you have newer patches somewhere, I'm
> interested as well :) )
From those messages, there were other patches posted about the same
time that did some radical splits to the zImage infrastructure code,
allowing it to become a helper instead of just a contained image.
And I do have later patches that were working (better). I have even
booted a linux-next kernel just before 2.6.27 opened, after doing some
fixups. However, I suffer from wanting to perferct the function of the
patches and never get the base part out :-). For instance, when
working with 2.6.27, I got ISA memory working and some video output.
Also, the ide-generic driver now has to be enabled on the command line
to give the same function we previously had. That, combined with
kernel for ppc-qemu is my hobby and my work keeps interrupting me.
The current state is: Rob Landley's Firmware Linux has a ppc_rom.bin
(and source) written by me that probes qemu nvram for the size of
memory, location of a command line (-append) and initrd (-initrd),
patching a device tree linked into it, then parses the kernel (or other
elf file) loaded via -elf a kernel and jumps into it whereever it was
loaded. The kernel has a corresponding platform patch that only
recognises qemu (based on the kernel patch you found). The version Rob
has works on 2.6.25.9 with serial, ide, and isa ne2000. Since then I
got isa memory to enable video (with hacks and you only see 1/4 of the
screen).
http://landley.net/hg/firmware/raw-file/6f1e69d7e7f5/sources/toys/make-
ppc_rom.tar.bz2
http://landley.net/hg/firmware/raw-file/59e22ea53e6a/sources/patches/
linux-ppcqemu.patch
http://landley.net/hg/firmware/raw-file/0d8e80202e94/sources/patches/
linux-2.6.23-ppcne2khack.patch
> 2) I'm not exactly sure about the build process in the case of qemu,
> using your patches.
>
> Am I right about I just have to compile the kernel, I'll be given a
> ppc_rom.bin and the usual vmlinux file, then I can boot these with
> qemu?
The version that you have built a rom out of the code in
arch/powerpc/boot after patching. The new version builds the rom in a
shell script. Either way, it activated by calling it ppc_rom.bin and
pointing QEMU's library drectory to it with the -L flag. This code
works for qemu -kernel when the kernel is patched to recogonise the
qemu platform specified in the device-tree.
Going forward, it probably needs to become a dtbImage or a combination
rom and optional image.
> Hopefully the rest is clear, currently I have 2.4.36.1 in qemu and it
> would be really time to upgrade to 2.6 :)
People were successfully able to get arch/ppc kernel to boot as last
ase 2.6.26, at least until they got to userspace. That doesn't provide
a way forward, as ppc is now removed, but it may provide a temporary
option.
I can't promise a timeframe, but I do want to get the patches updated
and out.
milton
^ permalink raw reply
* Re: [PATCH 0/9] Rework PowerPC 44x board support
From: Stefan Roese @ 2008-08-19 18:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
On Tuesday 19 August 2008, Josh Boyer wrote:
> The following patch series reworks the board support code for PowerPC 44x
> platforms. It eliminates a number of redundant <board>.c files and add a
> ppc44x_simple.c file that has an explicit list of boards that are supported
> by it. This is the same mechanism that Grant Likely has used for MPC 5200
> boards.
>
> It also adds some more explicit support for Glacier and Yosemite boards, as
> those boards were using a board level compatible property in their DTS
> files that was a bit confusing.
>
> Review would be appreciated. Tested on Sequoia, and I plan on testing on
> as many boards as I can before committing to my tree.
Looks great at first glance. I'll try to do some testing here too in the next
few days.
Thanks.
Best regards,
Stefan
^ 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