[BUG] 2.6.26-rc8-git2 - kernel BUG at mm/page_alloc.c:585
Hi, when running kernbench on powerpc box booted with the 2.6.26-rc8-git2 kernel the machine drops to xmon with the kernel BUG kernel BUG at mm/page_alloc.c:585! cpu 0x0: Vector: 700 (Program Check) at [c000c389ed50] pc: c00e22ec: .__rmqueue+0x178/0x25c lr: c00e22ec: .__rmqueue+0x178/0x25c sp: c000c389efd0 msr: 80029032 current = 0xc000f6e0e790 paca= 0xc0873480 pid = 3421, comm = tar kernel BUG at mm/page_alloc.c:585! enter ? for help [c000c389efd0] c00e22d0 .__rmqueue+0x15c/0x25c (unreliable) [c000c389f0a0] c00e2438 .rmqueue_bulk+0x68/0xf0 [c000c389f170] c00e43cc .get_page_from_freelist+0x2d0/0x848 [c000c389f2b0] c00e4abc .__alloc_pages_internal+0x12c/0x494 [c000c389f3c0] c00e4e6c .__alloc_pages+0x1c/0x30 [c000c389f440] c01107d8 .kmem_getpages+0x90/0x198 [c000c389f4e0] c0111200 .fallback_alloc+0x190/0x26c [c000c389f5b0] c0111478 .cache_alloc_node+0x19c/0x1d0 [c000c389f660] c0111e90 .kmem_cache_alloc+0x150/0x1f8 [c000c389f710] d019fb50 .ext3_alloc_inode+0x2c/0x74 [ext3] [c000c389f790] c013725c .alloc_inode+0x58/0x278 [c000c389f830] c01374b4 .new_inode+0x38/0xd4 [c000c389f8d0] d0193930 .ext3_new_inode+0x90/0xc64 [ext3] [c000c389f9f0] d019dc28 .ext3_create+0xc4/0x16c [ext3] [c000c389fab0] c0127944 .vfs_create+0x12c/0x1d4 [c000c389fb60] c012b54c .do_filp_open+0x210/0x8b4 [c000c389fd00] c01191f8 .do_sys_open+0x80/0x144 [c000c389fdb0] c015f5d8 .compat_sys_open+0x2c/0x44 [c000c389fe30] c00086dc syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 0ff0e6d4 SP (ffd3f5a0) is in userspace 0:mon> r R00 = f0008d00 R16 = 0001 R01 = c000c389efd0 R17 = 0044 R02 = c07e74e0 R18 = 0001 R03 = 0001 R19 = c0010828 R04 = f0069000 R20 = c0010800 R05 = 0003 R21 = c0015700 R06 = 0008 R22 = R07 = R23 = 0001 R08 = 1180 R24 = 0007 R09 = f0008cff R25 = 0007 R10 = c0015700 R26 = 0080 R11 = c0885df8 R27 = c0015e28 R12 = c00010010080 R28 = f0066000 R13 = c0873480 R29 = f0069000 R14 = 0001 R30 = c0791ce0 R15 = 0001 R31 = c000c389efd0 pc = c00e22ec .__rmqueue+0x178/0x25c lr = c00e22ec .__rmqueue+0x178/0x25c msr = 80029032 cr = 24000442 ctr = 0003 xer = 2000 trap = 700 0:mon> u SLB contents of cpu 0 00 c800 40004f7ca3000510 1T ESID= c0 VSID= 4f7ca3 LLP:110 01 d800 4000eb71b510 1T ESID= d0 VSID= eb71b0 LLP:110 11 0800 20b2b24a4d90 256M ESID=0 VSID=20b2b24a4 LLP:110 12 f800 2bea2a039d90 256M ESID=f VSID=2bea2a039 LLP:110 13 4800 23b06bd10d90 256M ESID=4 VSID=23b06bd10 LLP:110 14 1800 217220abfd90 256M ESID=1 VSID=217220abf LLP:110 38 f800 4000235bcc000500 1T ESID= f0 VSID= 235bcc LLP:100 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
On Wed, Jul 2, 2008 at 11:16 AM, Benjamin Herrenschmidt < [EMAIL PROTECTED]> wrote: > > > > > Actually the meachanism of stopping the queue and starting it is > > already there. But even then due to some sync issue between the poll > > routine and xmit, we were resulted in using the slots of skb which was > > not actually got freed before. > > I agree this could a bug , Since its not is not clear why buffers are > > not getting transferred timely?. But to handle this we should have a > > work around otherwise system may go out of memory. If we go for > > stopping the queue in these scenario also ( Where a unfreed skbs slot > > has been assigned to another ), Then kernel may call tx timeout, And > > reset the driver. In that case handelling this special case here could > > lead us better performance as compared to stopping the queue > > Let me know your comments. > > Well, if we have a bug, we need to fix it. ie, understand how it is that > the existing mechanism to stop the queue doesn't work, and prevent xmit > from overwriting a non-clear transmit slot (possibly displaying an error > to help us track down the bug). > > I'll have to dig a bit, I'll see if I can find some time tomorrow. The reason could be sync issue between poll and xmit. I would like to have one clarification , Why in the present design no locks has been implemented to protect the queue from simulatenous access ?? > > > Cheers, > Ben. > > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
> > Actually the meachanism of stopping the queue and starting it is > already there. But even then due to some sync issue between the poll > routine and xmit, we were resulted in using the slots of skb which was > not actually got freed before. > I agree this could a bug , Since its not is not clear why buffers are > not getting transferred timely?. But to handle this we should have a > work around otherwise system may go out of memory. If we go for > stopping the queue in these scenario also ( Where a unfreed skbs slot > has been assigned to another ), Then kernel may call tx timeout, And > reset the driver. In that case handelling this special case here could > lead us better performance as compared to stopping the queue > Let me know your comments. Well, if we have a bug, we need to fix it. ie, understand how it is that the existing mechanism to stop the queue doesn't work, and prevent xmit from overwriting a non-clear transmit slot (possibly displaying an error to help us track down the bug). I'll have to dig a bit, I'll see if I can find some time tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
Hi Benn, Please find my comments below. On Tue, Jun 24, 2008 at 4:51 AM, Benjamin Herrenschmidt < [EMAIL PROTECTED]> wrote: > On Mon, 2008-06-23 at 14:55 +0200, Stefan Roese wrote: > > From: Sathya Narayanan <[EMAIL PROTECTED]> > > > > This patch addresses the memory leak happenning in drivers transmit queue > > under heavy load condition. Once the transmit queue becomes full, driver > > does an automatic wrapup of queue. During which the untransmitted SKB's > are > > lost without getting freed up. > > This would be a bug. We should stop the queue when full instead. Actually the meachanism of stopping the queue and starting it is already there. But even then due to some sync issue between the poll routine and xmit, we were resulted in using the slots of skb which was not actually got freed before. I agree this could a bug , Since its not is not clear why buffers are not getting transferred timely?. But to handle this we should have a work around otherwise system may go out of memory. If we go for stopping the queue in these scenario also ( Where a unfreed skbs slot has been assigned to another ), Then kernel may call tx timeout, And reset the driver. In that case handelling this special case here could lead us better performance as compared to stopping the queue Let me know your comments. > > > > Signed-off-by: Sathya Narayanan <[EMAIL PROTECTED]> > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > --- > > drivers/net/ibm_newemac/core.c |7 +++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/net/ibm_newemac/core.c > b/drivers/net/ibm_newemac/core.c > > index aa407b2..ee868b6 100644 > > --- a/drivers/net/ibm_newemac/core.c > > +++ b/drivers/net/ibm_newemac/core.c > > @@ -1328,6 +1328,13 @@ static int emac_start_xmit(struct sk_buff *skb, > struct net_device *ndev) > > > > DBG2(dev, "xmit(%u) %d" NL, len, slot); > > > > + if (dev->tx_skb[slot] && dev->tx_desc[slot].data_ptr) { > > + dev_kfree_skb(dev->tx_skb[slot]); > > + dev->tx_skb[slot] = NULL; > > + dev->tx_cnt--; > > + ++dev->estats.tx_dropped; > > + } > > + > > dev->tx_skb[slot] = skb; > > dev->tx_desc[slot].data_ptr = dma_map_single(&dev->ofdev->dev, > >skb->data, len, > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/5200: fix compile warnings in bestcomm driver
From: Grant Likely <[EMAIL PROTECTED]> Fix for the following compiler warnings: CC arch/powerpc/sysdev/bestcomm/bestcomm.o arch/powerpc/sysdev/bestcomm/bestcomm.c: In function 'mpc52xx_bcom_probe': arch/powerpc/sysdev/bestcomm/bestcomm.c:446: warning: format '%08lx' expects type 'long unsigned int', but argument 2 has type 'phys_addr_t' CC arch/powerpc/sysdev/bestcomm/sram.o arch/powerpc/sysdev/bestcomm/sram.c: In function 'bcom_sram_init': arch/powerpc/sysdev/bestcomm/sram.c:89: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'phys_addr_t' Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/bestcomm/bestcomm.c |2 +- arch/powerpc/sysdev/bestcomm/sram.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c index 64ec7d6..446c9ea 100644 --- a/arch/powerpc/sysdev/bestcomm/bestcomm.c +++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c @@ -443,7 +443,7 @@ mpc52xx_bcom_probe(struct of_device *op, const struct of_device_id *match) /* Done ! */ printk(KERN_INFO "DMA: MPC52xx BestComm engine @%08lx ok !\n", - bcom_eng->regs_base); + (long)bcom_eng->regs_base); return 0; diff --git a/arch/powerpc/sysdev/bestcomm/sram.c b/arch/powerpc/sysdev/bestcomm/sram.c index 9978438..5d74ef7 100644 --- a/arch/powerpc/sysdev/bestcomm/sram.c +++ b/arch/powerpc/sysdev/bestcomm/sram.c @@ -86,7 +86,7 @@ int bcom_sram_init(struct device_node *sram_node, char *owner) if (!bcom_sram->base_virt) { printk(KERN_ERR "%s: bcom_sram_init: " "Map error SRAM zone 0x%08lx (0x%0x)!\n", - owner, bcom_sram->base_phys, bcom_sram->size ); + owner, (long)bcom_sram->base_phys, bcom_sram->size ); rv = -ENOMEM; goto error_release; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: cleanup copy_to/from_user for vsx and fpr
This merges and cleans up some of the ugly copy/to from user code which is required for the new fpr and vsx layout in the thread_struct. Also fixes some hard coded buffer sizes and removes a redundant fpr_flush_to_thread. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- Sorry, the last version broke 32bit kernel builds signal.h| 10 + signal_32.c | 109 +--- signal_64.c | 43 ++- 3 files changed, 96 insertions(+), 66 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal.h === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal.h +++ linux-2.6-ozlabs/arch/powerpc/kernel/signal.h @@ -24,6 +24,16 @@ extern int handle_rt_signal32(unsigned l siginfo_t *info, sigset_t *oldset, struct pt_regs *regs); +extern unsigned long copy_fpr_to_user(void __user *to, + struct task_struct *task); +extern unsigned long copy_fpr_from_user(struct task_struct *task, + void __user *from); +#ifdef CONFIG_VSX +extern unsigned long copy_vsx_to_user(void __user *to, + struct task_struct *task); +extern unsigned long copy_vsx_from_user(struct task_struct *task, + void __user *from); +#endif #ifdef CONFIG_PPC64 Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c @@ -328,6 +328,75 @@ struct rt_sigframe { int abigap[56]; }; +#ifdef CONFIG_VSX +unsigned long copy_fpr_to_user(void __user *to, + struct task_struct *task) +{ + double buf[ELF_NFPREG]; + int i; + + /* save FPR copy to local buffer then write to the thread_struct */ + for (i = 0; i < (ELF_NFPREG - 1) ; i++) + buf[i] = task->thread.TS_FPR(i); + memcpy(&buf[i], &task->thread.fpscr, sizeof(double)); + return __copy_to_user(to, buf, ELF_NFPREG * sizeof(double)); +} + +unsigned long copy_fpr_from_user(struct task_struct *task, +void __user *from) +{ + double buf[ELF_NFPREG]; + int i; + + if (__copy_from_user(buf, from, ELF_NFPREG * sizeof(double))) + return 1; + for (i = 0; i < (ELF_NFPREG - 1) ; i++) + task->thread.TS_FPR(i) = buf[i]; + memcpy(&task->thread.fpscr, &buf[i], sizeof(double)); + + return 0; +} + +unsigned long copy_vsx_to_user(void __user *to, + struct task_struct *task) +{ + double buf[ELF_NVSRHALFREG]; + int i; + + /* save FPR copy to local buffer then write to the thread_struct */ + for (i = 0; i < ELF_NVSRHALFREG; i++) + buf[i] = task->thread.fpr[i][TS_VSRLOWOFFSET]; + return __copy_to_user(to, buf, ELF_NVSRHALFREG * sizeof(double)); +} + +unsigned long copy_vsx_from_user(struct task_struct *task, +void __user *from) +{ + double buf[ELF_NVSRHALFREG]; + int i; + + if (__copy_from_user(buf, from, ELF_NVSRHALFREG * sizeof(double))) + return 1; + for (i = 0; i < ELF_NVSRHALFREG ; i++) + task->thread.fpr[i][TS_VSRLOWOFFSET] = buf[i]; + return 0; +} +#else +inline unsigned long copy_fpr_to_user(void __user *to, + struct task_struct *task) +{ + return __copy_to_user(to, task->thread.fpr, + ELF_NFPREG * sizeof(double)); +} + +inline unsigned long copy_fpr_from_user(struct task_struct *task, + void __user *from) +{ + return __copy_from_user(task->thread.fpr, from, + ELF_NFPREG * sizeof(double)); +} +#endif + /* * Save the current user registers on the user stack. * We only save the altivec/spe registers if the process has used @@ -337,10 +406,6 @@ static int save_user_regs(struct pt_regs int sigret) { unsigned long msr = regs->msr; -#ifdef CONFIG_VSX - double buf[32]; - int i; -#endif /* Make sure floating point registers are stored in regs */ flush_fp_to_thread(current); @@ -370,14 +435,9 @@ static int save_user_regs(struct pt_regs if (__put_user(current->thread.vrsave, (u32 __user *)&frame->mc_vregs[32])) return 1; #endif /* CONFIG_ALTIVEC */ -#ifdef CONFIG_VSX - /* save FPR copy to local buffer then write to the thread_struct */ - flush_fp_to_thread(current); - for (i = 0; i < 32 ; i++) - buf[i] = current->thread.TS_FPR(i); - memcpy(&buf[i], ¤t->thread.fpscr, sizeof(double)); - if
[PATCH] powerpc: cleanup copy_to/from_user for vsx and fpr
This merges and cleans up some of the ugly copy/to from user code which is required for the new fpr and vsx layout in the thread_struct. Also fixes some hard coded buffer sizes and removes a redundant fpr_flush_to_thread. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- arch/powerpc/kernel/signal.h| 10 +++ arch/powerpc/kernel/signal_32.c | 40 ++ arch/powerpc/kernel/signal_64.c | 112 3 files changed, 96 insertions(+), 66 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal.h === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal.h +++ linux-2.6-ozlabs/arch/powerpc/kernel/signal.h @@ -24,6 +24,16 @@ extern int handle_rt_signal32(unsigned l siginfo_t *info, sigset_t *oldset, struct pt_regs *regs); +extern unsigned long copy_fpr_to_user(void __user *to, + struct task_struct *task); +extern unsigned long copy_fpr_from_user(struct task_struct *task, + void __user *from); +#ifdef CONFIG_VSX +extern unsigned long copy_vsx_to_user(void __user *to, + struct task_struct *task); +extern unsigned long copy_vsx_from_user(struct task_struct *task, + void __user *from); +#endif #ifdef CONFIG_PPC64 Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c @@ -337,10 +337,6 @@ static int save_user_regs(struct pt_regs int sigret) { unsigned long msr = regs->msr; -#ifdef CONFIG_VSX - double buf[32]; - int i; -#endif /* Make sure floating point registers are stored in regs */ flush_fp_to_thread(current); @@ -370,14 +366,9 @@ static int save_user_regs(struct pt_regs if (__put_user(current->thread.vrsave, (u32 __user *)&frame->mc_vregs[32])) return 1; #endif /* CONFIG_ALTIVEC */ -#ifdef CONFIG_VSX - /* save FPR copy to local buffer then write to the thread_struct */ - flush_fp_to_thread(current); - for (i = 0; i < 32 ; i++) - buf[i] = current->thread.TS_FPR(i); - memcpy(&buf[i], ¤t->thread.fpscr, sizeof(double)); - if (__copy_to_user(&frame->mc_fregs, buf, ELF_NFPREG * sizeof(double))) + if (copy_fpr_to_user(&frame->mc_fregs, current)) return 1; +#ifdef CONFIG_VSX /* * Copy VSR 0-31 upper half from thread_struct to local * buffer, then write that to userspace. Also set MSR_VSX in @@ -386,18 +377,10 @@ static int save_user_regs(struct pt_regs */ if (current->thread.used_vsr) { flush_vsx_to_thread(current); - for (i = 0; i < 32 ; i++) - buf[i] = current->thread.fpr[i][TS_VSRLOWOFFSET]; - if (__copy_to_user(&frame->mc_vsregs, buf, - ELF_NVSRHALFREG * sizeof(double))) + if (copy_vsx_to_user(&frame->mc_vsregs, current)) return 1; msr |= MSR_VSX; } -#else - /* save floating-point registers */ - if (__copy_to_user(&frame->mc_fregs, current->thread.fpr, - ELF_NFPREG * sizeof(double))) - return 1; #endif /* CONFIG_VSX */ #ifdef CONFIG_SPE /* save spe registers */ @@ -442,7 +425,6 @@ static long restore_user_regs(struct pt_ unsigned int save_r2 = 0; unsigned long msr; #ifdef CONFIG_VSX - double buf[32]; int i; #endif @@ -490,13 +472,10 @@ static long restore_user_regs(struct pt_ if (__get_user(current->thread.vrsave, (u32 __user *)&sr->mc_vregs[32])) return 1; #endif /* CONFIG_ALTIVEC */ + if (copy_fpr_from_user(current, &sr->mc_fregs)) + return 1; #ifdef CONFIG_VSX - if (__copy_from_user(buf, &sr->mc_fregs,sizeof(sr->mc_fregs))) - return 1; - for (i = 0; i < 32 ; i++) - current->thread.TS_FPR(i) = buf[i]; - memcpy(¤t->thread.fpscr, &buf[i], sizeof(double)); /* * Force the process to reload the VSX registers from * current->thread when it next does VSX instruction. @@ -507,18 +486,11 @@ static long restore_user_regs(struct pt_ * Restore altivec registers from the stack to a local * buffer, then write this out to the thread_struct */ - if (__copy_from_user(buf, &sr->mc_vsregs, -sizeof(sr->mc_vsregs))) + if (copy_vsx_from_user(current, &sr->mc_vsregs)) return 1; - for (i = 0; i < 32 ; i++) -
Re: [PATCH] powerpc: Xilinx: add dts file for ML507 board
On Tue, 1 Jul 2008 16:02:54 -0700 John Linn <[EMAIL PROTECTED]> wrote: > This new file adds support for the ML507 board which > has a Virtex 5 FXT FPGA with a 440. I haven't looked this over thoroughly yet, but an immediate question comes to mind. Any way this can get converted to dts-v1 before it's pulled in? All of the in-tree DTS files should be dts-v1 now, so I'd like to have new ones go in as that. (Also CC'ing the proper list) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Tue, 2008-07-01 at 08:58 -0700, Stephen Neuendorffer wrote: > Doing this at the binary level would be nice, but I see enough problems > just doing it at the source level and at least for my purposes, doing it > on a dtb would be overkill, I think. > > The main difficulty remains how to deal with cross references between > nodes in a reasonable way where the references cross from one fragment > to another. I would have those done in the toplevel .dts You can always override the property with the reference Ie. you #include your CPU or your SOC for example, and then override some property to point to something else using the override mechanism I mentioned. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely <[EMAIL PROTECTED]> ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC v1 API, so I don't expect it to get merged as-is, but I want to get it out there for review. --- sound/soc/codecs/Kconfig |4 sound/soc/codecs/Makefile |2 sound/soc/codecs/tlv320aic26.c | 630 3 files changed, 636 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 3903ab7..96c7bfe 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -41,6 +41,10 @@ config SND_SOC_CS4270_VD33_ERRATA bool depends on SND_SOC_CS4270 +config SND_SOC_TLV320AIC26 + tristate "TI TLB320AIC26 Codec support" + depends on SND_SOC && SPI + config SND_SOC_TLV320AIC3X tristate depends on SND_SOC && I2C diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index 4e1314c..ec0cd93 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -5,6 +5,7 @@ snd-soc-wm8753-objs := wm8753.o snd-soc-wm9712-objs := wm9712.o snd-soc-wm9713-objs := wm9713.o snd-soc-cs4270-objs := cs4270.o +snd-soc-tlv320aic26-objs := tlv320aic26.o snd-soc-tlv320aic3x-objs := tlv320aic3x.o obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o @@ -14,4 +15,5 @@ obj-$(CONFIG_SND_SOC_WM8753) += snd-soc-wm8753.o obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o +obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c new file mode 100644 index 000..aee1dbc --- /dev/null +++ b/sound/soc/codecs/tlv320aic26.c @@ -0,0 +1,630 @@ +/* + * Texas Instruments TLV320AIC26 low power audio CODEC + * ALSA SoC CODEC driver + * + * Copyright (C) 2008 Secret Lab Technologies Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_DESCRIPTION("ASoC TLV320AIC26 codec driver"); +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>"); +MODULE_LICENSE("GPL"); + +/* AIC26 Registers */ +#define AIC26_READ_COMMAND_WORD(addr) ((1 << 15) | (addr << 5)) +#define AIC26_WRITE_COMMAND_WORD(addr) ((0 << 15) | (addr << 5)) +#define AIC26_PAGE_ADDR(page, offset) ((page << 6) | offset) +#define AIC26_NUM_REGS AIC26_PAGE_ADDR(3, 0) +#define AIC26_REG_CACHE_SIZE (0x20) /* only page 2 cached */ +#define AIC26_REG_IS_CACHED(addr) ((addr & ~0x1f) == (2 << 6)) +#define AIC26_REG_CACHE_ADDR(addr) (addr & 0x1f) + +/* Page 0: Auxillary data registers */ +#define AIC26_REG_BAT1 AIC26_PAGE_ADDR(0, 0x05) +#define AIC26_REG_BAT2 AIC26_PAGE_ADDR(0, 0x06) +#define AIC26_REG_AUX AIC26_PAGE_ADDR(0, 0x07) +#define AIC26_REG_TEMP1AIC26_PAGE_ADDR(0, 0x09) +#define AIC26_REG_TEMP2AIC26_PAGE_ADDR(0, 0x0A) + +/* Page 1: Auxillary control registers */ +#define AIC26_REG_AUX_ADC AIC26_PAGE_ADDR(1, 0x00) +#define AIC26_REG_STATUS AIC26_PAGE_ADDR(1, 0x01) +#define AIC26_REG_REFERENCEAIC26_PAGE_ADDR(1, 0x03) +#define AIC26_REG_RESETAIC26_PAGE_ADDR(1, 0x04) + +/* Page 2: Audio control registers */ +#define AIC26_REG_AUDIO_CTRL1 AIC26_PAGE_ADDR(2, 0x00) +#define AIC26_REG_ADC_GAIN AIC26_PAGE_ADDR(2, 0x01) +#define AIC26_REG_DAC_GAIN AIC26_PAGE_ADDR(2, 0x02) +#define AIC26_REG_SIDETONE AIC26_PAGE_ADDR(2, 0x03) +#define AIC26_REG_AUDIO_CTRL2 AIC26_PAGE_ADDR(2, 0x04) +#define AIC26_REG_POWER_CTRL AIC26_PAGE_ADDR(2, 0x05) +#define AIC26_REG_AUDIO_CTRL3 AIC26_PAGE_ADDR(2, 0x06) + +#define AIC26_REG_FILTER_COEFF_L_N0AIC26_PAGE_ADDR(2, 0x07) +#define AIC26_REG_FILTER_COEFF_L_N1AIC26_PAGE_ADDR(2, 0x08) +#define AIC26_REG_FILTER_COEFF_L_N2AIC26_PAGE_ADDR(2, 0x09) +#define AIC26_REG_FILTER_COEFF_L_N3AIC26_PAGE_ADDR(2, 0x0A) +#define AIC26_REG_FILTER_COEFF_L_N4AIC26_PAGE_ADDR(2, 0x0B) +#define AIC26_REG_FILTER_COEFF_L_N5AIC26_PAGE_ADDR(2, 0x0C) +#define AIC26_REG_FILTER_COEFF_L_D1AIC26_PAGE_ADDR(2, 0x0D) +#define AIC26_REG_FILTER_COEFF_L_D2AIC26_PAGE_ADDR(2, 0x0E) +#define AIC26_REG_FILTER_COEFF_L_D4AIC26_PAGE_ADDR(2, 0x0F) +#define AIC26_REG_FILTER_COEFF_L_D5AIC26_PAGE_ADDR(2, 0x10) +#define AIC26_REG_FILTER_COEFF_R_N0AIC26_PAGE_ADDR(2, 0x11) +#define AIC26_REG_FILTER_COEFF_R_N1AIC26_PAGE_ADDR(2, 0x12) +#define AIC26_REG_FILTER_COEFF_R_N2AIC26_PAGE_ADDR(2, 0x13) +#define AIC26_REG_FILTER_COEFF_R_N3AIC26_PAGE_ADDR(2, 0x14) +#define AIC26_REG_FILTER_COEFF_R_N4AIC26_PAGE_ADDR(2, 0x15) +#define AIC26_REG_FILTER_COEFF_R_N
[PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: Grant Likely <[EMAIL PROTECTED]> This is an I2S bus driver for the MPC5200 PSC device. It is probably will not be merged as-is because it uses v1 of the ASoC API, but I want to get it out there for comments. --- sound/soc/fsl/Kconfig |6 sound/soc/fsl/Makefile |2 sound/soc/fsl/mpc5200_psc_i2s.c | 899 +++ 3 files changed, 907 insertions(+), 0 deletions(-) diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 257101f..5daa8d3 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -17,4 +17,10 @@ config SND_SOC_MPC8610_HPCD help Say Y if you want to enable audio on the Freescale MPC8610 HPCD. +config SND_SOC_MPC5200_I2S + bool "Freescale MPC5200 PSC in I2S mode driver" + depends on SND_SOC && PPC_MPC52xx + help + Say Y here to support the MPC5200 PSCs in I2S mode. + endmenu diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile index 62f680a..98729a1 100644 --- a/sound/soc/fsl/Makefile +++ b/sound/soc/fsl/Makefile @@ -4,3 +4,5 @@ obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o # MPC8610 Platform Support obj-$(CONFIG_SND_SOC_MPC8610) += fsl_ssi.o fsl_dma.o +obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o + diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c new file mode 100644 index 000..81d0933 --- /dev/null +++ b/sound/soc/fsl/mpc5200_psc_i2s.c @@ -0,0 +1,899 @@ +/* + * Freescale MPC5200 PSC in I2S mode + * ALSA SoC Digital Audio Interface (DAI) driver + * + * Copyright (C) 2008 Secret Lab Technologies Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>"); +MODULE_DESCRIPTION("Freescale MPC5200 PSC in I2S mode ASoC Driver"); +MODULE_LICENSE("GPL"); + +/** + * PSC_I2S_RATES: sample rates supported by the I2S + * + * This driver currently only supports the PSC running in I2S slave mode, + * which means the codec determines the sample rate. Therefore, we tell + * ALSA that we support all rates and let the codec driver decide what rates + * are really supported. + */ +#define PSC_I2S_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \ + SNDRV_PCM_RATE_CONTINUOUS) + +/** + * PSC_I2S_FORMATS: audio formats supported by the PSC I2S mode + */ +#define PSC_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | \ +SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE | \ +SNDRV_PCM_FMTBIT_S32_BE) + +/** + * psc_i2s_stream - Data specific to a single stream (playback or capture) + * @active:flag indicating if the stream is active + * @psc_i2s: pointer back to parent psc_i2s data structure + * @bcom_task: bestcomm task structure + * @irq: irq number for bestcomm task + * @period_start: physical address of start of DMA region + * @period_end:physical address of end of DMA region + * @period_next_pt:physical address of next DMA buffer to enqueue + * @period_bytes: size of DMA period in bytes + */ +struct psc_i2s_stream { + int active; + struct psc_i2s *psc_i2s; + struct bcom_task *bcom_task; + int irq; + struct snd_pcm_substream *stream; + dma_addr_t period_start; + dma_addr_t period_end; + dma_addr_t period_next_pt; + dma_addr_t period_current_pt; + int period_bytes; +}; + +/** + * psc_i2s - Private driver data + * @name: short name for this device ("PSC0", "PSC1", etc) + * @psc_regs: pointer to the PSC's registers + * @fifo_regs: pointer to the PSC's FIFO registers + * @irq: IRQ of this PSC + * @dev: struct device pointer + * @playback: the number of playback streams opened + * @capture: the number of capture streams opened + * @dai: the CPU DAI for this device + * @playback_stream: Playback stream context data + * @capture_stream: Capture stream context data + */ +struct psc_i2s { + char name[32]; + struct mpc52xx_psc __iomem *psc_regs; + struct mpc52xx_psc_fifo __iomem *fifo_regs; + unsigned int irq; + struct device *dev; + struct snd_soc_cpu_dai dai; + spinlock_t lock; + + /* per-stream data */ + struct psc_i2s_stream playback_stream; + struct psc_i2s_stream capture_stream; + + /* Statistics */ + struct { + int overrun_count; + int underrun_count; + } stats; +}; + +/* + * Interrupt handlers + */ +static irqreturn_t psc_i2s_status_irq(int irq, void *_psc_i2s) +{ + struct psc_i2s *psc_i2s = _psc_i2s; + struct mpc52xx_psc __iomem *regs = psc_i2s->psc_regs; + u16 imr; + u16 isr; + + isr = in_be16(®s->mpc52xx_psc_isr); + imr = in_be16(®s->mpc52xx_psc_imr); + + /* Playba
[PATCH 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Grant Likely <[EMAIL PROTECTED]> Simple utility layer for creating ASoC machine instances based on data in the OpenFirmware device tree. OF aware platform drivers and codec drivers register themselves with this framework and the framework automatically instantiates a machine driver. This is most likely temporary glue code to work around limitations in the ASoC v1 framework. I expect ASoC v2 won't need this. --- sound/soc/Kconfig |6 ++ sound/soc/Makefile |1 sound/soc/soc-of.c | 171 3 files changed, 178 insertions(+), 0 deletions(-) diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 18f28ac..c5736e5 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -23,6 +23,12 @@ config SND_SOC This ASoC audio support can also be built as a module. If so, the module will be called snd-soc-core. +config SND_SOC_OF + tristate "OF helpers for SoC audio support" + depends on SND_SOC + ---help--- + Add support for OpenFirmware device tree descriptions of sound device + # All the supported Soc's source "sound/soc/at91/Kconfig" source "sound/soc/pxa/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index 782db21..191c2e5 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -2,3 +2,4 @@ snd-soc-core-objs := soc-core.o soc-dapm.o obj-$(CONFIG_SND_SOC) += snd-soc-core.o obj-$(CONFIG_SND_SOC) += codecs/ at91/ pxa/ s3c24xx/ sh/ fsl/ davinci/ omap/ +obj-$(CONFIG_SND_SOC_OF) += soc-of.o diff --git a/sound/soc/soc-of.c b/sound/soc/soc-of.c new file mode 100644 index 000..9694979 --- /dev/null +++ b/sound/soc/soc-of.c @@ -0,0 +1,171 @@ +/* + * OF helpers for ALSA SoC Layer + * + * Copyright (C) 2008, Secret Lab Technologies Ltd. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("ALSA SoC OpenFirmware bindings"); + +DEFINE_MUTEX(of_snd_soc_mutex); +LIST_HEAD(of_snd_soc_device_list); +static int of_snd_soc_next_index; + +struct of_snd_soc_device { + int id; + struct list_head list; + struct snd_soc_device device; + struct snd_soc_machine machine; + struct snd_soc_dai_link dai_link; + struct platform_device *pdev; + struct device_node *platform_node; + struct device_node *codec_node; +}; + +static struct snd_soc_ops of_snd_soc_ops = { +}; + +static struct of_snd_soc_device * +of_snd_soc_get_device(struct device_node *codec_node) +{ + struct of_snd_soc_device *of_soc; + + list_for_each_entry(of_soc, &of_snd_soc_device_list, list) { + if (of_soc->codec_node == codec_node) + return of_soc; + } + + of_soc = kzalloc(sizeof(struct of_snd_soc_device), GFP_KERNEL); + if (!of_soc) + return NULL; + + /* Initialize the structure and add it to the global list */ + of_soc->codec_node = codec_node; + of_soc->id = of_snd_soc_next_index++; + of_soc->machine.dai_link = &of_soc->dai_link; + of_soc->machine.num_links = 1; + of_soc->device.machine = &of_soc->machine; + of_soc->dai_link.ops = &of_snd_soc_ops; + list_add(&of_soc->list, &of_snd_soc_device_list); + + return of_soc; +} + +static void of_snd_soc_register_device(struct of_snd_soc_device *of_soc) +{ + struct platform_device *pdev; + int rc; + + /* Only register the device if both the codec and platform have +* been registered */ + if ((!of_soc->device.codec_data) || (!of_soc->platform_node)) + return; + + pr_info("platform<-->codec match achieved; registering machine\n"); + + pdev = platform_device_alloc("soc-audio", of_soc->id); + if (!pdev) { + pr_err("of_soc: platform_device_alloc() failed\n"); + return; + } + + pdev->dev.platform_data = of_soc; + platform_set_drvdata(pdev, &of_soc->device); + of_soc->device.dev = &pdev->dev; + + /* The ASoC device is complete; register it */ + rc = platform_device_add(pdev); + if (rc) { + pr_err("of_soc: platform_device_add() failed\n"); + return; + } + +} + +int of_snd_soc_register_codec(struct snd_soc_codec_device *codec_dev, + void *codec_data, struct snd_soc_codec_dai *dai, + struct device_node *node) +{ + struct of_snd_soc_device *of_soc; + int rc = 0; + + pr_info("registering ASoC codec driver: %s\n", node->full_name); + + mutex_lock(&of_snd_soc_mutex); + of_soc = of_snd_soc_get_device(node); + if (!of_soc) { + rc = -ENOMEM; + goto out; + } + + /* Store the codec data */ + of_soc->device.codec_data
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On Tue, 2008-07-01 at 11:13 -0700, Grant Erickson wrote: > In terms of the device tree expression, you would both favor something akin > to the following? > > - compatible = "ibm,emac-405exr", "ibm,emac4"; > + compatible = "ibm,emac-405exr", "ibm,emac4", "ibm,emac4sync"; leave ibm,emac4 either at the end or totally out Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: [MPC5200] (v2) Add ATA DMA support
On Fri, Jun 27, 2008 at 01:44:08PM +0100, Tim Yamin wrote: > diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c > linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c > --- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.c 2008-03-18 > 15:49:53.0 + > +++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.c > 2008-04-15 10:42:38.0 +0100 > @@ -330,11 +330,10 @@ > /* Init 'always' initiator */ > out_8(&bcom_eng->regs->ipr[BCOM_INITIATOR_ALWAYS], BCOM_IPR_ALWAYS); > > - /* Disable COMM Bus Prefetch on the original 5200; it's broken */ > - if ((mfspr(SPRN_SVR) & MPC5200_SVR_MASK) == MPC5200_SVR) { > - regval = in_be16(&bcom_eng->regs->PtdCntrl); > - out_be16(&bcom_eng->regs->PtdCntrl, regval | 1); > - } > + /* Disable COMM Bus Prefetch; ATA DMA does not work properly with it > +enabled. */ > + regval = in_be16(&bcom_eng->regs->PtdCntrl); > + out_be16(&bcom_eng->regs->PtdCntrl, regval | 1); This could have a performance impact on existing systems that don't use/need ATA DMA. Please run next version through checkpatch. There's lots of minor cosmetic stuff, but there are also a few important errors. > diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h > linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h > --- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm.h 2008-03-18 > 15:49:53.0 + > +++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm.h > 2008-04-15 10:42:38.0 +0100 > @@ -17,6 +17,7 @@ > #define __BESTCOMM_H__ > > struct bcom_bd; /* defined later on ... */ > +struct bcom_bd_2; > > > /* > */ > @@ -49,6 +50,22 @@ > void* priv; > }; > > +struct bcom_task_2 { > + unsigned inttasknum; > + unsigned intflags; > + int irq; > + > + struct bcom_bd_2*bd; > + phys_addr_t bd_pa; > + void**cookie; > + unsigned short index; > + unsigned short outdex; > + unsigned intnum_bd; > + unsigned intbd_size; > + > + void* priv; > +}; > + Oh, ugly. The only difference seems to be that bcom_bd_2 is 1 word larger than bcom_bd. There must be a better way to do this rather than just duplicating all the functions and structures.. It would probably be better to use bd_size to determine how to dereference an index into the *bd list. It will require a bit of refactoring, but it will be much cleaner and more maintainable that way. > diff -Nurp linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h > linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h > --- linux-2.6.26-rc6/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h > 2008-03-18 15:49:53.0 + > +++ linux-2.6.26-rc6.new/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h > 2008-04-15 10:42:38.0 +0100 > @@ -198,8 +198,8 @@ struct bcom_task_header { > #define BCOM_IPR_SCTMR_1 2 > #define BCOM_IPR_FEC_RX 6 > #define BCOM_IPR_FEC_TX 5 > -#define BCOM_IPR_ATA_RX 4 > -#define BCOM_IPR_ATA_TX 3 > +#define BCOM_IPR_ATA_RX 7 > +#define BCOM_IPR_ATA_TX 7 > #define BCOM_IPR_SCPCI_RX2 > #define BCOM_IPR_SCPCI_TX2 > #define BCOM_IPR_PSC3_RX 2 Is this a bug fix? If so, please put it into a separate patch. > diff -Nurp linux-2.6.26-rc6/drivers/ata/Kconfig > linux-2.6.26-rc6.new/drivers/ata/Kconfig > --- linux-2.6.26-rc6/drivers/ata/Kconfig 2008-03-18 15:49:33.0 > + > +++ linux-2.6.26-rc6.new/drivers/ata/Kconfig 2008-04-15 10:41:51.0 > +0100 > @@ -462,6 +462,15 @@ > > If unsure, say N. > > +config PATA_MPC52xx_DMA > + tristate "Freescale MPC52xx SoC internal IDE DMA" > + depends on PATA_MPC52xx > + help > + This option enables support for DMA on the MPC52xx SoC PATA > + controller. > + > + If unsure, say N. > + Good, it can be turned off. Do you think there is any risk to existing ATA users with this patch applied if this is turned off? > config PATA_MPIIX > tristate "Intel PATA MPIIX support" > depends on PCI > diff -Nurp linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c > linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c > --- linux-2.6.26-rc6/drivers/ata/pata_mpc52xx.c 2008-03-18 > 15:49:33.0 + > +++ linux-2.6.26-rc6.new/drivers/ata/pata_mpc52xx.c 2008-04-15 > 10:41:49.0 +0100 > @@ -6,6 +6,9 @@ > * Copyright (C) 2006 Sylvain Munaut <[EMAIL PROTECTED]> > * Copyright (C) 2003 Mipsys - Benjamin Herrenschmidt > * > + * UDMA support based on patches by Freescale (Bernard Kuhn, John Rigby), > + * Domen Puncer and Tim Yamin. > + * > * This file is licensed under the terms of the GNU General Public License > * version 2. This program
Please pull into 2.6.26
Hi Josh & Paul, Here are a couple of last minute bug fixes for 2.6.26. These are both Xilinx 4xx related. Could either of you please pull the tree? Thanks, g. The following changes since commit 1702b52092e9a6d05398d3f9581ddc050ef00d06: Linus Torvalds (1): Merge git://git.kernel.org/.../mchehab/v4l-dvb are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-virtex.git virtex-for-2.6.26 John Linn (2): powerpc/bootwrapper: update for initrd with simpleImage powerpc/legacy_serial: Bail if reg-offset/shift properties are present arch/powerpc/boot/Makefile |3 ++- arch/powerpc/kernel/legacy_serial.c |5 + 2 files changed, 7 insertions(+), 1 deletions(-) -- 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
[PATCH] powerpc/mpc5200: Fix lite5200b suspend/resume
From: Tim Yamin <[EMAIL PROTECTED]> Suspend/resume ("echo mem > /sys/power/state") does not work with vanilla kernels -- the system does not suspend correctly and just hangs. This patch fixes this so suspend/resume works: 1) of_iomap does not map the whole 0xC000 of the MPC5200 immr so saving registers does not work. 2) PCI registers need to be saved and restored. Signed-off-by: Tim Yamin <[EMAIL PROTECTED]> Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- Tim, please test this version. I fixed a couple of bugs and want to make sure I haven't broken anything. Once you ack it I'll ask Paul to pull it into 2.6.26. g. arch/powerpc/platforms/52xx/lite5200_pm.c | 14 +- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/52xx/lite5200_pm.c b/arch/powerpc/platforms/52xx/lite5200_pm.c index 41c7fd9..fe92e65 100644 --- a/arch/powerpc/platforms/52xx/lite5200_pm.c +++ b/arch/powerpc/platforms/52xx/lite5200_pm.c @@ -14,6 +14,7 @@ static struct mpc52xx_sdma __iomem *bes; static struct mpc52xx_xlb __iomem *xlb; static struct mpc52xx_gpio __iomem *gps; static struct mpc52xx_gpio_wkup __iomem *gpw; +static void __iomem *pci; static void __iomem *sram; static const int sram_size = 0x4000; /* 16 kBytes */ static void __iomem *mbar; @@ -50,6 +51,8 @@ static int lite5200_pm_prepare(void) { .type = "builtin", .compatible = "mpc5200", }, /* efika */ {} }; + u64 regaddr64 = 0; + const u32 *regaddr_p; /* deep sleep? let mpc52xx code handle that */ if (lite5200_pm_target_state == PM_SUSPEND_STANDBY) @@ -60,8 +63,12 @@ static int lite5200_pm_prepare(void) /* map registers */ np = of_find_matching_node(NULL, immr_ids); - mbar = of_iomap(np, 0); + regaddr_p = of_get_address(np, 0, NULL, NULL); + if (regaddr_p) + regaddr64 = of_translate_address(np, regaddr_p); of_node_put(np); + + mbar = ioremap((u32) regaddr64, 0xC000); if (!mbar) { printk(KERN_ERR "%s:%i Error mapping registers\n", __func__, __LINE__); return -ENOSYS; @@ -71,6 +78,7 @@ static int lite5200_pm_prepare(void) pic = mbar + 0x500; gps = mbar + 0xb00; gpw = mbar + 0xc00; + pci = mbar + 0xd00; bes = mbar + 0x1200; xlb = mbar + 0x1f00; sram = mbar + 0x8000; @@ -85,6 +93,7 @@ static struct mpc52xx_sdma sbes; static struct mpc52xx_xlb sxlb; static struct mpc52xx_gpio sgps; static struct mpc52xx_gpio_wkup sgpw; +static char spci[0x200]; static void lite5200_save_regs(void) { @@ -94,6 +103,7 @@ static void lite5200_save_regs(void) _memcpy_fromio(&sxlb, xlb, sizeof(*xlb)); _memcpy_fromio(&sgps, gps, sizeof(*gps)); _memcpy_fromio(&sgpw, gpw, sizeof(*gpw)); + _memcpy_fromio(spci, pci, 0x200); _memcpy_fromio(saved_sram, sram, sram_size); } @@ -103,6 +113,8 @@ static void lite5200_restore_regs(void) int i; _memcpy_toio(sram, saved_sram, sram_size); + /* PCI Configuration */ + _memcpy_toio(pci, spci, 0x200); /* * GPIOs. Interrupt Master Enable has higher address then other ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 27/60] microblaze_v4: virtualization
On Thu, Jun 26, 2008 at 02:29:56PM +0200, [EMAIL PROTECTED] wrote: > From: Michal Simek <[EMAIL PROTECTED]> > > > Signed-off-by: Michal Simek <[EMAIL PROTECTED]> > --- > include/asm-microblaze/kvm.h |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > create mode 100644 include/asm-microblaze/kvm.h > > diff --git a/include/asm-microblaze/kvm.h b/include/asm-microblaze/kvm.h > new file mode 100644 > index 000..01c5e79 > --- /dev/null > +++ b/include/asm-microblaze/kvm.h > @@ -0,0 +1 @@ > +/* Microblaze does not support KVM */ There's a patch pending for 2.6.27 that will remove the requirement for this empty header. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On Tuesday 01 July 2008, Grant Erickson wrote: > > Yes, this was my feeling too. Not the size of the dtb but more the > > increased complexity of the EMAC device node. I would prefer Ben's idea > > with this new compatible entry too. > > In terms of the device tree expression, you would both favor something akin > to the following? > > - compatible = "ibm,emac-405exr", "ibm,emac4"; > + compatible = "ibm,emac-405exr", "ibm,emac4", > "ibm,emac4sync"; If this is how IBM/AMCC call this "new" EMAC version, then yes. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 13:27:57 -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote: > > > On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > > > My preference is for things like of_spi and of_i2c to go with the > > > > related busses; I think it makes more sense to keep all the I2C stuff > > > > together, but I've already lost that battle once. > > > > > > This is a similar problem to adding aliases to the i2c driver drivers > > > for the device tree names of the i2c devices. Instead we have code in > > > drivers/of/of_i2c.c that tries to guess the translation from device > > > tree to linux names. Adding aliases to the drivers would eliminate the > > > need for of_find_i2c_driver(). > > > > > > I've previously posted patches implementing device tree names in the > > > drivers that used ifdef to only instantiate on powerpc builds. For > > > example > > > > > > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c > > > index e07274d..9cd1770 100644 > > > --- a/drivers/i2c/chips/tps65010.c > > > +++ b/drivers/i2c/chips/tps65010.c > > > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = { > > > { "tps65011", TPS65011 }, > > > { "tps65012", TPS65012 }, > > > { "tps65013", TPS65013 }, > > > + OF_ID("ti,tps65010", TPS65010) > > > + OF_ID("ti,tps65011", TPS65011) > > > + OF_ID("ti,tps65012", TPS65012) > > > + OF_ID("ti,tps65013", TPS65013) > > > { }, > > > }; > > > MODULE_DEVICE_TABLE(i2c, tps65010_id); > > > > > > Yeah, yeah, you've been asking for this for months already, but it's > > just not going to happen, sorry. You want to abuse the standard Linux > > alias mechanism for your personal (i.e. openfirmware) use, but that's > > bad. Linux drivers shouldn't have to know whether they are used in > > openfirmware trees and what device names are used there. And device > > names as seen by user-space shouldn't vary depending on whether the > > device comes from an openfirmware tree or not - otherwise all > > user-space apps need to learn about both naming conversions. > > > > Unsurprisingly, no other subsystem does what you propose. > > Then what are all of the PCI aliases doing? > > The only difference is that you are recognizing the PCI group as a > naming authority and not recognizing the PowerPC device tree group. > But on the PowerPC platform that is our naming authority. That's why I > proposed adding the names on ifdefs so that they disappear on non > PowerPC platforms. You're comparing PCI devices those ID is built-in, with I2C devices with no ID. This just can't compare. > PS - adding an alias to a driver does not change the name of the > driver. My PCI e1000 module has about 100 aliases but it is always > e1000. I said device names, not driver names. Linux I2C devices have a name attribute which contains the (Linux) device name. That's something a number of user-space applications are relying on. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 13:06:37 -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote: > > > But the other side of the coin is that each driver must have > > > driver-specific OF code to translate data in the device tree to data > > > usable by the driver. It doesn't make any sense to me for that stuff to > > > live anywhere other that with the driver that it supports. > > > > > > This code is glue between OF and subsystems. As with any glue code, you > > can argue forever on which side you want to push the code to. Both > > answers are valid. > > > > All I see on my personal side is that I don't have any system using OF > > and no knowledge about it either, so I can't maintain of_i2c. So having > > that file in drivers/of rather than drivers/i2c will make my life > > easier for sure. While I'd guess that most (all?) OF-based systems have > > an I2C bus, so whoever is responsible for drivers/of should be able to > > maintain of_i2c. > > We could modify the Makefile for i2c core to get the source out of > drivers/of and link it into i2c-core. That would remove the need to > export symbols. That might be a bit confusing, but could be done. I still don't know what problem you are trying to solve though. As I repeated, exporting i2c_bus_type is perfectly fine. All other bus types are always exported. So if it's all you need from i2c-core, there's no problem and we can stop the discussion here. > Or you could move the file into the i2c directory and just put a note > on it that Grant is the maintainer. Assuming that developers will read the source code to find out who the maintainer is, when we have told everyone to search for this information in MAINTAINERS. I'd rather add an entry in MAINTAINERS, but even then I have a doubt that people will get it. My experience is that people map maintainer names to directories and that's about it. That's one of the reasons why I wanted to move the i2c device drivers from drivers/i2c/chips to drivers/hwmon, drivers/rtc, drivers/gpio, etc. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add the of_find_i2c_device_by_node function, standalone V1
Add the of_find_i2c_device_by_node function. This allows you to follow a reference in the device tree to an i2c device node and then locate the linux device instantiated by the device tree. Example use, an i2s codec controlled by i2c. Depends on patch exporting i2c root bus symbol. Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> --- drivers/of/of_i2c.c| 37 ++--- include/linux/of_i2c.h |2 ++ 2 files changed, 28 insertions(+), 11 deletions(-) diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c index 715a444..ca69a16 100644 --- a/drivers/of/of_i2c.c +++ b/drivers/of/of_i2c.c @@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node, void of_register_i2c_devices(struct i2c_adapter *adap, struct device_node *adap_node) { - void *result; + struct i2c_client *i2c_dev; struct device_node *node; for_each_child_of_node(adap_node, node) { @@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap, continue; } - info.irq = irq_of_parse_and_map(node, 0); - if (info.irq == NO_IRQ) - info.irq = -1; - - if (of_find_i2c_driver(node, &info) < 0) { - irq_dispose_mapping(info.irq); + if (of_find_i2c_driver(node, &info) < 0) continue; - } + info.irq = irq_of_parse_and_map(node, 0); info.addr = *addr; - request_module(info.type); + request_module("%s", info.type); - result = i2c_new_device(adap, &info); - if (result == NULL) { + i2c_dev = i2c_new_device(adap, &info); + if (i2c_dev == NULL) { printk(KERN_ERR "of-i2c: Failed to load driver for %s\n", info.type); irq_dispose_mapping(info.irq); continue; } + + i2c_dev->dev.archdata.of_node = of_node_get(node); } } EXPORT_SYMBOL(of_register_i2c_devices); +static int of_dev_node_match(struct device *dev, void *data) +{ +return dev->archdata.of_node == data; +} + +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node) +{ + struct device *dev; + + dev = bus_find_device(&i2c_bus_type, NULL, node, +of_dev_node_match); + if (!dev) + return NULL; + + return to_i2c_client(dev); +} +EXPORT_SYMBOL(of_find_i2c_device_by_node); + MODULE_LICENSE("GPL"); diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h index bd2a870..17d5897 100644 --- a/include/linux/of_i2c.h +++ b/include/linux/of_i2c.h @@ -16,5 +16,7 @@ void of_register_i2c_devices(struct i2c_adapter *adap, struct device_node *adap_node); +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node); + #endif /* __LINUX_OF_I2C_H */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jon Smirl <[EMAIL PROTECTED]> wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote: > > > On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > > > My preference is for things like of_spi and of_i2c to go with the > > > > related busses; I think it makes more sense to keep all the I2C stuff > > > > together, but I've already lost that battle once. > > > > > > This is a similar problem to adding aliases to the i2c driver drivers > > > for the device tree names of the i2c devices. Instead we have code in > > > drivers/of/of_i2c.c that tries to guess the translation from device > > > tree to linux names. Adding aliases to the drivers would eliminate the > > > need for of_find_i2c_driver(). > > > > > > I've previously posted patches implementing device tree names in the > > > drivers that used ifdef to only instantiate on powerpc builds. For > > > example > > > > > > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c > > > index e07274d..9cd1770 100644 > > > --- a/drivers/i2c/chips/tps65010.c > > > +++ b/drivers/i2c/chips/tps65010.c > > > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = { > > > { "tps65011", TPS65011 }, > > > { "tps65012", TPS65012 }, > > > { "tps65013", TPS65013 }, > > > + OF_ID("ti,tps65010", TPS65010) > > > + OF_ID("ti,tps65011", TPS65011) > > > + OF_ID("ti,tps65012", TPS65012) > > > + OF_ID("ti,tps65013", TPS65013) > > > { }, > > > }; > > > MODULE_DEVICE_TABLE(i2c, tps65010_id); > > > > > > Yeah, yeah, you've been asking for this for months already, but it's > > just not going to happen, sorry. You want to abuse the standard Linux > > alias mechanism for your personal (i.e. openfirmware) use, but that's > > bad. Linux drivers shouldn't have to know whether they are used in > > openfirmware trees and what device names are used there. And device > > names as seen by user-space shouldn't vary depending on whether the > > device comes from an openfirmware tree or not - otherwise all > > user-space apps need to learn about both naming conversions. > > > > Unsurprisingly, no other subsystem does what you propose. > > > Then what are all of the PCI aliases doing? > > The only difference is that you are recognizing the PCI group as a > naming authority and not recognizing the PowerPC device tree group. > But on the PowerPC platform that is our naming authority. That's why I > proposed adding the names on ifdefs so that they disappear on non > PowerPC platforms. > > PS - adding an alias to a driver does not change the name of the > driver. My PCI e1000 module has about 100 aliases but it is always > e1000. Here's my e1000e sysfs entry: [EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ ls broken_parity_status device local_cpus power resource2 uevent bus driver modaliasresource subsystem vendor class enable msi_bus resource0 subsystem_device configirq net:eth0resource1 subsystem_vendor [EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ cat modalias pci:v8086d104Bsv1028sd01DBbc02sc00i00 This is the module alias that was used to load the driver. [EMAIL PROTECTED]:/sys/bus/pci/devices/:00:19.0$ ls -l driver lrwxrwxrwx 1 root root 0 2008-07-01 08:52 driver -> ../../../bus/pci/drivers/e1000e The driver is always e1000e no matter which alias was used to load it. "e1000e" is controled by the name field of the driver structure. That's the publicly visible name for the driver. Adding the OF aliases would change the modalias entry, not the driver name. The i2c implementation is adding a field to a device entry that contains the driver name. No other device drivers I could find do this. [EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ ls bus driver eeprom modalias name power subsystem uevent [EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ cat name eeprom [EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ ls -l driver lrwxrwxrwx 1 root root 0 2008-07-01 14:05 driver -> ../../../../bus/i2c/drivers/eeprom [EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ cat modalias [EMAIL PROTECTED]:/sys/bus/i2c/devices/1-0050$ I believe the correct way to get the driver name from sysfs is to follow the driver link. The name field is probably legacy. Other drivers in the system don't have a name entry on the device node. Is the user space i2c code looking at the modalias entry? -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch] PS3: Quiet system bus match output
Reduce the output verbosity of ps3_system_bus_match(). Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- Paul, Please queue for 2.6.27. -Geoff arch/powerpc/platforms/ps3/system-bus.c | 21 + 1 file changed, 13 insertions(+), 8 deletions(-) --- a/arch/powerpc/platforms/ps3/system-bus.c +++ b/arch/powerpc/platforms/ps3/system-bus.c @@ -349,9 +349,14 @@ static int ps3_system_bus_match(struct d result = dev->match_id == drv->match_id; - pr_info("%s:%d: dev=%u(%s), drv=%u(%s): %s\n", __func__, __LINE__, - dev->match_id, dev->core.bus_id, drv->match_id, drv->core.name, - (result ? "match" : "miss")); + if (result) + pr_info("%s:%d: dev=%u(%s), drv=%u(%s): match\n", __func__, + __LINE__, dev->match_id, dev->core.bus_id, + drv->match_id, drv->core.name); + else + pr_debug("%s:%d: dev=%u(%s), drv=%u(%s): miss\n", __func__, + __LINE__, dev->match_id, dev->core.bus_id, + drv->match_id, drv->core.name); return result; } @@ -362,7 +367,7 @@ static int ps3_system_bus_probe(struct d struct ps3_system_bus_driver *drv; BUG_ON(!dev); - pr_info(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id); + pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id); drv = ps3_system_bus_dev_to_system_bus_drv(dev); BUG_ON(!drv); @@ -370,10 +375,10 @@ static int ps3_system_bus_probe(struct d if (drv->probe) result = drv->probe(dev); else - pr_info("%s:%d: %s no probe method\n", __func__, __LINE__, + pr_debug("%s:%d: %s no probe method\n", __func__, __LINE__, dev->core.bus_id); - pr_info(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id); + pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id); return result; } @@ -384,7 +389,7 @@ static int ps3_system_bus_remove(struct struct ps3_system_bus_driver *drv; BUG_ON(!dev); - pr_info(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id); + pr_debug(" -> %s:%d: %s\n", __func__, __LINE__, _dev->bus_id); drv = ps3_system_bus_dev_to_system_bus_drv(dev); BUG_ON(!drv); @@ -395,7 +400,7 @@ static int ps3_system_bus_remove(struct dev_dbg(&dev->core, "%s:%d %s: no remove method\n", __func__, __LINE__, drv->core.name); - pr_info(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id); + pr_debug(" <- %s:%d: %s\n", __func__, __LINE__, dev->core.bus_id); return result; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Parameterize EMAC Multicast Match Handling
On 6/30/08 11:37 PM, Stefan Roese wrote: > On Tuesday 01 July 2008, Benjamin Herrenschmidt wrote: >>> Stefan and/or Ben: >>> >>> Any thoughts on this? >> >> I was hesitating a bit... do we really need to be -that- flexible ? >> >> That is, either that or use some new compatible entry to detect the new >> reg layout and whack that as a feature bit instead ? The advantage >> of the later is that we have the possibility of doing conditional >> compile for kernels that support only a given processor or set of >> processors (not that we have implemented much of it, but it just >> becomes Kconfig mumbo jumbo and a little bit of defines in the .h >> by turning the feature test into a compile-time 0 or 1. >> >> But this isn't a hot path and not a lot of code so maybe not worth >> bothering... however, it does add 3 properties to the DT and I know >> embedded people (especially Xilinx) are a bit concerned about the size >> of the DT when they try to fit it in block RAM... > > Yes, this was my feeling too. Not the size of the dtb but more the increased > complexity of the EMAC device node. I would prefer Ben's idea with this new > compatible entry too. In terms of the device tree expression, you would both favor something akin to the following? - compatible = "ibm,emac-405exr", "ibm,emac4"; + compatible = "ibm,emac-405exr", "ibm,emac4", "ibm,emac4sync"; Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Grant Likely <[EMAIL PROTECTED]> It is inconvenient to add additional default targets to the bootwrapper Makefile for each new board supported which just needs a different dts file. This change allows the defconfig to specify additional build targets. Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig | 13 + arch/powerpc/boot/Makefile |3 +++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 3934e26..f09f617 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -458,6 +458,19 @@ config CMDLINE some command-line options at build time by entering them here. In most cases you will need to specify the root device here. +config EXTRA_TARGETS + string "Additional default image types" + help + List additional targets to be built by the bootwrapper here (separated + by spaces). This is useful for targets that depend of device tree + files in the .dts directory. + + Targets in this list will be build as part of the default build + target, or when the user does a 'make zImage' or a + 'make zImage.initrd'. + + If unsure, leave blank + if !44x || BROKEN config ARCH_WANTS_FREEZER_CONTROL def_bool y diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 1cee2f9..1e38237 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -270,6 +270,9 @@ ifeq ($(CONFIG_PPC32),y) image-$(CONFIG_PPC_PMAC) += zImage.coff zImage.miboot endif +# Allow extra targets to be added to the defconfig +image-y+= $(subst ",,$(CONFIG_EXTRA_TARGETS)) + initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-)) initrd-y := $(patsubst zImage%, zImage.initrd%, \ $(patsubst dtbImage%, dtbImage.initrd%, \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Make device table externally visible
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [V2] powerpc: legacy_serial: reg-offset & shift aren't used
The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn <[EMAIL PROTECTED]> Acked-by: Grant Likely <[EMAIL PROTECTED]> --- V2 Corrected logic to use "||" rather than "&&". arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..cf37f5c 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, "clock-frequency", NULL) == NULL) return -1; + /* if reg-shift or offset, don't try to use it */ + if ((of_get_property(np, "reg-shift", NULL) != NULL) || + (of_get_property(np, "reg-offset", NULL) != NULL)) + return -1; + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, "used-by-rtas", NULL) != NULL) return -1; -- 1.5.2.1 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: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote: > > On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > > > My preference is for things like of_spi and of_i2c to go with the > > > related busses; I think it makes more sense to keep all the I2C stuff > > > together, but I've already lost that battle once. > > > > This is a similar problem to adding aliases to the i2c driver drivers > > for the device tree names of the i2c devices. Instead we have code in > > drivers/of/of_i2c.c that tries to guess the translation from device > > tree to linux names. Adding aliases to the drivers would eliminate the > > need for of_find_i2c_driver(). > > > > I've previously posted patches implementing device tree names in the > > drivers that used ifdef to only instantiate on powerpc builds. For > > example > > > > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c > > index e07274d..9cd1770 100644 > > --- a/drivers/i2c/chips/tps65010.c > > +++ b/drivers/i2c/chips/tps65010.c > > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = { > > { "tps65011", TPS65011 }, > > { "tps65012", TPS65012 }, > > { "tps65013", TPS65013 }, > > + OF_ID("ti,tps65010", TPS65010) > > + OF_ID("ti,tps65011", TPS65011) > > + OF_ID("ti,tps65012", TPS65012) > > + OF_ID("ti,tps65013", TPS65013) > > { }, > > }; > > MODULE_DEVICE_TABLE(i2c, tps65010_id); > > > Yeah, yeah, you've been asking for this for months already, but it's > just not going to happen, sorry. You want to abuse the standard Linux > alias mechanism for your personal (i.e. openfirmware) use, but that's > bad. Linux drivers shouldn't have to know whether they are used in > openfirmware trees and what device names are used there. And device > names as seen by user-space shouldn't vary depending on whether the > device comes from an openfirmware tree or not - otherwise all > user-space apps need to learn about both naming conversions. > > Unsurprisingly, no other subsystem does what you propose. Then what are all of the PCI aliases doing? The only difference is that you are recognizing the PCI group as a naming authority and not recognizing the PowerPC device tree group. But on the PowerPC platform that is our naming authority. That's why I proposed adding the names on ifdefs so that they disappear on non PowerPC platforms. PS - adding an alias to a driver does not change the name of the driver. My PCI e1000 module has about 100 aliases but it is always e1000. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 13:00:08 -0400, Jon Smirl wrote: > On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote: > > My preference is for things like of_spi and of_i2c to go with the > > related busses; I think it makes more sense to keep all the I2C stuff > > together, but I've already lost that battle once. > > This is a similar problem to adding aliases to the i2c driver drivers > for the device tree names of the i2c devices. Instead we have code in > drivers/of/of_i2c.c that tries to guess the translation from device > tree to linux names. Adding aliases to the drivers would eliminate the > need for of_find_i2c_driver(). > > I've previously posted patches implementing device tree names in the > drivers that used ifdef to only instantiate on powerpc builds. For > example > > diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c > index e07274d..9cd1770 100644 > --- a/drivers/i2c/chips/tps65010.c > +++ b/drivers/i2c/chips/tps65010.c > @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = { > { "tps65011", TPS65011 }, > { "tps65012", TPS65012 }, > { "tps65013", TPS65013 }, > + OF_ID("ti,tps65010", TPS65010) > + OF_ID("ti,tps65011", TPS65011) > + OF_ID("ti,tps65012", TPS65012) > + OF_ID("ti,tps65013", TPS65013) > { }, > }; > MODULE_DEVICE_TABLE(i2c, tps65010_id); Yeah, yeah, you've been asking for this for months already, but it's just not going to happen, sorry. You want to abuse the standard Linux alias mechanism for your personal (i.e. openfirmware) use, but that's bad. Linux drivers shouldn't have to know whether they are used in openfirmware trees and what device names are used there. And device names as seen by user-space shouldn't vary depending on whether the device comes from an openfirmware tree or not - otherwise all user-space apps need to learn about both naming conversions. Unsurprisingly, no other subsystem does what you propose. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
I'll respin the patch and send again. -- John -Original Message- From: Grant Likely [mailto:[EMAIL PROTECTED] On Behalf Of Grant Likely Sent: Tuesday, July 01, 2008 11:06 AM To: John Linn Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote: > It could be "||" but I didn't know if there were cases where that > wouldn't be true. I don't know that code that well so I was being > conservative and maybe shouldn't be. No, Stephen is right. It should be || g. 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: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote: > > On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: > > > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > > > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > > > I'm fine with this patch. In particular, exporting i2c_bus_type is > OK. > > > > > It was un-exported only because it had no user left, but it can be > > > > > exported again if needed. > > > > > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > > > directory and make it part of i2c core on powerpc builds. > > > > > > I don't think this is a good idea. Merging arch-specific code (or > > > half-arch-specific code in this case) into arch-neutral drivers ends up > > > being a pain to maintain. People will keep sending me patches for stuff > > > I don't know anything about and can't help with. Having of-specific > > > stuff in just one directory as is the case now sounds much better to > > > me. All it's missing is a MAINTAINERS entry. > > > > But the other side of the coin is that each driver must have > > driver-specific OF code to translate data in the device tree to data > > usable by the driver. It doesn't make any sense to me for that stuff to > > live anywhere other that with the driver that it supports. > > > This code is glue between OF and subsystems. As with any glue code, you > can argue forever on which side you want to push the code to. Both > answers are valid. > > All I see on my personal side is that I don't have any system using OF > and no knowledge about it either, so I can't maintain of_i2c. So having > that file in drivers/of rather than drivers/i2c will make my life > easier for sure. While I'd guess that most (all?) OF-based systems have > an I2C bus, so whoever is responsible for drivers/of should be able to > maintain of_i2c. We could modify the Makefile for i2c core to get the source out of drivers/of and link it into i2c-core. That would remove the need to export symbols. Or you could move the file into the i2c directory and just put a note on it that Grant is the maintainer. > > -- > > Jean Delvare > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
On Tue, Jul 01, 2008 at 10:52:20AM -0600, John Linn wrote: > It could be "||" but I didn't know if there were cases where that > wouldn't be true. I don't know that code that well so I was being > conservative and maybe shouldn't be. No, Stephen is right. It should be || g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 10:45:18 -0600, Grant Likely wrote: > On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: > > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > > > It was un-exported only because it had no user left, but it can be > > > > exported again if needed. > > > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > > directory and make it part of i2c core on powerpc builds. > > > > I don't think this is a good idea. Merging arch-specific code (or > > half-arch-specific code in this case) into arch-neutral drivers ends up > > being a pain to maintain. People will keep sending me patches for stuff > > I don't know anything about and can't help with. Having of-specific > > stuff in just one directory as is the case now sounds much better to > > me. All it's missing is a MAINTAINERS entry. > > But the other side of the coin is that each driver must have > driver-specific OF code to translate data in the device tree to data > usable by the driver. It doesn't make any sense to me for that stuff to > live anywhere other that with the driver that it supports. This code is glue between OF and subsystems. As with any glue code, you can argue forever on which side you want to push the code to. Both answers are valid. All I see on my personal side is that I don't have any system using OF and no knowledge about it either, so I can't maintain of_i2c. So having that file in drivers/of rather than drivers/i2c will make my life easier for sure. While I'd guess that most (all?) OF-based systems have an I2C bus, so whoever is responsible for drivers/of should be able to maintain of_i2c. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Grant Likely <[EMAIL PROTECTED]> wrote: > On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote: > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > > It was un-exported only because it had no user left, but it can be > > > exported again if needed. > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > directory and make it part of i2c core on powerpc builds. > > > My preference is for things like of_spi and of_i2c to go with the > related busses; I think it makes more sense to keep all the I2C stuff > together, but I've already lost that battle once. > This is a similar problem to adding aliases to the i2c driver drivers for the device tree names of the i2c devices. Instead we have code in drivers/of/of_i2c.c that tries to guess the translation from device tree to linux names. Adding aliases to the drivers would eliminate the need for of_find_i2c_driver(). I've previously posted patches implementing device tree names in the drivers that used ifdef to only instantiate on powerpc builds. For example diff --git a/drivers/i2c/chips/tps65010.c b/drivers/i2c/chips/tps65010.c index e07274d..9cd1770 100644 --- a/drivers/i2c/chips/tps65010.c +++ b/drivers/i2c/chips/tps65010.c @@ -571,6 +571,10 @@ static const struct i2c_device_id tps65010_id[] = { { "tps65011", TPS65011 }, { "tps65012", TPS65012 }, { "tps65013", TPS65013 }, + OF_ID("ti,tps65010", TPS65010) + OF_ID("ti,tps65011", TPS65011) + OF_ID("ti,tps65012", TPS65012) + OF_ID("ti,tps65013", TPS65013) { }, }; MODULE_DEVICE_TABLE(i2c, tps65010_id); -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
It could be "||" but I didn't know if there were cases where that wouldn't be true. I don't know that code that well so I was being conservative and maybe shouldn't be. Our specific case works fine with "&&" since we have both in the device tree. -- John -Original Message- From: Stephen Neuendorffer Sent: Tuesday, July 01, 2008 10:48 AM To: John Linn; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used > -Original Message- > From: John Linn [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 01, 2008 9:32 AM > To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer > Cc: John Linn > Subject: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used > > The legacy serial driver does not work with an 8250 > type UART that uses reg-offset and reg-shift. This > change updates the driver so it doesn't find the UART > when those properties are present on the UART in the > device tree for soc devices. > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > Acked-by: Grant Likely <[EMAIL PROTECTED]> > --- > > arch/powerpc/kernel/legacy_serial.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c > index 61dd174..b43235f 100644 > --- a/arch/powerpc/kernel/legacy_serial.c > +++ b/arch/powerpc/kernel/legacy_serial.c > @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, > if (of_get_property(np, "clock-frequency", NULL) == NULL) > return -1; > > + /* if reg-shift and offset, don't try to use it */ > + if ((of_get_property(np, "reg-shift", NULL) != NULL) && > + (of_get_property(np, "reg-offset", NULL) != NULL)) > + return -1; Um, shouldn't this be || ? > + > /* if rtas uses this device, don't try to use it as well */ > if (of_get_property(np, "used-by-rtas", NULL) != NULL) > return -1; > -- > 1.5.2.1 > 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: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
> -Original Message- > From: John Linn [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 01, 2008 9:32 AM > To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer > Cc: John Linn > Subject: [PATCH] powerpc: legacy_serial: reg-offset & shift aren't used > > The legacy serial driver does not work with an 8250 > type UART that uses reg-offset and reg-shift. This > change updates the driver so it doesn't find the UART > when those properties are present on the UART in the > device tree for soc devices. > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > Acked-by: Grant Likely <[EMAIL PROTECTED]> > --- > > arch/powerpc/kernel/legacy_serial.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c > index 61dd174..b43235f 100644 > --- a/arch/powerpc/kernel/legacy_serial.c > +++ b/arch/powerpc/kernel/legacy_serial.c > @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, > if (of_get_property(np, "clock-frequency", NULL) == NULL) > return -1; > > + /* if reg-shift and offset, don't try to use it */ > + if ((of_get_property(np, "reg-shift", NULL) != NULL) && > + (of_get_property(np, "reg-offset", NULL) != NULL)) > + return -1; Um, shouldn't this be || ? > + > /* if rtas uses this device, don't try to use it as well */ > if (of_get_property(np, "used-by-rtas", NULL) != NULL) > return -1; > -- > 1.5.2.1 > 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: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, Jul 01, 2008 at 06:29:49PM +0200, Jean Delvare wrote: > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > > It was un-exported only because it had no user left, but it can be > > > exported again if needed. > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > directory and make it part of i2c core on powerpc builds. > > I don't think this is a good idea. Merging arch-specific code (or > half-arch-specific code in this case) into arch-neutral drivers ends up > being a pain to maintain. People will keep sending me patches for stuff > I don't know anything about and can't help with. Having of-specific > stuff in just one directory as is the case now sounds much better to > me. All it's missing is a MAINTAINERS entry. But the other side of the coin is that each driver must have driver-specific OF code to translate data in the device tree to data usable by the driver. It doesn't make any sense to me for that stuff to live anywhere other that with the driver that it supports. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 12:38:05 -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > > > It was un-exported only because it had no user left, but it can be > > > > exported again if needed. > > > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > > directory and make it part of i2c core on powerpc builds. > > > > I don't think this is a good idea. Merging arch-specific code (or > > half-arch-specific code in this case) into arch-neutral drivers ends up > > being a pain to maintain. People will keep sending me patches for stuff > > I don't know anything about and can't help with. Having of-specific > > stuff in just one directory as is the case now sounds much better to > > me. All it's missing is a MAINTAINERS entry. > > A side effect of this is that the small pieces of code in drivers/of > have to be compiled into stand alone modules and they may need access > to internal symbols from the subsystem. If they were directly linked > into the subsystems you wouldn't need to make the internal symbols > visible. Do you think you'll need something else than i2c_bus_type? That I don't consider an i2c-core internal. As I said, the lack of export was simply due to a lack of user. > Now the subsystems have to be careful about breaking the > in-kernel, external users of the symbols Same holds if the code is merged into i2c-core. > and we've made it possible for out of tree drivers to get to internal > structures. Hopefully the namespaced exports which some kernel developers are working on, will become a reality soon, to mitigate that kind of issue. That being said... As an upstream kernel developer / maintainer, I don't care about that. If external modules make use of internals they shouldn't touch, and later changes cause them to break, that's none of my business. I leave this to distribution maintainers. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, Jul 01, 2008 at 11:12:58AM -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > It was un-exported only because it had no user left, but it can be > > exported again if needed. > > Another solution would be to move drivers/of/of_i2c into the i2c > directory and make it part of i2c core on powerpc builds. My preference is for things like of_spi and of_i2c to go with the related busses; I think it makes more sense to keep all the I2C stuff together, but I've already lost that battle once. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Xilinx: adding Xilinx 440 cpu support
The following change updates the cputable to support the 440 processor in the Xilinx Virtex5 FXT FPGA. Signed-off-by: John Linn <[EMAIL PROTECTED]> Acked-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/kernel/cputable.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c index e44d553..ae3660b 100644 --- a/arch/powerpc/kernel/cputable.c +++ b/arch/powerpc/kernel/cputable.c @@ -1410,6 +1410,16 @@ static struct cpu_spec __initdata cpu_specs[] = { .machine_check = machine_check_440A, .platform = "ppc440", }, + { /* 440 in Xilinx Virtex-5 FXT */ + .pvr_mask = 0xfff0, + .pvr_value = 0x7ff21910, + .cpu_name = "440 in Virtex-5 FXT", + .cpu_features = CPU_FTRS_44X, + .cpu_user_features = COMMON_USER_BOOKE, + .icache_bsize = 32, + .dcache_bsize = 32, + .platform = "ppc440", + }, { /* 460EX */ .pvr_mask = 0x0002, .pvr_value = 0x13020002, -- 1.5.2.1 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: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > > It was un-exported only because it had no user left, but it can be > > > exported again if needed. > > > > Another solution would be to move drivers/of/of_i2c into the i2c > > directory and make it part of i2c core on powerpc builds. > > > I don't think this is a good idea. Merging arch-specific code (or > half-arch-specific code in this case) into arch-neutral drivers ends up > being a pain to maintain. People will keep sending me patches for stuff > I don't know anything about and can't help with. Having of-specific > stuff in just one directory as is the case now sounds much better to > me. All it's missing is a MAINTAINERS entry. A side effect of this is that the small pieces of code in drivers/of have to be compiled into stand alone modules and they may need access to internal symbols from the subsystem. If they were directly linked into the subsystems you wouldn't need to make the internal symbols visible. Now the subsystems have to be careful about breaking the in-kernel, external users of the symbols and we've made it possible for out of tree drivers to get to internal structures. > > -- > > Jean Delvare > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: boot: update for initrd with simpleImage
This change to the makefile corrects the build of a simpleImage with initrd. Signed-off-by: John Linn <[EMAIL PROTECTED]> Acked-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/boot/Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 1cee2f9..095e04d 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -273,7 +273,8 @@ endif initrd- := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-)) initrd-y := $(patsubst zImage%, zImage.initrd%, \ $(patsubst dtbImage%, dtbImage.initrd%, \ - $(patsubst treeImage%, treeImage.initrd%, $(image-y + $(patsubst simpleImage%, simpleImage.initrd%, \ + $(patsubst treeImage%, treeImage.initrd%, $(image-y) initrd-y := $(filter-out $(image-y), $(initrd-y)) targets+= $(image-y) $(initrd-y) -- 1.5.2.1 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: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
On Tue, Jul 01, 2008 at 05:40:46PM +0200, Jochen Friedrich wrote: > Hi Grant, > > sorry for the late response on this one. > > > 2. You need to specifiy exact chip names in your compatible string. > > "fsl,cpm1-pario-" is a made up thing. > > >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank16") > >> + cpm1_gpiochip_add16(np); > >> + > >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32b") > >> + cpm1_gpiochip_add32(np); > >> + > >> + /* Port E uses CPM2 layout */ > >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32e") > >> + cpm2_gpiochip_add32(np); > > What do you suggest here? > > All GPIO ports of CPM1/CPM2 are on the SoC, so the chip name is in fact the > CPU itself > (like fsl,mpc866-pario-bank16). Right; so that is what I think you should call them. 'fsl,mpc866-*' instead of 'fsl,cpm1-*'. If multiple mpc8xx parts have the cpm1 core, then choose one of the parts for all the others to claim compatibility with. Now, there is a possible exception here... *IF* 'fsl,cpm1' is a very well defined ASIC logic block that is known to be identical or versioned between the various 8xx parts, *THEN* it is probably okay to call it fsl,cpm1 and my previous comment does not apply. But, I think it must be documented in the device tree binding as to what it is and where to get documentation for it. And you should still have the first compatible value to be something like "fsl,mpc866-pario-bank16", followed by the cpm ones. This was recently discussed between Kim and Segher. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 12:29:29 -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > Hi Jon, > > > > > > On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote: > > > Add the of_find_i2c_device_by_node function. This allows you to > > > follow a reference in the device to an i2c device node and then > > > locate the linux device instantiated by the device tree. Example > > > use, an i2s codec controlled by i2c. > > > --- > > > > > > drivers/i2c/i2c-core.c |2 +- > > > drivers/of/of_i2c.c| 37 ++--- > > > include/linux/i2c.h|3 +++ > > > include/linux/of_i2c.h |2 ++ > > > 4 files changed, 32 insertions(+), 12 deletions(-) > > > > > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > > > index d0175f4..e3abe1b 100644 > > > --- a/drivers/i2c/i2c-core.c > > > +++ b/drivers/i2c/i2c-core.c > > > @@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = { > > > { }, > > > }; > > > > > > -static struct bus_type i2c_bus_type = { > > > +struct bus_type i2c_bus_type = { > > > .name = "i2c", > > > .dev_attrs = i2c_dev_attrs, > > > .match = i2c_device_match, > > > > > > What if i2c-core is built as a module? Don't you need to export the > > symbol then? > > Jean, can you re-export i2c_bus_type and then I'll drop that part from > the patch? That way the patch won't hit multiple maintainers. Just send me a patch doing just that and I will be glad to push early in the 2.6.27 merge window. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: legacy_serial: reg-offset & shift aren't used
The legacy serial driver does not work with an 8250 type UART that uses reg-offset and reg-shift. This change updates the driver so it doesn't find the UART when those properties are present on the UART in the device tree for soc devices. Signed-off-by: John Linn <[EMAIL PROTECTED]> Acked-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/kernel/legacy_serial.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c index 61dd174..b43235f 100644 --- a/arch/powerpc/kernel/legacy_serial.c +++ b/arch/powerpc/kernel/legacy_serial.c @@ -136,6 +136,11 @@ static int __init add_legacy_soc_port(struct device_node *np, if (of_get_property(np, "clock-frequency", NULL) == NULL) return -1; + /* if reg-shift and offset, don't try to use it */ + if ((of_get_property(np, "reg-shift", NULL) != NULL) && + (of_get_property(np, "reg-offset", NULL) != NULL)) + return -1; + /* if rtas uses this device, don't try to use it as well */ if (of_get_property(np, "used-by-rtas", NULL) != NULL) return -1; -- 1.5.2.1 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: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On Tue, 1 Jul 2008 11:12:58 -0400, Jon Smirl wrote: > On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > > It was un-exported only because it had no user left, but it can be > > exported again if needed. > > Another solution would be to move drivers/of/of_i2c into the i2c > directory and make it part of i2c core on powerpc builds. I don't think this is a good idea. Merging arch-specific code (or half-arch-specific code in this case) into arch-neutral drivers ends up being a pain to maintain. People will keep sending me patches for stuff I don't know anything about and can't help with. Having of-specific stuff in just one directory as is the case now sounds much better to me. All it's missing is a MAINTAINERS entry. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi Jon, > > > On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote: > > Add the of_find_i2c_device_by_node function. This allows you to > > follow a reference in the device to an i2c device node and then > > locate the linux device instantiated by the device tree. Example > > use, an i2s codec controlled by i2c. > > --- > > > > drivers/i2c/i2c-core.c |2 +- > > drivers/of/of_i2c.c| 37 ++--- > > include/linux/i2c.h|3 +++ > > include/linux/of_i2c.h |2 ++ > > 4 files changed, 32 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > > index d0175f4..e3abe1b 100644 > > --- a/drivers/i2c/i2c-core.c > > +++ b/drivers/i2c/i2c-core.c > > @@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = { > > { }, > > }; > > > > -static struct bus_type i2c_bus_type = { > > +struct bus_type i2c_bus_type = { > > .name = "i2c", > > .dev_attrs = i2c_dev_attrs, > > .match = i2c_device_match, > > > What if i2c-core is built as a module? Don't you need to export the > symbol then? Jean, can you re-export i2c_bus_type and then I'll drop that part from the patch? That way the patch won't hit multiple maintainers. > > diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c > > index 715a444..ca69a16 100644 > > --- a/drivers/of/of_i2c.c > > +++ b/drivers/of/of_i2c.c > > @@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node, > > void of_register_i2c_devices(struct i2c_adapter *adap, > >struct device_node *adap_node) > > { > > - void *result; > > + struct i2c_client *i2c_dev; > > struct device_node *node; > > > > for_each_child_of_node(adap_node, node) { > > @@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap, > > continue; > > } > > > > - info.irq = irq_of_parse_and_map(node, 0); > > - if (info.irq == NO_IRQ) > > - info.irq = -1; > > - > > - if (of_find_i2c_driver(node, &info) < 0) { > > - irq_dispose_mapping(info.irq); > > + if (of_find_i2c_driver(node, &info) < 0) > > continue; > > - } > > > > + info.irq = irq_of_parse_and_map(node, 0); > > info.addr = *addr; > > > > - request_module(info.type); > > + request_module("%s", info.type); > > > A separate fix for this issue was already sent by Maximilian Attems a > few days go: > http://lists.lm-sensors.org/pipermail/i2c/2008-June/004030.html > > > > > > - result = i2c_new_device(adap, &info); > > - if (result == NULL) { > > + i2c_dev = i2c_new_device(adap, &info); > > + if (i2c_dev == NULL) { > > printk(KERN_ERR > > "of-i2c: Failed to load driver for %s\n", > > info.type); > > irq_dispose_mapping(info.irq); > > continue; > > } > > + > > + i2c_dev->dev.archdata.of_node = of_node_get(node); > > } > > } > > EXPORT_SYMBOL(of_register_i2c_devices); > > > > +static int of_dev_node_match(struct device *dev, void *data) > > +{ > > +return dev->archdata.of_node == data; > > +} > > + > > +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node) > > +{ > > + struct device *dev; > > + > > + dev = bus_find_device(&i2c_bus_type, NULL, node, > > + of_dev_node_match); > > + if (!dev) > > + return NULL; > > + > > + return to_i2c_client(dev); > > +} > > +EXPORT_SYMBOL(of_find_i2c_device_by_node); > > + > > MODULE_LICENSE("GPL"); > > diff --git a/include/linux/i2c.h b/include/linux/i2c.h > > index fb9af6a..186b22d 100644 > > --- a/include/linux/i2c.h > > +++ b/include/linux/i2c.h > > @@ -92,6 +92,9 @@ extern s32 i2c_smbus_read_i2c_block_data(struct > i2c_client * client, > > extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, > > u8 command, u8 length, > > const u8 *values); > > + > > +/* Base of the i2c bus */ > > +extern struct bus_type i2c_bus_type; > > > > /* > > * A driver is capable of handling one or more physical devices present on > > diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h > > index bd2a870..17d5897 100644 > > --- a/include/linux/of_i2c.h > > +++ b/include/linux/of_i2c.h > > @@ -16,5 +16,7 @@ > > > > void of_register_i2c_devices(struct i2c_adapter *adap, > >struct device_node *adap_node); > > +struct i2c_client *of_find_i2c_device_
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
Hi Jon, On Mon, 30 Jun 2008 19:01:26 -0400, Jon Smirl wrote: > Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c > to make i2c modules dynamically loadable by the device tree. > > Signed-off-by: Jon Smirl <[EMAIL PROTECTED]> > --- > > arch/powerpc/sysdev/fsl_soc.c | 122 > - > drivers/i2c/busses/i2c-mpc.c | 104 --- > 2 files changed, 60 insertions(+), 166 deletions(-) > > diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c > index 3a7054e..ebcec73 100644 > --- a/arch/powerpc/sysdev/fsl_soc.c > +++ b/arch/powerpc/sysdev/fsl_soc.c > @@ -414,128 +414,6 @@ err: > > arch_initcall(gfar_of_init); > > -#ifdef CONFIG_I2C_BOARDINFO > -#include > -struct i2c_driver_device { > - char*of_device; > - char*i2c_type; > -}; > - > -static struct i2c_driver_device i2c_devices[] __initdata = { > - {"ricoh,rs5c372a", "rs5c372a"}, > - {"ricoh,rs5c372b", "rs5c372b"}, > - {"ricoh,rv5c386", "rv5c386"}, > - {"ricoh,rv5c387a", "rv5c387a"}, > - {"dallas,ds1307", "ds1307"}, > - {"dallas,ds1337", "ds1337"}, > - {"dallas,ds1338", "ds1338"}, > - {"dallas,ds1339", "ds1339"}, > - {"dallas,ds1340", "ds1340"}, > - {"stm,m41t00", "m41t00"}, > - {"dallas,ds1374", "rtc-ds1374"}, > -}; > - > -static int __init of_find_i2c_driver(struct device_node *node, > - struct i2c_board_info *info) > -{ > - int i; > - > - for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) { > - if (!of_device_is_compatible(node, i2c_devices[i].of_device)) > - continue; > - if (strlcpy(info->type, i2c_devices[i].i2c_type, > - I2C_NAME_SIZE) >= I2C_NAME_SIZE) > - return -ENOMEM; > - return 0; > - } > - return -ENODEV; > -} > - > -static void __init of_register_i2c_devices(struct device_node *adap_node, > -int bus_num) > -{ > - struct device_node *node = NULL; > - > - while ((node = of_get_next_child(adap_node, node))) { > - struct i2c_board_info info = {}; > - const u32 *addr; > - int len; > - > - addr = of_get_property(node, "reg", &len); > - if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) { > - printk(KERN_WARNING "fsl_soc.c: invalid i2c device > entry\n"); > - continue; > - } > - > - info.irq = irq_of_parse_and_map(node, 0); > - if (info.irq == NO_IRQ) > - info.irq = -1; > - > - if (of_find_i2c_driver(node, &info) < 0) > - continue; > - > - info.addr = *addr; > - > - i2c_register_board_info(bus_num, &info, 1); > - } > -} > - > -static int __init fsl_i2c_of_init(void) > -{ > - struct device_node *np; > - unsigned int i = 0; > - struct platform_device *i2c_dev; > - int ret; > - > - for_each_compatible_node(np, NULL, "fsl-i2c") { > - struct resource r[2]; > - struct fsl_i2c_platform_data i2c_data; > - const unsigned char *flags = NULL; > - > - memset(&r, 0, sizeof(r)); > - memset(&i2c_data, 0, sizeof(i2c_data)); > - > - ret = of_address_to_resource(np, 0, &r[0]); > - if (ret) > - goto err; > - > - of_irq_to_resource(np, 0, &r[1]); > - > - i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2); > - if (IS_ERR(i2c_dev)) { > - ret = PTR_ERR(i2c_dev); > - goto err; > - } > - > - i2c_data.device_flags = 0; > - flags = of_get_property(np, "dfsrr", NULL); > - if (flags) > - i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR; > - > - flags = of_get_property(np, "fsl5200-clocking", NULL); > - if (flags) > - i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200; > - > - ret = > - platform_device_add_data(i2c_dev, &i2c_data, > - sizeof(struct > - fsl_i2c_platform_data)); > - if (ret) > - goto unreg; > - > - of_register_i2c_devices(np, i++); > - } > - > - return 0; > - > -unreg: > - platform_device_unregister(i2c_dev); > -err: > - return ret; > -} > - > -arch_initcall(fsl_i2c_of_init); > -#endif > > #ifdef CONFIG_PPC_83xx > static int __init mpc83xx_wdt_init(void) > diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c > index a076129..4fdfb62 100644 > --- a/drivers/i2c/busses/i2c-mpc.c > +++ b/drivers/i2c/busses/i2c-mpc.c > @@ -17,7 +17,8 @@ > #include > #include
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
Doing this at the binary level would be nice, but I see enough problems just doing it at the source level and at least for my purposes, doing it on a dtb would be overkill, I think. The main difficulty remains how to deal with cross references between nodes in a reasonable way where the references cross from one fragment to another. Steve > -Original Message- > From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED] > Sent: Monday, June 30, 2008 11:22 PM > To: Stephen Neuendorffer > Cc: John Williams; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michal Simek; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux- > [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; John Linn; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms > > > > As for the copyright, I haven't been able to find much information on > > whether or not generated files are even copyrightable. One might > > argue that they > > don't have sufficient 'creative value' to be copyrightable. Or > > arguably, they are as copyrightable by the generator author as by the > > author or the .mhs file. > > I admit in this case, I've followed the safe route by claiming a > > copyright, which at least at Xilinx has significant precedent. > > Also, thinking about your idea of sticking bits in BRAM etc... > > what would be nice would be the ability to "merge" trees. We've been > talking about that multiple times, it would be useful at several levels: > > - We could provide pre-made DTs for known CPUs (ie, 440GP, 440GX, > 405EX, ...) > - Boards can then include that, and then "override" some properties > (clocks, PHY wiring, ...) > - That could be done at the binary level too so that the BRAM contains > on "overlay" on top of the base ref. platform device-tree that comes > with the kernel for example. > > This is slightly different between doing that in the .dts source via > some kind of #include vs. doing that by merging blobs but we could make > it be essentially be the same internally: The #include generates a blob > that is then "merged in". > > Just random thoughts... > > Ben. > > 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: Commits added to powerpc.git master and powerpc-next branches
Hi Paul, On Tuesday 01 July 2008, Paul Mackerras wrote: > The following commits have been added to the master and powerpc-next > branches of the powerpc.git repository. This includes patches pulled > from Kumar's and Josh's trees. Now that the I2C driver for CPM1/CPM2 boards is in the i2c tree, is there any chance to get this one into 2.6.27? [POWERPC] Add i2c pins to dts and board setup http://patchwork.ozlabs.org/linuxppc/patch?person=1023&id=18603 Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
Hi Jean, > I'm not the one to push this upstream though, as the patch is > essentially an openfirmware patch. That would be something for Jochen > Friedrich and Paul Mackerras I guess. Would be nice to have a > MAINTAINERS entry for OF... Nope. I only did a small contribution to the OF stuff. I guess, Grant Likely or Stephen Rothwell are the defacto maintainers for OF. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH2/2] [POWERPC] CPM1: implement GPIO LIB API on CPM1 Freescale SoC.
Hi Grant, sorry for the late response on this one. > 2. You need to specifiy exact chip names in your compatible string. > "fsl,cpm1-pario-" is a made up thing. >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank16") >> + cpm1_gpiochip_add16(np); >> + >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32b") >> + cpm1_gpiochip_add32(np); >> + >> + /* Port E uses CPM2 layout */ >> + for_each_compatible_node(np, NULL, "fsl,cpm1-pario-bank32e") >> + cpm2_gpiochip_add32(np); What do you suggest here? All GPIO ports of CPM1/CPM2 are on the SoC, so the chip name is in fact the CPU itself (like fsl,mpc866-pario-bank16). Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Cascaded interrupt controller causing unbalanced interrupt.
Hi, I'm having a spot of trouble writing a driver for a cascaded interrupt handler used on one of our boards (8641D based board), patches to be forth-coming as soon as I have access to this list without Outlook (I'm working on it!). I have attached the driver at the bottom of the email for reference (sorry for the long email). The driver is cascaded like this: static void __init gef_sbc610_init_irq(void) { struct mpic *mpic1; struct device_node *np, *cascade_node = NULL; struct resource res; /* Determine MPIC address. */ np = of_find_node_by_type(NULL, "open-pic"); if (np == NULL) return; of_address_to_resource(np, 0, &res); mpic1 = mpic_alloc(np, res.start, MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN, 0, 256, "mpic"); of_node_put(np); BUG_ON(mpic1 == NULL); mpic_init(mpic1); /* * There is a simple interrupt handler in the main FPGA, this * needs To be cascaded into the MPIC */ cascade_node = of_find_compatible_node(NULL, NULL, "gef,fpga-pic"); if(!cascade_node) { printk(KERN_WARNING "SBC610: No FPGA PIC\n"); return; } gef_pic_init(cascade_node); of_node_put(cascade_node); } The cascaded interrupt controller is connected to the 8641D's mpic on interrupts 8 & 9, from the DTS file: gef_pic: [EMAIL PROTECTED],4000 { #interrupt-cells = <2>; interrupt-controller; device_type = "interrupt-controller"; compatible = "gef,fpga-pic"; reg = <0x4 0x4000 0x20>; interrupts = <0x8 0x1 0x9 0x1>; interrupt-parent = <&mpic>; }; The interrupts from the phys are connected to the cascaded interrupt controller: phy0: [EMAIL PROTECTED] { #interrupt-cells = <2>; interrupt-parent = <&gef_pic>; interrupts = <0x16 0x4>; reg = <0x0001>; device_type = "ethernet-phy"; }; phy2: [EMAIL PROTECTED] { #interrupt-cells = <2>; interrupt-parent = <&gef_pic>; interrupts = <0x17 0x4>; reg = <0x0003>; device_type = "ethernet-phy"; }; When I boot (with the debugging turned on) I see the following: mpic: Setting up MPIC "mpic" version 1.2 at fef4, max 2 CPUs mpic: ISU size: 88, shift: 7, mask: 7f mpic: Initializing for 88 sources gef_pic: gef_pic_init(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000) gef_pic: cascade mapped to irq 16 gef_pic: Setting up GEF FPGA pic at fdbf4000 ... gef_pic: gef_pic_host_xlate() gef_pic: Setting flags from intspec:4 gef_pic: gef_pic_host_map(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000, 22, 16) gef_pic: map virq 22, hwirq 0x16 gef_pic: gef_pic_host_xlate() gef_pic: Setting flags from intspec:4 gef_pic: gef_pic_host_map(/[EMAIL PROTECTED]/[EMAIL PROTECTED],4000, 23, 17) gef_pic: map virq 23, hwirq 0x17 ... gef_pic: Unmasking virtual interrupt 22, hw:22 Unbalanced enable for IRQ 22 [ cut here ] Badness at c0055868 [verbose debug info unavailable] NIP: c0055868 LR: c0055868 CTR: c01b3eb0 REGS: ef85be60 TRAP: 0700 Not tainted (2.6.26-rc8-13367-g62635be) MSR: 00021032 CR: 2222 XER: TASK = ef859970[10] 'events/1' THREAD: ef85a000 CPU: 1 GPR00: c0055868 ef85bf10 ef859970 0020 0001 0001 4000 GPR08: 0001 63f1 c03d 4282 0ff4ce00 0001 GPR16: c03c3040 c03a97f0 c03b c03a97f0 ef843f9c ef843f98 c03b GPR24: c004 c033 ef85a000 c01b1b40 c03c3a90 9032 c03c3a60 c03c3a60 NIP [c0055868] __enable_irq+0x50/0x84 LR [c0055868] __enable_irq+0x50/0x84 Call Trace: [ef85bf10] [c0055868] __enable_irq+0x50/0x84 (unreliable) [ef85bf20] [c0055cf8] enable_irq+0x50/0x70 [ef85bf40] [c01b1ba8] phy_change+0x68/0x108 [ef85bf60] [c003ade4] run_workqueue+0xac/0x15c [ef85bf90] [c003b330] worker_thread+0x74/0xd4 [ef85bfd0] [c003f3bc] kthread+0x48/0x84 [ef85bff0] [c00115f0] kernel_thread+0x44/0x60 Instruction dump: 419e0024 419a0044 3809 901f001c 80010014 83e1000c 38210010 7c0803a6 4e800020 3c60c033 3863f3a0 4bfd28c5 <0fe0> 80010014 83e1000c 38210010 ... gef_pic: Unmasking virtual interrupt 23, hw:23 Unbalanced enable for I
[PATCH v2 2/2] powerpc: fixup lwsync at runtime
To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up the code. We default to 'sync' since that is always safe and if the cpu is capable we will replace 'sync' with 'lwsync'. We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is needed. This flag could be moved elsewhere since we dont really use it for the normal CPU_FTR purpose. Finally we only store the relative offset in the fixup section to keep it as small as possible rather than using a full fixup_entry. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- * Moved and fixed up LWSYNC macros to feature-fixups.h * Added lwsync test case to feature-fixups * Reworked synch.h to be usable in asm code. - k arch/powerpc/kernel/module.c|6 + arch/powerpc/kernel/setup_32.c |4 +++ arch/powerpc/kernel/setup_64.c |2 + arch/powerpc/kernel/vdso.c | 10 arch/powerpc/kernel/vdso32/vdso32.lds.S |3 ++ arch/powerpc/kernel/vdso64/vdso64.lds.S |3 ++ arch/powerpc/kernel/vmlinux.lds.S |6 + arch/powerpc/lib/feature-fixups-test.S | 15 arch/powerpc/lib/feature-fixups.c | 36 + include/asm-powerpc/code-patching.h |3 +- include/asm-powerpc/cputable.h | 21 + include/asm-powerpc/feature-fixups.h| 10 include/asm-powerpc/synch.h | 38 ++ 13 files changed, 131 insertions(+), 26 deletions(-) diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c index 40dd52d..af07003 100644 --- a/arch/powerpc/kernel/module.c +++ b/arch/powerpc/kernel/module.c @@ -86,6 +86,12 @@ int module_finalize(const Elf_Ehdr *hdr, (void *)sect->sh_addr + sect->sh_size); #endif + sect = find_section(hdr, sechdrs, "__lwsync_fixup"); + if (sect != NULL) + do_lwsync_fixups(cur_cpu_spec->cpu_features, +(void *)sect->sh_addr, +(void *)sect->sh_addr + sect->sh_size); + return 0; } diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c index 9e83add..0109e7f 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr) PTRRELOC(&__start___ftr_fixup), PTRRELOC(&__stop___ftr_fixup)); + do_lwsync_fixups(spec->cpu_features, +PTRRELOC(&__start___lwsync_fixup), +PTRRELOC(&__stop___lwsync_fixup)); + return KERNELBASE + offset; } diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index 098fd96..04d8de9 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -363,6 +363,8 @@ void __init setup_system(void) &__start___ftr_fixup, &__stop___ftr_fixup); do_feature_fixups(powerpc_firmware_features, &__start___fw_ftr_fixup, &__stop___fw_ftr_fixup); + do_lwsync_fixups(cur_cpu_spec->cpu_features, +&__start___lwsync_fixup, &__stop___lwsync_fixup); /* * Unflatten the device-tree passed by prom_init or kexec diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index ce245a8..f177c60 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -571,6 +571,11 @@ static __init int vdso_fixup_features(struct lib32_elfinfo *v32, if (start64) do_feature_fixups(powerpc_firmware_features, start64, start64 + size64); + + start64 = find_section64(v64->hdr, "__lwsync_fixup", &size64); + if (start64) + do_lwsync_fixups(cur_cpu_spec->cpu_features, +start64, start64 + size64); #endif /* CONFIG_PPC64 */ start32 = find_section32(v32->hdr, "__ftr_fixup", &size32); @@ -585,6 +590,11 @@ static __init int vdso_fixup_features(struct lib32_elfinfo *v32, start32, start32 + size32); #endif /* CONFIG_PPC64 */ + start32 = find_section32(v32->hdr, "__lwsync_fixup", &size32); + if (start32) + do_lwsync_fixups(cur_cpu_spec->cpu_features, +start32, start32 + size32); + return 0; } diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S b/arch/powerpc/kernel/vdso32/vdso32.lds.S index 2717935..be3b6a4 100644 --- a/arch/powerpc/kernel/vdso32/vdso32.lds.S +++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S @@ -33,6 +33,9 @@ SECTIONS . = ALIGN(8); __ftr_fixup : { *(__ftr_fixup) } + . = ALIGN(8); + __lwsync_fixup : { *(__lwsync_fixup) } + #ifdef CONFIG_PPC64 . = ALIGN(8); __fw_ftr
[PATCH v2 1/2] powerpc: Fix building of feature-fixup tests on ppc32
We need to use PPC_LCMPI otherwise we get compile errors like: arch/powerpc/lib/feature-fixups-test.S: Assembler messages: arch/powerpc/lib/feature-fixups-test.S:142: Error: Unrecognized opcode: `cmpdi' arch/powerpc/lib/feature-fixups-test.S:149: Error: Unrecognized opcode: `cmpdi' arch/powerpc/lib/feature-fixups-test.S:164: Error: Unrecognized opcode: `cmpdi' Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/lib/feature-fixups-test.S |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/lib/feature-fixups-test.S b/arch/powerpc/lib/feature-fixups-test.S index 10d038b..0549be0 100644 --- a/arch/powerpc/lib/feature-fixups-test.S +++ b/arch/powerpc/lib/feature-fixups-test.S @@ -139,14 +139,14 @@ globl(ftr_fixup_test6) 1: or 1,1,1 BEGIN_FTR_SECTION or 5,5,5 -2: cmpdi r3,0 +2: PPC_LCMPI r3,0 beq 4f blt 2b b 1b b 4f FTR_SECTION_ELSE 2: or 2,2,2 - cmpdi r3,1 + PPC_LCMPI r3,1 beq 3f blt 2b b 3f @@ -161,7 +161,7 @@ globl(end_ftr_fixup_test6) globl(ftr_fixup_test6_expected) 1: or 1,1,1 2: or 2,2,2 - cmpdi r3,1 + PPC_LCMPI r3,1 beq 3f blt 2b b 3f -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
On 7/1/08, Jean Delvare <[EMAIL PROTECTED]> wrote: > I'm fine with this patch. In particular, exporting i2c_bus_type is OK. > It was un-exported only because it had no user left, but it can be > exported again if needed. Another solution would be to move drivers/of/of_i2c into the i2c directory and make it part of i2c core on powerpc builds. > I'm not the one to push this upstream though, as the patch is > essentially an openfirmware patch. That would be something for Jochen > Friedrich and Paul Mackerras I guess. Would be nice to have a > MAINTAINERS entry for OF... > > -- > > Jean Delvare > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: manual merge of the net tree
On Tue, 1 Jul 2008 17:19:40 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > Hi Dave, > > Today's linux-next merge of the net tree got a conflict in between ^ Documentation/powerpc/booting-without-of.txt -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpglOlQwQ7aB.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add the of_find_i2c_device_by_node function, V4
Hi Jon, On Mon, 30 Jun 2008 19:01:28 -0400, Jon Smirl wrote: > Add the of_find_i2c_device_by_node function. This allows you to > follow a reference in the device to an i2c device node and then > locate the linux device instantiated by the device tree. Example > use, an i2s codec controlled by i2c. > --- > > drivers/i2c/i2c-core.c |2 +- > drivers/of/of_i2c.c| 37 ++--- > include/linux/i2c.h|3 +++ > include/linux/of_i2c.h |2 ++ > 4 files changed, 32 insertions(+), 12 deletions(-) > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c > index d0175f4..e3abe1b 100644 > --- a/drivers/i2c/i2c-core.c > +++ b/drivers/i2c/i2c-core.c > @@ -208,7 +208,7 @@ static struct device_attribute i2c_dev_attrs[] = { > { }, > }; > > -static struct bus_type i2c_bus_type = { > +struct bus_type i2c_bus_type = { > .name = "i2c", > .dev_attrs = i2c_dev_attrs, > .match = i2c_device_match, What if i2c-core is built as a module? Don't you need to export the symbol then? > diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c > index 715a444..ca69a16 100644 > --- a/drivers/of/of_i2c.c > +++ b/drivers/of/of_i2c.c > @@ -75,7 +75,7 @@ static int of_find_i2c_driver(struct device_node *node, > void of_register_i2c_devices(struct i2c_adapter *adap, >struct device_node *adap_node) > { > - void *result; > + struct i2c_client *i2c_dev; > struct device_node *node; > > for_each_child_of_node(adap_node, node) { > @@ -90,29 +90,44 @@ void of_register_i2c_devices(struct i2c_adapter *adap, > continue; > } > > - info.irq = irq_of_parse_and_map(node, 0); > - if (info.irq == NO_IRQ) > - info.irq = -1; > - > - if (of_find_i2c_driver(node, &info) < 0) { > - irq_dispose_mapping(info.irq); > + if (of_find_i2c_driver(node, &info) < 0) > continue; > - } > > + info.irq = irq_of_parse_and_map(node, 0); > info.addr = *addr; > > - request_module(info.type); > + request_module("%s", info.type); A separate fix for this issue was already sent by Maximilian Attems a few days go: http://lists.lm-sensors.org/pipermail/i2c/2008-June/004030.html > > - result = i2c_new_device(adap, &info); > - if (result == NULL) { > + i2c_dev = i2c_new_device(adap, &info); > + if (i2c_dev == NULL) { > printk(KERN_ERR > "of-i2c: Failed to load driver for %s\n", > info.type); > irq_dispose_mapping(info.irq); > continue; > } > + > + i2c_dev->dev.archdata.of_node = of_node_get(node); > } > } > EXPORT_SYMBOL(of_register_i2c_devices); > > +static int of_dev_node_match(struct device *dev, void *data) > +{ > +return dev->archdata.of_node == data; > +} > + > +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node) > +{ > + struct device *dev; > + > + dev = bus_find_device(&i2c_bus_type, NULL, node, > + of_dev_node_match); > + if (!dev) > + return NULL; > + > + return to_i2c_client(dev); > +} > +EXPORT_SYMBOL(of_find_i2c_device_by_node); > + > MODULE_LICENSE("GPL"); > diff --git a/include/linux/i2c.h b/include/linux/i2c.h > index fb9af6a..186b22d 100644 > --- a/include/linux/i2c.h > +++ b/include/linux/i2c.h > @@ -92,6 +92,9 @@ extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client > * client, > extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client * client, > u8 command, u8 length, > const u8 *values); > + > +/* Base of the i2c bus */ > +extern struct bus_type i2c_bus_type; > > /* > * A driver is capable of handling one or more physical devices present on > diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h > index bd2a870..17d5897 100644 > --- a/include/linux/of_i2c.h > +++ b/include/linux/of_i2c.h > @@ -16,5 +16,7 @@ > > void of_register_i2c_devices(struct i2c_adapter *adap, >struct device_node *adap_node); > +struct i2c_client *of_find_i2c_device_by_node(struct device_node *node); > + > > #endif /* __LINUX_OF_I2C_H */ I'm fine with this patch. In particular, exporting i2c_bus_type is OK. It was un-exported only because it had no user left, but it can be exported again if needed. I'm not the one to push this upstream though, as the patch is essentially an openfirmware patch. That would be something for Jochen Friedrich and Paul Mackerras I guess. Would be nice to have a MAINTAINE
Re: AZFS file system proposal
On Wednesday 18 June 2008, Maxim Shchetynin wrote: > AZFS patch updated accordinly to comments of Christoph Hellwig and Dmitri > Vorobiev. Sorry for my not commenting earlier on this. I'm finally collecting my 2.6.27 patches and stumbled over it again. There are a few details that I hope we can fix up quickly, other than that, it looks good now, great work! > Subject: azfs: initial submit of azfs, a non-buffered filesystem Please make the patch subject the actual subject of your email next time, and put the introductory text below the Signed-off-by: lines, separated by a "---" line. That will make the standard tools work without extra effort on my side. Also, please always Cc the person you want to merge the patch, in this case probably me. > diff -Nuar linux-2.6.26-rc6/fs/Makefile linux-2.6.26-rc6-azfs/fs/Makefile > --- linux-2.6.26-rc6/fs/Makefile 2008-06-12 23:22:24.0 +0200 > +++ linux-2.6.26-rc6-azfs/fs/Makefile 2008-06-16 11:17:50.0 +0200 > @@ -119,3 +119,4 @@ > obj-$(CONFIG_DEBUG_FS) += debugfs/ > obj-$(CONFIG_OCFS2_FS) += ocfs2/ > obj-$(CONFIG_GFS2_FS) += gfs2/ > +obj-$(CONFIG_AZ_FS) += azfs.o > diff -Nuar linux-2.6.26-rc6/fs/azfs.c linux-2.6.26-rc6-azfs/fs/azfs.c > --- linux-2.6.26-rc6/fs/azfs.c1970-01-01 01:00:00.0 +0100 > +++ linux-2.6.26-rc6-azfs/fs/azfs.c 2008-06-18 15:56:13.252266896 +0200 All other file systems are in separate directories, so it would be better to rename fs/azfs.c to fs/azfs/inode.c > +#define AZFS_FILESYSTEM_NAME "azfs" > +#define AZFS_FILESYSTEM_FLAGSFS_REQUIRES_DEV > + > +#define AZFS_SUPERBLOCK_MAGIC0xABBA1972 > +#define AZFS_SUPERBLOCK_FLAGSMS_NOEXEC | \ > + MS_SYNCHRONOUS | \ > + MS_DIRSYNC | \ > + MS_ACTIVE Why MS_NOEXEC? What happens on a remount if the user does not specifies -o remount,exec? > +/** > + * azfs_block_find - get real address of a part of a file > + * @inode: inode > + * @direction: data direction > + * @from: offset for read/write operation > + * @size: pointer to a value of the amount of data to be read/written > + */ > +static unsigned long > +azfs_block_find(struct inode *inode, enum azfs_direction direction, > + unsigned long from, unsigned long *size) > +{ > + struct azfs_super *super; > + struct azfs_znode *znode; > + struct azfs_block *block; > + unsigned long block_id, west, east; > + > + super = inode->i_sb->s_fs_info; > + znode = I2Z(inode); > + > + if (from + *size > znode->size) { > + i_size_write(inode, from + *size); > + inode->i_op->truncate(inode); > + } > + > + read_lock(&znode->lock); > + > + if (list_empty(&znode->block_list)) { > + read_unlock(&znode->lock); > + return 0; > + } > + > + block_id = from >> super->block_shift; > + > + for_each_block(block, &znode->block_list) { > + if (block->count > block_id) > + break; > + block_id -= block->count; > + } > + > + west = from % super->block_size; > + east = ((block->count - block_id) << super->block_shift) - west; > + > + if (*size > east) > + *size = east; > + > + block_id = ((block->id + block_id) << super->block_shift) + west; > + > + read_unlock(&znode->lock); > + > + block_id += direction == AZFS_MMAP ? super->ph_addr : super->io_addr; > + > + return block_id; > +} This overloading of the return type to mean either a pointer or an offset on the block device is rather confusing. Why not just return the raw block_id before the last += and leave that part up to the caller? static void __iomem * azfs_block_addr(struct inode *inode, enum azfs_direction direction, unsigned long from, unsigned long *size) { struct azfs_super *super; unsigned long offset; void __iomem *p; super = inode->i_sb->s_fs_info; offset = azfs_block_find(inode, super, 0, from, size); p = super->ph_addr + offset; return p; } > + target = iov->iov_base; > + todo = min((loff_t) iov->iov_len, i_size_read(inode) - pos); > + > + for (step = todo; step; step -= size) { > + size = step; > + pin = azfs_block_find(inode, AZFS_READ, pos, &size); > + if (!pin) { > + rc = -ENOSPC; > + goto out; > + } > + if (copy_to_user(target, (void*) pin, size)) { > + rc = -EFAULT; > + goto out; > + } Question to the powerpc folks: is copy_to_user safe for an __iomem source? Should there be two copies (memcpy_fromio and copy_to_user) instead? > + page_prot = pgprot_val(vma->vm_page_prot); > + page_prot |= (_PAGE_NO_CACHE | _PAGE_RW); > +
Re: [PATCH] powerpc: fixup lwsync at runtime
On Jul 1, 2008, at 1:29 AM, Michael Ellerman wrote: On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote: To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up the code. We default to 'sync' since that is always safe and if the cpu is capable we will replace 'sync' with 'lwsync'. We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is needed. This flag could be moved elsewhere since we dont really use it for the normal CPU_FTR purpose. Finally we only store the relative offset in the fixup section to keep it as small as possible rather than using a full fixup_entry. How many entries are we talking? I guess it's not much bother to have a separate section. On the order of 1000 entries for an SMP build. diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/ setup_32.c index 9e83add..0109e7f 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -101,6 +101,10 @@ unsigned long __init early_init(unsigned long dt_ptr) PTRRELOC(&__start___ftr_fixup), PTRRELOC(&__stop___ftr_fixup)); + do_lwsync_fixups(spec->cpu_features, +PTRRELOC(&__start___lwsync_fixup), +PTRRELOC(&__stop___lwsync_fixup)); + This could be changed to use cur_cpu_spec->cpu_features, and then all the call sites would be passing that, which would mean do_lwsync_fixups() could just check cur_cpu_spec->cpu_features directly. cur_cpu_spec and spec at this point arent the same thing. will post a new version w/fixes. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Make device table externally visible
This gives ehca an autogenerated modalias and therefore enables automatic loading. Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]> --- drivers/infiniband/hw/ehca/ehca_main.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c index 482103e..598844d 100644 --- a/drivers/infiniband/hw/ehca/ehca_main.c +++ b/drivers/infiniband/hw/ehca/ehca_main.c @@ -923,6 +923,7 @@ static struct of_device_id ehca_device_table[] = }, {}, }; +MODULE_DEVICE_TABLE(of, ehca_device_table); static struct of_platform_driver ehca_driver = { .name= "ehca", -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/6] mm: Allow architectures to define additional protection bits
On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote: > On Wed, 18 Jun 2008 17:32:55 -0500 [EMAIL PROTECTED] wrote: > > > This patch allows architectures to define functions to deal with > > additional protections bits for mmap() and mprotect(). > > > > arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags > > arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot > > arch_validate_prot() checks for valid values of the protection bits > > It'd be simpler if Paul were to merge this. It doesn't conflict with > any pending work. That works for me. Paul, I'll send you an updated patchset. > Acked-by: Andrew Morton <[EMAIL PROTECTED]> > > > Note: vm_get_page_prot() is now pretty ugly. > > It is. But afacit it generates the same code for non-powerpc. > > > Suggestions? > > nfi. Let us rub the Hugh-summoning lamp. > > > Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> > > --- > > > > include/linux/mman.h | 28 +++- > > mm/mmap.c|5 +++-- > > mm/mprotect.c|2 +- > > 3 files changed, 31 insertions(+), 4 deletions(-) > > > > Index: linux-2.6.26-rc5/include/linux/mman.h > > === > > --- linux-2.6.26-rc5.orig/include/linux/mman.h > > +++ linux-2.6.26-rc5/include/linux/mman.h > > @@ -34,6 +34,31 @@ static inline void vm_unacct_memory(long > > } > > > > /* > > + * Allow architectures to handle additional protection bits > > + */ > > + > > +#ifndef arch_calc_vm_prot_bits > > +#define arch_calc_vm_prot_bits(prot) 0 > > +#endif > > + > > +#ifndef arch_vm_get_page_prot > > +#define arch_vm_get_page_prot(vm_flags) __pgprot(0) > > +#endif > > + > > +#ifndef arch_validate_prot > > +/* > > + * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have > > + * already been masked out. > > + * > > + * Returns true if the prot flags are valid > > + */ > > +static inline int arch_validate_prot(unsigned long prot) > > +{ > > + return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0; > > +} > > Officially we should now have > > #define arch_validate_prot arch_validate_prot > > here. No problem. > > +#endif > > + > > +/* > > * Optimisation macro. It is equivalent to: > > * (x & bit1) ? bit2 : 0 > > * but this version is faster. > > @@ -51,7 +76,8 @@ calc_vm_prot_bits(unsigned long prot) > > { > > return _calc_vm_trans(prot, PROT_READ, VM_READ ) | > >_calc_vm_trans(prot, PROT_WRITE, VM_WRITE) | > > - _calc_vm_trans(prot, PROT_EXEC, VM_EXEC ); > > + _calc_vm_trans(prot, PROT_EXEC, VM_EXEC) | > > + arch_calc_vm_prot_bits(prot); > > } > > > > /* > > Index: linux-2.6.26-rc5/mm/mmap.c > > === > > --- linux-2.6.26-rc5.orig/mm/mmap.c > > +++ linux-2.6.26-rc5/mm/mmap.c > > @@ -72,8 +72,9 @@ pgprot_t protection_map[16] = { > > > > pgprot_t vm_get_page_prot(unsigned long vm_flags) > > { > > - return protection_map[vm_flags & > > - (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]; > > + return __pgprot(pgprot_val(protection_map[vm_flags & > > + (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) | > > + pgprot_val(arch_vm_get_page_prot(vm_flags))); > > } > > EXPORT_SYMBOL(vm_get_page_prot); > > > > Index: linux-2.6.26-rc5/mm/mprotect.c > > === > > --- linux-2.6.26-rc5.orig/mm/mprotect.c > > +++ linux-2.6.26-rc5/mm/mprotect.c > > @@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_t > > end = start + len; > > if (end <= start) > > return -ENOMEM; > > - if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) > > + if (!arch_validate_prot(prot)) > > return -EINVAL; > > > > reqprot = prot; > > > > -- -- David Kleikamp IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] Helper routines for parsing drconf memory
Paul Mackerras wrote: Nathan Fontenot writes: This patch pulls several pieces of exisitng code for parsing memory under the ibm,dynamic-reconfiguration-memory node of the device tree into helper routines. This is in preparation for the next patch that will also use these same helper routines. There are no functional changes in this patch. I went to apply this, but it is whitespace-damaged... Hmmm... I am having problems getting this to apply to the latest mainline cleanly. I'll update the patchset and re-submit. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/86xx: mpc8610_hpcd: fix interrupt trigger type for ULi IDE
i8259 PIC is disabled on MPC8610HPCD, and ULi IDE is configured to use PCI sideband interrupt that is specified in the device tree. Current HPCD's device tree specify that IDE interrupt is low to high sensitive, but in practice ULi IDE throws active-high interrupts (not active-low as all normal PCI devices). Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- This is for -next, since the bug could be triggered only on RT kernels with hardirq preemption. arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts index 65a5f64..981941e 100644 --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts @@ -363,7 +363,7 @@ 0xe000 0 0 4 &mpic 1 1 /* IDSEL 0x1f */ - 0xf800 0 0 1 &mpic 3 0 + 0xf800 0 0 1 &mpic 3 2 0xf800 0 0 2 &mpic 0 1 >; -- 1.5.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUG] 2.6.26-rc8-git2 - powerpc - circular locking dependency detected with net/ehea driver
Hi, circular locking dependency is detected, while booting the powerpc box with the 2.6.26-rc8-git2 kernel. === [ INFO: possible circular locking dependency detected ] 2.6.26-rc8-git2 #1 --- ip/2214 is trying to acquire lock: (&ehea_fw_handles.lock){--..}, at: [] .ehea_up+0x6c/0x6f8 [ehea] but task is already holding lock: (&port->port_lock){--..}, at: [] .ehea_open+0x44/0xcc [ehea] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->port_lock){--..}: [] .__lock_acquire+0xc84/0xee0 [] .lock_acquire+0xd8/0x124 [] .mutex_lock_nested+0x168/0x420 [] .ehea_open+0x44/0xcc [ehea] [] .dev_open+0xec/0x160 [] .dev_change_flags+0x10c/0x210 [] .devinet_ioctl+0x2cc/0x778 [] .inet_ioctl+0xdc/0x134 [] .sock_ioctl+0x2dc/0x338 [] .vfs_ioctl+0x64/0xfc [] .do_vfs_ioctl+0x450/0x494 [] .sys_ioctl+0x78/0xc0 [] .dev_ifsioc+0x1e8/0x450 [] .compat_sys_ioctl+0x3ec/0x484 [] syscall_exit+0x0/0x40 -> #1 (rtnl_mutex){--..}: [] .__lock_acquire+0xc84/0xee0 [] .lock_acquire+0xd8/0x124 [] .mutex_lock_nested+0x168/0x420 [] .rtnl_lock+0x28/0x44 [] .register_netdev+0x24/0x8c [] .ehea_setup_single_port+0x2d4/0x3e0 [ehea] [] .ehea_probe_adapter+0x290/0x3a0 [ehea] [] .of_platform_device_probe+0x80/0x8c4 [] .driver_probe_device+0x144/0x20c [] .__driver_attach+0x68/0xb0 [] .bus_for_each_dev+0x88/0xe4 [] .driver_attach+0x34/0x50 [] .bus_add_driver+0xe0/0x294 [] .driver_register+0xcc/0x1a4 [] .of_register_driver+0x54/0x6c [] .ibmebus_register_driver+0x40/0x60 [] .ehea_module_init+0x1e4/0x22fc [ehea] [] .sys_init_module+0x19a0/0x1b80 [] syscall_exit+0x0/0x40 -> #0 (&ehea_fw_handles.lock){--..}: [] .__lock_acquire+0xb80/0xee0 [] .lock_acquire+0xd8/0x124 [] .mutex_lock_nested+0x168/0x420 [] .ehea_up+0x6c/0x6f8 [ehea] [] .ehea_open+0x6c/0xcc [ehea] [] .dev_open+0xec/0x160 [] .dev_change_flags+0x10c/0x210 [] .devinet_ioctl+0x2cc/0x778 [] .inet_ioctl+0xdc/0x134 [] .sock_ioctl+0x2dc/0x338 [] .vfs_ioctl+0x64/0xfc [] .do_vfs_ioctl+0x450/0x494 [] .sys_ioctl+0x78/0xc0 [] .dev_ifsioc+0x1e8/0x450 [] .compat_sys_ioctl+0x3ec/0x484 [] syscall_exit+0x0/0x40 other info that might help us debug this: 2 locks held by ip/2214: #0: (rtnl_mutex){--..}, at: [] .rtnl_lock+0x28/0x44 #1: (&port->port_lock){--..}, at: [] .ehea_open+0x44/0xcc [ehea] stack backtrace: Call Trace: [c000f4d0f030] [c0010b9c] .show_stack+0x78/0x1c8 (unreliable) [c000f4d0f0e0] [c0010d0c] .dump_stack+0x20/0x34 [c000f4d0f160] [c00a7644] .print_circular_bug_tail+0x84/0xa8 [c000f4d0f230] [c00a9fe4] .__lock_acquire+0xb80/0xee0 [c000f4d0f320] [c00aa41c] .lock_acquire+0xd8/0x124 [c000f4d0f3e0] [c0452008] .mutex_lock_nested+0x168/0x420 [c000f4d0f4d0] [d07b4fa8] .ehea_up+0x6c/0x6f8 [ehea] [c000f4d0f5e0] [d07b57e4] .ehea_open+0x6c/0xcc [ehea] [c000f4d0f680] [c03b62b0] .dev_open+0xec/0x160 [c000f4d0f710] [c03b46a4] .dev_change_flags+0x10c/0x210 [c000f4d0f7c0] [c04162b0] .devinet_ioctl+0x2cc/0x778 [c000f4d0f8d0] [c04173e0] .inet_ioctl+0xdc/0x134 [c000f4d0f950] [c03a4464] .sock_ioctl+0x2dc/0x338 [c000f4d0f9f0] [c012d12c] .vfs_ioctl+0x64/0xfc [c000f4d0fa90] [c012d614] .do_vfs_ioctl+0x450/0x494 [c000f4d0fb50] [c012d6d0] .sys_ioctl+0x78/0xc0 [c000f4d0fc10] [c016413c] .dev_ifsioc+0x1e8/0x450 [c000f4d0fd30] [c0163588] .compat_sys_ioctl+0x3ec/0x484 [c000f4d0fe30] [c00086dc] syscall_exit+0x0/0x40 ehea: eth0: Physical port up ehea: External switch port is backup port BUG: sleeping function called from invalid context at kernel/mutex.c:209 in_atomic():1, irqs_disabled():0 INFO: lockdep is turned off. Call Trace: [c000f4d0f200] [c0010b9c] .show_stack+0x78/0x1c8 (unreliable) [c000f4d0f2b0] [c0010d0c] .dump_stack+0x20/0x34 [c000f4d0f330] [c006dfc0] .__might_sleep+0x104/0x124 [c000f4d0f3c0] [c0451ef0] .mutex_lock_nested+0x50/0x420 [c000f4d0f4b0] [d07b2f80] .ehea_set_multicast_list+0x64/0x1d8 [ehea] [c000f4d0f560] [c03b2de4] .__dev_set_rx_mode+0xd0/0xf0 [c000f4d0f5f0] [c03b2e44] .dev_set_rx_mode+0x40/0x70 [c000f4d0f680] [c03b62ec] .dev_open+0x128/0x160 [c000f4d0f710] [c03b46a4] .dev_change_flags+0x10c/0x210 [c000f4d0f7c0] [c04162b0] .devinet_ioctl+0x2cc/0x778 [c000f4d0f8d0] [c04173e0] .inet_ioctl+0xdc/0x134 [c000f4d0f950] [c03a4464] .sock_i
Re: [PATCH] powerpc: fix compile warning in init_thread
In message <[EMAIL PROTECTED]> you wrote: > On Tue, 2008-07-01 at 17:00 +1000, Michael Neuling wrote: > > arch/powerpc/kernel/init_task.c:33: warning: missing braces around initiali zer > > arch/powerpc/kernel/init_task.c:33: warning: (near initialization for 'init _task.thread.fpr[0]') > > > > Noticed by SFR. > > > > Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> > > That's when fpr is part of the union but what if CONFIG_VSX is off ? It's not a union anymore. It's a 2D array irrespective of CONFIG_VSX. double fpr[32][TS_FPRWIDTH]; Mikey > > Ben. > > > --- > > > > include/asm-powerpc/processor.h |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h > > === > > --- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h > > +++ linux-2.6-ozlabs/include/asm-powerpc/processor.h > > @@ -222,7 +222,7 @@ struct thread_struct { > > .ksp_limit = INIT_SP_LIMIT, \ > > .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ > > .fs = KERNEL_DS, \ > > - .fpr = {0}, \ > > + .fpr = {{0}}, \ > > .fpscr = { .val = 0, }, \ > > .fpexc_mode = 0, \ > > } > > ___ > > 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
linux-next: manual merge of the ttydev tree
Hi Alan, Today's linux-next merge of the ttydev tree got a conflict in drivers/serial/cpm_uart/cpm_uart_core.c between commit 0b2a2e5b7747f1f63bd86ca22b5c6097da5b2137 ("cpm_uart: Remove !CONFIG_PPC_CPM_NEW_BINDING code") from the powerpc tree and commit 33e211d606d46d18befa6fe6aec76aa7971eefa8 ("03-serial_vcs") from the ttydev tree. The former removes some of the code modified by the latter. It is a simple fixup and I can carry it. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgph8pPzb5VtA.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: manual merge of the net tree
From: Stephen Rothwell <[EMAIL PROTECTED]> Date: Tue, 1 Jul 2008 17:19:40 +1000 > Today's linux-next merge of the net tree got a conflict ... Thanks for the heads up on these two conflicts with the powerpc tree. The best seems to let you keep using your resolving, so that's what I'll let you do :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile warning in init_thread
On Tue, 2008-07-01 at 17:00 +1000, Michael Neuling wrote: > arch/powerpc/kernel/init_task.c:33: warning: missing braces around initializer > arch/powerpc/kernel/init_task.c:33: warning: (near initialization for > 'init_task.thread.fpr[0]') > > Noticed by SFR. > > Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> That's when fpr is part of the union but what if CONFIG_VSX is off ? Ben. > --- > > include/asm-powerpc/processor.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h > === > --- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h > +++ linux-2.6-ozlabs/include/asm-powerpc/processor.h > @@ -222,7 +222,7 @@ struct thread_struct { > .ksp_limit = INIT_SP_LIMIT, \ > .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ > .fs = KERNEL_DS, \ > - .fpr = {0}, \ > + .fpr = {{0}}, \ > .fpscr = { .val = 0, }, \ > .fpexc_mode = 0, \ > } > ___ > 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
Re: [patch 1/6] mm: Allow architectures to define additional protection bits
On Wed, 18 Jun 2008 17:32:55 -0500 [EMAIL PROTECTED] wrote: > This patch allows architectures to define functions to deal with > additional protections bits for mmap() and mprotect(). > > arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags > arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot > arch_validate_prot() checks for valid values of the protection bits It'd be simpler if Paul were to merge this. It doesn't conflict with any pending work. Acked-by: Andrew Morton <[EMAIL PROTECTED]> > Note: vm_get_page_prot() is now pretty ugly. It is. But afacit it generates the same code for non-powerpc. > Suggestions? nfi. Let us rub the Hugh-summoning lamp. > Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]> > --- > > include/linux/mman.h | 28 +++- > mm/mmap.c|5 +++-- > mm/mprotect.c|2 +- > 3 files changed, 31 insertions(+), 4 deletions(-) > > Index: linux-2.6.26-rc5/include/linux/mman.h > === > --- linux-2.6.26-rc5.orig/include/linux/mman.h > +++ linux-2.6.26-rc5/include/linux/mman.h > @@ -34,6 +34,31 @@ static inline void vm_unacct_memory(long > } > > /* > + * Allow architectures to handle additional protection bits > + */ > + > +#ifndef arch_calc_vm_prot_bits > +#define arch_calc_vm_prot_bits(prot) 0 > +#endif > + > +#ifndef arch_vm_get_page_prot > +#define arch_vm_get_page_prot(vm_flags) __pgprot(0) > +#endif > + > +#ifndef arch_validate_prot > +/* > + * This is called from mprotect(). PROT_GROWSDOWN and PROT_GROWSUP have > + * already been masked out. > + * > + * Returns true if the prot flags are valid > + */ > +static inline int arch_validate_prot(unsigned long prot) > +{ > + return (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) == 0; > +} Officially we should now have #define arch_validate_prot arch_validate_prot here. > +#endif > + > +/* > * Optimisation macro. It is equivalent to: > * (x & bit1) ? bit2 : 0 > * but this version is faster. > @@ -51,7 +76,8 @@ calc_vm_prot_bits(unsigned long prot) > { > return _calc_vm_trans(prot, PROT_READ, VM_READ ) | > _calc_vm_trans(prot, PROT_WRITE, VM_WRITE) | > -_calc_vm_trans(prot, PROT_EXEC, VM_EXEC ); > +_calc_vm_trans(prot, PROT_EXEC, VM_EXEC) | > +arch_calc_vm_prot_bits(prot); > } > > /* > Index: linux-2.6.26-rc5/mm/mmap.c > === > --- linux-2.6.26-rc5.orig/mm/mmap.c > +++ linux-2.6.26-rc5/mm/mmap.c > @@ -72,8 +72,9 @@ pgprot_t protection_map[16] = { > > pgprot_t vm_get_page_prot(unsigned long vm_flags) > { > - return protection_map[vm_flags & > - (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]; > + return __pgprot(pgprot_val(protection_map[vm_flags & > + (VM_READ|VM_WRITE|VM_EXEC|VM_SHARED)]) | > + pgprot_val(arch_vm_get_page_prot(vm_flags))); > } > EXPORT_SYMBOL(vm_get_page_prot); > > Index: linux-2.6.26-rc5/mm/mprotect.c > === > --- linux-2.6.26-rc5.orig/mm/mprotect.c > +++ linux-2.6.26-rc5/mm/mprotect.c > @@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_t > end = start + len; > if (end <= start) > return -ENOMEM; > - if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM)) > + if (!arch_validate_prot(prot)) > return -EINVAL; > > reqprot = prot; > > -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] ibm_newemac: Fixes entry of short packets
From: Sathya Narayanan <[EMAIL PROTECTED]> Short packets has to be discarded by the driver. So this patch addresses the issue of discarding the short packets of size lesser then ethernet header size. Signed-off-by: Sathya Narayanan <[EMAIL PROTECTED]> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index ca63fa0..babc79a 100644 --- a/drivers/net/ibm_newemac/core.c +++ b/drivers/net/ibm_newemac/core.c @@ -1636,6 +1636,12 @@ static int emac_poll_rx(void *param, int budget) goto next; } + if (len < ETH_HLEN) { + ++dev->estats.rx_dropped_stack; + emac_recycle_rx_skb(dev, slot, len); + goto next; + } + if (len && len < EMAC_RX_COPY_THRESH) { struct sk_buff *copy_skb = alloc_skb(len + EMAC_RX_SKB_HEADROOM + 2, GFP_ATOMIC); -- 1.5.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] ibm_newemac: Fixes kernel crashes when speed of cable connected changes
From: Sathya Narayanan <[EMAIL PROTECTED]> The descriptor pointers were not initialized to NIL values, so it was poiniting to some random addresses which was completely invalid. This fix takes care of initializing the descriptor to NIL values and clearing the valid descriptors on clean ring operation. Signed-off-by: Sathya Narayanan <[EMAIL PROTECTED]> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> --- drivers/net/ibm_newemac/core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c index 5d2108c..ca63fa0 100644 --- a/drivers/net/ibm_newemac/core.c +++ b/drivers/net/ibm_newemac/core.c @@ -2719,6 +2719,8 @@ static int __devinit emac_probe(struct of_device *ofdev, /* Clean rings */ memset(dev->tx_desc, 0, NUM_TX_BUFF * sizeof(struct mal_descriptor)); memset(dev->rx_desc, 0, NUM_RX_BUFF * sizeof(struct mal_descriptor)); + memset(dev->tx_skb, 0, NUM_TX_BUFF * sizeof(struct sk_buff *)); + memset(dev->rx_skb, 0, NUM_RX_BUFF * sizeof(struct sk_buff *)); /* Attach to ZMII, if needed */ if (emac_has_feature(dev, EMAC_FTR_HAS_ZMII) && -- 1.5.6.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commits added to powerpc.git master and powerpc-next branches
Hi Paul, On Tuesday 01 July 2008, Paul Mackerras wrote: > The following commits have been added to the master and powerpc-next > branches of the powerpc.git repository. This includes patches pulled > from Kumar's and Josh's trees. Any change of getting the following patches into 2.6.27 ? They have either been acked and not picked, or just ignored so far :-/ [PATCHv2] fs_enet: restore promiscuous and multicast settings in restart() http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=19228 [PATCH 2/2] fs_enet: MDIO on GPIO support http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=18693 [PATCHv3 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC. http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=19045 [PATCH] powerpc: Modem control lines support for the cpm_uart driver http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=17928 [PATCH] cpm_uart: Support uart_wait_until_sent() http://patchwork.ozlabs.org/linuxppc/patch?person=968&id=19233 Best regards, -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 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: [BUILD-FAILURE] linux-next: Tree for June 30 - powerpc - build failure at arch_add_memory()
Tony Breeds wrote: > On Mon, Jun 30, 2008 at 11:55:02PM +0530, Kamalesh Babulal wrote: >> Hi Stephen, >> >> next-20080630 kernel build fails on powerpc, with randconfig >> >> CC arch/powerpc/mm/mem.o >> arch/powerpc/mm/mem.c: In function ‘arch_add_memory’: >> arch/powerpc/mm/mem.c:130: error: implicit declaration of function >> ‘create_section_mapping’ >> make[1]: *** [arch/powerpc/mm/mem.o] Error 1 >> make: *** [arch/powerpc/mm] Error 2 > > This problem exists in in 2.6.26-rc8, so it's not specifially linux-next > realted. The patch at: > http://patchwork.ozlabs.org/linuxppc/patch?id=19347 > should fix it but is un-ACK'd ;P Hi Tony, Thanks, the patch fixes the build failure on the machine. > > Yours Tony > > linux.conf.auhttp://www.marchsouth.org/ > Jan 19 - 24 2009 The Australian Linux Technical Conference! > -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC83xx ipic problem
Scott, thanks for your reply. Honestly I don't think the board wiring is incorrect. FPGA goes to IRQ0 and miniPCI is wired to IRQ1. Maybe there's a crosstalk problem since the pull-up resistors are packaged inside an array ... I'll check this. regards, André Scott Wood schrieb: André Schwarz wrote: There are two external PCI devices connected (FPGA + miniPCI socket). The FPGA is working fine and uses IRQ0 for its PCI_INTA line. As soon there's a miniPCI module present and the driver loaded (actually an ath5k WiFi module) the system complains after a while : irq 48: nobody cared handlers: location of the FPGA irq handler Disabling IRQ #48 -> This is weird since the FPGA isn't working at all and IRQ0 is *not* asserted ! Are you *sure* that IRQ0 isn't asserted? The IPIC seems to think it is. Of course the miniPCI irq is routed to a different pin on the CPU (IRQ1). Perhaps the board wiring is incorrect? interrupt-map = <0x5800 0 0 1 &ipic 0x30 0x8 -> FPGA @ IRQ0 0x6000 0 0 1 &ipic 0x11 0x8 -> miniPCI INTA @ IRQ1 0x6000 0 0 2 &ipic 0x11 0x8>;-> miniPCI INTB @ IRQ1 Is it legal to use a single irq pin twice ? Yes. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstra�e 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch�ftsf�hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the net tree
Hi Dave, Today's linux-next merge of the net tree got a conflict in between commits aee1dc73b519227084d77b0b2fc972b68b4153d8 ("[POWERPC] Update booting-without-of for Freescale PCIe MSI") and 83ff9dcf375c418ca3b98eb950711525ca1269e2 ("powerpc/sysdev: implement FSL GTM support") from the powerpc tree and commit a5edeccb1a8432ae5d9fb9bccea5a4b64c565017 ("net: OpenFirmware GPIO based MDIO bitbang driver") from the net tree. They are just overlapping additions. I renumbered(?) the "MDIO on GPIOs" section to 'v'. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpbG14XWbhyI.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fixup lwsync at runtime
On Tue, 2008-07-01 at 16:23 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2008-07-01 at 00:32 -0500, Kumar Gala wrote: > > To allow for a single kernel image on e500 v1/v2/mc we need to fixup lwsync > > at runtime. On e500v1/v2 lwsync causes an illop so we need to patch up > > the code. We default to 'sync' since that is always safe and if the cpu > > is capable we will replace 'sync' with 'lwsync'. > > > > We introduce CPU_FTR_LWSYNC as a way to determine at runtime if this is > > needed. This flag could be moved elsewhere since we dont really use it > > for the normal CPU_FTR purpose. > > > > Finally we only store the relative offset in the fixup section to keep it > > as small as possible rather than using a full fixup_entry. > > > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > > I'd rather have some more generic "alternatives" stuff but in the > meantime, Ack. Hrm... minus mpe's comments... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: manual merge of the net tree
Hi Dave, Today's linux-next merge of the net tree got a trivial conflict in drivers/net/fs_enet/fs_enet-main.c between commit 55b6c8e99d582cc66947b465d0ff3147a0219808 ("drivers/net: Use linux/of_ {device,platform}.h instead of asm") from the powerpc tree and commit d8b35fac8c7e1b44d873c1afcc5f88bc5ef4b361 ("fs_enet: MDIO on GPIO support") from the net tree. I fixed it up and can carry the fixup. (The powerpc commit just changed asm/of_platform.h to linux/of_platform.h) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpmwefGEwJPt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix compile warning in init_thread
arch/powerpc/kernel/init_task.c:33: warning: missing braces around initializer arch/powerpc/kernel/init_task.c:33: warning: (near initialization for 'init_task.thread.fpr[0]') Noticed by SFR. Signed-off-by: Michael Neuling <[EMAIL PROTECTED]> --- include/asm-powerpc/processor.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-ozlabs/include/asm-powerpc/processor.h === --- linux-2.6-ozlabs.orig/include/asm-powerpc/processor.h +++ linux-2.6-ozlabs/include/asm-powerpc/processor.h @@ -222,7 +222,7 @@ struct thread_struct { .ksp_limit = INIT_SP_LIMIT, \ .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ .fs = KERNEL_DS, \ - .fpr = {0}, \ + .fpr = {{0}}, \ .fpscr = { .val = 0, }, \ .fpexc_mode = 0, \ } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev