Re: PS3: Fix memory hotplug
> Paul, any thoughts here ? Should we add a lock ? That would mean being > careful as the LMB stuff can be called very early, and spinlock wants > things like PACA and possibly lockdep to be around.. Actually, we call early_init_devtree(), which populates the LMB, after we initialize the PACA and lockdep, so it -should- be safe to add a spinlock. Dave ? Any objection to adding a spinlock to the LMB code ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add irq_free_host() to free an irq_host
On Thu, 2008-05-08 at 14:23 +1000, Michael Ellerman wrote:
> +void irq_free_host(struct irq_host *host)
> +{
> + /* If it's still very early in boot we can't free, oh well. */
> + if (mem_init_done)
> + kfree(host);
> +}
Hrm... that means that a host that was allocated before mem_init_done
and freed later will call kfree on memory obtained from bootmem... no
good.
In which case do we need to free and irq host other than failure in
irq_alloc_host ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add irq_free_host() to free an irq_host
On Wed, 2008-05-14 at 23:55 -0700, Benjamin Herrenschmidt wrote:
> On Thu, 2008-05-08 at 14:23 +1000, Michael Ellerman wrote:
> > +void irq_free_host(struct irq_host *host)
> > +{
> > + /* If it's still very early in boot we can't free, oh well. */
> > + if (mem_init_done)
> > + kfree(host);
> > +}
>
> Hrm... that means that a host that was allocated before mem_init_done
> and freed later will call kfree on memory obtained from bootmem... no
> good.
God damn mem_init_done crap .. gah you're right.
> In which case do we need to free and irq host other than failure in
> irq_alloc_host ?
Well most code either doesn't check the return value, or panics. There's
two callers at the moment (after my patch) of irq_free_host(),
axon_msi.c and ipic.c - they both call free from the same function as
alloc so they're safe.
We could just do the free in irq_alloc_host()'s error path and have
irq_free_host() not actually free anything, just drop the reference
count. What a mess.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3: Fix memory hotplug
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Date: Wed, 14 May 2008 23:51:29 -0700 > > > Paul, any thoughts here ? Should we add a lock ? That would mean being > > careful as the LMB stuff can be called very early, and spinlock wants > > things like PACA and possibly lockdep to be around.. > > Actually, we call early_init_devtree(), which populates the LMB, after > we initialize the PACA and lockdep, so it -should- be safe to add a > spinlock. > > Dave ? Any objection to adding a spinlock to the LMB code ? No objections, just don't add any bugs. :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: powercp-next build failure
On Thu, May 15, Stephen Rothwell wrote:
> Today's linux-next build (sparc64 defconfig) fails like this:
>
> drivers/of/device.c: In function `modalias_show':
> drivers/of/device.c:66: error: implicit declaration of function
> `of_device_get_modalias'
>
> Caused by commit 140b932f8cb6cced10b96860651a198b1b89cbb9 ("[POWERPC]
> Create modalias file in sysfs for of_platform bus") from the powerpc-next
> tree as there is a definition and declaration of of_device_get_modalias
> only for powerpc. I reverted that commit for today.
Better fix it up because my patch was for 2.6.25, and I cant follow
mainline due to time constraints.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/4] powerpc: add i2c pins to dts and board setup
On May 15, 2008, at 1:47 AM, David Gibson wrote:
On Wed, May 14, 2008 at 06:25:11PM -0500, Scott Wood wrote:
[EMAIL PROTECTED] wrote:
From: Jochen Friedrich <[EMAIL PROTECTED]>
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++
arch/powerpc/boot/dts/mpc866ads.dts | 10 ++
arch/powerpc/boot/dts/mpc885ads.dts | 10 ++
arch/powerpc/platforms/82xx/mpc8272_ads.c|4
arch/powerpc/platforms/8xx/mpc86xads_setup.c |4
arch/powerpc/platforms/8xx/mpc885ads_setup.c |3 +++
6 files changed, 41 insertions(+)
diff -puN arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-
pins-to-dts-and-board-setup arch/powerpc/boot/dts/mpc8272ads.dts
--- a/arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-pins-to-
dts-and-board-setup
+++ a/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -217,6 +217,16 @@
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8272-i2c",
+"fsl,cpm2-i2c",
+"fsl,cpm-i2c";
+ reg = <11860 20 8afc 2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <2960>;
+ };
As I pointed out earlier, this patch is sticking dts-v0 style
constants
into a dts-v1 file. It will not work.
Enough of this. *Sends patch converting all remaining dts files to
v1*. With any luck we can merge that soon, and forget about the
mistakes of v0 forever.
The problem isn't that, its this patch is out of date with mainline
and needs to be respun. All the .dts it touches have already been
converted to v1.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Hi Question on External Interrupts
Hi, being new to low level details of PPC, I have this doubt on the external Interrupt openPIC of some platform like mpc8540ads. If at all, I request_irq on IRQ_EXT2 [say an example], and the interrupt handler is called, how do I know the line state of such an interrupt ? i.e is it low or high ? Actually I want to interface a spi or i2c slave device which also connects via an external Interrupt which generates and interrupt and my actions are based upon knowing the line status. [ Earlier interface was with arm architecture & GPIO and question must be naive]. Thanks ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3: Fix memory hotplug
Benjamin Herrenschmidt writes: > When you do an lmb_add you should probably also do an lmb_analyze to > update the total memory count etc... > > That leads to some interesting issues such as the LMB stuff wasn't > really meant to be dynamically modified after boot, and thus the kernel > has no locks in there. That can be an issue... > > Paul, any thoughts here ? Should we add a lock ? That would mean being > careful as the LMB stuff can be called very early, and spinlock wants > things like PACA and possibly lockdep to be around.. Either that, or we give in and use iomem_resource to track where system RAM is, as well as the other things in the physical address space, like other architectures do... Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Defer processing of interrupts when the CPU wakes from sleepmode
Thanks Paul. > > So, does power management patch from Scott Wood need to respin? > > No, because Scott's original patch did that too. Yes, one of scott's patchset did the same function too. So the patch http://patchwork.ozlabs.org/linuxppc/patch?id=18182 will conflict with your patch. That is why I asked you if we have to repsin scott's patchset. If have not feedback for Scott's patch, Could you merge Scott's power management to main tree? BTW, I noticed the NAP mode for 6xx didn't work for 83xx part. Did you try it on the other 6xx part? Thanks, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: powercp-next build failure
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Thu, 15 May 2008 19:24:23 +1000 > > drivers/of/device.c: In function `modalias_show': > > drivers/of/device.c:66: error: implicit declaration of function > > `of_device_get_modalias' > > Dave, how would you prefer to fix this? We could move > of_device_get_modalias into drivers/of/device.c, or I could simply > revert that commit. Feel free to move that function into drivers/of/device.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/4] powerpc: add i2c pins to dts and board setup
Hi David, >> As I pointed out earlier, this patch is sticking dts-v0 style constants >> into a dts-v1 file. It will not work. > > Enough of this. *Sends patch converting all remaining dts files to > v1*. With any luck we can merge that soon, and forget about the > mistakes of v0 forever. Many thanks :). I'll repost a fixed patch later. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/4] macintosh: replace deprecated __initcall with device_initcall
On Wed, 2008-05-14 at 23:41 -0700, Andrew Morton wrote:
> On Thu, 15 May 2008 16:28:28 +1000 Michael Ellerman <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2008-05-14 at 23:06 -0700, Andrew Morton wrote:
> > > On Thu, 15 May 2008 14:14:38 +1000 Paul Mackerras <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > [EMAIL PROTECTED] writes:
> > > >
> > > > > -__initcall(adb_init);
> > > > > +device_initcall(adb_init);
> > > >
> > > > There's no particular reason why this needs to go in 2.6.26, is there?
> > > > It looks to me like something that I should queue up for 2.6.27.
> > > >
> > >
> > > No, this make no difference in code generation - it's just a
> > > use-the-modern-interface thing.
> >
> > I missed the memo about __initcall being deprecated, or is it only
> > deprecated for use in device drivers?
> >
>
> It's just old-fashioned, that's all.
>
> #define pure_initcall(fn) __define_initcall("0",fn,0)
>
> #define core_initcall(fn) __define_initcall("1",fn,1)
> #define core_initcall_sync(fn)__define_initcall("1s",fn,1s)
> #define postcore_initcall(fn) __define_initcall("2",fn,2)
> #define postcore_initcall_sync(fn)__define_initcall("2s",fn,2s)
> #define arch_initcall(fn) __define_initcall("3",fn,3)
> #define arch_initcall_sync(fn)__define_initcall("3s",fn,3s)
> #define subsys_initcall(fn) __define_initcall("4",fn,4)
> #define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
> #define fs_initcall(fn) __define_initcall("5",fn,5)
> #define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
> #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
> #define device_initcall(fn) __define_initcall("6",fn,6)
> #define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
> #define late_initcall(fn) __define_initcall("7",fn,7)
> #define late_initcall_sync(fn)__define_initcall("7s",fn,7s)
>
> #define __initcall(fn) device_initcall(fn)
>
> See, we have the nicely-ordered foo_initcall()'s, and the old-fashioned
> legacy __initcall happens to map onto device_initcall().
>
> Such code should use device_initcall() directly. So we see at which
> stage in initcalls this function will be called.
Yeah fair enough.
A little git'ing tells me there were 31 new __initcall()'s added between
2.6.24 and 2.6.25, and there are 12 more lurking between 2.6.25 and
linux-next. They're breeding!
You can't stick a #warning inside a #define can you? How about:
#define __initcall(fn) \
do {\
int Use_device_initcall_not___initcall_please; \
device_initcall(fn);\
} while (0)
Which gives:
warning: unused variable ‘Use_device_initcall_not___initcall_please’
..
Yeah OK that was a joke.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Defer processing of interrupts when the CPU wakes from sleepmode
Liu Dave writes: > Thanks Paul for this patch. The patch looks like very nice. > But the users have to be aware of the LINK register (LR) not corrupted. Yes, if you set the _TLF_SLEEPING bit, you need to know what it does. :) > So, does power management patch from Scott Wood need to respin? No, because Scott's original patch did that too. > BTW, why the fast_exception_return does *not* need clear the reservation > with stwcx.? Because we haven't done anything that could have left a dangling reservation set. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: powercp-next build failure
> drivers/of/device.c: In function `modalias_show': > drivers/of/device.c:66: error: implicit declaration of function > `of_device_get_modalias' Dave, how would you prefer to fix this? We could move of_device_get_modalias into drivers/of/device.c, or I could simply revert that commit. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix for OProfile callgraph for Power 64 bit user apps
Carl Love writes:
> The following patch fixes the 64 bit user code backtrace
> which currently may hang the system.
What exactly is wrong with it?
Having now taken a much closer look, I now don't think Nate Case's
patch addresses this, since it only affects constant size arguments
<= 8 to copy_{to,from}_user_inatomic.
However, I don't see why your patch fixes anything. It means we do
two access_ok calls and two __copy_from_user_inatomic calls, for 8
bytes, at sp and at sp + 16, rather than doing one access_ok and
__copy_from_user_inatomic for 24 bytes at sp. Why does that make any
difference (apart from being slower)?
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Convert remaining dts-v0 files to v1
On Thu, 15 May 2008 16:46:39 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > At the moment we have a mixture of left-over version 0 and new-format > version 1 files in arch/powerpc/boot/dts. This is potentially > confusing to people new to the dts format attempting to figure it out. > > So, this patch converts all the as-yet unconverted dts v0 files and > converts them to v1. They're mechanically-converted, and not hand > tweaked so in some cases they're not 100% in keeping with usual v1 > style, but the convertor program does have some heuristics so the > discrepancies aren't too bad. > > I have checked that this patch produces no changes to the resulting > dtb binaries. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> The only dts affected that isn't something I maintain or wrote (holly) is the ps3.dts. How do we want to handle this one? I'd like to get it into my tree soon (today/tomorrow) as I'm queuing up patches for .27 at the moment. As for the 4xx and holly dts changes: Acked-by: Josh Boyer <[EMAIL PROTECTED]> josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
dead network on JS21 with tg3 driver after flowcontrol changes
Commit ef167e27039eeaea6d3cdd5c547b082e89840bdd ([TG3]: Fix supporting flowctrl code) breaks networking on IBM JS21 blade servers. If I revert this change from 2.6.26-rc2-git4, nfsroot for example will work again. There are no packages submitted, a tcpdump on a different host sees no broadcast messages. Any ideas how to fix this? What info do you need from the system? I started with arch/powerpc/configs/ppc64_defconfig and updated CONFIG_CMDLINE for nfsroot. tg3.c:v3.92 (May 2, 2008) tg3 :10:04.0: enabling device ( -> 0002) eth0: Tigon3 [partno(none) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:11:25:c9:07:22 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] WireSpeed[0] TSOcap[1] eth0: dma_rwctrl[76144000] dma_mask[40-bit] tg3 :10:04.1: enabling device ( -> 0002) eth1: Tigon3 [partno(none) rev 8003 PHY(5780)] (PCIX:133MHz:64-bit) 1000Base-SX Ethernet 00:11:25:c9:07:23 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1] eth1: dma_rwctrl[76144000] dma_mask[40-bit] ... full dmesg: Using pSeries machine description Page orders: linear mapping = 24, virtual = 12, io = 12 console [udbg0] enabled Partition configured for 2 cpus. CPU maps initialized for 1 thread per core (thread shift is 0) Starting Linux PPC64 #3 SMP Thu May 15 13:47:10 CEST 2008 - ppc64_pft_size= 0x19 physicalMemorySize= 0x7a00 htab_hash_mask= 0x3 - Initializing cgroup subsys cpuset Linux version 2.6.26-rc2-git4 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #3 SMP Thu May 15 13:47:10 CEST 2008 [boot]0012 Setup Arch Entering add_active_range(0, 0, 499712) 0 entries of 256 used PCI host bridge /[EMAIL PROTECTED] ranges: IO 0x0100f400..0x0100f43f -> 0x MEM 0x01008000..0x0100efff -> 0x8000 PPC64 nvram contains 8192 bytes Using dedicated idle loop Top of RAM: 0x7a00, Total RAM: 0x7a00 Memory hole size: 0MB Zone PFN ranges: DMA 0 -> 499712 Normal 499712 -> 499712 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 499712 On node 0 totalpages: 499712 DMA zone: 6832 pages used for memmap DMA zone: 0 pages reserved DMA zone: 492880 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap [boot]0015 Setup Done Built 1 zonelists in Zone order, mobility grouping on. Total pages: 492880 Kernel command line: debug panic=9 rw root=/dev/nfs nfsroot=10.10.4.97:/data/inst/nfs/olh ip=:eth1:dhcp [boot]0020 XICS Init [boot]0021 XICS Done pic: no ISA interrupt controller PID hash table entries: 4096 (order: 12, 32768 bytes) time_init: decrementer frequency = 14.318000 MHz time_init: processor frequency = 2597.40 MHz clocksource: timebase mult[1175e5e5] shift[22] registered clockevent: decrementer mult[3aa] shift[16] cpu[0] Console: colour dummy device 80x25 console handover: boot [udbg0] -> real [hvc0] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1942124k/1998848k available (8288k kernel code, 56096k reserved, 1412k data, 532k bss, 380k init) SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 Calibrating delay loop... 28.60 BogoMIPS (lpj=57216) Mount-cache hash table entries: 256 clockevent: decrementer mult[3aa] shift[16] cpu[1] Processor 1 found. Brought up 2 CPUs CPU0 attaching sched-domain: domain 0: span 0-1 groups: 0 1 CPU1 attaching sched-domain: domain 0: span 0-1 groups: 1 0 khelper used greatest stack depth: 12896 bytes left khelper used greatest stack depth: 12320 bytes left khelper used greatest stack depth: 11904 bytes left net_namespace: 936 bytes xor: measuring software checksum speed 8regs : 5830.000 MB/sec 8regs_prefetch: 4644.000 MB/sec 32regs: 5751.000 MB/sec 32regs_prefetch: 4601.000 MB/sec xor: using function: 8regs (5830.000 MB/sec) NET: Registered protocol family 16 IBM eBus Device Driver PCI: Probing PCI hardware IOMMU table initialized, virtual merging enabled PCI: Probing PCI hardware done SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 Switched to high resolution mode on CPU 0 Switched to high resolution mode on CPU 1 IP route cache hash table entries: 65536 (order: 7, 524288 bytes) TCP established hash table entries: 262144 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 262144 bind 65536) TCP reno registered NET: Registered protocol family 1 RTAS daemon started Total HugeTLB memory allocated, 0 JFS:
Re: [BUG] 2.6.26-rc1-git4 - task blocked on powerpc for more than 120 seconds
Kamalesh Babulal wrote: Adrian Bunk wrote: On Wed, May 07, 2008 at 06:52:53PM +0530, Kamalesh Babulal wrote: While running the ltp over the powerpc with the 2.6.26-rc1-git4 kernel, task get blocked for more 120 seconds and does not proceeds future. The task msgctl08 is a ipc testcase, which test the msgget(2) msgctl(2) syscalls. Thanks for your report. I assume this is reproducible? If yes, what was the last kernel that worked for you? This is reproducible on 2.6.26-rc1 and 2.6.26-rc1-git(s). 2.6.25 is the last know kernel to work. I've also added Pierre Peiffer and Nadia Derbey to the Cc since their recent ipc commits are my first suspects. Machine is stuck in the task, printing the following call trace more than 5000 times. The oom-killer invoked once in-between. INFO: task msgctl08:16248 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: [c000762435a0] [0001] 0x1 (unreliable) [c00076243770] [c0010acc] .__switch_to+0x128/0x16c [c00076243800] [c04b07a4] .schedule+0x7ac/0x890 [c000762438f0] [c04b2ba4] .rwsem_down_failed_common+0x260/0x2b0 [c000762439b0] [c04b2c60] .rwsem_down_read_failed+0x2c/0x44 [c00076243a60] [c04b1b84] .down_read+0x44/0x5c [c00076243af0] [c0295e10] .ipc_lock+0x34/0xe0 [c00076243b90] [c029690c] .ipc_lock_check+0x24/0x78 [c00076243c20] [c02972c0] .do_msgsnd+0xb0/0x3f8 [c00076243d10] [c0293ce8] .compat_sys_msgsnd+0x94/0xc0 [c00076243db0] [c0014418] .compat_sys_ipc+0x130/0x1f4 [c00076243e30] [c0008734] syscall_exit+0x0/0x40 msgctl08 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0 Call Trace: [c0001e1c7640] [c00101bc] .show_stack+0x70/0x1bc (unreliable) [c0001e1c76f0] [c00c2c78] .oom_kill_process+0x78/0x230 [c0001e1c77a0] [c00c3390] .out_of_memory+0x28c/0x320 [c0001e1c7870] [c00c70ac] .__alloc_pages_internal+0x364/0x468 [c0001e1c7980] [c00e83cc] .alloc_page_vma+0x120/0x14c [c0001e1c7a20] [c00e0224] .read_swap_cache_async+0x7c/0x160 [c0001e1c7ae0] [c00e035c] .swapin_readahead+0x54/0xd4 [c0001e1c7ba0] [c00d47e8] .handle_mm_fault+0x520/0x9d8 [c0001e1c7c80] [c04b5054] .do_page_fault+0x440/0x624 [c0001e1c7e30] [c00053fc] handle_page_fault+0x20/0x5c Mem-info: Node 0 DMA per-cpu: CPU0: hi:6, btch: 1 usd: 1 CPU1: hi:6, btch: 1 usd: 1 Node 1 DMA per-cpu: CPU0: hi:6, btch: 1 usd: 5 CPU1: hi:6, btch: 1 usd: 5 Active:31 inactive:2628 dirty:1 writeback:6 unstable:0 free:156 slab:13071 mapped:548 pagetables:41109 bounce:0 Node 0 DMA free:5312kB min:5760kB low:7168kB high:8640kB active:1024kB inactive:768kB present:3928832kB pages_scanned:3912 all_unreclaimable? no lowmem_reserve[]: 0 0 0 Node 1 DMA free:4672kB min:4992kB low:6208kB high:7488kB active:960kB inactive:169792kB present:3404992kB pages_scanned:140140 all_unreclaimable? no lowmem_reserve[]: 0 0 0 Node 0 DMA: 5*64kB 15*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 5312kB Node 1 DMA: 8*64kB 5*128kB 6*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB 0*8192kB 0*16384kB = 4736kB 8185 total pagecache pages Swap cache: add 29545, delete 21888, find 5602/10373 Free swap = 803712kB Total swap = 2048128kB 114688 pages of RAM 766 reserved pages 231218 pages shared 7657 pages swap cached Out of memory: kill process 15371 (msgctl08) score 39223 or a child Killed process 15373 (msgctl08) INFO: task msgctl08:15385 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: [c000e9a43290] [0001] 0x1 (unreliable) [c000e9a43460] [c0010acc] .__switch_to+0x128/0x16c [c000e9a434f0] [c04b07a4] .schedule+0x7ac/0x890 [c000e9a435e0] [c04b0d90] .io_schedule+0x7c/0xe8 [c000e9a43670] [c02d7f44] .get_request_wait+0x15c/0x1e0 [c000e9a43750] [c02d8950] .__make_request+0x3ec/0x4d8 [c000e9a43800] [c02d6624] .generic_make_request+0x35c/0x3b0 [c000e9a438e0] [c02d81b0] .submit_bio+0x118/0x140 [c000e9a439a0] [c00dfa88] .swap_readpage+0x94/0xb4 [c000e9a43a20] [c00e02b8] .read_swap_cache_async+0x110/0x160 [c000e9a43ae0] [c00e035c] .swapin_readahead+0x54/0xd4 [c000e9a43ba0] [c00d47e8] .handle_mm_fault+0x520/0x9d8 [c000e9a43c80] [c04b5054] .do_page_fault+0x440/0x624 [c000e9a43e30] [c00053fc] handle_page_fault+0x20/0x5c INFO: task msgctl08:15405 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Call Trace: [c000b1757290] [0001] 0x1 (unreliable) [c000b1757460] [c0010acc] .__switch_to+0x128/0x16c [c000b17574f0] [c04b07a4] .sch
Re: [PATCH 2/2] ftrace: support for PowerPC
On Wed, 14 May 2008, David Miller wrote: > From: Steven Rostedt <[EMAIL PROTECTED]> > Date: Wed, 14 May 2008 23:49:44 -0400 > > > +#ifdef CONFIG_FTRACE > > +#ifdef CONFIG_DYNAMIC_FTRACE > > +_GLOBAL(mcount) > > +_GLOBAL(_mcount) > > + stwur1,-48(r1) > > + stw r3, 12(r1) > > + stw r4, 16(r1) > > + stw r5, 20(r1) > > + stw r6, 24(r1) > > + mflrr3 > > + stw r7, 28(r1) > > + mfcrr5 > > + stw r8, 32(r1) > > + stw r9, 36(r1) > > + stw r10,40(r1) > > + stw r3, 44(r1) > > + stw r5, 8(r1) > > Yikes, that's really expensive. Well, at least with dynamic ftrace, it's only expensive when tracing is enabled. > > Can't you do a tail call and let the function you end > up calling do all the callee-saved register pops onto > the stack? Not sure PPC has such a thing. I'm only a hobby PPC hacker (did it full time in another life). If there is such a way, I'll be happy to Ack any patches. > > That's what I did on sparc. > So that was your secret! ;-) -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 39 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 12
arch/powerpc/boot/dts/mpc866ads.dts | 12
arch/powerpc/boot/dts/mpc885ads.dts | 12
arch/powerpc/platforms/82xx/mpc8272_ads.c|4 ++
arch/powerpc/platforms/8xx/mpc86xads_setup.c |4 ++
arch/powerpc/platforms/8xx/mpc885ads_setup.c |3 ++
7 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..b95f03a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2132,6 +2132,45 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ ix) I2C
+
+ The I2C controller is expressed as a bus under the CPM node.
+
+ Properties:
+ - compatible : "fsl,cpm1-i2c", "fsl,cpm2-i2c", "fsl,cpm-i2c"
+ - reg : On CPM2 devices, the second resource doesn't specify
+ the I2C Parameter RAM itself, but the I2C_BASE field
+ of the CPM2 Parameter RAM (typically 0x8afc 0x2).
+ - #address-cells : Should be one. The cell is the i2c device address with
+ the r/w bit set to zero.
+ - #size-cells : Should be zero.
+ - linux,i2c-index : Can be used to hard code an i2c bus nummer.
+ - linux,i2c-class : Can be used to override the i2c class. The class is used
+ by old style i2c device drivers to find a bus in a
+ specific context like system management, video or sound.
+ By default, I2C_CLASS_HWMON (1) is being used. The
+ definition of the classes can be found in
+ include/i2c/i2c.h
+
+ Example, based on mpc823:
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc823-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+ reg = <0x860 0x20 0x3c80 0x30>;
+ interrupts = <16>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ compatible = "dallas,ds1307";
+ reg = <0x68>;
+ };
+ };
+
m) Chipselect/Local Bus
Properties:
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 46e2da3..8ed1d22 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -217,6 +217,18 @@
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8272-i2c",
+"fsl,cpm2-i2c",
+"fsl,cpm-i2c";
+ reg = <0x11860 0x20 0x8afc 0x2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <0x2960>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts
b/arch/powerpc/boot/dts/mpc866ads.dts
index 765e43c..50565b5 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -171,6 +171,18 @@
fsl,cpm-command = <>;
linux,network-index = <1>;
};
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc866-i2c",
+"fsl,cpm1-i2c",
+"fsl,cpm-i2c";
+ reg = <0x860 0x20 0x3c80 0x30>;
+ interrupts = <16>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 9895043..d76331a 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -215,6 +215,18 @@
fsl,cpm-command = <0x80>;
[PATCH] 4xx: Fix PCI mem in rainier DTS
This fixes the PCI node in the Rainier to match the spec from AMCC. A similar fix was done for 440EPx, which shares the same values as 440GRx. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/rainier.dts |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts +++ linux-2.6/arch/powerpc/boot/dts/rainier.dts @@ -328,8 +328,9 @@ * later cannot be changed. Chip supports a second * IO range but we don't use it for now */ - ranges = <0200 0 8000 1 8000 0 1000 - 0100 0 1 e800 0 0010>; + ranges = <0200 0 8000 1 8000 0 4000 + 0100 0 1 e800 0 0001 + 0100 0 1 e880 0 0380>; /* Inbound 2GB range starting at 0 */ dma-ranges = <4200 0 0 0 0 0 8000>; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] 4xx: Workaround for CHIP_11 Errata
The PowerPC 440EP, 440GR, 440EPx, and 440GRx chips have an issue that
causes the PLB3-to-PLB4 bridge to wait indefinitely for transaction
requests that cross the end-of-memory-range boundary. Since the DDR
controller only returns the valid portion of a read request, the bridge
will prevent other PLB masters from completing their transactions.
This implements the recommended workaround for this errata for chips that
use older versions of firmware that do not already handle it. The last
4KiB of memory are hidden from the kernel to prevent the problem
transactions from occurring.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/4xx.c | 21 +
1 file changed, 21 insertions(+)
--- linux-2.6.orig/arch/powerpc/boot/4xx.c
+++ linux-2.6/arch/powerpc/boot/4xx.c
@@ -21,6 +21,25 @@
#include "reg.h"
#include "dcr.h"
+static unsigned long chip_11_errata(unsigned long memsize)
+{
+ unsigned long pvr;
+
+ pvr = mfpvr();
+
+ switch (pvr & 0xfff0) {
+ case 0x4850:
+ case 0x48d0:
+ case 0x28d0:
+ memsize -= 4096;
+ break;
+ default:
+ break;
+ }
+
+ return memsize;
+}
+
/* Read the 4xx SDRAM controller to get size of system memory. */
void ibm4xx_sdram_fixup_memsize(void)
{
@@ -34,6 +53,7 @@ void ibm4xx_sdram_fixup_memsize(void)
memsize += SDRAM_CONFIG_BANK_SIZE(bank_config);
}
+ memsize = chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
@@ -199,6 +219,7 @@ void ibm4xx_denali_fixup_memsize(void)
bank = 4; /* 4 banks */
memsize = cs * (1 << (col+row)) * bank * dpath;
+ memsize = chip_11_errata(memsize);
dt_fixup_memory(0, memsize);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/4] powerpc: fix for OProfile callgraph for Power 64 bit user apps
On Thu, 2008-05-15 at 13:58 +1000, Paul Mackerras wrote: > Michael Ellerman writes: > > > __copy_from_user_inatomic() accepts any value for n, it just has a > > special case for 1, 2, 4 and 8 - but it should still work for other > > values. > > There is a bug in __copy_from_user_inatomic that > > http://patchwork.ozlabs.org/linuxppc/patch?id=18418 > > fixes, and I'm about to send that Linus-wards. > > Carl, to what extent does that fix eliminate the need for the changes > in your patch? > > Paul. Paul: I will have to apply the above mentioned patch to see if it fixes the issue. What I found was when the original code tried to copy three unsigned long into stack_frame[3], i.e. 24 bytes my system consistently failed. The comment about 48 bytes is a note that is all that is guaranteed to be there according to the API. I found by restricting the copy to the values in the case statement, things worked. Carl Love ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
Olaf Hering wrote: > Any ideas how to fix this? > What info do you need from the system? Are you using eth0 or eth1? The dmesg below shows that link came up on eth1 and IP address from DHCP was received. > Sending DHCP requests .<6>tg3: eth1: Link is up at 1000 Mbps, > full duplex. > tg3: eth1: Flow control is off for TX and off for RX. > ., OK > IP-Config: Got DHCP answer from 10.10.4.97, my address is 10.10.1.110 > IP-Config: Complete: If you're using eth0 and link did not come up, please provide mii-tool -vvv eth0. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx: Workaround for CHIP_11 Errata
On Thursday 15 May 2008, Josh Boyer wrote: > The PowerPC 440EP, 440GR, 440EPx, and 440GRx chips have an issue that > causes the PLB3-to-PLB4 bridge to wait indefinitely for transaction > requests that cross the end-of-memory-range boundary. Since the DDR > controller only returns the valid portion of a read request, the bridge > will prevent other PLB masters from completing their transactions. > > This implements the recommended workaround for this errata for chips that > use older versions of firmware that do not already handle it. The last > 4KiB of memory are hidden from the kernel to prevent the problem > transactions from occurring. > > Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> Acked-by: Stefan Roese <[EMAIL PROTECTED]> Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
On Thursday 01 May 2008, Carl Love wrote:
> Finally, this patch backs out the changes previously added to the
> oprofile generic code for handling the architecture specific
> ops.sync_start and ops.sync_stop that allowed the architecture
> to skip the per CPU buffer creation.
Thanks for your patch, it looks a lot better than your previous version.
It would be good to have an oprofile person look into the changes
to the common code though.
Just a few more comments/questions this time:
> -static DEFINE_SPINLOCK(buffer_lock);
> +static DEFINE_SPINLOCK(add_value_lock);
> static DEFINE_SPINLOCK(cache_lock);
> static int num_spu_nodes;
> int spu_prof_num_nodes;
> int last_guard_val[MAX_NUMNODES * 8];
> +static int spu_ctx_sw_seen[MAX_NUMNODES * 8];
>
> /* Container for caching information about an active SPU task. */
> struct cached_info {
I noticed now that you are indexing arrays by SPU number. This is not
a good idea, because you make assumptions about the system that may
not be true. Better pass around 'struct spu' pointers and put those
values in there if you need them. Then again, the last_guard_val looks
like you should really store that information in the context instead
of the physical SPU, but that is something else to work on.
Let's leave this one as it is for now and fix the current bug at hand,
but please remember to fix the assumptions in the code later.
> @@ -289,6 +290,7 @@ static int process_context_switch(struct
> int retval;
> unsigned int offset = 0;
> unsigned long spu_cookie = 0, app_dcookie;
> + int cpu_buf;
>
> retval = prepare_cached_spu_info(spu, objectId);
> if (retval)
> @@ -303,17 +305,28 @@ static int process_context_switch(struct
> goto out;
> }
>
> - /* Record context info in event buffer */
> - spin_lock_irqsave(&buffer_lock, flags);
> - add_event_entry(ESCAPE_CODE);
> - add_event_entry(SPU_CTX_SWITCH_CODE);
> - add_event_entry(spu->number);
> - add_event_entry(spu->pid);
> - add_event_entry(spu->tgid);
> - add_event_entry(app_dcookie);
> - add_event_entry(spu_cookie);
> - add_event_entry(offset);
> - spin_unlock_irqrestore(&buffer_lock, flags);
> + /* Record context info in event buffer. Note, there are 4x more
> + * SPUs then CPUs. Map the SPU events/data for a given SPU to
> + * the same CPU buffer. Need to ensure the cntxt switch data and
> + * samples stay in order.
> + */
> + cpu_buf = spu->number >> 2;
The ratio of CPUs versus SPUs is anything but fixed, and the CPU numbers
may not start at 0. If you have a hypervisor (think PS3), or you are
running a non-SMP kernel, this is practically always wrong.
Please use get_cpu()/put_cpu() to read the current CPU number instead.
This one needs to be fixed now.
> + spin_lock_irqsave(&add_value_lock, flags);
> + oprofile_add_value(ESCAPE_CODE, cpu_buf);
> + oprofile_add_value(SPU_CTX_SWITCH_CODE, cpu_buf);
> + oprofile_add_value(spu->number, cpu_buf);
> + oprofile_add_value(spu->pid, cpu_buf);
> + oprofile_add_value(spu->tgid, cpu_buf);
> + oprofile_add_value(app_dcookie, cpu_buf);
> + oprofile_add_value(spu_cookie, cpu_buf);
> + oprofile_add_value(offset, cpu_buf);
> +
> + /* Set flag to indicate SPU PC data can now be written out. If
> + * the SPU program counter data is seen before an SPU context
> + * record is seen, the postprocessing will fail.
> + */
> + spu_ctx_sw_seen[spu->number] = 1;
> + spin_unlock_irqrestore(&add_value_lock, flags);
> smp_wmb(); /* insure spu event buffer updates are written */
> /* don't want entries intermingled... */
> out:
How does the spinlock protect you from racing against other values added
for the same CPU?
I'm not sure if this patch can still fix the original bug that you
are trying to solve, although it will certainly be harder to trigger.
If you are using the get_cpu() number for passing down the samples,
it is probably safe because you then can't add anything else to the
same buffer from a different CPU or from an interrupt, but I don't
understand enough about oprofile to be sure about that.
> - spin_lock_irqsave(&buffer_lock, flags);
> - add_event_entry(ESCAPE_CODE);
> - add_event_entry(SPU_PROFILING_CODE);
> - add_event_entry(num_spu_nodes);
> - spin_unlock_irqrestore(&buffer_lock, flags);
> + /* The SPU_PROFILING_CODE escape sequence must proceed
> + * the SPU context switch info.
> + */
> + for_each_online_cpu(cpu) {
> + oprofile_add_value(ESCAPE_CODE, cpu);
> + oprofile_add_value(SPU_PROFILING_CODE, cpu);
> + oprofile_add_value((unsigned long int)
> + num_spu_nodes, cpu);
> + }
>
You are no longer holding a lock while adding the events, which
may be correct as long as no switch_events come in, but it's
still inconsiste
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, May 15, Michael Chan wrote: > Olaf Hering wrote: > > > Any ideas how to fix this? > > What info do you need from the system? > > Are you using eth0 or eth1? The dmesg below shows that > link came up on eth1 and IP address from DHCP was received. I'm using eth1. The log was done with the patch reverted. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 0/3] Board-specific PCI fixups [was: Re: [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add support for ULI RTC]
On Thu, May 08, 2008 at 06:20:05PM +0400, Anton Vorontsov wrote: > On Mon, May 05, 2008 at 02:11:30PM -0500, Kumar Gala wrote: > > > > On May 5, 2008, at 1:56 PM, Anton Vorontsov wrote: > > > >> The ULI "Super South Bridge" contains ISA bridge to the legacy > >> devices, such as Super IO mouse/keyboard/floppy disk controllers, > >> parallel port, i8259 interrupt controller and so on. > >> > >> On the MPC8610HPCD, i8259 seems to be disabled (mpc8610_hpcd.c > >> confirms this), and other peripherals are not traced out. > >> So we use only RTC. > >> > >> This patch also adds ULI quirk to make RTC actually work (this > >> quirk differs a bit from the one in the fsl_uli1575.c). > > > > Can we just one quick for both? > > Probably yes, but fsl_uli1575 needs some other changes for this. > > This series fully tested on MPC8610HPCD, and build-tested for > MPC85xxDS and MPC8641HPCN. Are these patches ideal? No comments so far... ;-) Could we then apply this to the powerpc-next for proper testing? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 17:49 +0200, Olaf Hering wrote: > On Thu, May 15, Michael Chan wrote: > > > Olaf Hering wrote: > > > > > Any ideas how to fix this? > > > What info do you need from the system? > > > > Are you using eth0 or eth1? The dmesg below shows that > > link came up on eth1 and IP address from DHCP was received. > > I'm using eth1. > The log was done with the patch reverted. > In that case, please re-apply the patch and provide mii-tool -vvv eth1. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Using GPIO
Hello all, I'm trying to use the Xilinx GPIO from a user program. Since I haven't managed to compile their example (simon.c is given without a makefile), I wanted to try using /dev/gpio... So I added /dev/gpio0 c 666 0 0 10 185 - - - to device_table.txt when I generated my root filesystem with buildroot, but apparently this leads nowhere as it's not visible in /proc/devices. Is there some example or tutorial on how to use CONFIG_XILINX_GPIO ? Either as a device or as API calls... -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] ftrace: support for PowerPC
On Wed, May 14, 2008 at 10:28:57PM -0700, David Miller wrote: > From: Steven Rostedt <[EMAIL PROTECTED]> > Date: Wed, 14 May 2008 23:49:44 -0400 > > > +#ifdef CONFIG_FTRACE > > +#ifdef CONFIG_DYNAMIC_FTRACE > > +_GLOBAL(mcount) > > +_GLOBAL(_mcount) > > + stwur1,-48(r1) > > + stw r3, 12(r1) > > + stw r4, 16(r1) > > + stw r5, 20(r1) > > + stw r6, 24(r1) > > + mflrr3 > > + stw r7, 28(r1) > > + mfcrr5 > > + stw r8, 32(r1) > > + stw r9, 36(r1) > > + stw r10,40(r1) > > + stw r3, 44(r1) > > + stw r5, 8(r1) > > Yikes, that's really expensive. > > Can't you do a tail call and let the function you end > up calling do all the callee-saved register pops onto > the stack? The PPC32 ABI seems to (unfortunately) suggest that, with mcount, all registers are callee-saved (except for the modifiable-during-function-linkage registers like r0, r11, and r12) -- so mcount has to save the registers that the callee won't (because they're normally volatile). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/8 v3] mpc83xx_wdt rework, support for mpc8610 and mpc8xx
Hi all,
Once again thanks for the previous review, updated series follows.
Changes since v2:
- New patch to fix current driver's checkpatch issues;
- New patch supporting MPC8xx watchdogs (ok to drop until tested);
- Removed MODULE_ALIAS("platform:mpc83xx_wdt"), since this driver is no
longer on the platform bus;
- When renaming the driver also mention what kind of CPUs we support.
Also give a pointer for BookE watchdog driver. Though BookE users will
not see the MPC8xxx driver at all, because we're explicitly listing the
CPU families in "depends on". But this tip might be useful for
developers.
- Scott Wood noticed that we don't need device_type anymore. I thought
that OpenFirmware defines this type, but google didn't prove that.
So I just removed the device_type.
Changes since v1:
- Scott Wood asked for mpc83xx_wdt on multiplatform kernels. Done via
OF platform driver;
- Kumar Gala asked for mpc83xx_wdt -> mpc8xxx_wdt rename. Done in two
steps;
- Segher Boessenkool noticed a negligence in the wdt device tree node.
Fixed by removing mpc83xx_wdt compatible entry.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] [WATCHDOG] mpc83xx_wdt: fix checkpatch issues
Quite tired of these warnings ;-), checkpatch spitting them when
seeing the rename patch.
WARNING: Use #include instead of
#25: FILE: watchdog/mpc83xx_wdt.c:25:
+#include
WARNING: Use #include instead of
#26: FILE: watchdog/mpc83xx_wdt.c:26:
+#include
WARNING: line over 80 characters
#45: FILE: watchdog/mpc83xx_wdt.c:45:
+MODULE_PARM_DESC(timeout, "Watchdog timeout in ticks. (0start, sizeof (struct mpc83xx_wdt));
total: 0 errors, 5 warnings, 230 lines checked
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/mpc83xx_wdt.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index b16c5cd..6905712 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -22,8 +22,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
struct mpc83xx_wdt {
__be32 res0;
@@ -42,11 +42,13 @@ static struct mpc83xx_wdt __iomem *wd_base;
static u16 timeout = 0x;
module_param(timeout, ushort, 0);
-MODULE_PARM_DESC(timeout, "Watchdog timeout in ticks. (0start, sizeof (struct mpc83xx_wdt));
+ wd_base = ioremap(r->start, sizeof(struct mpc83xx_wdt));
if (wd_base == NULL) {
ret = -ENOMEM;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/8] [WATCHDOG] mpc83xx_wdt: convert to the OF platform driver
This patch simply converts mpc83xx_wdt to the OF platform driver so we
can directly work with the device tree without passing various stuff
through platform data.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/mpc83xx_wdt.c | 62 +++
1 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index 6905712..127d85e 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -19,11 +19,12 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
#include
+#include
struct mpc83xx_wdt {
__be32 res0;
@@ -149,53 +150,42 @@ static struct miscdevice mpc83xx_wdt_miscdev = {
.fops = &mpc83xx_wdt_fops,
};
-static int __devinit mpc83xx_wdt_probe(struct platform_device *dev)
+static int __devinit mpc83xx_wdt_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
{
- struct resource *r;
int ret;
- unsigned int *freq = dev->dev.platform_data;
+ u32 freq = fsl_get_sys_freq();
- /* get a pointer to the register memory */
- r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ if (!freq || freq == -1)
+ return -EINVAL;
- if (!r) {
- ret = -ENODEV;
- goto err_out;
- }
-
- wd_base = ioremap(r->start, sizeof(struct mpc83xx_wdt));
-
- if (wd_base == NULL) {
- ret = -ENOMEM;
- goto err_out;
- }
+ wd_base = of_iomap(ofdev->node, 0);
+ if (!wd_base)
+ return -ENOMEM;
ret = misc_register(&mpc83xx_wdt_miscdev);
if (ret) {
- printk(KERN_ERR "cannot register miscdev on minor=%d "
- "(err=%d)\n",
- WATCHDOG_MINOR, ret);
+ pr_err("cannot register miscdev on minor=%d (err=%d)\n",
+ WATCHDOG_MINOR, ret);
goto err_unmap;
}
/* Calculate the timeout in seconds */
if (prescale)
- timeout_sec = (timeout * 0x1) / (*freq);
+ timeout_sec = (timeout * 0x1) / freq;
else
- timeout_sec = timeout / (*freq);
+ timeout_sec = timeout / freq;
- printk(KERN_INFO "WDT driver for MPC83xx initialized. "
- "mode:%s timeout=%d (%d seconds)\n",
- reset ? "reset":"interrupt", timeout, timeout_sec);
+ pr_info("WDT driver for MPC83xx initialized. mode:%s timeout=%d "
+ "(%d seconds)\n", reset ? "reset" : "interrupt", timeout,
+ timeout_sec);
return 0;
-
err_unmap:
iounmap(wd_base);
-err_out:
return ret;
}
-static int __devexit mpc83xx_wdt_remove(struct platform_device *dev)
+static int __devexit mpc83xx_wdt_remove(struct of_device *ofdev)
{
misc_deregister(&mpc83xx_wdt_miscdev);
iounmap(wd_base);
@@ -203,7 +193,16 @@ static int __devexit mpc83xx_wdt_remove(struct
platform_device *dev)
return 0;
}
-static struct platform_driver mpc83xx_wdt_driver = {
+static const struct of_device_id mpc83xx_wdt_match[] = {
+ {
+ .compatible = "mpc83xx_wdt",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mpc83xx_wdt_match);
+
+static struct of_platform_driver mpc83xx_wdt_driver = {
+ .match_table= mpc83xx_wdt_match,
.probe = mpc83xx_wdt_probe,
.remove = __devexit_p(mpc83xx_wdt_remove),
.driver = {
@@ -214,12 +213,12 @@ static struct platform_driver mpc83xx_wdt_driver = {
static int __init mpc83xx_wdt_init(void)
{
- return platform_driver_register(&mpc83xx_wdt_driver);
+ return of_register_platform_driver(&mpc83xx_wdt_driver);
}
static void __exit mpc83xx_wdt_exit(void)
{
- platform_driver_unregister(&mpc83xx_wdt_driver);
+ of_unregister_platform_driver(&mpc83xx_wdt_driver);
}
module_init(mpc83xx_wdt_init);
@@ -229,4 +228,3 @@ MODULE_AUTHOR("Dave Updegraff, Kumar Gala");
MODULE_DESCRIPTION("Driver for watchdog timer in MPC83xx uProcessor");
MODULE_LICENSE("GPL");
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
-MODULE_ALIAS("platform:mpc83xx_wdt");
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] [WATCHDOG] mpc83xx_wdt: add support for MPC86xx CPUs
On MPC86xx the watchdog could be enabled only at power-on-reset, and
could not be disabled afterwards. We must ping the watchdog from the
kernel until the userspace handles it.
MPC83xx CPUs are only differ in a way that watchdog could be disabled
once, but after it was enabled via software it becomes just the same
as MPC86xx.
Thus, to support MPC86xx I added the kernel timer which pings the
watchdog until the userspace opens it.
Since we implemented the timer, now we're able to implement proper
handling for the CONFIG_WATCHDOG_NOWAYOUT case, for MPC83xx and MPC86xx.
Also move the probe code into subsys_initcall, because we want start
pinging the watchdog ASAP, and misc devices are available in
subsys_initcall.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/Kconfig |4 +-
drivers/watchdog/mpc83xx_wdt.c | 80
2 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 254d115..2929055 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -683,8 +683,8 @@ config 8xx_WDT
depends on 8xx
config 83xx_WDT
- tristate "MPC83xx Watchdog Timer"
- depends on PPC_83xx
+ tristate "MPC83xx/MPC86xx Watchdog Timer"
+ depends on PPC_83xx || PPC_86xx
config MV64X60_WDT
tristate "MV64X60 (Marvell Discovery) Watchdog Timer"
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
index 127d85e..19e3082 100644
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ b/drivers/watchdog/mpc83xx_wdt.c
@@ -1,10 +1,12 @@
/*
- * mpc83xx_wdt.c - MPC83xx watchdog userspace interface
+ * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff <[EMAIL PROTECTED]>
* Kumar Gala <[EMAIL PROTECTED]>
* Attribution: from 83xx_wst: Florian Schirmer <[EMAIL PROTECTED]>
* ..and from sc520_wdt
+ * Copyright (c) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
*
* Note: it appears that you can only actually ENABLE or DISABLE the thing
* once after POR. Once enabled, you cannot disable, and vice versa.
@@ -18,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -39,6 +42,11 @@ struct mpc83xx_wdt {
u8 res2[0xF0];
};
+struct mpc83xx_wdt_type {
+ int prescaler;
+ bool hw_enabled;
+};
+
static struct mpc83xx_wdt __iomem *wd_base;
static u16 timeout = 0x;
@@ -51,6 +59,11 @@ module_param(reset, bool, 0);
MODULE_PARM_DESC(reset, "Watchdog Interrupt/Reset Mode. "
"0 = interrupt, 1 = reset");
+static int nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, int, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
+"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
/*
* We always prescale, but if someone really doesn't want to they can set this
* to 0
@@ -70,6 +83,22 @@ static void mpc83xx_wdt_keepalive(void)
spin_unlock(&wdt_spinlock);
}
+static void mpc83xx_wdt_timer_ping(unsigned long arg);
+static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
+
+static void mpc83xx_wdt_timer_ping(unsigned long arg)
+{
+ mpc83xx_wdt_keepalive();
+ /* We're pinging it twice faster than needed, just to be sure. */
+ mod_timer(&wdt_timer, jiffies + HZ * timeout_sec / 2);
+}
+
+static void mpc83xx_wdt_pr_warn(const char *msg)
+{
+ pr_crit("mpc83xx_wdt: %s, expect the %s soon!\n", msg,
+ reset ? "reset" : "machine check exception");
+}
+
static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
@@ -85,7 +114,8 @@ static int mpc83xx_wdt_open(struct inode *inode, struct file
*file)
return -EBUSY;
/* Once we start the watchdog we can't stop it */
- __module_get(THIS_MODULE);
+ if (nowayout)
+ __module_get(THIS_MODULE);
/* Good, fire up the show */
if (prescale)
@@ -97,13 +127,17 @@ static int mpc83xx_wdt_open(struct inode *inode, struct
file *file)
out_be32(&wd_base->swcrr, tmp);
+ del_timer_sync(&wdt_timer);
+
return nonseekable_open(inode, file);
}
static int mpc83xx_wdt_release(struct inode *inode, struct file *file)
{
- printk(KERN_CRIT "Unexpected close, not stopping watchdog!\n");
- mpc83xx_wdt_keepalive();
+ if (!nowayout)
+ mpc83xx_wdt_timer_ping(0);
+ else
+ mpc83xx_wdt_pr_warn("watchdog closed");
clear_bit(0, &wdt_is_open);
return 0;
}
@@ -154,15 +188,25 @@ static int __devinit mpc83xx_wdt_probe(struct of_device
*ofdev,
const struct of_device_id *match)
{
int ret;
+ struct device_node *np = ofdev->node;
+ struct mpc83xx_w
[PATCH 4/8] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
Rename the driver because now we support some MPC86xx processors.
There are no changes to the mpc83xx_wdt.c file, yet. When possible, we do
file renames and changes separately (because Linus once asked so, because
it helps git to track the renamed files).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/Kconfig | 11 ++-
drivers/watchdog/Makefile |2 +-
drivers/watchdog/mpc83xx_wdt.c | 294
drivers/watchdog/mpc8xxx_wdt.c | 294
4 files changed, 304 insertions(+), 297 deletions(-)
delete mode 100644 drivers/watchdog/mpc83xx_wdt.c
create mode 100644 drivers/watchdog/mpc8xxx_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2929055..008eaa6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -682,9 +682,16 @@ config 8xx_WDT
tristate "MPC8xx Watchdog Timer"
depends on 8xx
-config 83xx_WDT
- tristate "MPC83xx/MPC86xx Watchdog Timer"
+config 8xxx_WDT
+ tristate "MPC8xxx Platform Watchdog Timer"
depends on PPC_83xx || PPC_86xx
+ help
+ This driver is for a SoC level watchdog that exists on some
+ Freescale PowerPC processors. So far this driver supports:
+ - MPC83xx watchdogs
+ - MPC86xx watchdogs
+
+ For BookE processors (MPC85xx) use the BOOKE_WDT driver instead.
config MV64X60_WDT
tristate "MV64X60 (Marvell Discovery) Watchdog Timer"
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f3fb170..d5782f9 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -102,7 +102,7 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
# POWERPC Architecture
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
-obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
+obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
diff --git a/drivers/watchdog/mpc83xx_wdt.c b/drivers/watchdog/mpc83xx_wdt.c
deleted file mode 100644
index 19e3082..000
--- a/drivers/watchdog/mpc83xx_wdt.c
+++ /dev/null
@@ -1,294 +0,0 @@
-/*
- * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
- *
- * Authors: Dave Updegraff <[EMAIL PROTECTED]>
- * Kumar Gala <[EMAIL PROTECTED]>
- * Attribution: from 83xx_wst: Florian Schirmer <[EMAIL PROTECTED]>
- * ..and from sc520_wdt
- * Copyright (c) 2008 MontaVista Software, Inc.
- * Anton Vorontsov <[EMAIL PROTECTED]>
- *
- * Note: it appears that you can only actually ENABLE or DISABLE the thing
- * once after POR. Once enabled, you cannot disable, and vice versa.
- *
- * 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
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct mpc83xx_wdt {
- __be32 res0;
- __be32 swcrr; /* System watchdog control register */
-#define SWCRR_SWTC 0x /* Software Watchdog Time Count. */
-#define SWCRR_SWEN 0x0004 /* Watchdog Enable bit. */
-#define SWCRR_SWRI 0x0002 /* Software Watchdog Reset/Interrupt Select
bit.*/
-#define SWCRR_SWPR 0x0001 /* Software Watchdog Counter Prescale bit. */
- __be32 swcnr; /* System watchdog count register */
- u8 res1[2];
- __be16 swsrr; /* System watchdog service register */
- u8 res2[0xF0];
-};
-
-struct mpc83xx_wdt_type {
- int prescaler;
- bool hw_enabled;
-};
-
-static struct mpc83xx_wdt __iomem *wd_base;
-
-static u16 timeout = 0x;
-module_param(timeout, ushort, 0);
-MODULE_PARM_DESC(timeout, "Watchdog timeout in ticks. "
-"(0swsrr, 0x556c);
- out_be16(&wd_base->swsrr, 0xaa39);
- spin_unlock(&wdt_spinlock);
-}
-
-static void mpc83xx_wdt_timer_ping(unsigned long arg);
-static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
-
-static void mpc83xx_wdt_timer_ping(unsigned long arg)
-{
- mpc83xx_wdt_keepalive();
- /* We're pinging it twice faster than needed, just to be sure. */
- mod_timer(&wdt_timer, jiffies + HZ * timeout_sec / 2);
-}
-
-static void mpc83xx_wdt_pr_warn(const char *msg)
-{
- pr_crit("mpc83xx_wdt: %s, expect the %s soon!\n", msg,
- reset ? "reset" : "machine check exception");
-}
-
-static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
-size_t count, loff_t *ppos)
-{
- if (count)
- mpc83xx_wdt_keepalive();
- return count;
-}
-
-static int mpc83xx_wdt_open(struct inode *inode, struct file *file)
-{
- u32 tmp = SWCRR_SWEN;
- if (test_and_set_bit(0, &wdt_is_op
[PATCH 5/8] [WATCHDOG] mpc8xxx_wdt: various renames, mostly s/mpc83xx/mpc8xxx/g
mpc83xx_wdt.c renamed to mpc8xxx_wdt.c, now we can do various renames
in the file itself.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/mpc8xxx_wdt.c | 104
1 files changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index 19e3082..2f0681f 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -1,5 +1,5 @@
/*
- * mpc83xx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
+ * mpc8xxx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff <[EMAIL PROTECTED]>
* Kumar Gala <[EMAIL PROTECTED]>
@@ -29,7 +29,7 @@
#include
#include
-struct mpc83xx_wdt {
+struct mpc8xxx_wdt {
__be32 res0;
__be32 swcrr; /* System watchdog control register */
#define SWCRR_SWTC 0x /* Software Watchdog Time Count. */
@@ -42,12 +42,12 @@ struct mpc83xx_wdt {
u8 res2[0xF0];
};
-struct mpc83xx_wdt_type {
+struct mpc8xxx_wdt_type {
int prescaler;
bool hw_enabled;
};
-static struct mpc83xx_wdt __iomem *wd_base;
+static struct mpc8xxx_wdt __iomem *wd_base;
static u16 timeout = 0x;
module_param(timeout, ushort, 0);
@@ -74,7 +74,7 @@ static unsigned int timeout_sec;
static unsigned long wdt_is_open;
static DEFINE_SPINLOCK(wdt_spinlock);
-static void mpc83xx_wdt_keepalive(void)
+static void mpc8xxx_wdt_keepalive(void)
{
/* Ping the WDT */
spin_lock(&wdt_spinlock);
@@ -83,31 +83,31 @@ static void mpc83xx_wdt_keepalive(void)
spin_unlock(&wdt_spinlock);
}
-static void mpc83xx_wdt_timer_ping(unsigned long arg);
-static DEFINE_TIMER(wdt_timer, mpc83xx_wdt_timer_ping, 0, 0);
+static void mpc8xxx_wdt_timer_ping(unsigned long arg);
+static DEFINE_TIMER(wdt_timer, mpc8xxx_wdt_timer_ping, 0, 0);
-static void mpc83xx_wdt_timer_ping(unsigned long arg)
+static void mpc8xxx_wdt_timer_ping(unsigned long arg)
{
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
/* We're pinging it twice faster than needed, just to be sure. */
mod_timer(&wdt_timer, jiffies + HZ * timeout_sec / 2);
}
-static void mpc83xx_wdt_pr_warn(const char *msg)
+static void mpc8xxx_wdt_pr_warn(const char *msg)
{
- pr_crit("mpc83xx_wdt: %s, expect the %s soon!\n", msg,
+ pr_crit("mpc8xxx_wdt: %s, expect the %s soon!\n", msg,
reset ? "reset" : "machine check exception");
}
-static ssize_t mpc83xx_wdt_write(struct file *file, const char __user *buf,
+static ssize_t mpc8xxx_wdt_write(struct file *file, const char __user *buf,
size_t count, loff_t *ppos)
{
if (count)
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
return count;
}
-static int mpc83xx_wdt_open(struct inode *inode, struct file *file)
+static int mpc8xxx_wdt_open(struct inode *inode, struct file *file)
{
u32 tmp = SWCRR_SWEN;
if (test_and_set_bit(0, &wdt_is_open))
@@ -132,17 +132,17 @@ static int mpc83xx_wdt_open(struct inode *inode, struct
file *file)
return nonseekable_open(inode, file);
}
-static int mpc83xx_wdt_release(struct inode *inode, struct file *file)
+static int mpc8xxx_wdt_release(struct inode *inode, struct file *file)
{
if (!nowayout)
- mpc83xx_wdt_timer_ping(0);
+ mpc8xxx_wdt_timer_ping(0);
else
- mpc83xx_wdt_pr_warn("watchdog closed");
+ mpc8xxx_wdt_pr_warn("watchdog closed");
clear_bit(0, &wdt_is_open);
return 0;
}
-static int mpc83xx_wdt_ioctl(struct inode *inode, struct file *file,
+static int mpc8xxx_wdt_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg)
{
void __user *argp = (void __user *)arg;
@@ -150,7 +150,7 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
static struct watchdog_info ident = {
.options = WDIOF_KEEPALIVEPING,
.firmware_version = 1,
- .identity = "MPC83xx",
+ .identity = "MPC8xxx",
};
switch (cmd) {
@@ -160,7 +160,7 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
case WDIOC_GETBOOTSTATUS:
return put_user(0, p);
case WDIOC_KEEPALIVE:
- mpc83xx_wdt_keepalive();
+ mpc8xxx_wdt_keepalive();
return 0;
case WDIOC_GETTIMEOUT:
return put_user(timeout_sec, p);
@@ -169,27 +169,27 @@ static int mpc83xx_wdt_ioctl(struct inode *inode, struct
file *file,
}
}
-static const struct file_operations mpc83xx_wdt_fops = {
+static const struct file_operations mpc8xxx_wdt_fops = {
.owner = THIS_MODULE,
.llseek = no_llseek,
- .write = mpc83xx_wdt_write,
- .ioctl =
[PATCH 6/8] [WATCHDOG] mpc8xxx_wdt: add support for MPC8xx watchdogs
The mpc8xxx_wdt driver is using two registers: SWSRR to push magic
numbers, and SWCRR to control the watchdog. Both registers are available
on the MPC8xx, and seem to have the same offsets and semantics as in
MPC83xx/MPC86xx watchdogs. The only difference is prescale value. So this
driver should simply work on the MPC8xx CPUs.
MPC823 seem to be the first CPU in MPC8xx line, so we use fsl,mpc823-wdt
compatible matching.
Though, this patch was only build-tested and okay to drop from this
series until tested or corrected to work on the actual hardware.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/watchdog/Kconfig |3 ++-
drivers/watchdog/mpc8xxx_wdt.c | 11 +--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 008eaa6..f9e617b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -684,10 +684,11 @@ config 8xx_WDT
config 8xxx_WDT
tristate "MPC8xxx Platform Watchdog Timer"
- depends on PPC_83xx || PPC_86xx
+ depends on PPC_8xx || PPC_83xx || PPC_86xx
help
This driver is for a SoC level watchdog that exists on some
Freescale PowerPC processors. So far this driver supports:
+ - MPC8xx watchdogs
- MPC83xx watchdogs
- MPC86xx watchdogs
diff --git a/drivers/watchdog/mpc8xxx_wdt.c b/drivers/watchdog/mpc8xxx_wdt.c
index 2f0681f..c7e28f0 100644
--- a/drivers/watchdog/mpc8xxx_wdt.c
+++ b/drivers/watchdog/mpc8xxx_wdt.c
@@ -1,5 +1,5 @@
/*
- * mpc8xxx_wdt.c - MPC83xx/MPC86xx watchdog userspace interface
+ * mpc8xxx_wdt.c - MPC8xx/MPC83xx/MPC86xx watchdog userspace interface
*
* Authors: Dave Updegraff <[EMAIL PROTECTED]>
* Kumar Gala <[EMAIL PROTECTED]>
@@ -261,6 +261,12 @@ static const struct of_device_id mpc8xxx_wdt_match[] = {
.hw_enabled = true,
},
},
+ {
+ .compatible = "fsl,mpc823-wdt",
+ .data = &(struct mpc8xxx_wdt_type) {
+ .prescaler = 0x800,
+ },
+ },
{},
};
MODULE_DEVICE_TABLE(of, mpc8xxx_wdt_match);
@@ -289,6 +295,7 @@ subsys_initcall(mpc8xxx_wdt_init);
module_exit(mpc8xxx_wdt_exit);
MODULE_AUTHOR("Dave Updegraff, Kumar Gala");
-MODULE_DESCRIPTION("Driver for watchdog timer in MPC83xx/MPC86xx uProcessors");
+MODULE_DESCRIPTION("Driver for watchdog timer in MPC8xx/MPC83xx/MPC86xx "
+ "uProcessors");
MODULE_LICENSE("GPL");
MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] [POWERPC] fsl_soc: remove mpc83xx_wdt code
mpc83xx_wdt is the OF driver now, so we don't need fsl_soc constructor.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 46 -
1 files changed, 0 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index a5ceeef..32a3ac8 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -545,52 +545,6 @@ err:
arch_initcall(fsl_i2c_of_init);
#endif
-#ifdef CONFIG_PPC_83xx
-static int __init mpc83xx_wdt_init(void)
-{
- struct resource r;
- struct device_node *np;
- struct platform_device *dev;
- u32 freq = fsl_get_sys_freq();
- int ret;
-
- np = of_find_compatible_node(NULL, "watchdog", "mpc83xx_wdt");
-
- if (!np) {
- ret = -ENODEV;
- goto nodev;
- }
-
- memset(&r, 0, sizeof(r));
-
- ret = of_address_to_resource(np, 0, &r);
- if (ret)
- goto err;
-
- dev = platform_device_register_simple("mpc83xx_wdt", 0, &r, 1);
- if (IS_ERR(dev)) {
- ret = PTR_ERR(dev);
- goto err;
- }
-
- ret = platform_device_add_data(dev, &freq, sizeof(freq));
- if (ret)
- goto unreg;
-
- of_node_put(np);
- return 0;
-
-unreg:
- platform_device_unregister(dev);
-err:
- of_node_put(np);
-nodev:
- return ret;
-}
-
-arch_initcall(mpc83xx_wdt_init);
-#endif
-
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
if (!phy_type)
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] [POWERPC] 86xx: mpc8610_hpcd: add watchdog node
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 5030533..b502202 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -195,6 +195,11 @@
fsl,has-rstcr;
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8610-wdt";
+ reg = <0xe4000 0x100>;
+ };
+
[EMAIL PROTECTED] {
compatible = "fsl,mpc8610-gpio";
reg = <0xf000 0x100>;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 3/4] macintosh: replace deprecated __initcall with device_initcall
On Thu, 15 May 2008 19:08:37 +1000 Michael Ellerman <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-05-14 at 23:41 -0700, Andrew Morton wrote:
> > On Thu, 15 May 2008 16:28:28 +1000 Michael Ellerman <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Wed, 2008-05-14 at 23:06 -0700, Andrew Morton wrote:
> > > > On Thu, 15 May 2008 14:14:38 +1000 Paul Mackerras <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > [EMAIL PROTECTED] writes:
> > > > >
> > > > > > -__initcall(adb_init);
> > > > > > +device_initcall(adb_init);
> > > > >
> > > > > There's no particular reason why this needs to go in 2.6.26, is there?
> > > > > It looks to me like something that I should queue up for 2.6.27.
> > > > >
> > > >
> > > > No, this make no difference in code generation - it's just a
> > > > use-the-modern-interface thing.
> > >
> > > I missed the memo about __initcall being deprecated, or is it only
> > > deprecated for use in device drivers?
> > >
> >
> > It's just old-fashioned, that's all.
> >
> > #define pure_initcall(fn) __define_initcall("0",fn,0)
> >
> > #define core_initcall(fn) __define_initcall("1",fn,1)
> > #define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
> > #define postcore_initcall(fn) __define_initcall("2",fn,2)
> > #define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
> > #define arch_initcall(fn) __define_initcall("3",fn,3)
> > #define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
> > #define subsys_initcall(fn) __define_initcall("4",fn,4)
> > #define subsys_initcall_sync(fn)__define_initcall("4s",fn,4s)
> > #define fs_initcall(fn) __define_initcall("5",fn,5)
> > #define fs_initcall_sync(fn)__define_initcall("5s",fn,5s)
> > #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
> > #define device_initcall(fn) __define_initcall("6",fn,6)
> > #define device_initcall_sync(fn)__define_initcall("6s",fn,6s)
> > #define late_initcall(fn) __define_initcall("7",fn,7)
> > #define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
> >
> > #define __initcall(fn) device_initcall(fn)
> >
> > See, we have the nicely-ordered foo_initcall()'s, and the old-fashioned
> > legacy __initcall happens to map onto device_initcall().
> >
> > Such code should use device_initcall() directly. So we see at which
> > stage in initcalls this function will be called.
>
> Yeah fair enough.
>
> A little git'ing tells me there were 31 new __initcall()'s added between
> 2.6.24 and 2.6.25, and there are 12 more lurking between 2.6.25 and
> linux-next. They're breeding!
>
> You can't stick a #warning inside a #define can you? How about:
>
> #define __initcall(fn)\
> do { \
> int Use_device_initcall_not___initcall_please;\
> device_initcall(fn); \
> } while (0)
>
> Which gives:
> warning: unused variable __Use_device_initcall_not___initcall_please___
>
> ..
>
> Yeah OK that was a joke.
I'm sure Andy can give us a checkpatch warning when someone uses
__initcall. That'll help a bit.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix for OProfile callgraph for Power 64 bit user apps
On Thu, 2008-05-15 at 20:47 +1000, Paul Mackerras wrote:
> Carl Love writes:
>
> > The following patch fixes the 64 bit user code backtrace
> > which currently may hang the system.
>
> What exactly is wrong with it?
>
> Having now taken a much closer look, I now don't think Nate Case's
> patch addresses this, since it only affects constant size arguments
> <= 8 to copy_{to,from}_user_inatomic.
>
> However, I don't see why your patch fixes anything. It means we do
> two access_ok calls and two __copy_from_user_inatomic calls, for 8
> bytes, at sp and at sp + 16, rather than doing one access_ok and
> __copy_from_user_inatomic for 24 bytes at sp. Why does that make any
> difference (apart from being slower)?
>
> Paul
When I tried testing the oprofile call graph on a 64 bit app the system
consistently hung. I was able to isolate it to the
__copy_from_user_inatomic() call. When I made the change in my patch to
make sure I was only requesting one of the values (8bytes) listed in the
case statement this fixed the issue. I do not know nor was I able to
figure out why the __copy_from_user_inatomic() call failed trying to
read 24 bytes. The system would hang and any attempt to use printk to
see what was going on failed as the output of the print would not go to
the console before the system hangs.
I backed out my patch, put in Nate's patch. The call graph test ran
fine. I then backed out Nate's patch to go back and try to re-validate
that the system still hangs with the original code and it is not
hanging. Not sure why it now seems to work. I have done some other
work on the system but I don't see how that would have changed this.
Argh, I hate chasing phantom bugs! I was working on 2.6.21. I believe
the 2.6.21 kernel had not been changed. Let me load the latest 2.6.25
and start over with a pristine kernel and see if I can reproduce the
hang. Sorry for all the hassle.
Carl Love
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
If you were to start with the original file, does the following patch
fix the problem?
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 07b3f77..4c248d7 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int
force_reset)
err |= tg3_readphy(tp, MII_BMCR, &bmcr);
if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset &&
- (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT) &&
-tp->link_config.flowctrl == tp->link_config.active_flowctrl) {
+ (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT)) {
/* do nothing, just check for link up at the end */
} else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
u32 adv, new_adv;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Using GPIO
Hi Guillaume, If you're using arch/powerpc, my understanding is that CONFIG_XILINX_GPIO needs to be enabled as well as having the right info in the dts file. Right now I'll have to defer to others to tell you what's needed in the dts file. If you're using arch/ppc, I believe you just need CONFIG_XILINX_GPIO enabled. When the system boots up, you see a message on the console when the GPIO driver initializes. This is not exactly a tutorial. Hopefully this still helps, - John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Dargaud Sent: Thursday, May 15, 2008 9:35 AM To: linuxppc-dev@ozlabs.org Subject: Using GPIO Hello all, I'm trying to use the Xilinx GPIO from a user program. Since I haven't managed to compile their example (simon.c is given without a makefile), I wanted to try using /dev/gpio... So I added /dev/gpio0 c 666 0 0 10 185 - - - to device_table.txt when I generated my root filesystem with buildroot, but apparently this leads nowhere as it's not visible in /proc/devices. Is there some example or tutorial on how to use CONFIG_XILINX_GPIO ? Either as a device or as API calls... -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: dead network on JS21 with tg3 driver after flowcontrol changes
On Thu, 2008-05-15 at 10:15 -0700, Matt Carlson wrote:
> If you were to start with the original file, does the following patch
> fix the problem?
>
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 07b3f77..4c248d7 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -3168,8 +3168,7 @@ static int tg3_setup_fiber_mii_phy(struct tg3 *tp, int
> force_reset)
> err |= tg3_readphy(tp, MII_BMCR, &bmcr);
>
> if ((tp->link_config.autoneg == AUTONEG_ENABLE) && !force_reset &&
> - (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT) &&
> - tp->link_config.flowctrl == tp->link_config.active_flowctrl) {
> + (tp->tg3_flags2 & TG3_FLG2_PARALLEL_DETECT)) {
> /* do nothing, just check for link up at the end */
> } else if (tp->link_config.autoneg == AUTONEG_ENABLE) {
> u32 adv, new_adv;
>
Matt, I think that's very likely the problem. If we are trying to
establish link in parallel detect mode, the flow control settings may
not match. If we do not enter the if statement to do nothing, we will
keep autonegotiating forever and never establish link.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Using GPIO
I don't think the GPIO driver has device tree bindings yet in the driver for ARCH=powerpc. Steve > -Original Message- > From: [EMAIL PROTECTED] [mailto:linuxppc-dev- > [EMAIL PROTECTED] On Behalf Of John Bonesio > Sent: Thursday, May 15, 2008 11:39 AM > To: Guillaume Dargaud; linuxppc-dev@ozlabs.org > Subject: RE: Using GPIO > > > Hi Guillaume, > > If you're using arch/powerpc, my understanding is that > CONFIG_XILINX_GPIO needs to be enabled as well as having the right info > in the dts file. > > Right now I'll have to defer to others to tell you what's needed in the > dts file. > > If you're using arch/ppc, I believe you just need CONFIG_XILINX_GPIO > enabled. > > When the system boots up, you see a message on the console when the GPIO > driver initializes. > > This is not exactly a tutorial. Hopefully this still helps, > > - John > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Guillaume Dargaud > Sent: Thursday, May 15, 2008 9:35 AM > To: linuxppc-dev@ozlabs.org > Subject: Using GPIO > > Hello all, > I'm trying to use the Xilinx GPIO from a user program. > Since I haven't managed to compile their example (simon.c is given > without a > makefile), I wanted to try using /dev/gpio... > > So I added > /dev/gpio0 c 666 0 0 10 185 - - - > to device_table.txt when I generated my root filesystem with buildroot, > but > apparently this leads nowhere as it's not visible in /proc/devices. > > Is there some example or tutorial on how to use CONFIG_XILINX_GPIO ? > Either > as a device or as API calls... > -- > Guillaume Dargaud > http://www.gdargaud.net/ > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) > confidential information that may be proprietary, privileged or copyrighted under applicable law. If > you are not the intended recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
440EPx - SPI and IIC1 conflict
Hello, I've developed a driver for the SPI controller in the 440EPx, which should also work for e.g. the 460EX, and maybe other AMCC processors. According to the UM bit 14 in SDR0_PFC1 controls whether certain signals are for IIC1 or SPI. My driver assures that this bit is set to 0. Note that I haven't been able to find any code in the Linux tree which manipulates this register except for my driver, so IIC1 isn't actually enabled for the 440EPx or the 460EX. Anyway. In order to guarantee that IIC1 doesn't interfere with the operation of SPI I have this code snippet in i2c-ibm_of.c: #if (defined(CONFIG_SPI_PPC4xx) || defined(CONFIG_SPI_PPC4xx_MODULE)) \ && defined(CONFIG_440EPX) /* * Hack, but on the 440EPx we can have either IIC1 or SPI. */ if (dev->paddr == 0x1ef600800ULL) goto fail1; #endif which skips IIC1 if the SPI controller is being used. However, this isn't very aesthetically pleasing. A colleague suggested testing bit 14 in SDR0_PFC1 and bailing if it's set. The problem with this is that the test would depend on the order in which the init routines are called. Right now the SPI driver is initialized before the i2c driver, but I'm not certain that this would be the case for all time. Basically I'm wondering whether anyone on this list has any brilliant idea for handling this problem or whether my present solution is really just OK. --- Gary Jennejohn * DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] * ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
On Thu, 2008-05-15 at 17:39 +0200, Arnd Bergmann wrote:
> On Thursday 01 May 2008, Carl Love wrote:
>
> > Finally, this patch backs out the changes previously added to the
> > oprofile generic code for handling the architecture specific
> > ops.sync_start and ops.sync_stop that allowed the architecture
> > to skip the per CPU buffer creation.
>
> Thanks for your patch, it looks a lot better than your previous version.
> It would be good to have an oprofile person look into the changes
> to the common code though.
>
> Just a few more comments/questions this time:
>
> > -static DEFINE_SPINLOCK(buffer_lock);
> > +static DEFINE_SPINLOCK(add_value_lock);
> > static DEFINE_SPINLOCK(cache_lock);
> > static int num_spu_nodes;
> > int spu_prof_num_nodes;
> > int last_guard_val[MAX_NUMNODES * 8];
> > +static int spu_ctx_sw_seen[MAX_NUMNODES * 8];
> >
> > /* Container for caching information about an active SPU task. */
> > struct cached_info {
>
> I noticed now that you are indexing arrays by SPU number. This is not
> a good idea, because you make assumptions about the system that may
> not be true. Better pass around 'struct spu' pointers and put those
> values in there if you need them.
Hmm, well, we have arrays for last_guard_val[], spu_info[] as well that
are indexed by spu number. So this would seem to be a more general
issue then just spu_ctx_seen[]. Not sure exactly what you are
suggesting with passing around 'struct spu' as a solution. Are you
suggesting that a field be added to the structure for the spu context
seen flag? Not sure that is a good idea. We will need to clarify how
you propose to fix this not only for spu_ctx_sw_seen but the other
arrays as well that are already being indexed by spu number.
> Then again, the last_guard_val looks
> like you should really store that information in the context instead
> of the physical SPU, but that is something else to work on.
>
> Let's leave this one as it is for now and fix the current bug at hand,
> but please remember to fix the assumptions in the code later.
>
> > @@ -289,6 +290,7 @@ static int process_context_switch(struct
> > int retval;
> > unsigned int offset = 0;
> > unsigned long spu_cookie = 0, app_dcookie;
> > + int cpu_buf;
> >
> > retval = prepare_cached_spu_info(spu, objectId);
> > if (retval)
> > @@ -303,17 +305,28 @@ static int process_context_switch(struct
> > goto out;
> > }
> >
> > - /* Record context info in event buffer */
> > - spin_lock_irqsave(&buffer_lock, flags);
> > - add_event_entry(ESCAPE_CODE);
> > - add_event_entry(SPU_CTX_SWITCH_CODE);
> > - add_event_entry(spu->number);
> > - add_event_entry(spu->pid);
> > - add_event_entry(spu->tgid);
> > - add_event_entry(app_dcookie);
> > - add_event_entry(spu_cookie);
> > - add_event_entry(offset);
> > - spin_unlock_irqrestore(&buffer_lock, flags);
> > + /* Record context info in event buffer. Note, there are 4x more
> > +* SPUs then CPUs. Map the SPU events/data for a given SPU to
> > +* the same CPU buffer. Need to ensure the cntxt switch data and
> > +* samples stay in order.
> > +*/
> > + cpu_buf = spu->number >> 2;
>
> The ratio of CPUs versus SPUs is anything but fixed, and the CPU numbers
> may not start at 0. If you have a hypervisor (think PS3), or you are
> running a non-SMP kernel, this is practically always wrong.
> Please use get_cpu()/put_cpu() to read the current CPU number instead.
> This one needs to be fixed now.
>
> > + spin_lock_irqsave(&add_value_lock, flags);
> > + oprofile_add_value(ESCAPE_CODE, cpu_buf);
> > + oprofile_add_value(SPU_CTX_SWITCH_CODE, cpu_buf);
> > + oprofile_add_value(spu->number, cpu_buf);
> > + oprofile_add_value(spu->pid, cpu_buf);
> > + oprofile_add_value(spu->tgid, cpu_buf);
> > + oprofile_add_value(app_dcookie, cpu_buf);
> > + oprofile_add_value(spu_cookie, cpu_buf);
> > + oprofile_add_value(offset, cpu_buf);
> > +
> > + /* Set flag to indicate SPU PC data can now be written out. If
> > +* the SPU program counter data is seen before an SPU context
> > +* record is seen, the postprocessing will fail.
> > +*/
> > + spu_ctx_sw_seen[spu->number] = 1;
> > + spin_unlock_irqrestore(&add_value_lock, flags);
> > smp_wmb(); /* insure spu event buffer updates are written */
> > /* don't want entries intermingled... */
> > out:
>
> How does the spinlock protect you from racing against other values added
> for the same CPU?
You have lost me with this statement. There are three sequences of
entries that need to be made, the first is the SPU_PROFILING_CODE, the
second is the SPU_CTX_SWITCH_CODE and the third is an SPU program
counter value. The SPU_PROFILING_CODE sequence occurs once at the very
beginning when OProfile starts. It occurs during oprofile setup before
we have registered for the context switch notification and the timer has
been setup to call the routine to read/
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Hi Benjamin and Olaf,
Thanks for the suggestions.
Ideally, what I'm looking for is something that mimics the operation of
MASKABLE_EXCEPTION_PSERIES.
I've been looking at the kernel code (entry_64.S, exception.h, head_64.S)
but am finding it quite complicated and hard to follow, particularly in the
area of interrupt disabling wrt the soft and hard disable logic.
My initial thought is to do something like this in the beginning of my
perfmon2 interrupt handler:
void perfmon_pmu_int_handler(struct pt_regs *regs) {
if (get_paca()->soft_enabled == 0) {
/* disable hardware interrupts */
get_paca()->hard_enabled = 0;
regs->msr &= ^MSR_EE;
return;
}
...
}
Does this seem like it might work?
Thanks
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on 05/14/2008
11:46:07 PM:
>
> On Tue, 2008-05-13 at 15:26 -0700, Corey Ashford wrote:
> > The perfmon2 code is available here:
> > http://sourceforge.net/project/showfiles.php?group_id=144822
> >
> > perfmon2's interrupt handler does have a single entry point. Could I
> > somehow mimic what the MASKABLE_EXCEPTION_PSERIES macro does inside
> > of
> > the perfmon2 interrupt handler? Are there examples of this I can look
> > at?
> >
> > That would give us the best of both worlds.
>
> You can definitely snapshot as many data as you can, and if interrupts
> are soft-disabled, just return to the caller, storing that snapshot in
> some per-cpu data structure.
>
> You can then add something to local_irq_restore() that checks whether
> some perfmon2 stuff happened and does the actual storing of the data
> that were previously collected.
>
> Cheers,
> Ben.
>
>___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Convert remaining dts-v0 files to v1
David Gibson wrote: > At the moment we have a mixture of left-over version 0 and new-format > version 1 files in arch/powerpc/boot/dts. This is potentially > confusing to people new to the dts format attempting to figure it out.p > > So, this patch converts all the as-yet unconverted dts v0 files and > converts them to v1. They're mechanically-converted, and not hand > tweaked so in some cases they're not 100% in keeping with usual v1 > style, but the convertor program does have some heuristics so the > discrepancies aren't too bad. > > I have checked that this patch produces no changes to the resulting > dtb binaries. > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> > ... > Index: working-2.6/arch/powerpc/boot/dts/ps3.dts > === > --- working-2.6.orig/arch/powerpc/boot/dts/ps3.dts2008-05-15 > 16:32:08.0 +1000 > +++ working-2.6/arch/powerpc/boot/dts/ps3.dts 2008-05-15 16:32:08.0 > +1000 I tested this on PS3 and it seems to work OK. Acked-by: Geoff Levand <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx: Workaround for CHIP_11 Errata
On Thu, 15 May 2008 09:43:46 -0500 "Josh Boyer" <[EMAIL PROTECTED]> wrote: > This implements the recommended workaround for this errata for chips > that use older versions of firmware that do not already handle it. > The last 4KiB of memory are hidden from the kernel to prevent the > problem transactions from occurring. Do you know which versions of firmware have this problem? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch v2] PS3: Fix memory hotplug
A change was made to walk_memory_resource() in commit 4b119e21d0c66c22e8ca03df05d9de623d0eb50f that added a check of find_lmb(). Add the coresponding lmb_add() call to ps3_mm_add_memory() so that that check will succeed. This fixes the condition where the PS3 boots up with only the 128 MiB of boot memory. Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- v2: Add call to lmb_analyze(). arch/powerpc/platforms/ps3/mm.c |3 +++ 1 file changed, 3 insertions(+) --- a/arch/powerpc/platforms/ps3/mm.c +++ b/arch/powerpc/platforms/ps3/mm.c @@ -317,6 +317,9 @@ static int __init ps3_mm_add_memory(void return result; } + lmb_add(start_addr, map.r1.size); + lmb_analyze(); + result = online_pages(start_pfn, nr_pages); if (result) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
Benjamin Herrenschmidt wrote: > This patch changes vmemmap to use a different region (region 0xf) of the > address space whose page size can be dynamically configured at boot. This doesn't seem to cause any problems, and users successfully used it with the ubuntu hardy kernel, so I think it is OK to proceed with it. https://bugs.launchpad.net/ubuntu-ps3-port/+bug/220524 -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next branch
Paul Mackerras wrote: > I have added the following patches to the powerpc-next and master > branches of the powerpc.git repository. This includes commits pulled > from Kumar's tree. What about these: [PATCH] Add null pointer check to of_find_property [PATCH v2] Update defconfig for MPC8610 HPCD -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git powerpc-next branch
On May 15, 2008, at 4:00 PM, Timur Tabi wrote: Paul Mackerras wrote: I have added the following patches to the powerpc-next and master branches of the powerpc.git repository. This includes commits pulled from Kumar's tree. What about these: [PATCH] Add null pointer check to of_find_property That's up to paul. [PATCH v2] Update defconfig for MPC8610 HPCD I'm hold this one off until we update all the defconfigs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx: Workaround for CHIP_11 Errata
On Thu, 15 May 2008 16:31:04 -0400 Sean MacLennan <[EMAIL PROTECTED]> wrote: > On Thu, 15 May 2008 09:43:46 -0500 > "Josh Boyer" <[EMAIL PROTECTED]> wrote: > > > This implements the recommended workaround for this errata for chips > > that use older versions of firmware that do not already handle it. > > The last 4KiB of memory are hidden from the kernel to prevent the > > problem transactions from occurring. > > Do you know which versions of firmware have this problem? Any U-Boot older than 1.3.3-rc1. Not sure about PIBS, but I don't think the version that is on my Bamboo board has a fix for it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/8 v3] mpc83xx_wdt rework, support for mpc8610 and mpc8xx
Hi Anton, > - New patch supporting MPC8xx watchdogs (ok to drop until tested); Unfortunately, current 2.6.26-rc2 doesn't boot at all on MPC823. I'll have to bisect which patch broke it. I hope to have some testing results, soon. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add warning for unrecognized I2C nodes in the device tree
Update of_find_i2c_driver in fsl_soc.c to display a warning message if an
I2C node in the device tree isn't found in the i2c_devices[] array.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3a7054e..a38c364 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -448,6 +448,10 @@ static int __init of_find_i2c_driver(struct device_node
*node,
return -ENOMEM;
return 0;
}
+
+ pr_warning("fsl_soc.c: unrecognized i2c node %s\n",
+ (const char *) of_get_property(node, "compatible", NULL));
+
return -ENODEV;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 440EPx - SPI and IIC1 conflict
On Thu, May 15, 2008 at 1:02 PM, Gary Jennejohn <[EMAIL PROTECTED]> wrote: > Hello, > > I've developed a driver for the SPI controller in the 440EPx, which should > also work for e.g. the 460EX, and maybe other AMCC processors. > > According to the UM bit 14 in SDR0_PFC1 controls whether certain signals > are for IIC1 or SPI. My driver assures that this bit is set to 0. Note > that I haven't been able to find any code in the Linux tree which > manipulates this register except for my driver, so IIC1 isn't actually > enabled for the 440EPx or the 460EX. > > > Basically I'm wondering whether anyone on this list has any brilliant > idea for handling this problem or whether my present solution is really > just OK. Yes, this is an easy issue to solve. The way to do it is to *not* let your device drivers fiddle with board level configuration stuff (like the register that selects between SPI and I2C mode). Instead, that register should ideally setup by the bootloader, or if that is not possible, then by the platform code (the board specific stuff in arch/ppc/platforms/*). Then your driver can test that bit if it likes to see if the pins are connected; (or even better, disable the device entirely by not listing it in the device tree). In fact, if it doesn't hurt anything to have the device enabled when the bit is set against it, then the driver shouldn't care. That makes the driver more portable to other SoCs, and you should be relying on the device tree anyway to bind devices to drivers. For an example, you can look at the MPC5200 support code. There is a system level configuration register called "port_config" that controls pin routing. In most cases, u-boot sets the right value in port_config so that Linux code never needs to touch it. In cases where we cannot trust u-boot to set things up correctly, like on the lite5200 board, then the platform code fixes things up. None of the mpc5200 device drivers ever touch port_config. (See arch/powerpc/platforms/52xx/lite5200.c) Cheers, g. > > --- > Gary Jennejohn > * > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] > * > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Just FYI: I just tried out the code I suggested below, and it does not
work; it results in a system hang. I have spent some time analyzing why
this doesn't work as I expected, but so far I haven't been able to figure
it out.
Regards,
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 05/15/2008
12:41:55 PM:
> Hi Benjamin and Olaf,
>
> Thanks for the suggestions.
>
> Ideally, what I'm looking for is something that mimics the operation
> of MASKABLE_EXCEPTION_PSERIES.
> I've been looking at the kernel code (entry_64.S, exception.h,
> head_64.S) but am finding it quite complicated and hard to follow,
> particularly in the area of interrupt disabling wrt the soft and
> hard disable logic.
>
> My initial thought is to do something like this in the beginning of
> my perfmon2 interrupt handler:
>
> void perfmon_pmu_int_handler(struct pt_regs *regs) {
>
> if (get_paca()->soft_enabled == 0) {
> /* disable hardware interrupts */
> get_paca()->hard_enabled = 0;
> regs->msr &= ^MSR_EE;
> return;
> }
> ...
> }
>
> Does this seem like it might work?
>
> Thanks
>
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> [EMAIL PROTECTED]
>
>
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on
> 05/14/2008 11:46:07 PM:
>
> >
> > On Tue, 2008-05-13 at 15:26 -0700, Corey Ashford wrote:
> > > The perfmon2 code is available here:
> > > http://sourceforge.net/project/showfiles.php?group_id=144822
> > >
> > > perfmon2's interrupt handler does have a single entry point. Could I
> > > somehow mimic what the MASKABLE_EXCEPTION_PSERIES macro does inside
> > > of
> > > the perfmon2 interrupt handler? Are there examples of this I can
look
> > > at?
> > >
> > > That would give us the best of both worlds.
> >
> > You can definitely snapshot as many data as you can, and if interrupts
> > are soft-disabled, just return to the caller, storing that snapshot in
> > some per-cpu data structure.
> >
> > You can then add something to local_irq_restore() that checks whether
> > some perfmon2 stuff happened and does the actual storing of the data
> > that were previously collected.
> >
> > Cheers,
> > Ben.
> >
> > ___
> 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
[PATCH] Add CS4270 i2c data to fsl_soc.c
The i2c_devices[] array in fsl_soc.c lists all the I2C nodes that are supported
on Freescale boards. Add an entry for the Cirrus Logic CS4270 so that a
new-style CS4270 driver will work.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index a38c364..167523e 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -433,6 +433,7 @@ static struct i2c_driver_device i2c_devices[] __initdata = {
{"dallas,ds1340", "ds1340"},
{"stm,m41t00", "m41t00"},
{"dallas,ds1374", "rtc-ds1374"},
+ {"cirrus,cs4270", "cs4270"},
};
static int __init of_find_i2c_driver(struct device_node *node,
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: iBook G4, keyboard is locked after wakeup
Hi, I've an iBook G4 and tried the linux-next tree 20080515. When the computer awakes I see a black screen with the cursor blinking in the left upper corner. I can change the console with Alt+F1 …, but I can input anything else. The system is locked. I've ran git bisect and it reported acff8d4223ddfb35f3950dce3709b1c515e96c08 as the first bad commit. commit acff8d4223ddfb35f3950dce3709b1c515e96c08 Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Date: Tue May 13 11:09:44 2008 +1000 ide: use __generic_unplug_device() in ide_do_drive_cmd() Call __elv_add_request() with 'plug' == 1 (so the device will be plugged) and then use __generic_unplug_device() instead of calling ide_do_request() directly. This is a preparation for converting IDE to use blk_execute_rq(). Cc: FUJITA Tomonori <[EMAIL PROTECTED]> Cc: Borislav Petkov <[EMAIL PROTECTED]> Cc: Jens Axboe <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c index 5aed79e..a4083e4 100644 --- a/drivers/ide/ide-io.c +++ b/drivers/ide/ide-io.c @@ -1606,8 +1606,8 @@ int ide_do_drive_cmd (ide_drive_t *drive, struct request *rq, ide_action_t actio spin_lock_irqsave(&ide_lock, flags); if (action == ide_preempt) hwgroup->rq = NULL; - __elv_add_request(drive->queue, rq, where, 0); - ide_do_request(hwgroup, IDE_NO_IRQ); + __elv_add_request(drive->queue, rq, where, 1); + __generic_unplug_device(drive->queue); spin_unlock_irqrestore(&ide_lock, flags); err = 0; % cat /proc/cpuinfo processor : 0 cpu : 7455, altivec supported clock : 606.00MHz revision: 0.3 (pvr 8001 0303) bogomips: 36.73 timebase: 18432000 platform: PowerMac model : PowerBook6,3 machine : PowerBook6,3 motherboard : PowerBook6,3 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 001b L2 cache: 256K unified pmac-generation : NewWorld What else information do you need? Bye, Jörg. -- Real programmers don't comment their code. It was hard to write, it should be hard to understand. signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Convert remaining dts-v0 files to v1
On Thu, 15 May 2008 13:22:07 -0700 Geoff Levand <[EMAIL PROTECTED]> wrote: > David Gibson wrote: > > At the moment we have a mixture of left-over version 0 and new-format > > version 1 files in arch/powerpc/boot/dts. This is potentially > > confusing to people new to the dts format attempting to figure it out.p > > > > So, this patch converts all the as-yet unconverted dts v0 files and > > converts them to v1. They're mechanically-converted, and not hand > > tweaked so in some cases they're not 100% in keeping with usual v1 > > style, but the convertor program does have some heuristics so the > > discrepancies aren't too bad. > > > > I have checked that this patch produces no changes to the resulting > > dtb binaries. > > > > Signed-off-by: David Gibson <[EMAIL PROTECTED]> > > > ... > > Index: working-2.6/arch/powerpc/boot/dts/ps3.dts > > === > > --- working-2.6.orig/arch/powerpc/boot/dts/ps3.dts 2008-05-15 > > 16:32:08.0 +1000 > > +++ working-2.6/arch/powerpc/boot/dts/ps3.dts 2008-05-15 > > 16:32:08.0 +1000 > > I tested this on PS3 and it seems to work OK. > > Acked-by: Geoff Levand <[EMAIL PROTECTED]> Paul, Since this mostly effects DTSs for my boards, do you mind if I pull this into my tree? I spoke with Geoff today and he doesn't have any planned PS3 DTS updates, so we shouldn't get conflicts doing it that way. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Corey J Ashford writes:
> Ideally, what I'm looking for is something that mimics the operation of
> MASKABLE_EXCEPTION_PSERIES.
> I've been looking at the kernel code (entry_64.S, exception.h, head_64.S)
> but am finding it quite complicated and hard to follow, particularly in the
> area of interrupt disabling wrt the soft and hard disable logic.
>
> My initial thought is to do something like this in the beginning of my
> perfmon2 interrupt handler:
>
> void perfmon_pmu_int_handler(struct pt_regs *regs) {
>
> if (get_paca()->soft_enabled == 0) {
> /* disable hardware interrupts */
> get_paca()->hard_enabled = 0;
> regs->msr &= ^MSR_EE;
> return;
> }
> ...
> }
>
> Does this seem like it might work?
That's a start (with ~MSR_EE rather than ^MSR_EE, of course). You
also need to set a flag in that case, and test the flag in the part of
arch/powerpc/kernel/irq.c:raw_local_irq_restore() that hard-enables
interrupts. If the flag is set then you should call back into the
perfmon2 code at that point (and clear the flag, of course). You
could add a field to the paca for that flag.
You probably also want to read some of the PMU's SPRs when you first
get the interrupt and save their values away, and then when you get
the call back from raw_local_irq_restore, use the saved values rather
than what's currently in the SPRs, since the saved values will be more
accurate.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 0/3] Board-specific PCI fixups [was: Re: [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add support for ULI RTC]
Hi Anton, This is not me picking on you, I just want to make a general statement. On Thu, 15 May 2008 20:20:48 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > Could we then apply this to the powerpc-next for proper testing? We should not do this. powerpc-next feeds into linux-next which is for inter subsystem integration testing. Architecture specific testing should be done before things get to -next. I am hoping that Paul will run a separate powerpc tree/branch for powerpc wide testing and then migrate stuff form there to powerpc-next when he is happy that things are as good as we can get. This does not mean "perfect". :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpIlepdVrCf0.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] powerpc: DTS file for the C2K
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part 1 of 5: DTS file describing the board peripherals. As far as I know
all peripherals except the FPGA are listed in there (I did not included
the FPGA because a lot of work is needed there).
Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
---
c2k.dts | 353
1 files changed, 353 insertions(+)
diff --git a/arch/powerpc/boot/dts/c2k.dts b/arch/powerpc/boot/dts/c2k.dts
new file mode 100644
index 000..21281b8
--- /dev/null
+++ b/arch/powerpc/boot/dts/c2k.dts
@@ -0,0 +1,353 @@
+/* Device Tree Source for GEFanuc C2K
+ *
+ * Author: Remi Machet <[EMAIL PROTECTED]>
+ *
+ * Originated from prpmc2800.dts
+ *
+ * 2008 (c) Stanford University
+ * 2007 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "C2K";
+ compatible = "GEFanuc,C2K";
+ coherency-off;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,7447 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <99600>; /* 996 MHz */
+ bus-frequency = <16667>;/* 166. MHz */
+ timebase-frequency = <4167>;/* 166./4
MHz */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1GB */
+ };
+
+ [EMAIL PROTECTED] { /* Marvell Discovery */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "mv64460";
+ compatible = "marvell,mv64360";
+ clock-frequency = <16667>; /* 166.66... MHz */
+ reg = <0xd800 0x0001>;
+ virtual-reg = <0xd800>;
+ ranges = <0xd400 0xd400 0x0100 /* PCI 0 I/O
Space */
+ 0x8000 0x8000 0x0800 /* PCI 0 MEM
Space */
+ 0xd000 0xd000 0x0100 /* PCI 1 I/O
Space */
+ 0xa000 0xa000 0x0800 /* PCI 1 MEM
Space */
+ 0xf800 0xf800 0x0800 /* User FLASH */
+ 0x 0xd800 0x0001 /* Bridge's
regs */
+ 0xd814 0xd814 0x0004>;/* Integrated
SRAM */
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "marvell,mv64360-mdio";
+ PHY0: [EMAIL PROTECTED] {
+ device_type = "ethernet-phy";
+ interrupts = <76>; /* GPP 12 */
+ interrupt-parent = <&PIC>;
+ reg = <0>;
+ };
+ PHY1: [EMAIL PROTECTED] {
+ device_type = "ethernet-phy";
+ interrupts = <76>; /* GPP 12 */
+ interrupt-parent = <&PIC>;
+ reg = <1>;
+ };
+ PHY2: [EMAIL PROTECTED] {
+ device_type = "ethernet-phy";
+ interrupts = <76>; /* GPP 12 */
+ interrupt-parent = <&PIC>;
+ reg = <2>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,mv64360-eth-group";
+ reg = <0x2000 0x2000>;
+ [EMAIL PROTECTED] {
+ device_type = "network";
+ compatible = "marvell,mv64360-eth";
+ reg = <0>;
+ interrupts = <32>;
+ interrupt-parent = <&PIC>;
+ phy = <&PHY0>;
+ local-mac-add
[PATCH 2/5] powerpc: boot code for the C2K
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part 2 of 5: support for the board in arch/powerpc/boot.
Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
---
Makefile |3
c2k.c| 238 +++
2 files changed, 240 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 7822d25..232a9b3 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -63,7 +63,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
- fixed-head.S ep88xc.c ep405.c \
+ fixed-head.S ep88xc.c ep405.c c2k.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c
\
virtex405-head.S
@@ -197,6 +197,7 @@ image-$(CONFIG_PPC_HOLLY) += zImage.holly
image-$(CONFIG_PPC_PRPMC2800) += dtbImage.prpmc2800
image-$(CONFIG_PPC_ISERIES)+= zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
+image-$(CONFIG_PPC_C2K)+= dtbImage.c2k
#
# Targets which embed a device tree blob
diff --git a/arch/powerpc/boot/c2k.c b/arch/powerpc/boot/c2k.c
new file mode 100644
index 000..e0a587a
--- /dev/null
+++ b/arch/powerpc/boot/c2k.c
@@ -0,0 +1,238 @@
+/*
+ * GEFanuc C2K platform code.
+ *
+ * Author: Remi Machet <[EMAIL PROTECTED]>
+ *
+ * Originated from prpmc2800.c
+ *
+ * 2008 (c) Stanford University
+ * 2007 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "types.h"
+#include "stdio.h"
+#include "io.h"
+#include "ops.h"
+#include "elf.h"
+#include "gunzip_util.h"
+#include "mv64x60.h"
+
+#define KB1024U
+#define MB(KB*KB)
+
+BSS_STACK(16*KB);
+
+static u8 *bridge_base;
+
+static void c2k_bridge_setup(u32 mem_size)
+{
+ u32 i, v[30], enables, acc_bits;
+ u32 pci_base_hi, pci_base_lo, size, buf[2];
+ unsigned long cpu_base;
+ int rc;
+ void *devp, *mv64x60_devp;
+ u8 *bridge_pbase, is_coherent;
+ struct mv64x60_cpu2pci_win *tbl;
+ int hose;
+
+ bridge_pbase = mv64x60_get_bridge_pbase();
+ is_coherent = mv64x60_is_coherent();
+
+ if (is_coherent)
+ acc_bits = MV64x60_PCI_ACC_CNTL_SNOOP_WB
+ | MV64x60_PCI_ACC_CNTL_SWAP_NONE
+ | MV64x60_PCI_ACC_CNTL_MBURST_32_BYTES
+ | MV64x60_PCI_ACC_CNTL_RDSIZE_32_BYTES;
+ else
+ acc_bits = MV64x60_PCI_ACC_CNTL_SNOOP_NONE
+ | MV64x60_PCI_ACC_CNTL_SWAP_NONE
+ | MV64x60_PCI_ACC_CNTL_MBURST_128_BYTES
+ | MV64x60_PCI_ACC_CNTL_RDSIZE_256_BYTES;
+
+ mv64x60_config_ctlr_windows(bridge_base, bridge_pbase, is_coherent);
+ mv64x60_devp = find_node_by_compatible(NULL, "marvell,mv64360");
+ if (mv64x60_devp == NULL)
+ fatal("Error: Missing marvell,mv64360 device tree node\n\r");
+
+ enables = in_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE));
+ enables |= 0x007ffe00; /* Disable all cpu->pci windows */
+ out_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE), enables);
+
+ /* Get the cpu -> pci i/o & mem mappings from the device tree */
+ devp = NULL;
+ while (1) {
+ devp = find_node_by_compatible(devp, "marvell,mv64360-pci");
+ if (devp == NULL)
+ break;
+
+ rc = getprop(devp, "cell-index", &hose, sizeof(hose));
+ if (rc != sizeof(hose))
+ hose = 0;
+
+ if (hose >= 2)
+ fatal("Error: Only 2 PCI controllers are supported at" \
+ " this time.\n");
+
+ mv64x60_config_pci_windows(bridge_base, bridge_pbase, hose, 0,
+ mem_size, acc_bits);
+
+ rc = getprop(devp, "ranges", v, sizeof(v));
+ if (rc == 0)
+ fatal("Error: Can't find marvell,mv64360-pci ranges"
+ " property\n\r");
+
+ /* Get the cpu -> pci i/o & mem mappings from the device tree */
+
+ for (i = 0; i < rc; i += 6) {
+ switc
[PATCH 3/5] powerpc: C2K board driver
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part 3 of 5: driver for the board. At this time it is very generic
and similar to its original, the driver for the prpmc2800.
Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
---
Note: checkpatch.pl reported one warning, but asm/time.h is needed
(defines generic_calibrate_decr):
WARNING: Use #include instead of
#58: FILE: arch/powerpc/platforms/embedded6xx/c2k.c:26:
+#include
Makefile |1
c2k.c| 157 +++
2 files changed, 158 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/Makefile
b/arch/powerpc/platforms/embedded6xx/Makefile
index 06524d3..0773c08 100644
--- a/arch/powerpc/platforms/embedded6xx/Makefile
+++ b/arch/powerpc/platforms/embedded6xx/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_LINKSTATION) += linkstation.o ls_uart.o
obj-$(CONFIG_STORCENTER) += storcenter.o
obj-$(CONFIG_PPC_HOLLY)+= holly.o
obj-$(CONFIG_PPC_PRPMC2800)+= prpmc2800.o
+obj-$(CONFIG_PPC_C2K) += c2k.o
diff --git a/arch/powerpc/platforms/embedded6xx/c2k.c
b/arch/powerpc/platforms/embedded6xx/c2k.c
new file mode 100644
index 000..d1e8113
--- /dev/null
+++ b/arch/powerpc/platforms/embedded6xx/c2k.c
@@ -0,0 +1,157 @@
+/*
+ * Board setup routines for the GEFanuc C2K board
+ *
+ * Author: Remi Machet <[EMAIL PROTECTED]>
+ *
+ * Originated from prpmc2800.c
+ *
+ * 2008 (c) Stanford University
+ * 2007 (c) MontaVista, Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+
+#define MV64x60_MPP_CNTL_0 0x
+#define MV64x60_MPP_CNTL_2 0x0008
+
+#define MV64x60_GPP_IO_CNTL0x
+#define MV64x60_GPP_LEVEL_CNTL 0x0010
+#define MV64x60_GPP_VALUE_SET 0x0018
+
+static void __iomem *mv64x60_mpp_reg_base;
+static void __iomem *mv64x60_gpp_reg_base;
+
+static void __init c2k_setup_arch(void)
+{
+ struct device_node *np;
+ phys_addr_t paddr;
+ const unsigned int *reg;
+
+ /*
+* ioremap mpp and gpp registers in case they are later
+* needed by c2k_reset_board().
+*/
+ np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp");
+ reg = of_get_property(np, "reg", NULL);
+ paddr = of_translate_address(np, reg);
+ of_node_put(np);
+ mv64x60_mpp_reg_base = ioremap(paddr, reg[1]);
+
+ np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp");
+ reg = of_get_property(np, "reg", NULL);
+ paddr = of_translate_address(np, reg);
+ of_node_put(np);
+ mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
+
+#ifdef CONFIG_PCI
+ mv64x60_pci_init();
+#endif
+}
+
+static void c2k_reset_board(void)
+{
+ u32 temp;
+
+ local_irq_disable();
+
+ temp = in_le32(mv64x60_mpp_reg_base + MV64x60_MPP_CNTL_0);
+ temp &= 0x0FFF;
+ out_le32(mv64x60_mpp_reg_base + MV64x60_MPP_CNTL_0, temp);
+
+ temp = in_le32(mv64x60_gpp_reg_base + MV64x60_GPP_LEVEL_CNTL);
+ temp |= 0x0004;
+ out_le32(mv64x60_gpp_reg_base + MV64x60_GPP_LEVEL_CNTL, temp);
+
+ temp = in_le32(mv64x60_gpp_reg_base + MV64x60_GPP_IO_CNTL);
+ temp |= 0x0004;
+ out_le32(mv64x60_gpp_reg_base + MV64x60_GPP_IO_CNTL, temp);
+
+ temp = in_le32(mv64x60_mpp_reg_base + MV64x60_MPP_CNTL_2);
+ temp &= 0x0FFF;
+ out_le32(mv64x60_mpp_reg_base + MV64x60_MPP_CNTL_2, temp);
+
+ temp = in_le32(mv64x60_gpp_reg_base + MV64x60_GPP_LEVEL_CNTL);
+ temp |= 0x0008;
+ out_le32(mv64x60_gpp_reg_base + MV64x60_GPP_LEVEL_CNTL, temp);
+
+ temp = in_le32(mv64x60_gpp_reg_base + MV64x60_GPP_IO_CNTL);
+ temp |= 0x0008;
+ out_le32(mv64x60_gpp_reg_base + MV64x60_GPP_IO_CNTL, temp);
+
+ out_le32(mv64x60_gpp_reg_base + MV64x60_GPP_VALUE_SET, 0x00080004);
+}
+
+static void c2k_restart(char *cmd)
+{
+ c2k_reset_board();
+ msleep(100);
+ panic("restart failed\n");
+}
+
+#ifdef CONFIG_NOT_COHERENT_CACHE
+#define COHERENCY_SETTING "off"
+#else
+#define COHERENCY_SETTING "on"
+#endif
+
+void c2k_show_cpuinfo(struct seq_file *m)
+{
+ uint memsize = total_memory;
+
+ seq_printf(m, "Vendor\t\t: GEFanuc\n");
+ seq_printf(m, "Memory\t\t: %d MB\n", memsize / (1024 * 1024));
+ seq_printf(m, "coherency\t: %s\n", COHERENCY_SETTING);
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init c2k_probe(void)
+
[PATCH 4/5] powerpc: default configuration for C2K
Support for the C2K cPCI Single Board Computer from GEFanuc (PowerPC MPC7448 with a Marvell MV64460 chipset) All features of the board are not supported yet, but the board boots, flash works, all Ethernet ports are working and PCI devices are all found (USB and SATA on PCI1 do not work yet). Part 4 of 5: this is the default config for the board. In this configuration the kernel is going to try to boot from MTD partition 3 on the NOR flash (see c2k.dts for details about the partitioning of the flash). Signed-off-by: Remi Machet <[EMAIL PROTECTED]> --- c2k_defconfig | 1872 ++ 1 files changed, 1872 insertions(+) diff --git a/arch/powerpc/configs/c2k_defconfig b/arch/powerpc/configs/c2k_defconfig new file mode 100644 index 000..dc599c7 --- /dev/null +++ b/arch/powerpc/configs/c2k_defconfig @@ -0,0 +1,1872 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.26-rc2 +# Thu May 15 11:00:14 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +# CONFIG_ALTIVEC is not set +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_CHECK_CACHE_COHERENCY=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_IRQ_PER_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +# CONFIG_PPC_UDBG_16550 is not set +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +# CONFIG_TASKSTATS is not set +CONFIG_AUDIT=y +CONFIG_AUDITSYSCALL=y +CONFIG_AUDIT_TREE=y +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=17 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_SYSCTL=y +# CONFIG_EMBEDDED is not set +CONFIG_SYSCTL_SYSCALL=y +CONFIG_SYSCTL_SYSCALL_CHECK=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +CONFIG_PROFILING=y +# CONFIG_MARKERS is not set +CONFIG_OPROFILE=m +CONFIG_HAVE_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_KRETPROBES=y +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +# CONFIG_HAVE_DMA_ATTRS is not set +CONFIG_PROC_PAGE_MONITOR=y +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +# CONFIG_DEFAULT_AS is not set +# CONFIG_DEFAULT_DEADLINE is not set +CONFIG_DEFAULT_CFQ=y +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="cfq" +CONFIG_CLASSIC_RCU=y + +# +# Platform support +# +CONFIG_PPC_MULTIPLATFORM=y +# CONFIG_PPC_82xx is not set +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +CONFIG_CLASSIC32=y +# CONFIG_PPC_C
[PATCH 5/5] powerpc: add C2K to configuration
Support for the C2K cPCI Single Board Computer from GEFanuc (PowerPC MPC7448 with a Marvell MV64460 chipset) All features of the board are not supported yet, but the board boots, flash works, all Ethernet ports are working and PCI devices are all found (USB and SATA on PCI1 do not work yet). Part 5 of 5: add the configuration tool entry for the C2K board. Signed-off-by: Remi Machet <[EMAIL PROTECTED]> --- Kconfig | 10 ++ 1 files changed, 10 insertions(+) diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig index 4290889..4f9f818 100644 --- a/arch/powerpc/platforms/embedded6xx/Kconfig +++ b/arch/powerpc/platforms/embedded6xx/Kconfig @@ -59,6 +59,16 @@ config PPC_PRPMC2800 help This option enables support for the Motorola PrPMC2800 board +config PPC_C2K + bool "SBS/GEFanuc C2K board" + depends on EMBEDDED6xx + select MV64X60 + select NOT_COHERENT_CACHE + select MTD_CFI_I4 + help + This option enables support for the GE Fanuc C2K board (formerly + an SBS board). + config TSI108_BRIDGE bool select PCI ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Paul Mackerras <[EMAIL PROTECTED]> wrote on 05/15/2008 04:36:02 PM:
> Corey J Ashford writes:
>
> > Ideally, what I'm looking for is something that mimics the operation of
> > MASKABLE_EXCEPTION_PSERIES.
> > I've been looking at the kernel code (entry_64.S, exception.h,
head_64.S)
> > but am finding it quite complicated and hard to follow, particularly in
the
> > area of interrupt disabling wrt the soft and hard disable logic.
> >
> > My initial thought is to do something like this in the beginning of my
> > perfmon2 interrupt handler:
> >
> > void perfmon_pmu_int_handler(struct pt_regs *regs) {
> >
> > if (get_paca()->soft_enabled == 0) {
> > /* disable hardware interrupts */
> > get_paca()->hard_enabled = 0;
> > regs->msr &= ^MSR_EE;
> > return;
> > }
> > ...
> > }
> >
> > Does this seem like it might work?
>
> That's a start (with ~MSR_EE rather than ^MSR_EE, of course). You
> also need to set a flag in that case, and test the flag in the part of
> arch/powerpc/kernel/irq.c:raw_local_irq_restore() that hard-enables
> interrupts. If the flag is set then you should call back into the
> perfmon2 code at that point (and clear the flag, of course). You
> could add a field to the paca for that flag.
>
> You probably also want to read some of the PMU's SPRs when you first
> get the interrupt and save their values away, and then when you get
> the call back from raw_local_irq_restore, use the saved values rather
> than what's currently in the SPRs, since the saved values will be more
> accurate.
>
> Paul.
Hi Paul,
Thanks for the feedback. I don't believe I need a separate flag, because
the PMU interrupt (via the PMAO bit) will still be pending when interrupts
are hard enabled again, and the handler will be reentered automatically.
I'll think about the issue of caching the SPR values some more, but I don't
want to complicate things too much. PMU event counts are not so critical
that they need to so accurately reflect the exact value at the time of the
interrupt.
I discovered through some trial and error that get_paca() doesn't work
correctly in the interrupt handler. It appears that the value of r13 (the
PACA pointer) is not initialized. Perhaps r13 is a scratch register used
by the compiler?
Fortunately, because the soft enable flag is available in the pt_regs
structure, and because the hard enable flag will be set to the same as the
value of regs->msr's MSR_EE flag in the restore code, I now have this code
in the interrupt handler:
void perfmon_pmu_int_handler(struct pt_regs *regs) {
if (regs->softe == 0) {
/* disable hardware interrupts */
regs->msr &= ~MSR_EE;
return;
}
...
}
This code does seem to be working, but needs more testing.
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
Most of the bulk is in defconfig and device-tree source (.dts) files,
which are effectively documentation. The change to mpc85xx_mds.c is
adding some fixups to allow ethernet to work on the 8568 MDS board
even if firmware doesn't initialize it properly. The rest are all
relatively small, well-contained bug and compile fixes.
Thanks,
Paul.
arch/powerpc/boot/dts/mpc8377_mds.dts| 27 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 60 -
arch/powerpc/boot/dts/sbc8548.dts| 94
arch/powerpc/configs/mpc8610_hpcd_defconfig | 95 +++-
arch/powerpc/mm/hash_utils_64.c | 28 ++
arch/powerpc/mm/init_64.c| 10 +-
arch/powerpc/mm/slb.c| 16 +++
arch/powerpc/mm/slb_low.S| 16 +++
arch/powerpc/platforms/85xx/mpc85xx_mds.c| 121 ++
arch/powerpc/platforms/85xx/sbc8548.c| 30 ++
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 15 +++
arch/powerpc/platforms/cell/io-workarounds.c |6 +
arch/powerpc/platforms/cell/io-workarounds.h |6 +
arch/powerpc/platforms/cell/spufs/file.c |1
arch/powerpc/platforms/cell/spufs/sched.c|2
drivers/macintosh/adb.c |2
drivers/of/base.c|3 +
include/asm-powerpc/mmu-hash64.h |1
include/asm-powerpc/pgtable-ppc64.h | 10 +-
include/asm-powerpc/uaccess.h|4 -
20 files changed, 508 insertions(+), 39 deletions(-)
Andy Fleming (2):
[POWERPC] 85xx: Add 8568 PHY workarounds to board code
[POWERPC] 85xx: Fix some sparse warnings for 85xx MDS
Anton Vorontsov (3):
[POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
[POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
[POWERPC] 86xx: mpc8610_hpcd: fix second serial port
Benjamin Herrenschmidt (1):
[POWERPC] vmemmap fixes to use smaller pages
FUJITA Tomonori (1):
[POWERPC] spufs: Fix compile error
Ishizaki Kou (1):
[POWERPC] cell: Fix section mismatches in io-workarounds code
Jeremy McNicoll (1):
[POWERPC] 85xx: SBC8548 - Add flash support and HW Rev reporting
Luke Browning (1):
[POWERPC] spufs: Fix pointer reference in find_victim
Nate Case (1):
[POWERPC] Fix uninitialized variable bug in copy_{to|from}_user
Robert P. J. Day (1):
[POWERPC] macintosh: Replace deprecated __initcall with device_initcall
Timur Tabi (1):
[POWERPC] Add null pointer check to of_find_property
Zhang Wei (1):
[POWERPC] 83xx: Enable DMA engine on the MPC8377 MDS board.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Convert remaining dts-v0 files to v1
Josh Boyer writes: > Since this mostly effects DTSs for my boards, do you mind if I pull > this into my tree? I spoke with Geoff today and he doesn't have any > planned PS3 DTS updates, so we shouldn't get conflicts doing it that > way. Sounds fine. Is this for 2.6.26? Do you have some 2.6.26 updates queued up for me (or will you)? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Corey J Ashford writes:
> Thanks for the feedback. I don't believe I need a separate flag, because
> the PMU interrupt (via the PMAO bit) will still be pending when interrupts
> are hard enabled again, and the handler will be reentered automatically.
If that were the case then we wouldn't have had the problem with
losing PMU interrupts that meant we had to change the PMU interrupt
handler from a MASKABLE_EXCEPTION to a STD_EXCEPTION. This was in
commit 449d846dbcbf61bdf7d50a923e4791102168c292.
My understanding is that the PMU only requests an interrupt when PMAO
goes from 0 to 1 (i.e. it's edge-triggered). If the CPU takes the
interrupt and then sets MSR.EE again (e.g. by returning from the
interrupt handler), and PMAO has not been reset to 0, then I don't
think the PMU requests another interrupt at that point.
> I discovered through some trial and error that get_paca() doesn't work
> correctly in the interrupt handler. It appears that the value of r13 (the
> PACA pointer) is not initialized. Perhaps r13 is a scratch register used
> by the compiler?
Weird. It definitely should be correct. Loading r13 is one of the
first things the interrupt entry code does, and r13 is not a scratch
register (it's normally the thread-local storage pointer).
If r13 is bogus then that's definitely a serious bug.
> Fortunately, because the soft enable flag is available in the pt_regs
> structure, and because the hard enable flag will be set to the same as the
> value of regs->msr's MSR_EE flag in the restore code, I now have this code
> in the interrupt handler:
>
> void perfmon_pmu_int_handler(struct pt_regs *regs) {
>
> if (regs->softe == 0) {
> /* disable hardware interrupts */
> regs->msr &= ~MSR_EE;
> return;
> }
> ...
> }
>
> This code does seem to be working, but needs more testing.
I expect that after a little while you'll stop getting PMU
interrupts...
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Convert remaining dts-v0 files to v1
On Fri, 16 May 2008 10:52:21 +1000 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Josh Boyer writes: > > > Since this mostly effects DTSs for my boards, do you mind if I pull > > this into my tree? I spoke with Geoff today and he doesn't have any > > planned PS3 DTS updates, so we shouldn't get conflicts doing it that > > way. > > Sounds fine. Is this for 2.6.26? Do you have some 2.6.26 updates > queued up for me (or will you)? No, this is .27 work. Which is why I figured it would be easier if I grabbed it for now. The only possible .26 candidate I have at the moment would be the CHIP_11 errata workaround patch I sent out earlier today. I need to do more testing across a wider variety of boards and that I was planning on having you pull that from me. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx: Fix PCI mem in rainier DTS
On Thu, May 15, 2008 at 09:41:23AM -0500, Josh Boyer wrote: > This fixes the PCI node in the Rainier to match the spec from AMCC. A > similar fix was done for 440EPx, which shares the same values as 440GRx. This will conflict with the dts-v1 conversion patch. > --- linux-2.6.orig/arch/powerpc/boot/dts/rainier.dts > +++ linux-2.6/arch/powerpc/boot/dts/rainier.dts > @@ -328,8 +328,9 @@ >* later cannot be changed. Chip supports a second >* IO range but we don't use it for now >*/ > - ranges = <0200 0 8000 1 8000 0 1000 > - 0100 0 1 e800 0 0010>; > + ranges = <0200 0 8000 1 8000 0 4000 > + 0100 0 1 e800 0 0001 > + 0100 0 1 e880 0 0380>; > > /* Inbound 2GB range starting at 0 */ > dma-ranges = <4200 0 0 0 0 0 8000>; -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Discourage use of __initcall() in favour of device_initcall()
Add a comment above the definition of __initcall(), just in case
someone looks here.
And add a checkpatch warning for new uses of __initcall().
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
How's this? My perl skills are not good, but this seems to work.
include/linux/init.h |1 +
scripts/checkpatch.pl |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h
index 21d658c..6390e22 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -193,6 +193,7 @@ extern void (*late_time_init)(void);
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
+/* Please use device_initcall() directly in new code */
#define __initcall(fn) device_initcall(fn)
#define __exitcall(fn) \
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index b6bbbcd..3faff3f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2026,6 +2026,10 @@ sub process {
if ($line =~ /\bsimple_(strto.*?)\s*\(/) {
WARN("consider using strict_$1 in preference to
simple_$1\n" . $herecurr);
}
+# check for __initcall(), use device_initcall() explicitly please
+ if ($line =~ /^.\s*__initcall\(/) {
+ WARN("please use device_initcall() instead of
__initcall()\n" . $herecurr);
+ }
# use of NR_CPUS is usually wrong
# ignore definitions of NR_CPUS and usage to define arrays as likely right
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] move of_device_get_modalias fo drivers/of
Commit 140b932f8cb6cced10b96860651a198b1b89cbb9 ("Create modalias file
in sysfs for of_platform bus") needs this to avoid breaking the sparc
builds.
Just move the code and add whitespace around some binary operators.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/of_device.c | 48 ---
drivers/of/device.c | 48 +++
include/asm-powerpc/of_device.h |2 -
include/linux/of_device.h |3 ++
4 files changed, 51 insertions(+), 50 deletions(-)
I have built this for ppc64_defconfig and sparc and sparc64 defconfigs.
diff --git a/arch/powerpc/kernel/of_device.c b/arch/powerpc/kernel/of_device.c
index 5748ddb..e9be908 100644
--- a/arch/powerpc/kernel/of_device.c
+++ b/arch/powerpc/kernel/of_device.c
@@ -89,54 +89,6 @@ struct of_device *of_device_alloc(struct device_node *np,
}
EXPORT_SYMBOL(of_device_alloc);
-ssize_t of_device_get_modalias(struct of_device *ofdev,
- char *str, ssize_t len)
-{
- const char *compat;
- int cplen, i;
- ssize_t tsize, csize, repend;
-
- /* Name & Type */
- csize = snprintf(str, len, "of:N%sT%s",
- ofdev->node->name, ofdev->node->type);
-
- /* Get compatible property if any */
- compat = of_get_property(ofdev->node, "compatible", &cplen);
- if (!compat)
- return csize;
-
- /* Find true end (we tolerate multiple \0 at the end */
- for (i=(cplen-1); i>=0 && !compat[i]; i--)
- cplen--;
- if (!cplen)
- return csize;
- cplen++;
-
- /* Check space (need cplen+1 chars including final \0) */
- tsize = csize + cplen;
- repend = tsize;
-
- if (csize>=len) /* @ the limit, all is already filled */
- return tsize;
-
- if (tsize>=len) { /* limit compat list */
- cplen = len-csize-1;
- repend = len;
- }
-
- /* Copy and do char replacement */
- memcpy(&str[csize+1], compat, cplen);
- for (i=csize; idev);
}
EXPORT_SYMBOL(of_device_unregister);
+
+ssize_t of_device_get_modalias(struct of_device *ofdev,
+ char *str, ssize_t len)
+{
+ const char *compat;
+ int cplen, i;
+ ssize_t tsize, csize, repend;
+
+ /* Name & Type */
+ csize = snprintf(str, len, "of:N%sT%s",
+ ofdev->node->name, ofdev->node->type);
+
+ /* Get compatible property if any */
+ compat = of_get_property(ofdev->node, "compatible", &cplen);
+ if (!compat)
+ return csize;
+
+ /* Find true end (we tolerate multiple \0 at the end */
+ for (i = (cplen - 1); i >= 0 && !compat[i]; i--)
+ cplen--;
+ if (!cplen)
+ return csize;
+ cplen++;
+
+ /* Check space (need cplen+1 chars including final \0) */
+ tsize = csize + cplen;
+ repend = tsize;
+
+ if (csize >= len) /* @ the limit, all is already filled */
+ return tsize;
+
+ if (tsize >= len) { /* limit compat list */
+ cplen = len - csize - 1;
+ repend = len;
+ }
+
+ /* Copy and do char replacement */
+ memcpy(&str[csize + 1], compat, cplen);
+ for (i = csize; i < repend; i++) {
+ char c = str[i];
+ if (c == '\0')
+ str[i] = 'C';
+ else if (c == ' ')
+ str[i] = '_';
+ }
+
+ return tsize;
+}
diff --git a/include/asm-powerpc/of_device.h b/include/asm-powerpc/of_device.h
index 6526e13..3c12399 100644
--- a/include/asm-powerpc/of_device.h
+++ b/include/asm-powerpc/of_device.h
@@ -21,8 +21,6 @@ extern struct of_device *of_device_alloc(struct device_node
*np,
const char *bus_id,
struct device *parent);
-extern ssize_t of_device_get_modalias(struct of_device *ofdev,
- char *str, ssize_t len);
extern int of_device_uevent(struct device *dev,
struct kobj_uevent_env *env);
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index afe3382..d3a74e0 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -24,4 +24,7 @@ static inline void of_device_free(struct of_device *dev)
of_release_dev(&dev->dev);
}
+extern ssize_t of_device_get_modalias(struct of_device *ofdev,
+ char *str, ssize_t len);
+
#endif /* _LINUX_OF_DEVICE_H */
--
1.5.5.1
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxp
Re: Feedback requested on switching the exception wrapper used for the PMU interrupt on ppc64
Paul Mackerras <[EMAIL PROTECTED]> wrote on 05/15/2008 06:02:03 PM:
> Corey J Ashford writes:
>
> > Thanks for the feedback. I don't believe I need a separate flag,
because
> > the PMU interrupt (via the PMAO bit) will still be pending when
interrupts
> > are hard enabled again, and the handler will be reentered
automatically.
>
> If that were the case then we wouldn't have had the problem with
> losing PMU interrupts that meant we had to change the PMU interrupt
> handler from a MASKABLE_EXCEPTION to a STD_EXCEPTION. This was in
> commit 449d846dbcbf61bdf7d50a923e4791102168c292.
>
> My understanding is that the PMU only requests an interrupt when PMAO
> goes from 0 to 1 (i.e. it's edge-triggered). If the CPU takes the
> interrupt and then sets MSR.EE again (e.g. by returning from the
> interrupt handler), and PMAO has not been reset to 0, then I don't
> think the PMU requests another interrupt at that point.
I think that is the case on early POWER4 and PPC970 chips where this is no
PMAO bit. However, from personal [bad] experience, I can say that if PMAO
is not cleared in the interrupt handler, the exception will be taken again
when interrupts are reenabled. I've seen the system lockup in interrupt
handling "loops" because it wasn't being cleared.
>
> > I discovered through some trial and error that get_paca() doesn't work
> > correctly in the interrupt handler. It appears that the value of r13
(the
> > PACA pointer) is not initialized. Perhaps r13 is a scratch register
used
> > by the compiler?
>
> Weird. It definitely should be correct. Loading r13 is one of the
> first things the interrupt entry code does, and r13 is not a scratch
> register (it's normally the thread-local storage pointer).
>
> If r13 is bogus then that's definitely a serious bug.
My evidence for this was that I was seeing get_paca()->soft_enable and
get_paca()->hard_enable set to zero, but regs->softe set to 1.
Looking at the code again, I see that in STD_EXCEPTION_COMMON in
exception.h, the macro DISABLE_INTS is used, which zeros out the soft and
hard disable flags. So r13 is ok, and I think using the regs struct is
the right way to go.
>
> > Fortunately, because the soft enable flag is available in the pt_regs
> > structure, and because the hard enable flag will be set to the same as
the
> > value of regs->msr's MSR_EE flag in the restore code, I now have this
code
> > in the interrupt handler:
> >
> > void perfmon_pmu_int_handler(struct pt_regs *regs) {
> >
> > if (regs->softe == 0) {
> > /* disable hardware interrupts */
> > regs->msr &= ~MSR_EE;
> > return;
> > }
> > ...
> > }
> >
> > This code does seem to be working, but needs more testing.
>
> I expect that after a little while you'll stop getting PMU
> interrupts...
>
> Paul.
I haven't seen that yet, but I am seeing another kernel hang with my test
case that creates and deals with about 2000 interrupts per second. After
a random amount of time running it, it hangs the system. If I restart the
system into xmon, I see a callstack that doesn't have any perfmon code in
it, but does have some kernel interrupt handling code. The hang is the
same when using MASKABLE_EXCEPTION_PSERIES and STD_EXCEPTION_PSERIES (+
the above fix).
I'd love to be able to run that call stack by you, if you have time to
look at it.
Thanks,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: DTS file for the C2K
On Thu, May 15, 2008 at 05:22:50PM -0700, Remi Machet wrote:
> Support for the C2K cPCI Single Board Computer from GEFanuc
> (PowerPC MPC7448 with a Marvell MV64460 chipset)
> All features of the board are not supported yet, but the board
> boots, flash works, all Ethernet ports are working and PCI
> devices are all found (USB and SATA on PCI1 do not work yet).
>
> Part 1 of 5: DTS file describing the board peripherals. As far as I know
> all peripherals except the FPGA are listed in there (I did not included
> the FPGA because a lot of work is needed there).
>
> Signed-off-by: Remi Machet <[EMAIL PROTECTED]>
> ---
> c2k.dts | 353
>
> 1 files changed, 353 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/c2k.dts b/arch/powerpc/boot/dts/c2k.dts
> new file mode 100644
> index 000..21281b8
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/c2k.dts
> @@ -0,0 +1,353 @@
> +/* Device Tree Source for GEFanuc C2K
> + *
> + * Author: Remi Machet <[EMAIL PROTECTED]>
> + *
> + * Originated from prpmc2800.dts
> + *
> + * 2008 (c) Stanford University
> + * 2007 (c) MontaVista, Software, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "C2K";
> + compatible = "GEFanuc,C2K";
> + coherency-off;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,7447 {
This needs a unit address. So, either "PowerPC,[EMAIL PROTECTED]" or simply
"[EMAIL PROTECTED]". The latter is the newer convention, but if you do that you
should add a compatible property listing "PowerPC,7447".
[snip]
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
Remove this device_type.
[snip]
> + CUNIT: [EMAIL PROTECTED] {
> + reg = <0xf200 0x200>;
> + };
> +
> + MPSCROUTING: [EMAIL PROTECTED] {
> + reg = <0xb400 0xc>;
> + };
> +
> + MPSCINTR: [EMAIL PROTECTED] {
> + reg = <0xb800 0x100>;
> + virtual-reg = <0xd800b800>;
> + };
These devices should really have compatible properties, but that's
not really your problem, it needs to be addressed by whoever's
responsible for the mpsc binding.
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "i2c";
Remove this device_type.
[snip]
> + PCI0: [EMAIL PROTECTED] {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "marvell,mv64360-pci";
> + cell-index = <0>;
This is a suspicious looking use of cell-index, though again this
could be a problem in the binding rather than your tree per se.
cell-index should *only* be present if it's used to index into some
shared resource register.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: boot code for the C2K
On Thu, May 15, 2008 at 05:23:40PM -0700, Remi Machet wrote: > Support for the C2K cPCI Single Board Computer from GEFanuc > (PowerPC MPC7448 with a Marvell MV64460 chipset) > All features of the board are not supported yet, but the board > boots, flash works, all Ethernet ports are working and PCI > devices are all found (USB and SATA on PCI1 do not work yet). > > Part 2 of 5: support for the board in arch/powerpc/boot. > > Signed-off-by: Remi Machet <[EMAIL PROTECTED]> [snip] > +BSS_STACK(16*KB); 16kB is a really big stack for a bootwrapper. Do you really need this much? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] move of_device_get_modalias fo drivers/of
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Fri, 16 May 2008 11:57:45 +1000
> Commit 140b932f8cb6cced10b96860651a198b1b89cbb9 ("Create modalias file
> in sysfs for of_platform bus") needs this to avoid breaking the sparc
> builds.
>
> Just move the code and add whitespace around some binary operators.
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Simplify error handling for unparseable input [resend]
Currently, main() tests if it got a valid input tree from whichever
dt_from_*() function it invoked and if not, die()s. For one thing,
this test has, for no good reason, three different ways for those
functions to communicate a failure to provide input (bi NULL, bi->dt
NULL, or bi->error non-zero). For another, in every case save one, if
the dt_from_*() functions are unable to provide input they will
immediately die() (with a more specific error message) rather than
proceeding to the test in main().
Therefore, this patch removes this test, making the one case that
could have triggered it (in dt_from_source()) call die() directly
instead. With this change, the error field in struct boot_info is now
unused, so remove it.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
dtc.c|3 ---
dtc.h|1 -
livetree.c |1 -
treesource.c |6 --
4 files changed, 4 insertions(+), 7 deletions(-)
Index: dtc/dtc.h
===
--- dtc.orig/dtc.h 2008-03-24 14:33:33.0 +1100
+++ dtc/dtc.h 2008-03-24 14:33:34.0 +1100
@@ -232,7 +232,6 @@
struct boot_info {
struct reserve_info *reservelist;
struct node *dt;/* the device tree */
- int error;
};
struct boot_info *build_boot_info(struct reserve_info *reservelist,
Index: dtc/livetree.c
===
--- dtc.orig/livetree.c 2008-03-24 14:18:44.0 +1100
+++ dtc/livetree.c 2008-03-24 14:33:34.0 +1100
@@ -172,7 +172,6 @@
bi = xmalloc(sizeof(*bi));
bi->reservelist = reservelist;
bi->dt = tree;
- bi->error = 0;
return bi;
}
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-24 14:35:05.0 +1100
+++ dtc/dtc.c 2008-03-24 14:35:10.0 +1100
@@ -201,9 +201,6 @@
if (inf && inf->file != stdin)
fclose(inf->file);
- if (! bi || ! bi->dt || bi->error)
- die("Couldn't read input tree\n");
-
fill_fullpaths(bi->dt, "");
process_checks(force, bi);
Index: dtc/treesource.c
===
--- dtc.orig/treesource.c 2008-03-24 14:33:44.0 +1100
+++ dtc/treesource.c2008-03-24 14:35:52.0 +1100
@@ -36,9 +36,11 @@
yyin = srcpos_file->file;
if (yyparse() != 0)
- return NULL;
+ die("Unable to parse input tree\n");
+
+ if (treesource_error)
+ die("Syntax error parsing input tree\n");
- the_boot_info->error = treesource_error;
return the_boot_info;
}
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
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
dtc: Clean up included Makefile fragments [resend]
Currently the Makefile.dtc and Makefile.libfdt fragments include a number of things that seemed like they might be useful for other projects embedding the pieces, or for a make dist target. Well, we have no make dist target, it's become fairly unclear that these things would actually be useful to embedders (the kernel certainly doesn't use them), and it's a bunch of stuff with no current users. This patch, therefore, removes a bunch of unused definitions from the Makefile fragments. It also removes a dependency declared in Makefile.libfdt (of libfdt.a on the constituent .o files) which was incorrect (wrong path), and if corrected would be redundant with the similar dependency in the top-level makefile. Signed-off-by: David Gibson <[EMAIL PROTECTED]> --- Makefile |7 --- Makefile.dtc | 18 +- libfdt/Makefile.libfdt |7 --- tests/Makefile.tests |4 ++-- 4 files changed, 7 insertions(+), 29 deletions(-) Index: dtc/Makefile.dtc === --- dtc.orig/Makefile.dtc 2008-03-24 13:16:17.0 +1100 +++ dtc/Makefile.dtc2008-03-24 13:24:06.0 +1100 @@ -5,21 +5,5 @@ # DTC_SRCS = dtc.c flattree.c fstree.c data.c livetree.c treesource.c srcpos.c \ checks.c -DTC_EXTRA = dtc.h srcpos.h -DTC_LEXFILES = dtc-lexer.l -DTC_BISONFILES = dtc-parser.y - -DTC_LEX_SRCS = $(DTC_LEXFILES:%.l=%.lex.c) -DTC_BISON_SRCS = $(DTC_BISONFILES:%.y=%.tab.c) -DTC_BISON_INCLUDES = $(DTC_BISONFILES:%.y=%.tab.h) - -DTC_GEN_SRCS = $(DTC_LEX_SRCS) $(DTC_BISON_SRCS) -DTC_GEN_ALL = $(DTC_GEN_SRCS) $(DTC_BISON_INCLUDES) +DTC_GEN_SRCS = dtc-lexer.lex.c dtc-parser.tab.c DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o) - -DTC_CLEANFILES = $(DTC_GEN_ALL) - -# We assume the containing Makefile system can do auto-dependencies for most -# things, but we supply the dependencies on generated header files explicitly - -$(addprefix $(DTC_objdir)/,$(DTC_GEN_SRCS:%.c=%.o)): $(addprefix $(DTC_objdir)/,$(DTC_BISON_INCLUDES)) Index: dtc/Makefile === --- dtc.orig/Makefile 2008-03-24 13:16:17.0 +1100 +++ dtc/Makefile2008-03-24 13:17:58.0 +1100 @@ -53,7 +53,7 @@ $(INSTALL) -d $(DESTDIR)$(BINDIR) $(INSTALL) -m 755 dtc $(DESTDIR)$(BINDIR) $(INSTALL) -d $(DESTDIR)$(LIBDIR) - $(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR) + $(INSTALL) -m 644 $(LIBFDT_lib) $(DESTDIR)$(LIBDIR) $(INSTALL) -d $(DESTDIR)$(INCLUDEDIR) $(INSTALL) -m 644 $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_INCLUDES)) $(DESTDIR)$(INCLUDEDIR) @@ -135,12 +135,13 @@ # LIBFDT_objdir = libfdt LIBFDT_srcdir = libfdt +LIBFDT_lib = $(LIBFDT_objdir)/libfdt.a include $(LIBFDT_srcdir)/Makefile.libfdt .PHONY: libfdt -libfdt: $(LIBFDT_LIB) +libfdt: $(LIBFDT_lib) -$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS)) +$(LIBFDT_lib): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS)) libfdt_clean: @$(VECHO) CLEAN "(libfdt)" Index: dtc/libfdt/Makefile.libfdt === --- dtc.orig/libfdt/Makefile.libfdt 2008-03-24 13:16:17.0 +1100 +++ dtc/libfdt/Makefile.libfdt 2008-03-24 13:17:58.0 +1100 @@ -4,11 +4,4 @@ # be easily embeddable into other systems of Makefiles. # LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c -LIBFDT_INCLUDES = fdt.h libfdt.h -LIBFDT_EXTRA = libfdt_internal.h -LIBFDT_LIB = libfdt/libfdt.a - LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o) - -$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS)) - Index: dtc/tests/Makefile.tests === --- dtc.orig/tests/Makefile.tests 2008-03-24 13:16:17.0 +1100 +++ dtc/tests/Makefile.tests2008-03-24 13:17:58.0 +1100 @@ -35,9 +35,9 @@ .PHONY: tests tests: $(TESTS) $(TESTS_TREES) -$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_LIB) +$(LIB_TESTS): %: $(TESTS_PREFIX)testutils.o $(LIBFDT_lib) -$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_LIB) +$(LIBTREE_TESTS): %: $(TESTS_PREFIX)testutils.o $(TESTS_PREFIX)trees.o $(LIBFDT_lib) $(TESTS_PREFIX)dumptrees: $(TESTS_PREFIX)trees.o -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ 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
dtc: Trivial formatting fixes [resend]
This patch fixes some trivial indentation and brace/bracket style
problems.
---
dtc.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-26 16:18:51.0 +1100
+++ dtc/dtc.c 2008-03-26 16:19:12.0 +1100
@@ -163,8 +163,8 @@
boot_cpuid_phys = strtol(optarg, NULL, 0);
break;
case 'v':
- printf("Version: %s\n", DTC_VERSION);
- exit(0);
+ printf("Version: %s\n", DTC_VERSION);
+ exit(0);
case 'h':
default:
usage();
@@ -179,9 +179,8 @@
arg = argv[optind];
/* minsize and padsize are mutually exclusive */
- if ((minsize) && (padsize)) {
+ if (minsize && padsize)
die("Can't set both -p and -S\n");
- }
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
inform, outform, arg);
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
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
dtc: Make dt_from_blob() open its own input file, like the other input formats [resend]
Currently, main() has a variable for the input file. It used to be
that main() would open the input based on command line arguments
before passing it to the dt_from_*() function. However, only
dt_from_blob() uses this. dt_from_source() opens its own file, and
dt_from_fs() interprets the argument as as a directory and does its
own opendir() call.
Furthermore, main() opened the file with dtc_open_file() but closed it
with a direct call to fclose().
Therefore, to improve the interface consistency between the
dt_from_*() functions, make dt_from_blob() open and close its own
files like the other dt_from_*() functions.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
dtc.c | 16 +---
dtc.h |2 +-
flattree.c | 26 --
3 files changed, 22 insertions(+), 22 deletions(-)
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-26 16:08:22.0 +1100
+++ dtc/dtc.c 2008-03-26 16:08:37.0 +1100
@@ -118,7 +118,6 @@
int force = 0, check = 0;
const char *arg;
int opt;
- struct dtc_file *inf = NULL;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
@@ -187,19 +186,14 @@
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
inform, outform, arg);
- if (streq(inform, "dts")) {
+ if (streq(inform, "dts"))
bi = dt_from_source(arg);
- } else if (streq(inform, "fs")) {
+ else if (streq(inform, "fs"))
bi = dt_from_fs(arg);
- } else if(streq(inform, "dtb")) {
- inf = dtc_open_file(arg, NULL);
- bi = dt_from_blob(inf->file);
- } else {
+ else if(streq(inform, "dtb"))
+ bi = dt_from_blob(arg);
+ else
die("Unknown input format \"%s\"\n", inform);
- }
-
- if (inf && inf->file != stdin)
- fclose(inf->file);
fill_fullpaths(bi->dt, "");
process_checks(force, bi);
Index: dtc/dtc.h
===
--- dtc.orig/dtc.h 2008-03-26 16:08:22.0 +1100
+++ dtc/dtc.h 2008-03-26 16:08:37.0 +1100
@@ -248,7 +248,7 @@
void dt_to_asm(FILE *f, struct boot_info *bi, int version,
int boot_cpuid_phys);
-struct boot_info *dt_from_blob(FILE *f);
+struct boot_info *dt_from_blob(const char *fname);
/* Tree source */
Index: dtc/flattree.c
===
--- dtc.orig/flattree.c 2008-03-26 16:08:22.0 +1100
+++ dtc/flattree.c 2008-03-26 16:08:37.0 +1100
@@ -19,6 +19,7 @@
*/
#include "dtc.h"
+#include "srcpos.h"
#define FTF_FULLPATH 0x1
#define FTF_VARALIGN 0x2
@@ -780,8 +781,9 @@
}
-struct boot_info *dt_from_blob(FILE *f)
+struct boot_info *dt_from_blob(const char *fname)
{
+ struct dtc_file *dtcf;
u32 magic, totalsize, version, size_dt;
u32 off_dt, off_str, off_mem_rsvmap;
int rc;
@@ -796,12 +798,14 @@
u32 val;
int flags = 0;
- rc = fread(&magic, sizeof(magic), 1, f);
- if (ferror(f))
+ dtcf = dtc_open_file(fname, NULL);
+
+ rc = fread(&magic, sizeof(magic), 1, dtcf->file);
+ if (ferror(dtcf->file))
die("Error reading DT blob magic number: %s\n",
strerror(errno));
if (rc < 1) {
- if (feof(f))
+ if (feof(dtcf->file))
die("EOF reading DT blob magic number\n");
else
die("Mysterious short read reading magic number\n");
@@ -811,11 +815,11 @@
if (magic != FDT_MAGIC)
die("Blob has incorrect magic number\n");
- rc = fread(&totalsize, sizeof(totalsize), 1, f);
- if (ferror(f))
+ rc = fread(&totalsize, sizeof(totalsize), 1, dtcf->file);
+ if (ferror(dtcf->file))
die("Error reading DT blob size: %s\n", strerror(errno));
if (rc < 1) {
- if (feof(f))
+ if (feof(dtcf->file))
die("EOF reading DT blob size\n");
else
die("Mysterious short read reading blob size\n");
@@ -835,12 +839,12 @@
p = blob + sizeof(magic) + sizeof(totalsize);
while (sizeleft) {
- if (feof(f))
+ if (feof(dtcf->file))
die("EOF before reading %d bytes of DT blob\n",
totalsize);
- rc = fread(p, 1, sizeleft, f);
- if (ferror(f))
+ rc = fread(p, 1, sizeleft, dtcf->file);
+ if (ferror(dtcf->file))
die("Error reading DT blob: %s\n",
strerror(errno));
@@ -902,5 +906,7 @@
free(blob);
+ dtc_close_file(dtcf
dtc: Rework handling of boot_cpuid_phys [resend]
Currently, dtc will put the nonsense value 0xfeedbeef into the
boot_cpuid_phys field of an output blob, unless explicitly given
another value with the -b command line option. As well as being a
totally unuseful default value, this also means that dtc won't
properly preserve the boot_cpuid_phys field in -I dtb -O dtb mode.
This patch reworks things to improve the boot_cpuid handling. The new
semantics are that the output's boot_cpuid_phys value is:
the value given on the command line if -b is used
otherwise
the value from the input, if in -I dtb mode
otherwise
0
Implementation-wise we do the following:
- boot_cpuid_phys is added to struct boot_info, so that
structure now contains all of the blob's semantic information.
- dt_to_blob() and dt_to_asm() output the cpuid given in
boot_info
- dt_from_blob() fills in boot_info based on the input blob
- The other dt_from_*() functions just record 0, but we can
change this easily if e.g. we invent a way of specifying the boot cpu
in the source format.
- main() overrides the cpuid in the boot_info between input
and output if -b is given
We add some testcases to check this new behaviour.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
dtc-parser.y |4 +--
dtc.c | 12 +++
dtc.h |9 +++-
flattree.c | 14 ++---
fstree.c |2 -
livetree.c |3 +-
tests/Makefile.tests |2 -
tests/boot-cpuid.c | 48 +
tests/dtbs_equal_ordered.c |7 ++
tests/run_tests.sh |8 +++
10 files changed, 88 insertions(+), 21 deletions(-)
Index: dtc/tests/dtbs_equal_ordered.c
===
--- dtc.orig/tests/dtbs_equal_ordered.c 2008-03-26 17:53:17.0 +1100
+++ dtc/tests/dtbs_equal_ordered.c 2008-03-26 17:53:17.0 +1100
@@ -125,6 +125,7 @@
int main(int argc, char *argv[])
{
void *fdt1, *fdt2;
+ uint32_t cpuid1, cpuid2;
test_init(argc, argv);
if (argc != 3)
@@ -135,5 +136,11 @@
compare_mem_rsv(fdt1, fdt2);
compare_structure(fdt1, fdt2);
+ cpuid1 = fdt_boot_cpuid_phys(fdt1);
+ cpuid2 = fdt_boot_cpuid_phys(fdt2);
+ if (cpuid1 != cpuid2)
+ FAIL("boot_cpuid_phys mismatch 0x%x != 0x%x",
+cpuid1, cpuid2);
+
PASS();
}
Index: dtc/dtc-parser.y
===
--- dtc.orig/dtc-parser.y 2008-03-26 17:53:17.0 +1100
+++ dtc/dtc-parser.y2008-03-26 17:53:17.0 +1100
@@ -85,11 +85,11 @@
sourcefile:
DT_V1 ';' memreserves devicetree
{
- the_boot_info = build_boot_info($3, $4);
+ the_boot_info = build_boot_info($3, $4, 0);
}
| v0_memreserves devicetree
{
- the_boot_info = build_boot_info($1, $2);
+ the_boot_info = build_boot_info($1, $2, 0);
}
;
Index: dtc/dtc.c
===
--- dtc.orig/dtc.c 2008-03-26 17:53:17.0 +1100
+++ dtc/dtc.c 2008-03-26 17:53:17.0 +1100
@@ -120,7 +120,7 @@
int opt;
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
- int boot_cpuid_phys = 0xfeedbeef;
+ long long cmdline_boot_cpuid = -1;
quiet = 0;
reservenum = 0;
@@ -160,7 +160,7 @@
quiet++;
break;
case 'b':
- boot_cpuid_phys = strtol(optarg, NULL, 0);
+ cmdline_boot_cpuid = strtoll(optarg, NULL, 0);
break;
case 'v':
printf("Version: %s\n", DTC_VERSION);
@@ -194,9 +194,13 @@
else
die("Unknown input format \"%s\"\n", inform);
+ if (cmdline_boot_cpuid != -1)
+ bi->boot_cpuid_phys = cmdline_boot_cpuid;
+
fill_fullpaths(bi->dt, "");
process_checks(force, bi);
+
if (streq(outname, "-")) {
outf = stdout;
} else {
@@ -209,9 +213,9 @@
if (streq(outform, "dts")) {
dt_to_source(outf, bi);
} else if (streq(outform, "dtb")) {
- dt_to_blob(outf, bi, outversion, boot_cpuid_phys);
+ dt_to_blob(outf, bi, outversion);
} else if (streq(outform, "asm")) {
- dt_to_asm(outf, bi, outversion, boot_cpuid_phys);
+ dt_to_asm(outf, bi, outversion);
} else if (streq(outform, "null")) {
/* do nothing */
} else {
Index: dtc/dtc.h
===
--- dtc.or
Re: [PATCH] 4xx: Fix PCI mem in rainier DTS
On Fri, 16 May 2008 10:15:29 +1000 David Gibson <[EMAIL PROTECTED]> wrote: > On Thu, May 15, 2008 at 09:41:23AM -0500, Josh Boyer wrote: > > This fixes the PCI node in the Rainier to match the spec from AMCC. A > > similar fix was done for 440EPx, which shares the same values as 440GRx. > > This will conflict with the dts-v1 conversion patch. I'm well aware of that. It will be fixed up. Thanks. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] [WATCHDOG] mpc83xx_wdt: convert to the OF platform driver
Hi Anton, On Thu, 15 May 2008 20:53:49 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > This patch simply converts mpc83xx_wdt to the OF platform driver so we > can directly work with the device tree without passing various stuff > through platform data. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Looks good. Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgphnAy4FXkk4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] powerpc: C2K board driver
Hi Remi, On Thu, 15 May 2008 17:24:28 -0700 Remi Machet <[EMAIL PROTECTED]> wrote: > > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include Normally we don'y mix linux/ and asm/ includes (put all the linux ones at the top). You need to include because you use the device tree accessor functions. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpC9DdsjsYC4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 4xx: Workaround for CHIP_11 Errata
On Thursday 15 May 2008, Josh Boyer wrote: > > "Josh Boyer" <[EMAIL PROTECTED]> wrote: > > > This implements the recommended workaround for this errata for chips > > > that use older versions of firmware that do not already handle it. > > > The last 4KiB of memory are hidden from the kernel to prevent the > > > problem transactions from occurring. > > > > Do you know which versions of firmware have this problem? > > Any U-Boot older than 1.3.3-rc1. Not sure about PIBS, but I don't > think the version that is on my Bamboo board has a fix for it. PIBS will definitely have this problem too. This errata is quite new on 440EP/GR. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
