Re: [PATCH 3/3] powerpc/85xx: Cleanup QE initialization for MPC85xxMDS boards
On Wed, Aug 18, 2010 at 02:31:42PM -0500, Timur Tabi wrote: On Tue, Jun 8, 2010 at 2:55 PM, Anton Vorontsov avoront...@mvista.com wrote: The mpc85xx_mds_setup_arch() function is incomprehensible and unmaintainable. Factor out all QE specific stuff into mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys(). Also move QE stuff out of mpc85xx_mds_pic_init(). The diff is unreadable, but only because the code was so. ;-) It should be better now, and less indented. Signed-off-by: Anton Vorontsov avoront...@mvista.com --- This patch introduces breaks mpc85xx_smp_defconfig: CC arch/powerpc/platforms/85xx/mpc85xx_mds.o arch/powerpc/platforms/85xx/mpc85xx_mds.c: In function 'mpc85xx_mds_setup_arch': arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: 'np' undeclared (first use in this function) arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: (Each undeclared identifier is reported only once arch/powerpc/platforms/85xx/mpc85xx_mds.c:367: error: for each function it appears in.) Thanks for the report, apparently I tested my patch without CONFIG_PCI... But the issue should be already fixed by powerpc/85xx: Fix compile error in mpc85xx_mds.c http://patchwork.ozlabs.org/patch/60933/ (Though, not in Linus' tree yet.) Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc8xx microcode patch?
Hi, The kernel supports three microcode patch: USB_SOF_UCODE_PATCH, I2C_SPI_UCODE_PATCH, and I2C_SPI_SMC1_UCODE_PATCH. However from the mpc8xxmc01.zip downloaded from freescale website, there are 4 combinations of microcode (I2C/SPI, SMC/SPI, SMC/I2C, and SMC). Also in the EB662.pdf it's mentioned that SMC relocation patch is applicable to all MPC8xx families and revisions. Surprisingly the SMC only relocation patch cannot be found in the kernel. My processor is MPC870 and I'm not sure what ucode patch I shall apply. What am I missing here? This EB662.pdf was published in Jan. 2006. It's hard to believe that the kernel hasn't incorporate what needs to be done. Thanks, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Thanks, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 64-bit ppc rwsem
On Wed, 2010-08-18 at 22:29 -0700, David Miller wrote: From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu, 19 Aug 2010 15:23:23 +1000 Similar here, but using atomic_long_t instead so it works for 32-bit too for me. I suppose we could make that part common indeed. What about asm-generic/rwsem-atomic.h or rwsem-cmpxchg.h ? Using rwsem-cmpxchg.h sounds best I guess. Ok, I'll send a new patch tomorrow that does that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote: On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote: The timer/alarm stuff is ancillary and is not at all necessary. It is just a nice to have. I will happily remove it, if it is too troubling for people. If there's a compelling argument for it, I'm interested to hear. But again, it seems like just yet-another-way-to-get-alarm/timer-functionality, so before we add an extra API (or widen an existing API) I'd like to understand the need. We don't really need it, IMHO. But if we offer clockid_t CLOCK_PTP, then we get timer_settime() without any extra effort. Makes sense. So in thinking about this, try to focus on what the new clock_id provides that the other existing clockids do not? Are they at comparable levels of abstraction? 15 years from now, are folks likely to still be using it? Will it be maintainable? etc... Arnd convinced me that clockid_t=CLOCK_PTP is a good fit. My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. My plan would be to introduce just one additional syscall: SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Have you considered passing a struct timex instead of ppb and ts? Is using ppb instead of the timex ppm required to get the accuracy you want? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The struct k_clock contains callback functions to clock source specific implementations of the syscalls and other functions. Adding a new clock source that is (potentially) implemented as a module means you have to define a new k_clock in that module that you register using register_posix_clock. If you need additional syscalls to be implemented by the same module, you can put more callback functions into struct k_clock that would then only be implemented by the new module. The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Hmm, right. I wonder what I was thinking of then. You can certainly do config PTP bool IEEE 1588 Precision Time Protocol depends on PPS != m but that will hide the PTP option if PPS is set to 'm', which is normally not what you want. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, Aug 19, 2010 at 02:29:49PM +0200, Arnd Bergmann wrote: On Thursday 19 August 2010, Richard Cochran wrote: On Wed, Aug 18, 2010 at 05:02:03PM +0200, Arnd Bergmann wrote: You might want to use callbacks for these system calls that you can register to at module load time, like it is done for the existing syscalls. Can you point me to a specific example? The struct k_clock contains callback functions to clock source specific implementations of the syscalls and other functions. Adding a new clock source that is (potentially) implemented as a module means you have to define a new k_clock in that module that you register using register_posix_clock. If you need additional syscalls to be implemented by the same module, you can put more callback functions into struct k_clock that would then only be implemented by the new module. The simpler way (e.g. for testing) is using Kconfig dependencies, like config PTP bool IEEE 1588 Precision Time Protocol config PPS tristate Pulse per Second depends on PTP || !PTP The depends statement is a way of expressing that when PTP is enabled, PPS cannot be a module, while it may be a module if PTP is disabled. THis did not work for me. What I got was, in effect, two independent booleans. Hmm, right. I wonder what I was thinking of then. You can certainly do config PTP bool IEEE 1588 Precision Time Protocol depends on PPS != m but that will hide the PTP option if PPS is set to 'm', which is normally not what you want. Arnd, Perhaps you were thinking of the vhost example (taken from drivers/vhost/Kconfig): config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP) EXPERIMENTAL They have a similar construct with both TUN and MACVTAP there. Perhaps the parens are a necessary part of the X || !X syntax? Just a random guess. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote: My point was that a syscall is better than an ioctl based interface here, which I definitely still think. Given that John knows much more about clocks than I do, we still need to get agreement on the question that he raised, which is whether we actually need to expose this clock to the user or not. If we can find a way to sync system time accurate enough with PTP and PPS, user applications may not need to see two separate clocks at all. At the very least, one user application (the PTPd) needs to see the PTP clock. SYSCALL_DEFINE3(clock_adjtime, const clockid_t, clkid, int, ppb, struct timespec __user *, ts) ppb - desired frequency adjustment in parts per billion ts - desired time step (or jump) in sec,nsec to correct a measured offset Arguably, this syscall might be useful for other clocks, too. This is a mix of adjtime and adjtimex with the addition of the clkid parameter, right? Sort of, but not really. ADJTIME(3) takes an offset and slowly corrects the clock using a servo in the kernel, over hours. For this function, the offset passed in the 'ts' parameter will be immediately corrected, by jumping to the new time. This reflects the way that PTP works. After the first few samples, the PTPd has an estimate of the offset to the master and the rate difference. The PTPd can proceed in one of two ways. 1. If resetting the clock is not desired, then the clock is set to the maximum adjustment (in the right direction) until the clock time is close to the master's time. 2. The estimated offset is added to the current time, resulting in a jump in time. We need clock_adjtime(id, 0, ts) for the second case. Have you considered passing a struct timex instead of ppb and ts? Yes, but the timex is not suitable, IMHO. Is using ppb instead of the timex ppm required to get the accuracy you want? That is one very good reason. Another is this: can you explain what the 20+ fields mean? Consider the field, freq. The comment says frequency offset (scaled ppm). To what is it scaled? The only way I know of to find out is to read the NTP code (which is fairly complex) and see what the unit really is meant to be. Ditto for the other fields. The timex structure reveals, AFAICT, the inner workings of the kernel clock servo. For PTP, we don't need or want the kernel servo. The PTPd has its own clock servo in user space. Richard ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
On Thursday 19 August 2010, Ira W. Snyder wrote: Perhaps you were thinking of the vhost example (taken from drivers/vhost/Kconfig): config VHOST_NET tristate Host kernel accelerator for virtio net (EXPERIMENTAL) depends on NET EVENTFD (TUN || !TUN) (MACVTAP || !MACVTAP) EXPERIMENTAL They have a similar construct with both TUN and MACVTAP there. Perhaps the parens are a necessary part of the X || !X syntax? Just a random guess. Yes, that's the one I was thinking of. My mistake was that the effect is slightly different here. VHOST and TUN are both tristate. What we guarantee here is that if TUN is m, VHOST cannot be y, because its dependency cannot be fulfilled for y. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
Hi Darren, On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote: With some instrumentation we were able to determine that the preempt_count() appears to change across the extended_cede_processor() call. Specifically across the plpar_hcall_norets(H_CEDE) call. On PREEMPT_RT we call this with preempt_count=1 and return with preempt_count=0x. On mainline with CONFIG_PREEMPT=y, the value is different (0x65) but is still incorrect. I was trying to reproduce this issue on a 2.6.33.7-rt29 kernel. I could easily reproduce this on the RT kernel and not the non-RT kernel. However, I hit it every single time I did a cpu online operation. I also noticed that the issue persists even when I disable H_CEDE by passing the cede_offline=0 kernel commandline parameter. Could you pl confirm if you observe the same in your setup ? However, the issue still remains. Will spend few cycles looking into this issue. Also of interest is that this path cpu_idle()-cpu_die()-pseries_mach_cpu_die() to start_secondary() enters with a preempt_count=1 if it wasn't corrupted across the hcall. The early boot path from _start however appears to call start_secondary() with a preempt_count of 0. The following patch is most certainly not correct, but it does eliminate the situation on mainline 100% of the time (there is still a 25% reproduction rate on PREEMPT_RT). Can someone comment on: 1) How can the preempt_count() get mangled across the H_CEDE hcall? 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ? Hacked-up-by: Darren Hart dvh...@us.ibm.com Index: linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c === --- linux-2.6.33.6.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -138,6 +138,7 @@ static void pseries_mach_cpu_die(void) * Kernel stack will be reset and start_secondary() * will be called to continue the online operation. */ + preempt_count() = 0; start_secondary_resume(); } } -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
On Thursday 19 August 2010 17:15:37 Andreas Schwab wrote: +SYSCALL(fanotify_init) +COMPAT_SYS(fanotify_mark) why not _SPU? If it doesn't depend on getting signals, SPUs should be able to use it. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
Ankita Garg ank...@in.ibm.com wrote on 08/19/2010 10:58:24 AM: Subject Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries Hi Darren, On Thu, Jul 22, 2010 at 11:24:13AM -0700, Darren Hart wrote: With some instrumentation we were able to determine that the preempt_count() appears to change across the extended_cede_processor() call. Specifically across the plpar_hcall_norets(H_CEDE) call. On PREEMPT_RT we call this with preempt_count=1 and return with preempt_count=0x. On mainline with CONFIG_PREEMPT=y, the value is different (0x65) but is still incorrect. I was trying to reproduce this issue on a 2.6.33.7-rt29 kernel. I could easily reproduce this on the RT kernel and not the non-RT kernel. However, I hit it every single time I did a cpu online operation. I also noticed that the issue persists even when I disable H_CEDE by passing the cede_offline=0 kernel commandline parameter. Could you pl confirm if you observe the same in your setup ? If you see it every time, double-check that you have http://patchwork.ozlabs.org/patch/60922/ or an equivalent in your tree. (The patch moves the preempt_enable_no_resched() call up above a call to cpu_die (). An earlier variation called a preempt_enable before calling start_secondary_resume()). Darren and I have been seeing different problems (different dedicated-processor LPARS on the same physical system). He's seeing scrambled preempt_count values, I'm tending to see a system hang/death [with processor backtraces showing .pseries_mach_cpu_die or .pseries_dedicated_idle_sleep as expected, but no processes running] . I'll be curious which you end up seeing. With 2.6.33.7-rt27 as of a few minutes ago, I'm still seeing a system hang/death. However, the issue still remains. Will spend few cycles looking into this issue. Also of interest is that this path cpu_idle()-cpu_die()-pseries_mach_cpu_die() to start_secondary() enters with a preempt_count=1 if it wasn't corrupted across the hcall. The early boot path from _start however appears to call start_secondary() with a preempt_count of 0. The following patch is most certainly not correct, but it does eliminate the situation on mainline 100% of the time (there is still a 25% reproduction rate on PREEMPT_RT). Can someone comment on: 1) How can the preempt_count() get mangled across the H_CEDE hcall? 2) Should we call preempt_enable() in cpu_idle() prior to cpu_die() ? Hacked-up-by: Darren Hart dvh...@us.ibm.com Index: linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c === --- linux-2.6.33.6.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c +++ linux-2.6.33.6/arch/powerpc/platforms/pseries/hotplug-cpu.c @@ -138,6 +138,7 @@ static void pseries_mach_cpu_die(void) * Kernel stack will be reset and start_secondary() * will be called to continue the online operation. */ + preempt_count() = 0; start_secondary_resume(); } } -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/device: Replace struct of_device with struct of_platform
On Sun, Aug 1, 2010 at 2:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: sound/soc/fsl/mpc8610_hpcd.c | 4 +- This file is/was significantly rewritten for 2.6.37. I posted a fix to the alsa mailing list, but it will conflict with your patch. You might want to remove all changes to sound/soc/fsl from this commit. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p1022: add probing for individual DMA channels, not just DMA controllers
Like the MPC8610 HPCD, the P1022DS ASoC DMA driver probes on individual DMA
channel nodes, so the DMA controller nodes' compatible string must be listed in
p1022_ds_ids[] to work.
Signed-off-by: Timur Tabi ti...@freescale.com
---
This is for -next.
I don't know why I forgot to include this change in the original P1022DS patch.
arch/powerpc/platforms/85xx/p1022_ds.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
b/arch/powerpc/platforms/85xx/p1022_ds.c
index e1467c9..08446fc 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -112,6 +112,8 @@ static struct of_device_id __initdata p1022_ds_ids[] = {
{ .compatible = soc, },
{ .compatible = simple-bus, },
{ .compatible = gianfar, },
+ /* So that the DMA channel nodes can be probed individually: */
+ { .compatible = fsl,eloplus-dma, },
{},
};
--
1.7.0.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/device: Replace struct of_device with struct of_platform
On Thu, Aug 19, 2010 at 2:36 PM, Timur Tabi ti...@freescale.com wrote: On Sun, Aug 1, 2010 at 2:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: sound/soc/fsl/mpc8610_hpcd.c | 4 +- This file is/was significantly rewritten for 2.6.37. I posted a fix to the alsa mailing list, but it will conflict with your patch. You might want to remove all changes to sound/soc/fsl from this commit. This change is already in Linus' tree. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
This is current 2.6.36-rc1+git on 32-bit PowerPC: CC [M] drivers/scsi/qla4xxx/ql4_nx.o drivers/scsi/qla4xxx/ql4_nx.c: In function 'qla4_8xxx_pci_mem_read_direct': drivers/scsi/qla4xxx/ql4_nx.c:717: error: implicit declaration of function 'readq' drivers/scsi/qla4xxx/ql4_nx.c: In function 'qla4_8xxx_pci_mem_write_direct': drivers/scsi/qla4xxx/ql4_nx.c:788: error: implicit declaration of function 'writeq' readq and writeq are defined in io.h but only when compiling for 64-bit kernel. Adding manual #include linux/io.h does not help here. -- Meelis Roos (mr...@linux.ee) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/device: Replace struct of_device with struct of_platform
Grant Likely wrote: On Thu, Aug 19, 2010 at 2:36 PM, Timur Tabi ti...@freescale.com wrote: On Sun, Aug 1, 2010 at 2:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: sound/soc/fsl/mpc8610_hpcd.c |4 +- This file is/was significantly rewritten for 2.6.37. I posted a fix to the alsa mailing list, but it will conflict with your patch. You might want to remove all changes to sound/soc/fsl from this commit. This change is already in Linus' tree. Then I suspect the ALSA guys are going to have a merge conflict coming up, because I had to make these changes to the -next branch. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [powerpc] Wire up fanotify_init, fanotify_mark, prlimit64 syscalls
Arnd Bergmann arndbergm...@googlemail.com writes: On Thursday 19 August 2010 17:15:37 Andreas Schwab wrote: +SYSCALL(fanotify_init) +COMPAT_SYS(fanotify_mark) why not _SPU? See arch/powerpc/platforms/cell/spu_callbacks.c. * 4. They are optional and we can't rely on them being *linked into the kernel. Unfortunately, the cond_syscall *helper does not work here as it does not add the necessary *opd symbols: Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of/device: Replace struct of_device with struct of_platform
On Thu, Aug 19, 2010 at 3:36 PM, Timur Tabi ti...@freescale.com wrote: Grant Likely wrote: On Thu, Aug 19, 2010 at 2:36 PM, Timur Tabi ti...@freescale.com wrote: On Sun, Aug 1, 2010 at 2:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: sound/soc/fsl/mpc8610_hpcd.c | 4 +- This file is/was significantly rewritten for 2.6.37. I posted a fix to the alsa mailing list, but it will conflict with your patch. You might want to remove all changes to sound/soc/fsl from this commit. This change is already in Linus' tree. Then I suspect the ALSA guys are going to have a merge conflict coming up, because I had to make these changes to the -next branch. It is a trivial conflict. They shouldn't have any problem fixing it up. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
cc'ing old list
Hi all, The posting address of this list is linuxppc-...@lists.ozlabs.org. Please do *not* cc linuxppc-...@ozlabs.org (the old posting address) as that just means we get two copies of the mail on the list. Yes, I do know that the kernel MAINTAINERS file has the old address. :-( Thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpdkzGWIxHZP.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2]: Powerpc: Fix EHCA driver on relocatable kernel
Some modules (like eHCA) want to map all of kernel memory, for this to
work with a relocated kernel, we need to export kernstart_addr so
modules can use PHYSICAL_START and memstart_addr so they could use
MEMORY_START. Note that the 32bit code already exports these symbols.
Signed-off-By: Sonny Rao sonny...@us.ibm.com
Index: common/arch/powerpc/mm/init_64.c
===
--- common.orig/arch/powerpc/mm/init_64.c 2010-08-16 02:38:33.0
-0500
+++ common/arch/powerpc/mm/init_64.c2010-08-16 02:39:25.0 -0500
@@ -79,7 +79,9 @@
#endif /* CONFIG_PPC_STD_MMU_64 */
phys_addr_t memstart_addr = ~0;
+EXPORT_SYMBOL(memstart_addr);
phys_addr_t kernstart_addr;
+EXPORT_SYMBOL(kernstart_addr);
void free_initmem(void)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2]: Powerpc: Fix EHCA driver on relocatable kernel
the eHCA driver registers a MR for all of kernel memory, but makes the
assumption that valid memory exists at KERNELBASE. This assumption
may not be true in the case of a relocatable kernel, so use KERNELBASE
+ PHYSICAL_START to get the true beginning of usable kernel memory.
This patch depends on the earlier patch which exports the necessary
symbol for PHYSICAL_START in a relocatable kernel.
cc: Joachim Fenkes fen...@de.ibm.com
cc: Christoph Raisch rai...@de.ibm.com
cc: Hoan-Ham Hguyen hngu...@de.ibm.com
Signed-off-by: Sonny Rao sonny...@us.ibm.com
Index: linux-2.6/drivers/infiniband/hw/ehca/ehca_mrmw.c
===
--- linux-2.6.orig/drivers/infiniband/hw/ehca/ehca_mrmw.c 2010-08-09
22:16:57.688652613 -0500
+++ linux-2.6/drivers/infiniband/hw/ehca/ehca_mrmw.c2010-08-19
22:53:03.451507146 -0500
@@ -171,7 +171,7 @@
}
ret = ehca_reg_maxmr(shca, e_maxmr,
-(void *)ehca_map_vaddr((void *)KERNELBASE),
+(void *)ehca_map_vaddr((void *)(KERNELBASE
+ PHYSICAL_START)),
mr_access_flags, e_pd,
e_maxmr-ib.ib_mr.lkey,
e_maxmr-ib.ib_mr.rkey);
@@ -1636,7 +1636,7 @@
/* register internal max-MR on HCA */
size_maxmr = ehca_mr_len;
- iova_start = (u64 *)ehca_map_vaddr((void *)KERNELBASE);
+ iova_start = (u64 *)ehca_map_vaddr((void *)(KERNELBASE +
PHYSICAL_START));
ib_pbuf.addr = 0;
ib_pbuf.size = size_maxmr;
num_kpages = NUM_CHUNKS(((u64)iova_start % PAGE_SIZE) + size_maxmr,
@@ -2209,7 +2209,7 @@
{
/* a MR is treated as max-MR only if it fits following: */
if ((size == ehca_mr_len)
- (iova_start == (void *)ehca_map_vaddr((void *)KERNELBASE))) {
+ (iova_start == (void *)ehca_map_vaddr((void *)(KERNELBASE +
PHYSICAL_START {
ehca_gen_dbg(this is a max-MR);
return 1;
} else
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Make rwsem use long type
This makes the 64-bit kernel use 64-bit signed integers for the counter
(effectively supporting 32-bit of active count in the semaphore), thus
avoiding things like overflow of the mmap_sem if you use a really crazy
number of threads
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/rwsem.h | 64 ++
1 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/include/asm/rwsem.h b/arch/powerpc/include/asm/rwsem.h
index 24cd928..8447d89 100644
--- a/arch/powerpc/include/asm/rwsem.h
+++ b/arch/powerpc/include/asm/rwsem.h
@@ -21,15 +21,20 @@
/*
* the semaphore definition
*/
-struct rw_semaphore {
- /* XXX this should be able to be an atomic_t -- paulus */
- signed int count;
-#define RWSEM_UNLOCKED_VALUE 0x
-#define RWSEM_ACTIVE_BIAS 0x0001
-#define RWSEM_ACTIVE_MASK 0x
-#define RWSEM_WAITING_BIAS (-0x0001)
+#ifdef CONFIG_PPC64
+# define RWSEM_ACTIVE_MASK 0xL
+#else
+# define RWSEM_ACTIVE_MASK 0xL
+#endif
+
+#define RWSEM_UNLOCKED_VALUE 0xL
+#define RWSEM_ACTIVE_BIAS 0x0001L
+#define RWSEM_WAITING_BIAS (-RWSEM_ACTIVE_MASK-1)
#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
#define RWSEM_ACTIVE_WRITE_BIAS(RWSEM_WAITING_BIAS +
RWSEM_ACTIVE_BIAS)
+
+struct rw_semaphore {
+ longcount;
spinlock_t wait_lock;
struct list_headwait_list;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
@@ -43,9 +48,13 @@ struct rw_semaphore {
# define __RWSEM_DEP_MAP_INIT(lockname)
#endif
-#define __RWSEM_INITIALIZER(name) \
- { RWSEM_UNLOCKED_VALUE, __SPIN_LOCK_UNLOCKED((name).wait_lock), \
- LIST_HEAD_INIT((name).wait_list) __RWSEM_DEP_MAP_INIT(name) }
+#define __RWSEM_INITIALIZER(name) \
+{ \
+ RWSEM_UNLOCKED_VALUE, \
+ __SPIN_LOCK_UNLOCKED((name).wait_lock), \
+ LIST_HEAD_INIT((name).wait_list)\
+ __RWSEM_DEP_MAP_INIT(name) \
+}
#define DECLARE_RWSEM(name)\
struct rw_semaphore name = __RWSEM_INITIALIZER(name)
@@ -70,13 +79,13 @@ extern void __init_rwsem(struct rw_semaphore *sem, const
char *name,
*/
static inline void __down_read(struct rw_semaphore *sem)
{
- if (unlikely(atomic_inc_return((atomic_t *)(sem-count)) = 0))
+ if (unlikely(atomic_long_inc_return((atomic_long_t *)sem-count) = 0))
rwsem_down_read_failed(sem);
}
static inline int __down_read_trylock(struct rw_semaphore *sem)
{
- int tmp;
+ long tmp;
while ((tmp = sem-count) = 0) {
if (tmp == cmpxchg(sem-count, tmp,
@@ -92,10 +101,10 @@ static inline int __down_read_trylock(struct rw_semaphore
*sem)
*/
static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
{
- int tmp;
+ long tmp;
- tmp = atomic_add_return(RWSEM_ACTIVE_WRITE_BIAS,
- (atomic_t *)(sem-count));
+ tmp = atomic_long_add_return(RWSEM_ACTIVE_WRITE_BIAS,
+(atomic_long_t *)sem-count);
if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
rwsem_down_write_failed(sem);
}
@@ -107,7 +116,7 @@ static inline void __down_write(struct rw_semaphore *sem)
static inline int __down_write_trylock(struct rw_semaphore *sem)
{
- int tmp;
+ long tmp;
tmp = cmpxchg(sem-count, RWSEM_UNLOCKED_VALUE,
RWSEM_ACTIVE_WRITE_BIAS);
@@ -119,9 +128,9 @@ static inline int __down_write_trylock(struct rw_semaphore
*sem)
*/
static inline void __up_read(struct rw_semaphore *sem)
{
- int tmp;
+ long tmp;
- tmp = atomic_dec_return((atomic_t *)(sem-count));
+ tmp = atomic_long_dec_return((atomic_long_t *)sem-count);
if (unlikely(tmp -1 (tmp RWSEM_ACTIVE_MASK) == 0))
rwsem_wake(sem);
}
@@ -131,17 +140,17 @@ static inline void __up_read(struct rw_semaphore *sem)
*/
static inline void __up_write(struct rw_semaphore *sem)
{
- if (unlikely(atomic_sub_return(RWSEM_ACTIVE_WRITE_BIAS,
- (atomic_t *)(sem-count)) 0))
+ if (unlikely(atomic_long_sub_return(RWSEM_ACTIVE_WRITE_BIAS,
+(atomic_long_t *)sem-count) 0))
rwsem_wake(sem);
}
/*
* implement atomic add functionality
*/
-static inline void rwsem_atomic_add(int delta, struct rw_semaphore *sem)
+static inline void rwsem_atomic_add(long delta, struct rw_semaphore *sem)
{
- atomic_add(delta, (atomic_t *)(sem-count));
+ atomic_long_add(delta, (atomic_long_t *)sem-count);
}
[PATCH 2/2] rwsem: Move powerpc atomic-long based implementation to asm-generic
Other architectures who support cmpxchg and atomic_long can
use that directly.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/rwsem.h| 184 +--
include/asm-generic/rwsem-cmpxchg.h | 183 ++
2 files changed, 184 insertions(+), 183 deletions(-)
create mode 100644 include/asm-generic/rwsem-cmpxchg.h
diff --git a/arch/powerpc/include/asm/rwsem.h b/arch/powerpc/include/asm/rwsem.h
index 8447d89..1237ad6 100644
--- a/arch/powerpc/include/asm/rwsem.h
+++ b/arch/powerpc/include/asm/rwsem.h
@@ -1,183 +1 @@
-#ifndef _ASM_POWERPC_RWSEM_H
-#define _ASM_POWERPC_RWSEM_H
-
-#ifndef _LINUX_RWSEM_H
-#error Please don't include asm/rwsem.h directly, use linux/rwsem.h
instead.
-#endif
-
-#ifdef __KERNEL__
-
-/*
- * R/W semaphores for PPC using the stuff in lib/rwsem.c.
- * Adapted largely from include/asm-i386/rwsem.h
- * by Paul Mackerras pau...@samba.org.
- */
-
-#include linux/list.h
-#include linux/spinlock.h
-#include asm/atomic.h
-#include asm/system.h
-
-/*
- * the semaphore definition
- */
-#ifdef CONFIG_PPC64
-# define RWSEM_ACTIVE_MASK 0xL
-#else
-# define RWSEM_ACTIVE_MASK 0xL
-#endif
-
-#define RWSEM_UNLOCKED_VALUE 0xL
-#define RWSEM_ACTIVE_BIAS 0x0001L
-#define RWSEM_WAITING_BIAS (-RWSEM_ACTIVE_MASK-1)
-#define RWSEM_ACTIVE_READ_BIAS RWSEM_ACTIVE_BIAS
-#define RWSEM_ACTIVE_WRITE_BIAS(RWSEM_WAITING_BIAS +
RWSEM_ACTIVE_BIAS)
-
-struct rw_semaphore {
- longcount;
- spinlock_t wait_lock;
- struct list_headwait_list;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- struct lockdep_map dep_map;
-#endif
-};
-
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
-# define __RWSEM_DEP_MAP_INIT(lockname) , .dep_map = { .name = #lockname }
-#else
-# define __RWSEM_DEP_MAP_INIT(lockname)
-#endif
-
-#define __RWSEM_INITIALIZER(name) \
-{ \
- RWSEM_UNLOCKED_VALUE, \
- __SPIN_LOCK_UNLOCKED((name).wait_lock), \
- LIST_HEAD_INIT((name).wait_list)\
- __RWSEM_DEP_MAP_INIT(name) \
-}
-
-#define DECLARE_RWSEM(name)\
- struct rw_semaphore name = __RWSEM_INITIALIZER(name)
-
-extern struct rw_semaphore *rwsem_down_read_failed(struct rw_semaphore *sem);
-extern struct rw_semaphore *rwsem_down_write_failed(struct rw_semaphore *sem);
-extern struct rw_semaphore *rwsem_wake(struct rw_semaphore *sem);
-extern struct rw_semaphore *rwsem_downgrade_wake(struct rw_semaphore *sem);
-
-extern void __init_rwsem(struct rw_semaphore *sem, const char *name,
-struct lock_class_key *key);
-
-#define init_rwsem(sem)\
- do {\
- static struct lock_class_key __key; \
- \
- __init_rwsem((sem), #sem, __key); \
- } while (0)
-
-/*
- * lock for reading
- */
-static inline void __down_read(struct rw_semaphore *sem)
-{
- if (unlikely(atomic_long_inc_return((atomic_long_t *)sem-count) = 0))
- rwsem_down_read_failed(sem);
-}
-
-static inline int __down_read_trylock(struct rw_semaphore *sem)
-{
- long tmp;
-
- while ((tmp = sem-count) = 0) {
- if (tmp == cmpxchg(sem-count, tmp,
- tmp + RWSEM_ACTIVE_READ_BIAS)) {
- return 1;
- }
- }
- return 0;
-}
-
-/*
- * lock for writing
- */
-static inline void __down_write_nested(struct rw_semaphore *sem, int subclass)
-{
- long tmp;
-
- tmp = atomic_long_add_return(RWSEM_ACTIVE_WRITE_BIAS,
-(atomic_long_t *)sem-count);
- if (unlikely(tmp != RWSEM_ACTIVE_WRITE_BIAS))
- rwsem_down_write_failed(sem);
-}
-
-static inline void __down_write(struct rw_semaphore *sem)
-{
- __down_write_nested(sem, 0);
-}
-
-static inline int __down_write_trylock(struct rw_semaphore *sem)
-{
- long tmp;
-
- tmp = cmpxchg(sem-count, RWSEM_UNLOCKED_VALUE,
- RWSEM_ACTIVE_WRITE_BIAS);
- return tmp == RWSEM_UNLOCKED_VALUE;
-}
-
-/*
- * unlock after reading
- */
-static inline void __up_read(struct rw_semaphore *sem)
-{
- long tmp;
-
- tmp = atomic_long_dec_return((atomic_long_t *)sem-count);
- if (unlikely(tmp -1 (tmp RWSEM_ACTIVE_MASK) == 0))
- rwsem_wake(sem);
-}
-
-/*
- * unlock after writing
- */
-static inline void __up_write(struct rw_semaphore *sem)
-{
- if (unlikely(atomic_long_sub_return(RWSEM_ACTIVE_WRITE_BIAS,
-(atomic_long_t *)sem-count)
