Re: [PATCH 0/6] 8xx MMU fixes
Rex Feany rfe...@mrv.com wrote on 09/10/2009 02:15:27: Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): So here we go again. This time I am fairly confindent I got most things correct :) Also manged to use even less instructions in the TLB Miss handlers. Scott and Rex, forget previous versions and try this one out. This patch set is better, userspace seems more stable but I am still seeing some odd problems. This is from straceing mount, which displays nothing even though /proc/mounts shows everything mounted properly: open(/proc/mounts, O_RDONLY) = 3 fstat64(0x3, 0x7fe7e2a8)= 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000 read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address) exit_group(0) = ? it looks like the memory allocated using mmap is bad? Try making the tlbil_va in fault.c unconditional, just to make sure there isn't any old TLBs around. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] 8xx: Update TLB asm so it behaves as linux mm expects.
Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 09/10/2009 02:53:31: Subject: Re: [PATCH 2/6] 8xx: Update TLB asm so it behaves as linux mm expects. On Fri, 2009-10-09 at 00:44 +0200, Joakim Tjernlund wrote: accessed == 1 and present = 0 is impossible, right? So basically just copy over accessed to present and linux mm set both when trapping to C. No, when present = 0, then the rest of the PTE can contain unrelated things, you can't trust ACCESSED. Ah, OK. What about the execute perms in Level 2 descriptor, page 247? Not useful, not fine grained enough. You still need to massage the PP bits into place. I don't see that happening. Not at the moment, later. As it is, your PTE contains for bit 20 and 21, which translates to: PTE: Translates to PP bits: RW: 0 USER: 0 00 supervisor RW (ok) RW: 0 USER: 1 01 supervisor RW user RO (WRONG) RW: 1 USER: 0 10 supervisor RW user RW (WRONG) RW: 1 USER: 1 11 supervisor RO user RO (WRONG) You got USER and RW swapped and the table is different for exec. Hrm, let me see... yes. You are right, I mixed RW and USER. However, I don't think the PP bits change do they ? IE. Basically, Read == Exec at the page level. So the table isn't really different between I and D. However, indeed, since you don't have a unified TLB, the case can be made that we can ignore R vs. W in the iTLB case. In which case, you get for iTLB: PTE: Translates to PP bits: RW: 0 USER: 0 00 supervisor X only (ok) RW: 0 USER: 1 10 supervisor X user X (ok) RW: 1 USER: 0 01 supervisor X user X (WRONG) RW: 1 USER: 1 11 supervisor X user X (ok) So a page with _PAGE_RW and not _PAGE_USER would still be executable from user... oops :-) Yes, it is not perfect, but should work for now. I think what you want for iTLB is just basically have a base of 00 and or-in _PAGE_USER only (ie, keep _PAGE_RW clear with a rlwinm) so that you basically get supervisor X only if _PAGE_USER is 0 and both X if _PAGE_USER is 1 For the dTLB, the table becomes (including your inversion of _PAGE_RW) PTE: Translates to PP bits: RW: 0 USER: 0 01 supervisor RW user RO (WRONG) RW: 0 USER: 1 11 supervisor RO user RO (ok) RW: 1 USER: 0 00 supervisor RW only (ok) RW: 1 USER: 1 10 supervisor RW user RW (ok) So it's -almost- right :-) You still got the RW:0 USER:0 case wrong, ie a read-only kernel page would be user readable. Which will be fixed once I activate: #if 0 /* Not yet */ /* Honour kernel RO, User NA */ andi. r11, r10, _PAGE_USER | _PAGE_RW bne-cr0, 5f ori r10,r10, 0x200 /* Extended encoding, bit 22 */ #endif You can work around that by never setting kernel pages read-only (which we do mostly), but in the grand scheme of things, my trick I proposed initially would sort it out all including support for kernel RO :-) Not convinced that your trick will be a win. The other bits will need to move around too. Maybe I misunderstand something? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH/RFC] powerpc: Fix decrementer setup on 1GHz boards
On Fri, 2009-10-09 at 07:28 +0200, Stefan Roese wrote: So how could we solve this issue now? Apply my current patch? Any other suggestions? Well, we probably need your current patch, but I'm not 100% it's enough. We need to check for example that the vDSO code for 32-bit isn't going to go out of bounds neither. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/6] 8xx: Update TLB asm so it behaves as linux mm expects.
On Fri, 2009-10-09 at 08:16 +0200, Joakim Tjernlund wrote: Which will be fixed once I activate: #if 0 /* Not yet */ /* Honour kernel RO, User NA */ andi. r11, r10, _PAGE_USER | _PAGE_RW bne-cr0, 5f ori r10,r10, 0x200 /* Extended encoding, bit 22 */ #endif Which will be more code including a conditional than my proposed trick :-) I'll try to write the asm for you later. Not convinced that your trick will be a win. The other bits will need to move around too. Maybe I misunderstand something? I'll write some code to show you what I have in mind later. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Thu, Oct 8, 2009 at 4:20 PM, Anton Vorontsov avoront...@ru.mvista.com wrote: On Thu, Oct 08, 2009 at 09:48:50AM -0600, Grant Likely wrote: But the focus is still on creating pdata. If a translator gets too big, then sure, split it into a separate file. Until then, there I see no good reason to do so now. Luckily, I'm not at24 driver maintainer (Wolfram himself is ;-), but as a maintainer of driver Foo, I would not want to see completely unfamiliar Bar in my shiny driver. It sounds like your saying that data parsing isn't really the same as driver code, and I don't think that is true. Device data parsing is equally as important as the functional behaviour. A device driver isn't complete unless it does both. Right now most drivers only understand LInux's internal representation (pdata) because that is the only data source they've needed to this point. When new data sources appear (device tree), it is completely appropriate for the driver to be modified to understand the new data format (with all the caveats of coding it in a logical way with translation decoupled from function to keep impact at a bare minimum). To use your example, a driver author who states I only use Bar; so I don't ever want to see Foo code is probably being a bit short sighted with regards to portability. Another plus is that you can bypass (or almost bypass) subsystem maintainers when merging OF-specific patches (since he/she couldn't possibly care less about all these weird arch internals. But again, this doesn't work for this particular driver since Wolfram is the maintainer :-). I don't want OF parsing to bypass subsystem or driver maintainers. :-) I think they should be involved in reviewing and acking translator code. If I wasn't a PPC/OF guy to some degree, I'd hate PPC/OF people for bringing arch-specific details into a generic code... :-P No, this goes beyond PPC/OF. The real issue is that it is no longer a safe assumption that pdata will be a static data structure in platform code. The number of possible data sources is going to get larger, not smaller. OF is just one. UEFI is another. Translating that data into pdata will be the problem that comes up over and over again. However, translation code is still driver specific, so it belongs with the driver that it translates code for. Wait... The translation code depends on a platform, and on a platform_data structure, the same as non-OF arch-specific code depends on it. The translation code depends on the data source. That may be OF. It may be UEFI. It may be another driver (think a PCI driver instantiating a set of child platform devices). It may be a kernel hacker (who hard codes it into the platform code). It has nothing to do with arch/. (and ignore the whole of_platform bus stuff; that was a bad idea from the outset (not that we knew that at the time). I don't intend to port of_platform to other architectures). How is it different from a static platform data in the arch/ code? We don't put static platform data into the drivers and surround them with ugly #ifdefs+machine_is()... Of course we don't put static platform data into the drivers; because static platform data is platform specific, and therefore belongs with the platform. An OF translator is different from a static pdata because it is driver specific code instead of platform specific code. Platform specific code is only applicable for the platform, so of course it belongs with the platform code. Driver specific code belongs with the driver because it isn't applicable to anything else. The whole point of the device tree is that it allows driver specific code to be written that understands the data describing the device instead of having a programmer hard code it. So, in my opinion, translation code must: 1. be *tiny* Yeah, dream on. ;-) It's tiny when all you have is of_get_property(), I'd like to see the code when you'll have GPIOs, IRQs, and platform- specific fixups. It's still pretty tiny, because it still needs to populate a pdata structure. 99% of the time there won't be any platform specific fixups either In the odd case when there *are* platform specific hacks, then of course the pdata should be created by platform code, and not driver code. One way to do this is to have platform code hook into the notifier call chain for a bus and watch for devices it needs to meddle with. When one shows up, register the custom pdata before the driver gets probed. But that is the special case, which doesn't need to impact the common case. You might say that at24 doesn't need that stuff, but it does. Suppose AT24's WP pin is connected to a GPIO, and without 'read-only' property I'd like the driver to pull the pin low, and vice versa: with 'read-only' specifier, WP should be tied high. Or if WP is controlled by a switch/jumper, GPIO can be used to read current WP state. I still don't see a problem. If it can be described in pdata, then a
Re: [RFC PATCH 05/12] of: add common header for flattened device tree representation
On Tue, Oct 06, 2009 at 10:30:59PM -0600, Grant Likely wrote: Add a common header file for working with the flattened device tree data structure and merge the shared data tags used by Microblaze and PowerPC Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- arch/microblaze/include/asm/prom.h | 12 +--- arch/powerpc/include/asm/prom.h| 12 +--- include/linux/of_fdt.h | 30 ++ 3 files changed, 32 insertions(+), 22 deletions(-) create mode 100644 include/linux/of_fdt.h diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h index 64e8b3a..5f461f0 100644 --- a/arch/microblaze/include/asm/prom.h +++ b/arch/microblaze/include/asm/prom.h @@ -17,20 +17,10 @@ #ifndef _ASM_MICROBLAZE_PROM_H #define _ASM_MICROBLAZE_PROM_H #ifdef __KERNEL__ - -/* Definitions used by the flattened device tree */ -#define OF_DT_HEADER 0xd00dfeed /* marker */ -#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */ -#define OF_DT_END_NODE 0x2 /* End node */ -#define OF_DT_PROP 0x3 /* Property: name off, size, content */ -#define OF_DT_NOP0x4 /* nop */ -#define OF_DT_END0x9 - -#define OF_DT_VERSION0x10 So, if you're merging all these, I guess the question is do we also want to merge them with scripts/dtc/libfdt/fdt.h, and by extension with the upstream libfdt header file which defines the same things. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] 8xx MMU fixes
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): Rex Feany rfe...@mrv.com wrote on 09/10/2009 02:15:27: open(/proc/mounts, O_RDONLY) = 3 fstat64(0x3, 0x7fe7e2a8)= 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3001f000 read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address) exit_group(0) = ? Try making the tlbil_va in fault.c unconditional, just to make sure there isn't any old TLBs around. didn't make a difference ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 10/12] of: merge of_*_flat_dt*() functions
On Fri, Oct 9, 2009 at 12:36 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Tue, Oct 06, 2009 at 10:32:02PM -0600, Grant Likely wrote: Merge common flattened device tree code between Microblaze and PowerPC And I guess another question is do we want to replace these with a libfdt based implementation. Perhaps. Let me get things unified and sane first though. 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
Re: [RFC PATCH 05/12] of: add common header for flattened device tree representation
On Fri, Oct 9, 2009 at 12:35 AM, David Gibson da...@gibson.dropbear.id.au wrote: On Tue, Oct 06, 2009 at 10:30:59PM -0600, Grant Likely wrote: Add a common header file for working with the flattened device tree data structure and merge the shared data tags used by Microblaze and PowerPC Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- arch/microblaze/include/asm/prom.h | 12 +--- arch/powerpc/include/asm/prom.h | 12 +--- include/linux/of_fdt.h | 30 ++ 3 files changed, 32 insertions(+), 22 deletions(-) create mode 100644 include/linux/of_fdt.h diff --git a/arch/microblaze/include/asm/prom.h b/arch/microblaze/include/asm/prom.h index 64e8b3a..5f461f0 100644 --- a/arch/microblaze/include/asm/prom.h +++ b/arch/microblaze/include/asm/prom.h @@ -17,20 +17,10 @@ #ifndef _ASM_MICROBLAZE_PROM_H #define _ASM_MICROBLAZE_PROM_H #ifdef __KERNEL__ - -/* Definitions used by the flattened device tree */ -#define OF_DT_HEADER 0xd00dfeed /* marker */ -#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */ -#define OF_DT_END_NODE 0x2 /* End node */ -#define OF_DT_PROP 0x3 /* Property: name off, size, content */ -#define OF_DT_NOP 0x4 /* nop */ -#define OF_DT_END 0x9 - -#define OF_DT_VERSION 0x10 So, if you're merging all these, I guess the question is do we also want to merge them with scripts/dtc/libfdt/fdt.h, and by extension with the upstream libfdt header file which defines the same things. I see your question and raise you another. Where should the merge file live for it to be included both by dtc and kernel code? Or should it just be cloned in the kernel tree? 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
RE: Regression detecting memory size on PPC440EPx
On Mon, 2009-10-05 at 11:49 -0400, Mike Nuss wrote: PS: Is top posting customary on this list? I'm used to bottom posting; let me know if I'm doing it wrong. No you are right but if we were going to have a go at everybody who does top-posting, we would never finish :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/1] powerpc/40x: Add new PPC440EPx based board HCU5 of Netstal Maschinen
Cc: niklaus.gi...@netstal.com, jwbo...@linux.vnet.ibm.com, mpor...@kernel.crashing.org Patch ist against the next branch of git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git This is my second board to go into the kernel after the 40x/HCU4. The HCU5 board is based on the Sequoia board, but has an addition CPLD with various clocking facilities for our HD and two CAN chips. As with the HCU4 I will track the mainline kernel. I use hudson as my continuos integration tool. If I can compile, start the kernel using NFS and login, I report success. Niklaus Giger (1): powerpc/40x: Add new PPC440EPx based board HCU5 of Netstal Maschinen arch/powerpc/boot/dts/hcu5.dts | 254 +++ arch/powerpc/configs/44x/hcu5_defconfig | 1166 +++ arch/powerpc/platforms/44x/Kconfig |9 + arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/hcu5.c | 153 5 files changed, 1583 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/hcu5.dts create mode 100644 arch/powerpc/configs/44x/hcu5_defconfig create mode 100644 arch/powerpc/platforms/44x/hcu5.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc/40x: Add new PPC440EPx based board HCU5 of Netstal Maschinen
Adds support for a HCU5 PPC405EPx based board from Netstal Maschinen AG.
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
arch/powerpc/boot/dts/hcu5.dts | 254 +++
arch/powerpc/configs/44x/hcu5_defconfig | 1166 +++
arch/powerpc/platforms/44x/Kconfig |9 +
arch/powerpc/platforms/44x/Makefile |1 +
arch/powerpc/platforms/44x/hcu5.c | 153
5 files changed, 1583 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/hcu5.dts
create mode 100644 arch/powerpc/configs/44x/hcu5_defconfig
create mode 100644 arch/powerpc/platforms/44x/hcu5.c
diff --git a/arch/powerpc/boot/dts/hcu5.dts b/arch/powerpc/boot/dts/hcu5.dts
new file mode 100644
index 000..abb15f0
--- /dev/null
+++ b/arch/powerpc/boot/dts/hcu5.dts
@@ -0,0 +1,254 @@
+/*
+ * Device Tree Source for the Nestal Maschinen HCU5 board
+ *
+ * Copyright (c) 2008 Niklaus Giger niklaus.gi...@member.fsf.org
+ *
+ * Based on Sequoia code by Josh Boyer jwbo...@linux.vnet.ibm.com
+ * Copyright (c) 2006, 2007 IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = netstal,hcu5;
+ compatible = netstal,hcu5;
+ dcr-parent = {/cpus/c...@0};
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,440EPx;
+ reg = 0x;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x 0x; /* Filled in by
U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440epx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0x0c0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440epx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0x0d0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-440epx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0x0e0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x1c 0x4 0x1d 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440epx, ibm,sdr-440ep;
+ dcr-reg = 0x00e 0x002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440epx, ibm,cpr-440ep;
+ dcr-reg = 0x00c 0x002; /* ngngng ??? */
+ };
+
+ plb {
+ compatible = ibm,plb-440epx, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges;
+ clock-frequency = 0; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = ibm,sdram-440epx,
ibm,sdram-44x-ddr2denali;
+ dcr-reg = 0x010 0x002;
+ };
+
+ DMA0: dma {
+ compatible = ibm,dma-440epx, ibm,dma-4xx;
+ dcr-reg = 0x100 0x027;
+ };
+
+ MAL0: mcmal {
+ compatible = ibm,mcmal-440epx, ibm,mcmal2;
+ dcr-reg = 0x180 0x062;
+ num-tx-chans = 2;
+ num-rx-chans = 2;
+ interrupt-parent = MAL0;
+ interrupts = 0x0 0x1 0x2 0x3 0x4;
+ #interrupt-cells = 1;
+ #address-cells = 0;
+ #size-cells = 0;
+ interrupt-map = /*TXEOB*/ 0x0 UIC0 0xa 0x4
+
[PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
This introduces new bitmap functions:
bitmap_set: Set specified bit area
bitmap_clear: Clear specified bit area
bitmap_find_next_zero_area: Find free bit area
These are stolen from iommu helper.
I changed the return value of bitmap_find_next_zero_area if there is
no zero area.
find_next_zero_area in iommu helper: returns -1
bitmap_find_next_zero_area: return = bitmap size
Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@ozlabs.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Lothar Wassmann l...@karo-electronics.de
Cc: linux-...@vger.kernel.org
Cc: Roland Dreier rola...@cisco.com
Cc: Yevgeny Petrilin yevge...@mellanox.co.il
Cc: net...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
---
include/linux/bitmap.h | 11 +++
lib/bitmap.c | 47 +++
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 756d78b..daf8c48 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -42,6 +42,9 @@
* bitmap_empty(src, nbits)Are all bits zero in *src?
* bitmap_full(src, nbits) Are all bits set in *src?
* bitmap_weight(src, nbits) Hamming Weight: number set bits
+ * bitmap_set(dst, pos, nbits) Set specified bit area
+ * bitmap_clear(dst, pos, nbits) Clear specified bit area
+ * bitmap_find_next_zero_area(buf, len, pos, n, mask) Find bit free area
* bitmap_shift_right(dst, src, n, nbits) *dst = *src n
* bitmap_shift_left(dst, src, n, nbits) *dst = *src n
* bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src)
@@ -108,6 +111,14 @@ extern int __bitmap_subset(const unsigned long *bitmap1,
const unsigned long *bitmap2, int bits);
extern int __bitmap_weight(const unsigned long *bitmap, int bits);
+extern void bitmap_set(unsigned long *map, int i, int len);
+extern void bitmap_clear(unsigned long *map, int start, int nr);
+extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask);
+
extern int bitmap_scnprintf(char *buf, unsigned int len,
const unsigned long *src, int nbits);
extern int __bitmap_parse(const char *buf, unsigned int buflen, int is_user,
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 7025658..95070fa 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -271,6 +271,53 @@ int __bitmap_weight(const unsigned long *bitmap, int bits)
}
EXPORT_SYMBOL(__bitmap_weight);
+void bitmap_set(unsigned long *map, int i, int len)
+{
+ int end = i + len;
+
+ while (i end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
+EXPORT_SYMBOL(bitmap_set);
+
+void bitmap_clear(unsigned long *map, int start, int nr)
+{
+ int end = start + nr;
+
+ while (start end) {
+ __clear_bit(start, map);
+ start++;
+ }
+}
+EXPORT_SYMBOL(bitmap_clear);
+
+unsigned long bitmap_find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
+ end = index + nr;
+ if (end = size)
+ return end;
+ i = find_next_bit(map, end, index);
+ if (i end) {
+ start = i + 1;
+ goto again;
+ }
+ return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area);
+
/*
* Bitmap printing parsing functions: first version by Bill Irwin,
* second version by Paul Jackson, third by Joe Korty.
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/8] iommu-helper: Use bitmap library
Use bitmap library and kill some unused iommu helper functions. Cc: David S. Miller da...@davemloft.net Cc: sparcli...@vger.kernel.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: linuxppc-...@ozlabs.org Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp Signed-off-by: Akinobu Mita akinobu.m...@gmail.com --- arch/powerpc/kernel/iommu.c |4 +- arch/sparc/kernel/iommu.c|3 +- arch/x86/kernel/amd_iommu.c |4 +- arch/x86/kernel/pci-calgary_64.c |6 ++-- arch/x86/kernel/pci-gart_64.c|6 ++-- include/linux/iommu-helper.h |3 -- lib/iommu-helper.c | 55 - 7 files changed, 18 insertions(+), 63 deletions(-) diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index fd51578..5547ae6 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -30,7 +30,7 @@ #include linux/spinlock.h #include linux/string.h #include linux/dma-mapping.h -#include linux/bitops.h +#include linux/bitmap.h #include linux/iommu-helper.h #include linux/crash_dump.h #include asm/io.h @@ -251,7 +251,7 @@ static void __iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, } ppc_md.tce_free(tbl, entry, npages); - iommu_area_free(tbl-it_map, free_entry, npages); + bitmap_clear(tbl-it_map, free_entry, npages); } static void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, diff --git a/arch/sparc/kernel/iommu.c b/arch/sparc/kernel/iommu.c index 7690cc2..5fad949 100644 --- a/arch/sparc/kernel/iommu.c +++ b/arch/sparc/kernel/iommu.c @@ -11,6 +11,7 @@ #include linux/dma-mapping.h #include linux/errno.h #include linux/iommu-helper.h +#include linux/bitmap.h #ifdef CONFIG_PCI #include linux/pci.h @@ -169,7 +170,7 @@ void iommu_range_free(struct iommu *iommu, dma_addr_t dma_addr, unsigned long np entry = (dma_addr - iommu-page_table_map_base) IO_PAGE_SHIFT; - iommu_area_free(arena-map, entry, npages); + bitmap_clear(arena-map, entry, npages); } int iommu_table_init(struct iommu *iommu, int tsbsize, diff --git a/arch/x86/kernel/amd_iommu.c b/arch/x86/kernel/amd_iommu.c index 98f230f..08b1d20 100644 --- a/arch/x86/kernel/amd_iommu.c +++ b/arch/x86/kernel/amd_iommu.c @@ -19,7 +19,7 @@ #include linux/pci.h #include linux/gfp.h -#include linux/bitops.h +#include linux/bitmap.h #include linux/debugfs.h #include linux/scatterlist.h #include linux/dma-mapping.h @@ -959,7 +959,7 @@ static void dma_ops_free_addresses(struct dma_ops_domain *dom, address = (address % APERTURE_RANGE_SIZE) PAGE_SHIFT; - iommu_area_free(range-bitmap, address, pages); + bitmap_clear(range-bitmap, address, pages); } diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c index 971a3be..c87bb20 100644 --- a/arch/x86/kernel/pci-calgary_64.c +++ b/arch/x86/kernel/pci-calgary_64.c @@ -31,7 +31,7 @@ #include linux/string.h #include linux/crash_dump.h #include linux/dma-mapping.h -#include linux/bitops.h +#include linux/bitmap.h #include linux/pci_ids.h #include linux/pci.h #include linux/delay.h @@ -211,7 +211,7 @@ static void iommu_range_reserve(struct iommu_table *tbl, spin_lock_irqsave(tbl-it_lock, flags); - iommu_area_reserve(tbl-it_map, index, npages); + bitmap_set(tbl-it_map, index, npages); spin_unlock_irqrestore(tbl-it_lock, flags); } @@ -305,7 +305,7 @@ static void iommu_free(struct iommu_table *tbl, dma_addr_t dma_addr, spin_lock_irqsave(tbl-it_lock, flags); - iommu_area_free(tbl-it_map, entry, npages); + bitmap_clear(tbl-it_map, entry, npages); spin_unlock_irqrestore(tbl-it_lock, flags); } diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c index 98a827e..3010cd1 100644 --- a/arch/x86/kernel/pci-gart_64.c +++ b/arch/x86/kernel/pci-gart_64.c @@ -22,7 +22,7 @@ #include linux/module.h #include linux/topology.h #include linux/interrupt.h -#include linux/bitops.h +#include linux/bitmap.h #include linux/kdebug.h #include linux/scatterlist.h #include linux/iommu-helper.h @@ -122,7 +122,7 @@ static void free_iommu(unsigned long offset, int size) unsigned long flags; spin_lock_irqsave(iommu_bitmap_lock, flags); - iommu_area_free(iommu_gart_bitmap, offset, size); + bitmap_clear(iommu_gart_bitmap, offset, size); if (offset = next_bit) next_bit = offset + size; spin_unlock_irqrestore(iommu_bitmap_lock, flags); @@ -781,7 +781,7 @@ void __init gart_iommu_init(void) * Out of IOMMU space handling. * Reserve some invalid pages at the beginning of the GART. */ - iommu_area_reserve(iommu_gart_bitmap, 0, EMERGENCY_PAGES); +
[PATCH v4 0/4] pseries: Add cede support for cpu-offline
Hi,
This is version 4 of patch series that provides a framework to choose the
state a pseries CPU must be put to when it is offlined.
Previous versions can be found here:
Version 3: http://lkml.org/lkml/2009/9/15/164
Version 2: http://lkml.org/lkml/2009/8/28/102
Version 1: http://lkml.org/lkml/2009/8/6/236
This patch series differs considerably from the previous iterations in that:
- It is based on top of Nathan Fontenot's
pseries kernel handling of dynamic logical partitioning v2 patches
found here: http://lkml.org/lkml/2009/9/18/173
- It does away with the sysfs tunables available_hotplug_states and
currrent_hotplug_state, thereby refraining from exposing any platform
specific option to the userspace.
- It provides a framework that discovers the support for ceding the vcpu
to the hypervisor with a latency specifier value. When such a support is
present, it would put the offlined CPUs into a ceded state while
setting the cede latency specifier value in the VPA indicating
the latency expectation of the guest OS. Hypervisor may use this for
better energy savings.
- On platforms which don't have support for ceding with a latency specifier
hint, it puts the offlined CPUs into the rtas_stop_self() state.
- Currently, Nathan's patches have provided sysfs interfaces
/sys/devices/system/cpu/{probe, release}
to dynamically allocate and deallocate resources respectively. The current
process of allocating and deallocating CPUs would require two steps,
namely:
- Write to the probe/release file
- Write to the online file.
This patch-series combines these two operations such that when the user
writes to the probe, the CPUs would not only get allocated to the
partition but also onlined. Similarly, when the user writes to release,
the CPUs would be offlined before they are deallocated.
Thus, the user will now have to play with only one set of sysfs tunables
for performing deallocate and the sysfs tunable online can be used for
the purpose of deactivating the CPU while still letting the LPAR own it.
- It provides serializations for handling the writes the the online file
against the writes to probe/release pair so that at any given instant,
the user could either be deallocating the CPUs or deactivating it, but
not both.
With this approach, I hope that the objection regarding the layering
violation that was raised by Peter for previous approaches is
addressed, while also providing clean interfaces for the userspace tools
to distinguish between the deallocation and deactivation without exposing
any platform specific details.
The patchset has been tested on the available pseries platforms and it
works as per the expectations.
Comments are very much appreciated.
---
Gautham R Shenoy (4):
pseries: Serialize cpu hotplug operations during deactivate Vs deallocate
pseries: Add code to online/offline CPUs of a DLPAR node.
pSeries: Add hooks to put the CPU into an appropriate offline state
pSeries: extended_cede_processor() helper function.
arch/powerpc/include/asm/lppaca.h |9 +
arch/powerpc/platforms/pseries/dlpar.c | 129 ++-
arch/powerpc/platforms/pseries/hotplug-cpu.c| 157 ++-
arch/powerpc/platforms/pseries/offline_states.h | 18 +++
arch/powerpc/platforms/pseries/plpar_wrappers.h | 22 +++
arch/powerpc/platforms/pseries/smp.c| 19 +++
arch/powerpc/xmon/xmon.c|3
drivers/base/cpu.c |2
include/linux/cpu.h | 13 ++
9 files changed, 356 insertions(+), 16 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/offline_states.h
--
Thanks and Regards
gautham.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 2/4] pSeries: Add hooks to put the CPU into an appropriate offline state
When a CPU is offlined on POWER currently, we call rtas_stop_self() and hand
the CPU back to the resource pool. This path is used for DLPAR which will
cause a change in the LPAR configuration which will be visible outside.
This patch changes the default state a CPU is put into when it is offlined.
On platforms which support ceding the processor to the hypervisor with
latency hint specifier value, during a cpu offline operation,
instead of calling rtas_stop_self(), we cede the vCPU to the hypervisor
while passing a latency hint specifier value. The Hypervisor can use this hint
to provide better energy savings. Also, during the offline
operation, the control of the vCPU remains with the LPAR as oppposed to
returning it to the resource pool.
The patch achieves this by creating an infrastructure to set the
preferred_offline_state() which can be either
- CPU_STATE_OFFLINE: which is the current behaviour of calling
rtas_stop_self()
- CPU_STATE_INACTIVE: which cedes the vCPU to the hypervisor with the latency
hint specifier.
The codepath which wants to perform a DLPAR operation can set the
preferred_offline_state() of a CPU to CPU_STATE_OFFLINE before invoking
cpu_down().
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
arch/powerpc/platforms/pseries/hotplug-cpu.c| 157 ++-
arch/powerpc/platforms/pseries/offline_states.h | 18 +++
arch/powerpc/platforms/pseries/smp.c| 19 +++
3 files changed, 185 insertions(+), 9 deletions(-)
create mode 100644 arch/powerpc/platforms/pseries/offline_states.h
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index ebff6d9..8a47db4 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -30,6 +30,7 @@
#include asm/pSeries_reconfig.h
#include xics.h
#include plpar_wrappers.h
+#include offline_states.h
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -39,6 +40,37 @@ static struct rtas_args rtas_stop_self_args = {
.rets = rtas_stop_self_args.args[0],
};
+static DEFINE_PER_CPU(enum cpu_state_vals, preferred_offline_state) =
+ CPU_STATE_OFFLINE;
+static DEFINE_PER_CPU(enum cpu_state_vals, current_state) = CPU_STATE_OFFLINE;
+
+static enum cpu_state_vals default_offline_state = CPU_STATE_OFFLINE;
+
+enum cpu_state_vals get_cpu_current_state(int cpu)
+{
+ return per_cpu(current_state, cpu);
+}
+
+void set_cpu_current_state(int cpu, enum cpu_state_vals state)
+{
+ per_cpu(current_state, cpu) = state;
+}
+
+enum cpu_state_vals get_preferred_offline_state(int cpu)
+{
+ return per_cpu(preferred_offline_state, cpu);
+}
+
+void set_preferred_offline_state(int cpu, enum cpu_state_vals state)
+{
+ per_cpu(preferred_offline_state, cpu) = state;
+}
+
+void set_default_offline_state(int cpu)
+{
+ per_cpu(preferred_offline_state, cpu) = default_offline_state;
+}
+
static void rtas_stop_self(void)
{
struct rtas_args *args = rtas_stop_self_args;
@@ -56,11 +88,66 @@ static void rtas_stop_self(void)
static void pseries_mach_cpu_die(void)
{
+ unsigned int cpu = smp_processor_id();
+ unsigned int hwcpu = hard_smp_processor_id();
+ u8 cede_latency_hint = 0;
+
local_irq_disable();
idle_task_exit();
xics_teardown_cpu();
- unregister_slb_shadow(hard_smp_processor_id(), __pa(get_slb_shadow()));
- rtas_stop_self();
+
+ if (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
+ set_cpu_current_state(cpu, CPU_STATE_INACTIVE);
+ cede_latency_hint = 2;
+
+ get_lppaca()-idle = 1;
+ if (!get_lppaca()-shared_proc)
+ get_lppaca()-donate_dedicated_cpu = 1;
+
+ printk(KERN_INFO
+ cpu %u (hwid %u) ceding for offline with hint %d\n,
+ cpu, hwcpu, cede_latency_hint);
+ while (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
+ extended_cede_processor(cede_latency_hint);
+ printk(KERN_INFO cpu %u (hwid %u) returned from
cede.\n,
+ cpu, hwcpu);
+ printk(KERN_INFO
+ Decrementer value = %x Timebase value = %llx\n,
+ get_dec(), get_tb());
+ }
+
+ printk(KERN_INFO cpu %u (hwid %u) got prodded to go online\n,
+ cpu, hwcpu);
+
+ if (!get_lppaca()-shared_proc)
+ get_lppaca()-donate_dedicated_cpu = 0;
+ get_lppaca()-idle = 0;
+ }
+
+ if (get_preferred_offline_state(cpu) == CPU_STATE_ONLINE) {
+ unregister_slb_shadow(hwcpu, __pa(get_slb_shadow()));
+
+
[PATCH v4 3/4] pseries: Add code to online/offline CPUs of a DLPAR node.
Currently the cpu-allocation/deallocation on pSeries is a
two step process from the Userspace.
- Set the indicators and update the device tree by writing to the sysfs
tunable probe during allocation and release during deallocation.
- Online / Offline the CPUs of the allocated/would_be_deallocated node by
writing to the sysfs tunable online.
This patch adds kernel code to online/offline the CPUs soon_after/just_before
they have been allocated/would_be_deallocated. This way, the userspace tool
that performs DLPAR operations would only have to deal with one set of sysfs
tunables namely probe and release.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
---
arch/powerpc/platforms/pseries/dlpar.c | 103
1 files changed, 102 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 84d156b..9752386 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -20,7 +20,7 @@
#include linux/sysdev.h
#include linux/sysfs.h
#include linux/cpu.h
-
+#include offline_states.h
#include asm/prom.h
#include asm/machdep.h
@@ -357,6 +357,98 @@ int remove_device_tree_nodes(struct device_node *dn)
return rc;
}
+int online_node_cpus(struct device_node *dn)
+{
+ int rc = 0;
+ unsigned int cpu;
+ int len, nthreads, i;
+ const u32 *intserv;
+
+ intserv = of_get_property(dn, ibm,ppc-interrupt-server#s, len);
+ if (!intserv)
+ return -EINVAL;
+
+ nthreads = len / sizeof(u32);
+
+ cpu_maps_update_begin();
+ for (i = 0; i nthreads; i++) {
+ for_each_present_cpu(cpu) {
+ if (get_hard_smp_processor_id(cpu) != intserv[i])
+ continue;
+ BUG_ON(get_cpu_current_state(cpu)
+ != CPU_STATE_OFFLINE);
+ cpu_maps_update_done();
+ rc = cpu_up(cpu);
+ if (rc)
+ goto out;
+ cpu_maps_update_begin();
+
+ break;
+ }
+ if (cpu == num_possible_cpus())
+ printk(KERN_WARNING Could not find cpu to online
+ with physical id 0x%x\n, intserv[i]);
+ }
+ cpu_maps_update_done();
+
+out:
+ return rc;
+
+}
+
+int offline_node_cpus(struct device_node *dn)
+{
+ int rc = 0;
+ unsigned int cpu;
+ int len, nthreads, i;
+ const u32 *intserv;
+
+ intserv = of_get_property(dn, ibm,ppc-interrupt-server#s, len);
+ if (!intserv)
+ return -EINVAL;
+
+ nthreads = len / sizeof(u32);
+
+ cpu_maps_update_begin();
+ for (i = 0; i nthreads; i++) {
+ for_each_present_cpu(cpu) {
+ if (get_hard_smp_processor_id(cpu) != intserv[i])
+ continue;
+
+ if (get_cpu_current_state(cpu) == CPU_STATE_OFFLINE)
+ break;
+
+ if (get_cpu_current_state(cpu) == CPU_STATE_ONLINE) {
+ cpu_maps_update_done();
+ rc = cpu_down(cpu);
+ if (rc)
+ goto out;
+ cpu_maps_update_begin();
+ break;
+
+ }
+
+ /*
+* The cpu is in CPU_STATE_INACTIVE.
+* Upgrade it's state to CPU_STATE_OFFLINE.
+*/
+ set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
+ BUG_ON(plpar_hcall_norets(H_PROD, intserv[i])
+ != H_SUCCESS);
+ __cpu_die(cpu);
+ break;
+ }
+ if (cpu == num_possible_cpus())
+ printk(KERN_WARNING Could not find cpu to offline
+ with physical id 0x%x\n, intserv[i]);
+ }
+ cpu_maps_update_done();
+
+out:
+ return rc;
+
+}
+
#define DR_ENTITY_SENSE9003
#define DR_ENTITY_PRESENT 1
#define DR_ENTITY_UNUSABLE 2
@@ -591,6 +683,8 @@ static ssize_t cpu_probe_store(struct class *class, const
char *buf,
if (rc)
release_drc(drc_index);
+ rc = online_node_cpus(dn);
+
return rc ? rc : count;
}
@@ -611,6 +705,11 @@ static ssize_t cpu_release_store(struct class *class,
const char *buf,
return -EINVAL;
}
+ rc = offline_node_cpus(dn);
+
+ if (rc)
+ goto out;
+
rc = release_drc(*drc_index);
if (rc) {
[PATCH v4 4/4] pseries: Serialize cpu hotplug operations during deactivate Vs deallocate
Currently the cpu-allocation/deallocation process comprises of two steps:
- Set the indicators and to update the device tree with DLPAR node
information.
- Online/offline the allocated/deallocated CPU.
This is achieved by writing to the sysfs tunables probe during allocation
and release during deallocation.
At the sametime, the userspace can independently online/offline the CPUs of
the system using the sysfs tunable online.
It is quite possible that when a userspace tool offlines a CPU
for the purpose of deallocation and is in the process of updating the device
tree, some other userspace tool could bring the CPU back online by writing to
the online sysfs tunable thereby causing the deallocate process to fail.
The solution to this is to serialize writes to the probe/release sysfs
tunable with the writes to the online sysfs tunable.
This patch employs a mutex to provide this serialization, which is a no-op on
all architectures except PPC_PSERIES
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/platforms/pseries/dlpar.c | 26 ++
drivers/base/cpu.c |2 ++
include/linux/cpu.h| 13 +
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 9752386..fc261e6 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -644,6 +644,18 @@ static ssize_t memory_release_store(struct class *class,
const char *buf,
return rc ? -1 : count;
}
+static DEFINE_MUTEX(pseries_cpu_hotplug_mutex);
+
+void cpu_hotplug_driver_lock()
+{
+ mutex_lock(pseries_cpu_hotplug_mutex);
+}
+
+void cpu_hotplug_driver_unlock()
+{
+ mutex_unlock(pseries_cpu_hotplug_mutex);
+}
+
static ssize_t cpu_probe_store(struct class *class, const char *buf,
size_t count)
{
@@ -656,14 +668,15 @@ static ssize_t cpu_probe_store(struct class *class, const
char *buf,
if (rc)
return -EINVAL;
+ cpu_hotplug_driver_lock();
rc = acquire_drc(drc_index);
if (rc)
- return rc;
+ goto out;
dn = configure_connector(drc_index);
if (!dn) {
release_drc(drc_index);
- return rc;
+ goto out;
}
/* fixup dn name */
@@ -672,7 +685,8 @@ static ssize_t cpu_probe_store(struct class *class, const
char *buf,
if (!cpu_name) {
free_cc_nodes(dn);
release_drc(drc_index);
- return -ENOMEM;
+ rc = -ENOMEM;
+ goto out;
}
sprintf(cpu_name, /cpus/%s, dn-full_name);
@@ -684,6 +698,8 @@ static ssize_t cpu_probe_store(struct class *class, const
char *buf,
release_drc(drc_index);
rc = online_node_cpus(dn);
+out:
+ cpu_hotplug_driver_unlock();
return rc ? rc : count;
}
@@ -705,6 +721,7 @@ static ssize_t cpu_release_store(struct class *class, const
char *buf,
return -EINVAL;
}
+ cpu_hotplug_driver_lock();
rc = offline_node_cpus(dn);
if (rc)
@@ -713,7 +730,7 @@ static ssize_t cpu_release_store(struct class *class, const
char *buf,
rc = release_drc(*drc_index);
if (rc) {
of_node_put(dn);
- return rc;
+ goto out;
}
rc = remove_device_tree_nodes(dn);
@@ -723,6 +740,7 @@ static ssize_t cpu_release_store(struct class *class, const
char *buf,
of_node_put(dn);
out:
+ cpu_hotplug_driver_unlock();
return rc ? rc : count;
}
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index e62a4cc..07c3f05 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -35,6 +35,7 @@ static ssize_t __ref store_online(struct sys_device *dev,
struct sysdev_attribut
struct cpu *cpu = container_of(dev, struct cpu, sysdev);
ssize_t ret;
+ cpu_hotplug_driver_lock();
switch (buf[0]) {
case '0':
ret = cpu_down(cpu-sysdev.id);
@@ -49,6 +50,7 @@ static ssize_t __ref store_online(struct sys_device *dev,
struct sysdev_attribut
default:
ret = -EINVAL;
}
+ cpu_hotplug_driver_unlock();
if (ret = 0)
ret = count;
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 4753619..b0ad4e1 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -115,6 +115,19 @@ extern void put_online_cpus(void);
#define unregister_hotcpu_notifier(nb) unregister_cpu_notifier(nb)
int cpu_down(unsigned int cpu);
+#ifdef CONFIG_PPC_PSERIES
+extern void cpu_hotplug_driver_lock(void);
+extern void cpu_hotplug_driver_unlock(void);
+#else
+static inline void cpu_hotplug_driver_lock(void)
+{
+}
+
+static inline void cpu_hotplug_driver_unlock(void)
+{
+}
+#endif
+
#else /*
Re: [v8 PATCH 2/8]: cpuidle: implement a list based approach to register a set of idle routines.
* Peter Zijlstra a.p.zijls...@chello.nl [2009-10-08 14:25:37]: On Thu, 2009-10-08 at 17:31 +0530, Arun R Bharadwaj wrote: Uhm, no, it would mean ACPI putting its idle routines on the same level as all others. Putting them all on the same level would mean, we need an enable/disable routine to enable only the currently active routines. What's this enable/disable stuff about? Also, the way governor works is that, it assumes that idle routines are indexed in the increasing order of power benefit that can be got out of the state. So this would get messed up. Right, which is why I initially had a power-savings field in my proposal, so it could weight the power savings vs the wakeup latency. http://lkml.org/lkml/2009/8/27/159 There it was said that was exactly what these governors were doing, seems its not. Sounds like something is wrong alright. If you can register an idle routine you should be able to unregister it too. Yes, we can register and unregister in a clean way now. Consider this. We have a set of routines A, B, C currently registered. Now a module comes and registers D and E, and later on at some point of time wants to unregister. So how do you keep track of what all idle routines the module registered and unregister only those? Best way to do that is a stack, which is how I have currently implemented. Right, so destroy that inner set thing, that way we only have one left ;-) I'm not convinced with your argument. Why dont we do this incrementally. Right now, this set of sets mechanism works fine and doesn't look like it has any obvious flaws in it. We have a clean register/unregister mechanism which solves all the earlier problems we started out to solve. We can gradually build on this and try to come up with a single set of idle states for a governor to choose from. thanks, arun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux booting fails on ppc440x5 with SRAM
We ported the uboot Memory test and tested the 15MB ram and it was successful.interestingly we have only 16MB SRAM in our board.We used 1 MB of RAM for the bootloader to execute and tested the other 15 MB. i couldnt see any reason why the DEAR, MSR value become identical. checked the objcopy of my linux image and the instruction on that particular location was an ordinary branch instruction. ! On Fri, Oct 2, 2009 at 10:47 PM, Johnny Hung johnny.hack...@gmail.com wrote: It's seems a RAM initialize problem. Try to use ICE or your bootloader to test initialized RAM wirh write/read operation. Ex, use mtest in uboot to check memory. For ICE, it should be an detailed memory test function like hardware diagnostic. 2009/9/24 Benjamin Herrenschmidt b...@kernel.crashing.org: On Wed, 2009-09-23 at 20:19 +0530, Vineeth _ wrote: I am trying to port linux on IBM powerpc-440x5. I have this board which has this processor, a 16MB SRAM sits on location 0x0, uart and a flash.I have a simple bootloader which does the following. 1. Initialize the processor (as part of it, we Generates the tlbs for UART,16MB flash,16MB SRAM) 2. Initialize the UART 3. Copy the simple-boot linux_image (binary file) from flash to 0x40 location of SRAM. 4. Kernel entry to 0x40 Not sure yet, looks like things are being overwritten during boot. Interestingly enough, the DEAR value looks like an MSR value.. Hard to tell what's up. You'll have to dig a bit more youself to figure out how come the kernel's getting that bad pointer. All I can tell you is that things work fine on 440x5 cores, though I haven't tested a configuration with so little memory in a while. Ben. zImage starting: loaded at 0x0040 (sp: 0x004deeb0) Allocating 0x1dad84 bytes for kernel ... gunzipping (0x - 0x0040c000:0x004dd3f1)...done 0x1c31cc bytes Linux/PowerPC load: console=ttyS0 root=/dev/ram Finalizing device tree... flat tree at 0x4eb300 id mach(): done inside skybeam_register_console function MMU:enterMMU:hw initMMU:mapinMMU:setioMMU:exitinside _setup_arch-begininginside _setup_arch-1inside _setup_arch-2setup_arch: bootmemarch: exit7Top of RAM: 0x100, Total RAM: 0x100 Zone PFN ranges: DMA 0x - 0x1000 Normal 0x1000 - 0x1000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x1000 MMU: Allocated 1088 bytes of context maps for 255 contexts Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: console=ttyS0 root=/dev/ram Unable to handle kernel paging request for data at address 0x00021000 Faulting instruction address: 0xc010a7c4 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT PowerPC 44x Platform Modules linked in: NIP: c010a7c4 LR: c010dc50 CTR: REGS: c01bfeb0 TRAP: 0300 Not tainted (2.6.30) MSR: 00021000 ME,CE CR: 2444 XER: DEAR: 00021000, ESR: TASK = c01a94b8[0] 'swapper' THREAD: c01be000 GPR00: 1180 c01bff60 c01a94b8 00021000 0025 0008 c0104968 GPR08: 2f72616d c011 c0155938 c01a 2224 f104 GPR16: fff8 08b8 c010d758 c0104968 GPR24: 1198 1190 c018a001 c01c5498 08c0 1188 00021000 c01c42f0 NIP [c010a7c4] strchr+0x0/0x3c LR [c010dc50] match_token+0x138/0x228 Call Trace: [c01bff60] [c016b99c] 0xc016b99c (unreliable) [c01bffa0] [c0104a00] sort_extable+0x28/0x38 [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30 [c01bffc0] [c018c734] start_kernel+0x140/0x288 [c01bfff0] [c200] skpinv+0x190/0x1cc Instruction dump: 7ca903a6 8804 38a5 38840001 2f80 9809 39290001 419e0010 4200ffe4 98a9 4e800020 4e800020 8803 5484063e 7f802000 4d9e0020 ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Call Trace: [c01bfd90] [c0005d5c] show_stack+0x4c/0x16c (unreliable) [c01bfdd0] [c002f17c] panic+0xa0/0x168 [c01bfe20] [c0032eb8] do_exit+0x61c/0x638 [c01bfe60] [c000b60c] kernel_bad_stack+0x0/0x4c [c01bfe90] [c000f310] bad_page_fault+0x90/0xd8 [c01bfea0] [c000e184] handle_page_fault+0x7c/0x80 [c01bff60] [c016b99c] 0xc016b99c [c01bffa0] [c0104a00] sort_extable+0x28/0x38 [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30 [c01bffc0] [c018c734] start_kernel+0x140/0x288 [c01bfff0] [c200] skpinv+0x190/0x1cc Rebooting in 180 seconds.. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC] scripts/get_maintainer: add emails based on keywords in the patch
Make get_maintainer.pl scan the modifying lines of a patch for a list of
keywords and add an associated email if found. The first user is the
devicetree-discuss mailing list which should always be cc'ed if a device tree
property is inserted/removed (keyword 'of_get_property'). This patch is the
result from commit 1965d30356c1c65660ba3330927671cfe81acdd5 entering mainline
which seems to have been missed by all parties interested in the device tree
(and at least had the documentation missing). As adding properties can happen
anywhere and so there is no fitting fileglob, this keyword based approach is
proposed.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Joe Perches j...@perches.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Anton Vorontsov avoront...@ru.mvista.com
---
scripts/get_maintainer.pl | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index cdb44b6..e1150ea 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -44,6 +44,11 @@ my $help = 0;
my $exit = 0;
+my %keywords_to_mail = (
+ 'of_get_property' = 'L: devicetree-disc...@lists.ozlabs.org',
+);
+my $keywords_to_mail_match = join('|', keys %keywords_to_mail);
+
my @penguin_chief = ();
push(@penguin_chief,Linus Torvalds:torval...@linux-foundation.org);
#Andrew wants in on most everything - 2009/01/14
@@ -188,6 +193,12 @@ if ($email_remove_duplicates) {
my @files = ();
my @range = ();
+my @email_to = ();
+my @list_to = ();
+my @scm = ();
+my @web = ();
+my @subsystem = ();
+my @status = ();
foreach my $file (@ARGV) {
##if $file is a directory and it lacks a trailing slash, add one
@@ -213,7 +224,11 @@ foreach my $file (@ARGV) {
if ($email_git_blame) {
push(@range, $lastfile:$1:$2);
}
- }
+ # Check the lines which a patch modifies for keywords; add mail if
found.
+ } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
+ (my $keyword_mail = $keywords_to_mail{$1}) =~ s/^([LM]): //;
+ push( @{ ($1 eq 'L') ? \...@list_to : \...@email_to },
$keyword_mail );
+ }
}
close(PATCH);
if ($file_cnt == @files) {
@@ -224,13 +239,6 @@ foreach my $file (@ARGV) {
}
}
-my @email_to = ();
-my @list_to = ();
-my @scm = ();
-my @web = ();
-my @subsystem = ();
-my @status = ();
-
# Find responsible parties
foreach my $file (@files) {
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] 8xx MMU fixes
Rex Feany rfe...@mrv.com wrote on 09/10/2009 08:46:49: Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): Rex Feany rfe...@mrv.com wrote on 09/10/2009 02:15:27: open(/proc/mounts, O_RDONLY) = 3 fstat64(0x3, 0x7fe7e2a8)= 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =0x3001f000 read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address) exit_group(0) = ? Try making the tlbil_va in fault.c unconditional, just to make sure there isn't any old TLBs around. didn't make a difference OK, so how about: diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 6541855..f4b5dca 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -339,9 +339,9 @@ InstructionTLBMiss: mfspr r11, SPRN_MD_TWC/* and get the pte address */ lwz r10, 0(r11) /* Get the pte */ - /* r10=(r10~_PAGE_PRESENT)|((r10_PAGE_ACCESSED)5) */ - rlwimi. r10, r10, 27, 31, 31 - beq-cr0, 2f /* Can be removed, costs a ITLB Err */ + andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT + cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT + bne-cr0, 2f #if 0 /* Dont' bother with PP lsb, bit 21 for now */ /* r10 = (r10 ~0x0400) | ((r10 _PAGE_EXEC) 7) */ @@ -429,9 +429,11 @@ DataStoreTLBMiss: /* Need to know if load/store - force a TLB Error * by copying ACCESSED to PRESENT. */ - /* r10=(r10~_PAGE_PRESENT)|((r10_PAGE_ACCESSED)5) */ - rlwimi r10, r10, 27, 31, 31 - + andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT + cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT + beq+cr0, 6f + rlwinm r10, r10, 0, 0, 30 /* Clear _PAGE_PRESENT */ +6: #if 0 /* Not yet */ /* Honour kernel RO, User NA */ andi. r11, r10, _PAGE_USER | _PAGE_RW @@ -492,7 +494,7 @@ DataTLBError: cmpwi cr0, r10, 0x00f0 beq-FixDAR /* must be a buggy dcbX, icbi insn. */ DARFix:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */ - + b 2f /* Do DIRTY in C */ mfspr r11, SPRN_DSISR andis. r11, r11, 0x4800/* !translation or protection */ bne 2f /* branch if either is set */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
On Fri, Oct 02, 2009 at 01:44:58PM -0500, Robert Jennings wrote:
Memory balloon drivers can allocate a large amount of memory which
is not movable but could be freed to accomodate memory hotplug remove.
Prior to calling the memory hotplug notifier chain the memory in the
pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
isolation will not proceed, causing the memory removal for that page
range to fail.
Rather than failing pageblock isolation if the the migrateteype is not
s/the the migrateteype/the migratetype/
MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
are owned by a registered balloon driver (or other entity) using a
notifier chain. If all of the non-movable pages are owned by a balloon,
they can be freed later through the memory notifier chain and the range
can still be isolated in set_migratetype_isolate().
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
---
drivers/base/memory.c | 19 +++
include/linux/memory.h | 26 ++
mm/page_alloc.c| 45 ++---
3 files changed, 83 insertions(+), 7 deletions(-)
Index: b/drivers/base/memory.c
===
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
}
EXPORT_SYMBOL(unregister_memory_notifier);
+static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
+
+int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(register_memory_isolate_notifier);
+
+void unregister_memory_isolate_notifier(struct notifier_block *nb)
+{
+ blocking_notifier_chain_unregister(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
return blocking_notifier_call_chain(memory_chain, val, v);
}
+int memory_isolate_notify(unsigned long val, void *v)
+{
+ return blocking_notifier_call_chain(memory_isolate_chain, val, v);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
Index: b/include/linux/memory.h
===
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -50,6 +50,18 @@ struct memory_notify {
int status_change_nid;
};
+/*
+ * During pageblock isolation, count the number of pages in the
+ * range [start_pfn, start_pfn + nr_pages)
+ */
The comment could have been slightly better. The count of pages in the
range is nr_pages - memory_holes but what you're counting is the number
of pages owned by the balloon driver in the notification chain.
+#define MEM_ISOLATE_COUNT(10)
+
+struct memory_isolate_notify {
+ unsigned long start_pfn;
+ unsigned int nr_pages;
+ unsigned int pages_found;
+};
+
struct notifier_block;
struct mem_section;
@@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
{
return 0;
}
+static inline int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+static inline void unregister_memory_isolate_notifier(struct notifier_block
*nb)
+{
+}
+static inline int memory_isolate_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
+extern int register_memory_isolate_notifier(struct notifier_block *nb);
+extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
extern int register_new_memory(int, struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
extern int memory_notify(unsigned long val, void *v);
+extern int memory_isolate_notify(unsigned long val, void *v);
extern struct memory_block *find_memory_block(struct mem_section *);
#define CONFIG_MEM_BLOCK_SIZE(PAGES_PER_SECTIONPAGE_SHIFT)
enum mem_add_context { BOOT, HOTPLUG };
Index: b/mm/page_alloc.c
===
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -48,6 +48,7 @@
#include linux/page_cgroup.h
#include linux/debugobjects.h
#include linux/kmemleak.h
+#include linux/memory.h
#include trace/events/kmem.h
#include asm/tlbflush.h
@@ -4985,23 +4986,53 @@ void set_pageblock_flags_group(struct pa
int set_migratetype_isolate(struct page *page)
{
struct zone *zone;
- unsigned long flags;
+ unsigned long flags, pfn, iter;
+ unsigned
Re: [RFC] scripts/get_maintainer: add emails based on keywords in the patch
On Fri, 2009-10-09 at 12:32 +0200, Wolfram Sang wrote:
+my %keywords_to_mail = (
+ 'of_get_property' = 'L: devicetree-disc...@lists.ozlabs.org',
maybe: '\bof_get_property\b'
+ # Check the lines which a patch modifies for keywords; add mail if
found.
+ } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
+ (my $keyword_mail = $keywords_to_mail{$1}) =~ s/^([LM]): //;
+ push( @{ ($1 eq 'L') ? \...@list_to : \...@email_to },
$keyword_mail );
+}
If this facility is desired by many others, it might be
better to have a separate file of 'regex generates email'
read at initialization.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux booting fails on ppc440x5 with SRAM
Dear Vineeth _, In message a9b543570910090320t1444f8f1qf4c8ab7dbbef6...@mail.gmail.com you wrote: We ported the uboot Memory test and tested the 15MB ram and it was successful.interestingly we have only 16MB SRAM in our board.We used 1 Such a memory test means nothing. The only thing you can learn from it is that basic read and write accesses are working. You don;t get any information about the behaviour for burst mode accesses from such a test. See the FAQ at http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly and at http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/4xx: Add 16K FIFO size DTS entries on supported platforms
On Fri, Oct 09, 2009 at 01:15:54PM +1100, Benjamin Herrenschmidt wrote: On Thu, 2009-10-08 at 11:33 -0500, Dave Mitchell wrote: Adding tx/rx-fifo-size-gige to EMAC fields for evaluation kit DTS files where appropriate. Signed-off-by: Dave Mitchell dmitch...@appliedmicro.com Acked-by: Prodyut Hazarika phazar...@appliedmicro.com Acked-by: Victor Gallardo vgalla...@appliedmicro.com Acked-by: Loc Ho l...@appliedmicro.com --- v1-v2: local date/time was out-of-sync and thus mail was as well I'll have to wait for the EMAC patch to go in, so ping me if you don't see me take that one after that happens. I have some other DTS changes I'll be making soon. Mind if I pick it up in my tree to avoid headaches? I will, of course, wait until the EMAC patch is merged. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RESEND][PATCH]Ftrace - fix function_graph tracer OOPS
This time sending the patch as inline and not as an attachment. Enabling function graph causes oops due to usage of LOAD_REG_IMMEDIATE(). As explained by Ben the usage of LOAD_REG_IMMEDIATE generates relocs that are not supported when CONFIG_RELOCATABLE is set. Switch to LOAD_REG_ADDR(). Signed-off-by : Sachin Sant sach...@in.ibm.com --- diff -Naurp old/arch/powerpc/kernel/entry_64.S new/arch/powerpc/kernel/entry_64.S --- old/arch/powerpc/kernel/entry_64.S 2009-10-08 18:37:44.0 +0530 +++ new/arch/powerpc/kernel/entry_64.S 2009-10-08 18:34:33.0 +0530 @@ -1038,8 +1038,8 @@ _GLOBAL(mod_return_to_handler) * We are in a module using the module's TOC. * Switch to our TOC to run inside the core kernel. */ - LOAD_REG_IMMEDIATE(r4,ftrace_return_to_handler) - ld r2, 8(r4) + ld r2, PACATOC(r13) + LOAD_REG_ADDR(r4,ftrace_return_to_handler) bl .ftrace_return_to_handler nop ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/6] 8xx MMU fixes
Rex Feany rfe...@mrv.com wrote on 09/10/2009 08:46:49: Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): Rex Feany rfe...@mrv.com wrote on 09/10/2009 02:15:27: open(/proc/mounts, O_RDONLY) = 3 fstat64(0x3, 0x7fe7e2a8)= 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =0x3001f000 read(3, 0x3001f000, 1024) = -1 EFAULT (Bad address) exit_group(0) = ? Try making the tlbil_va in fault.c unconditional, just to make sure there isn't any old TLBs around. didn't make a difference Perhaps you are suffering from a buggy dcbst insn? I tested it on a RO mapping and it SEGVs. Clearing the store bit manually at least fixes the SEGVs. Here is a patch for that. Jocke From 07dbca0cf9dc13cf0fbccf54d577e3bc1c5dfdf1 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund joakim.tjernl...@transmode.se Date: Fri, 9 Oct 2009 14:18:21 +0200 Subject: [PATCH] 8xx: dcbst sets store bit in DTLB error, workaround. dcbst should not set the store bit(bit 6, DSISR) when trapping into a DTLB Error. Clear this bit while doing the dcbX missing DAR workaround. --- arch/powerpc/kernel/head_8xx.S | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 292bd87..7b31feb 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -630,6 +630,30 @@ FixDAR:/* Entry point for dcbx workaround. */ tophys (r11, r10) beq-139b/* Branch if user space address */ 140: lwz r11,0(r11) +/* Check if it really is a dcbx instruction. */ +/* dcbt and dcbtst does not generate DTLB Misses/Errors, + * no need to include them here */ + srwir10, r11, 26/* check if major OP code is 31 */ + cmpwi cr0, r10, 31 + bne-141f + rlwinm r10, r11, 0, 21, 30 + cmpwi cr0, r10, 2028 /* Is dcbz? */ + beq+142f + cmpwi cr0, r10, 940 /* Is dcbi? */ + beq+142f + cmpwi cr0, r10, 108 /* Is dcbst? */ + beq+144f/* Fix up store bit! */ + cmpwi cr0, r10, 172 /* Is dcbf? */ + beq+142f + cmpwi cr0, r10, 1964 /* Is icbi? */ + beq+142f +141: mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */ + b DARfix /* Nope, go back to normal TLB processing */ + +144: mfspr r10, SPRN_DSISR + rlwinm r10, r10,0,7,5 /* Clear store bit for buggy dcbst insn */ + mtspr SPRN_DSISR, r10 +142: /* continue, it was a dcbx, dcbi instruction. */ #ifdef CONFIG_8xx_CPU6 lwz r3, 8(r0) /* restore r3 from memory */ #endif -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc_md.SMI replacement for 2.6
On Friday 09 October 2009, Donald Kayser wrote:
On further comparison, this section of code has been added by the
vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
anyone would like to lend a thought towards System Managment
Exceptions on PPC, please cc me at li...@kayser.net. I will be
stopping the subscription to this list shortly. Regards, Donald
Hi Donald,
You should ask ppc specific questions on the linuxppc-...@ozlabs.org
mailing list instead of the global linux-kernel list to increase the
chances of someone reading it who knows the answer.
The world of powerpc linux has changed a lot since 2.4, as you
undoubtedly found out. You are certainly encouraged to submit
your platform code for inclusion in the mainline kernel (if you
can do the usual cleanups necessary to do that), even for
old code.
I don't know a specific reason why the SMI callback was removed,
but I would guess that if you have a platform that requires it
and want it in the mainline kernel, a callback for it can be
added back, either through ppc_md or some other method.
Arnd
On Oct 8, 2009, at 8:37 AM, Donald Kayser wrote:
I have found the differences between the 2.4 and 2.6 kernel. It is
in linux-2.4/arch/ppc/kernel/traps.c and linux-2.6/arch/powerpc/
kernel/traps.c in the function SMIException(). There is no longer
the code segment
if (ppc_md.SMI)
{
ppc_md.SMI(regs);
return;
}
There is now only a
die(System Management Interrupt, regs, SIGABRT);
I am guessing that the SMI callback is no longer needed by the linux
community at large, so I modified the code for my specific hardware
(HPPB) and acknowledged the exception as in the 2.4 kernel, and
returned from the exception without the call to die(). My problem
now is that it doesn't seem to work. Does anyone have a reason why
the SMI exception might hang the system when it has been provided a
handler?
Thanks in advance.
Donald Kayser
On Oct 7, 2009, at 10:06 AM, Donald Kayser wrote:
I have ported the 2.6 kernel to an embedded PPC target (old stuff).
I have managed to figure everything out, but can't find any
replacement for a SMI handler. The original 2.4 version for this
target has a bit of code ppc_md.SMI == SmiFuncHandler; I have not
been able to find in the current source anything like this. I am
not certain that I need to provide a handler at all, but the
original developers saw some reason for including it. The
particular handler does not do anything more than cancel a watchdog
listener for this specific target. I have been living without the
handler, but would like to find any kind of replacement if it is
supported.
Thanks,
Donald Kayser
li...@kayser.net
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
For your future reference, patches that look at the device tree should
also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can
be reviewed and common mistakes can be avoided. It is expected that
new device tree bindings are accompanied with documentation describing
what the binding is for and how it should be used (see
Documentation/powerpc/dts-bindings).
I know this change is already in mainline, but can you please post the
device tree fragment that you're using to describe this chip? I want
to make sure we don't get stuck with things in the kernel that will be
hard to maintain in the long term.
Hi Grant,
Sorry for neglecting to include devicetree-discuss on that one. I was
in fact aware of this list, and subscribe to it. I really just forgot
in this case.
I also have a documentation patch for it that went along with it, but it
wasn't ready in time and so it's been sitting in our local patch queue.
I can submit that soon, but it probably makes sense for Wolfram to
voice whatever his concerns were about questionable properties before
I document what's there.
Here's an example device tree node for this case:
gpio1: g...@18 {
compatible = nxp,pca9557;
reg = 0x18;
#gpio-cells = 2;
gpio-controller;
polarity = 0x00;
};
In this case, the linux,gpio-base property wasn't specified. But, the
use case is identical to the pdata-gpio_base field. polarity is used
for specifying polarity inversion for each line, and is in the same
format of the 'polarity inversion' register on the chip. My reasoning
in the property naming was as follows:
linux,gpio-base: Linux-specific as it relates to internal GPIO
numbering. So, it's prefixed with linux,
polarity: Dictated by how hardware is wired up, so it's needed
regardless of the OS.
- Nate
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote: And while doing this and figuring the pro/cons of those methods, I stumbled over this commit: gpio: pca953x: Get platform_data from OpenFirmware (1965d30356c1c65660ba3330927671cfe81acdd5) Aside from any issues you have with the properties themselves, what's your take on this approach? Personally, I just got tired of waiting for someone else to solve the pdata/OF problem. So I submitted that commit as an attempt at something very simple and unobtrusive to the device driver itself. It seems pretty clean to me, but I'm curious to see if others have any better ideas. - Nate ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Support for S29JL064 in MPC8272ADS?
Hello, My uboot can read my flash chip, finding the uImage and the initramfs, and booting the kernel fine. However, I'd like the Linux kernel to read my flash chip so that it can update files in it. My flash chip is the Spansion S29JL064H (AMD), 16 bit wide, 64 Mbit. The chip is mapped from FF80 to . The rootfs.jffs2 was written on 0XFF99 and is 0x39 long. I know that the JFFS is written correctly, because it is detected by uboot: = fsinfo ### filesystem type is JFFS2 Scanning JFFS2 FS: ... done. Compression: NONE frag count: 523 compressed sum: 138074 uncompressed sum: 138074 Compression: ZERO frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: RTIME frag count: 1 compressed sum: 48 uncompressed sum: 52 Compression: RUBINMIPS frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: COPY frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: DYNRUBIN frag count: 0 compressed sum: 0 uncompressed sum: 0 Compression: ZLIB frag count: 2031 compressed sum: 3370991 uncompressed sum: 7598685 = flinfo Bank # 1: CFI conformant FLASH (16 x 16) Size: 8 MB in 142 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x7E0201 Erase timeout: 8192 ms, write timeout: 1 ms Sector Start Addresses: FF80FF802000FF804000FF806000FF808000 FF80A000FF80C000FF80E000FF81FF82 FF83FF84FF85FF86FF87 FF88FF89FF8AFF8BFF8C FF8DFF8EFF8FFF90FF91 FF92FF93FF94FF95FF96 FF97FF98FF99FF9AFF9B FF9CFF9DFF9EFF9FFFA0 FFA1FFA2FFA3FFA4FFA5 FFA6FFA7FFA8FFA9FFAA FFABFFACFFADFFAEFFAF FFB0FFB1FFB2FFB3FFB4 FFB5FFB6FFB7FFB8FFB9 FFBAFFBBFFBCFFBDFFBE FFBFFFC0FFC1FFC2FFC3 FFC4FFC5FFC6FFC7FFC8 FFC9FFCAFFCBFFCCFFCD FFCEFFCFFFD0FFD1FFD2 FFD3FFD4FFD5FFD6FFD7 FFD8FFD9FFDAFFDBFFDC FFDDFFDEFFDFFFE0FFE1 FFE2FFE3FFE4FFE5FFE6 FFE7FFE8FFE9FFEAFFEB FFECFFEDFFEEFFEFFFF0 RO FFF1 RO FFF2 RO FFF3 RO FFF4 RO FFF5 RO FFF6 RO FFF7 RO FFF8FFF9FFFA FFFBFFFCFFFDFFFE 2000400060008000A000 C000E000 My bootargs are: bootargs=console=ttyCPM0,115200 root=/dev/mtdblock1 rw mtdparts=phys:1600K(ROM)ro,6M(root),512K(U-Boot)ro,512K(unused) However, the kernel does not detect any flash chip (nor there's any indication that a CFI probe is being performed). My flash kconfig section: # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=y # CONFIG_MTD_JEDECPROBE is not set CONFIG_MTD_GEN_PROBE=y CONFIG_MTD_CFI_ADV_OPTIONS=y # CONFIG_MTD_CFI_NOSWAP is not set # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set CONFIG_MTD_CFI_LE_BYTE_SWAP=y # CONFIG_MTD_CFI_GEOMETRY is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_OTP is not set # CONFIG_MTD_CFI_INTELEXT is not set CONFIG_MTD_CFI_AMDSTD=y # CONFIG_MTD_CFI_STAA is not set CONFIG_MTD_CFI_UTIL=y # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PHYSMAP_OF is not set # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set #
Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
* KAMEZAWA Hiroyuki (kamezawa.hir...@jp.fujitsu.com) wrote:
On Fri, 2 Oct 2009 13:44:58 -0500
Robert Jennings r...@linux.vnet.ibm.com wrote:
Memory balloon drivers can allocate a large amount of memory which
is not movable but could be freed to accomodate memory hotplug remove.
Prior to calling the memory hotplug notifier chain the memory in the
pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
isolation will not proceed, causing the memory removal for that page
range to fail.
Rather than failing pageblock isolation if the the migrateteype is not
MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
are owned by a registered balloon driver (or other entity) using a
notifier chain. If all of the non-movable pages are owned by a balloon,
they can be freed later through the memory notifier chain and the range
can still be isolated in set_migratetype_isolate().
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
---
drivers/base/memory.c | 19 +++
include/linux/memory.h | 26 ++
mm/page_alloc.c| 45 ++---
3 files changed, 83 insertions(+), 7 deletions(-)
Index: b/drivers/base/memory.c
===
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
}
EXPORT_SYMBOL(unregister_memory_notifier);
+static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
+
IIUC, this notifier is called under zone-lock.
please ATOMIC_NOTIFIER_HEAD().
I will correct this.
+int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(register_memory_isolate_notifier);
+
+void unregister_memory_isolate_notifier(struct notifier_block *nb)
+{
+ blocking_notifier_chain_unregister(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
return blocking_notifier_call_chain(memory_chain, val, v);
}
+int memory_isolate_notify(unsigned long val, void *v)
+{
+ return blocking_notifier_call_chain(memory_isolate_chain, val, v);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
Index: b/include/linux/memory.h
===
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -50,6 +50,18 @@ struct memory_notify {
int status_change_nid;
};
+/*
+ * During pageblock isolation, count the number of pages in the
+ * range [start_pfn, start_pfn + nr_pages)
+ */
+#define MEM_ISOLATE_COUNT (10)
+
+struct memory_isolate_notify {
+ unsigned long start_pfn;
+ unsigned int nr_pages;
+ unsigned int pages_found;
+};
Could you add commentary for each field ?
This will be documented in the next version of the patch.
+
struct notifier_block;
struct mem_section;
@@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
{
return 0;
}
+static inline int register_memory_isolate_notifier(struct notifier_block
*nb)
+{
+ return 0;
+}
+static inline void unregister_memory_isolate_notifier(struct
notifier_block *nb)
+{
+}
+static inline int memory_isolate_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
+extern int register_memory_isolate_notifier(struct notifier_block *nb);
+extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
extern int register_new_memory(int, struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
extern int memory_notify(unsigned long val, void *v);
+extern int memory_isolate_notify(unsigned long val, void *v);
extern struct memory_block *find_memory_block(struct mem_section *);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTIONPAGE_SHIFT)
enum mem_add_context { BOOT, HOTPLUG };
Index: b/mm/page_alloc.c
===
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -48,6 +48,7 @@
#include linux/page_cgroup.h
#include linux/debugobjects.h
#include linux/kmemleak.h
+#include linux/memory.h
#include trace/events/kmem.h
#include asm/tlbflush.h
@@ -4985,23 +4986,53 @@ void set_pageblock_flags_group(struct pa
int
Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
* Mel Gorman (m...@csn.ul.ie) wrote:
On Fri, Oct 02, 2009 at 01:44:58PM -0500, Robert Jennings wrote:
Memory balloon drivers can allocate a large amount of memory which
is not movable but could be freed to accomodate memory hotplug remove.
Prior to calling the memory hotplug notifier chain the memory in the
pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the
isolation will not proceed, causing the memory removal for that page
range to fail.
Rather than failing pageblock isolation if the the migrateteype is not
s/the the migrateteype/the migratetype/
MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock
are owned by a registered balloon driver (or other entity) using a
notifier chain. If all of the non-movable pages are owned by a balloon,
they can be freed later through the memory notifier chain and the range
can still be isolated in set_migratetype_isolate().
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
---
drivers/base/memory.c | 19 +++
include/linux/memory.h | 26 ++
mm/page_alloc.c| 45 ++---
3 files changed, 83 insertions(+), 7 deletions(-)
Index: b/drivers/base/memory.c
===
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
}
EXPORT_SYMBOL(unregister_memory_notifier);
+static BLOCKING_NOTIFIER_HEAD(memory_isolate_chain);
+
+int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(register_memory_isolate_notifier);
+
+void unregister_memory_isolate_notifier(struct notifier_block *nb)
+{
+ blocking_notifier_chain_unregister(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
return blocking_notifier_call_chain(memory_chain, val, v);
}
+int memory_isolate_notify(unsigned long val, void *v)
+{
+ return blocking_notifier_call_chain(memory_isolate_chain, val, v);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
Index: b/include/linux/memory.h
===
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -50,6 +50,18 @@ struct memory_notify {
int status_change_nid;
};
+/*
+ * During pageblock isolation, count the number of pages in the
+ * range [start_pfn, start_pfn + nr_pages)
+ */
The comment could have been slightly better. The count of pages in the
range is nr_pages - memory_holes but what you're counting is the number
of pages owned by the balloon driver in the notification chain.
Right, it is misleading. I'll fix this.
+#define MEM_ISOLATE_COUNT (10)
+
+struct memory_isolate_notify {
+ unsigned long start_pfn;
+ unsigned int nr_pages;
+ unsigned int pages_found;
+};
+
struct notifier_block;
struct mem_section;
@@ -76,14 +88,28 @@ static inline int memory_notify(unsigned
{
return 0;
}
+static inline int register_memory_isolate_notifier(struct notifier_block
*nb)
+{
+ return 0;
+}
+static inline void unregister_memory_isolate_notifier(struct
notifier_block *nb)
+{
+}
+static inline int memory_isolate_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
+extern int register_memory_isolate_notifier(struct notifier_block *nb);
+extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
extern int register_new_memory(int, struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
extern int memory_notify(unsigned long val, void *v);
+extern int memory_isolate_notify(unsigned long val, void *v);
extern struct memory_block *find_memory_block(struct mem_section *);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTIONPAGE_SHIFT)
enum mem_add_context { BOOT, HOTPLUG };
Index: b/mm/page_alloc.c
===
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -48,6 +48,7 @@
#include linux/page_cgroup.h
#include linux/debugobjects.h
#include linux/kmemleak.h
+#include linux/memory.h
#include trace/events/kmem.h
#include asm/tlbflush.h
@@ -4985,23 +4986,53 @@ void
Re: [RFC] scripts/get_maintainer: add emails based on keywords in the patch
On Fri, Oct 9, 2009 at 4:32 AM, Wolfram Sang w.s...@pengutronix.de wrote:
Make get_maintainer.pl scan the modifying lines of a patch for a list of
keywords and add an associated email if found. The first user is the
devicetree-discuss mailing list which should always be cc'ed if a device tree
property is inserted/removed (keyword 'of_get_property'). This patch is the
result from commit 1965d30356c1c65660ba3330927671cfe81acdd5 entering mainline
which seems to have been missed by all parties interested in the device tree
(and at least had the documentation missing). As adding properties can happen
anywhere and so there is no fitting fileglob, this keyword based approach is
proposed.
Nice. I cannot comment on the implementation, but I like the approach.
g.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Joe Perches j...@perches.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Anton Vorontsov avoront...@ru.mvista.com
---
scripts/get_maintainer.pl | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index cdb44b6..e1150ea 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -44,6 +44,11 @@ my $help = 0;
my $exit = 0;
+my %keywords_to_mail = (
+ 'of_get_property' = 'L: devicetree-disc...@lists.ozlabs.org',
+);
+my $keywords_to_mail_match = join('|', keys %keywords_to_mail);
+
my @penguin_chief = ();
push(@penguin_chief,Linus Torvalds:torval...@linux-foundation.org);
#Andrew wants in on most everything - 2009/01/14
@@ -188,6 +193,12 @@ if ($email_remove_duplicates) {
my @files = ();
my @range = ();
+my @email_to = ();
+my @list_to = ();
+my @scm = ();
+my @web = ();
+my @subsystem = ();
+my @status = ();
foreach my $file (@ARGV) {
##if $file is a directory and it lacks a trailing slash, add one
@@ -213,7 +224,11 @@ foreach my $file (@ARGV) {
if ($email_git_blame) {
push(@range, $lastfile:$1:$2);
}
- }
+ # Check the lines which a patch modifies for keywords; add mail
if found.
+ } elsif (m/^[+-].*($keywords_to_mail_match)/o) {
+ (my $keyword_mail = $keywords_to_mail{$1}) =~ s/^([LM]): //;
+ push( @{ ($1 eq 'L') ? \...@list_to : \...@email_to },
$keyword_mail );
+ }
}
close(PATCH);
if ($file_cnt == @files) {
@@ -224,13 +239,6 @@ foreach my $file (@ARGV) {
}
}
-my @email_to = ();
-my @list_to = ();
-my @scm = ();
-my @web = ();
-my @subsystem = ();
-my @status = ();
-
# Find responsible parties
foreach my $file (@files) {
--
1.6.3.3
--
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
Re: [PATCH 10/16] percpu: make percpu symbols in powerpc unique
On Wednesday 07 October 2009, Tejun Heo wrote: This patch updates percpu related symbols in powerpc such that percpu symbols are unique and don't clash with local symbols. This serves two purposes of decreasing the possibility of global percpu symbol collision and allowing dropping per_cpu__ prefix from percpu symbols. * arch/powerpc/kernel/perf_callchain.c: s/callchain/cpu_perf_callchain/ * arch/powerpc/kernel/setup-common.c: s/pvr/cpu_pvr/ * arch/powerpc/platforms/pseries/dtl.c: s/dtl/cpu_dtl/ * arch/powerpc/platforms/cell/interrupt.c: s/iic/cpu_iic/ Partly based on Rusty Russell's alloc_percpu: rename percpu vars which cause name clashes patch. Patch looks good, I checked both the cell bits I'm maintaining and the other powerpc parts. Acked-by: Arnd Bergmann a...@arndb.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: ppc_md.SMI replacement for 2.6
I have more information on this PPC HPPB target. I compared the
EXCEPTION macro between 2.4 and 2.6 with respect to SMI Exceptions. I
noticed that in the 2.4 kernel a macro named STD_EXCEPTION was used
and in the 2.6 kernel their is a new EXCEPTION macro structure. In the
2.6 kernel, it is much different, but with the TAUException I noticed
that it used an EXC_XFER_STD instead of EXC_XFER_EE, so I tried it and
with great news, I am actually getting the exceptions correctly now.
My question to anyone who understands is: is it OK to change the line
in arch/powerpc/kernel/head_32.S from
EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_EE)
to
EXCEPTION(0x1400, SMI, SMIException, EXC_XFER_STD)
I have not decoded assembler to determine the exact differences, and I
will do so, but I wanted to know if there was anyone who knew why this
would make my SMI interrupt behave correctly.
Also, as noted earlier in this post, there is no hook for notification
of the SMI. The vendor who did the 2.4 port provided his own hook
through ppc_md global variable. Would anyone care to suggest the 'best/
preferred' method to provide a callback to the SMI Exception.
Thanks
Donald
li...@kayser.net
On Oct 9, 2009, at 8:50 AM, Arnd Bergmann wrote:
On Friday 09 October 2009, Donald Kayser wrote:
On further comparison, this section of code has been added by the
vendor that actually ported linux 2.4 to this PPC HPPB target. So, if
anyone would like to lend a thought towards System Managment
Exceptions on PPC, please cc me at li...@kayser.net. I will be
stopping the subscription to this list shortly. Regards, Donald
Hi Donald,
You should ask ppc specific questions on the linuxppc-...@ozlabs.org
mailing list instead of the global linux-kernel list to increase the
chances of someone reading it who knows the answer.
The world of powerpc linux has changed a lot since 2.4, as you
undoubtedly found out. You are certainly encouraged to submit
your platform code for inclusion in the mainline kernel (if you
can do the usual cleanups necessary to do that), even for
old code.
I don't know a specific reason why the SMI callback was removed,
but I would guess that if you have a platform that requires it
and want it in the mainline kernel, a callback for it can be
added back, either through ppc_md or some other method.
Arnd
On Oct 8, 2009, at 8:37 AM, Donald Kayser wrote:
I have found the differences between the 2.4 and 2.6 kernel. It is
in linux-2.4/arch/ppc/kernel/traps.c and linux-2.6/arch/powerpc/
kernel/traps.c in the function SMIException(). There is no longer
the code segment
if (ppc_md.SMI)
{
ppc_md.SMI(regs);
return;
}
There is now only a
die(System Management Interrupt, regs, SIGABRT);
I am guessing that the SMI callback is no longer needed by the linux
community at large, so I modified the code for my specific hardware
(HPPB) and acknowledged the exception as in the 2.4 kernel, and
returned from the exception without the call to die(). My problem
now is that it doesn't seem to work. Does anyone have a reason why
the SMI exception might hang the system when it has been provided a
handler?
Thanks in advance.
Donald Kayser
On Oct 7, 2009, at 10:06 AM, Donald Kayser wrote:
I have ported the 2.6 kernel to an embedded PPC target (old stuff).
I have managed to figure everything out, but can't find any
replacement for a SMI handler. The original 2.4 version for this
target has a bit of code ppc_md.SMI == SmiFuncHandler; I have not
been able to find in the current source anything like this. I am
not certain that I need to provide a handler at all, but the
original developers saw some reason for including it. The
particular handler does not do anything more than cancel a watchdog
listener for this specific target. I have been living without the
handler, but would like to find any kind of replacement if it is
supported.
Thanks,
Donald Kayser
li...@kayser.net
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Fri, Oct 9, 2009 at 8:01 AM, Nate Case nc...@xes-inc.com wrote:
On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
For your future reference, patches that look at the device tree should
also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can
be reviewed and common mistakes can be avoided. It is expected that
new device tree bindings are accompanied with documentation describing
what the binding is for and how it should be used (see
Documentation/powerpc/dts-bindings).
I know this change is already in mainline, but can you please post the
device tree fragment that you're using to describe this chip? I want
to make sure we don't get stuck with things in the kernel that will be
hard to maintain in the long term.
Hi Grant,
Sorry for neglecting to include devicetree-discuss on that one. I was
in fact aware of this list, and subscribe to it. I really just forgot
in this case.
No worries, it happens.
I also have a documentation patch for it that went along with it, but it
wasn't ready in time and so it's been sitting in our local patch queue.
I can submit that soon, but it probably makes sense for Wolfram to
voice whatever his concerns were about questionable properties before
I document what's there.
Yes, please post it as soon as you can.
Here's an example device tree node for this case:
gpio1: g...@18 {
compatible = nxp,pca9557;
reg = 0x18;
#gpio-cells = 2;
gpio-controller;
polarity = 0x00;
};
In this case, the linux,gpio-base property wasn't specified. But, the
use case is identical to the pdata-gpio_base field. polarity is used
for specifying polarity inversion for each line, and is in the same
format of the 'polarity inversion' register on the chip. My reasoning
in the property naming was as follows:
linux,gpio-base: Linux-specific as it relates to internal GPIO
numbering. So, it's prefixed with linux,
This would be the 'questionable' property. :-) The device tree is
supposed to be OS agnostic, so I get the heebee geebees when I see new
'linux,blah' properties defined because it means Linux internal
implementation details are getting leaked out into the data blob. The
problem leakage is that the device tree should not be impacted by
internal Linux code changes.
In this particular case, specifying the exact GPIO base number doesn't
really belong in the device tree because Linux is able to assign and
manage GPIO numbers on its own just like all other OF GPIO controller
drivers currently do. In fact, that goes for pretty much all
enumeration, not just GPIO. In general, a particular device instance
(uart, gpio, phy, whatever) should be resolved from its node in the
device tree, and not by some arbitrary number assigned by the .dts
author. The problem with arbitrary numbers is they don't expose the
linkage between nodes in the same way a 'phandle' does (A phandle can
be searched for. An arbitrary number assignment, good luck?), and
they don't expose intended usage (its just a meaningless number, and
it only works because userspace just happens to 'agree' to use the
same number).
polarity: Dictated by how hardware is wired up, so it's needed
regardless of the OS.
Typically GPIO drivers have been handling this by using #gpio-cells
set to 2, and using the 2nd cell for flags. The priority can be
encoded as a flag.
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
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
Aside from any issues you have with the properties themselves, what's your take on this approach? Well, my approach for AT24 looked very similar to your approach. In fact, even the motivation was the same as yours :) Well, the outcome of this is the current thread and no definite solution yet. The archdata surely helps for this issue, it just seems that a bit more generalization is needed. Kind regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
On Fri, Oct 9, 2009 at 7:43 AM, Nate Case nc...@xes-inc.com wrote: On Fri, 2009-10-09 at 07:14 +0200, Wolfram Sang wrote: And while doing this and figuring the pro/cons of those methods, I stumbled over this commit: gpio: pca953x: Get platform_data from OpenFirmware (1965d30356c1c65660ba3330927671cfe81acdd5) Aside from any issues you have with the properties themselves, what's your take on this approach? As I mentioned in an earlier email, I don't think quite the right form has been found yet, but I like the direction things are moving. Personally, I just got tired of waiting for someone else to solve the pdata/OF problem. So I submitted that commit as an attempt at something very simple and unobtrusive to the device driver itself. It seems pretty clean to me, but I'm curious to see if others have any better ideas. Yup, that's good. Between Anton's, Wolfram's and your work things are going the right way. 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
Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
I can submit that soon, but it probably makes sense for Wolfram to voice whatever his concerns were about questionable properties before I document what's there. Please don't feel offended. The things I noticed are: a) no documentation b) 'polarity' is a direct mapping to the register which IMO is a hint to look closer. I haven't checked in detil, but maybe the active_low-flag could be used for this? I mainly got alarmed that properties were mainlined without being reviewed; as the device-tree is based on convention (which is hard to change afterwards), I try to make sure this will not so easily happen again (thus the get_maintainer-patch on lkml). Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Support for S29JL064 in MPC8272ADS?
On Fri, Oct 09, 2009 at 10:14:56AM -0400, Roberto Guerra wrote: Hello, My uboot can read my flash chip, finding the uImage and the initramfs, and booting the kernel fine. However, I'd like the Linux kernel to read my flash chip so that it can update files in it. Have you described your flash chip in the device tree? However, the kernel does not detect any flash chip (nor there's any indication that a CFI probe is being performed). The stock device tree for mpc8272ads only specifies it as a JEDEC flash, not CFI. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Support for S29JL064 in MPC8272ADS?
No. I did not. My FDT was simplified from the stock MPC8272ADS:
= fdt list
/ {
model = pq2fads;
compatible = fsl,pq2fads;
#address-cells = 0x0001;
#size-cells = 0x0001;
cpus {
};
memory {
};
s...@f000 {
};
chosen {
};
};
I am searching how I could add the mtd branch between the soc and
the chosen.
On Fri, Oct 9, 2009 at 1:04 PM, Scott Wood scottw...@freescale.com wrote:
On Fri, Oct 09, 2009 at 10:14:56AM -0400, Roberto Guerra wrote:
Hello,
My uboot can read my flash chip, finding the uImage and the initramfs,
and booting the kernel fine. However, I'd like the Linux kernel to
read my flash chip so that it can update files in it.
Have you described your flash chip in the device tree?
However, the kernel does not detect any flash chip (nor there's any
indication that a CFI probe is being performed).
The stock device tree for mpc8272ads only specifies it as a JEDEC
flash, not CFI.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Support for S29JL064 in MPC8272ADS?
On Fri, Oct 09, 2009 at 01:59:58PM -0400, Roberto Guerra wrote:
No. I did not. My FDT was simplified from the stock MPC8272ADS:
= fdt list
/ {
model = pq2fads;
compatible = fsl,pq2fads;
#address-cells = 0x0001;
#size-cells = 0x0001;
cpus {
};
memory {
};
s...@f000 {
};
chosen {
};
};
You need more than that. What happened to all the content of those nodes?
I am searching how I could add the mtd branch between the soc and
the chosen.
Look at the localbus node on the mpc8272ads dts.
Look at (and use) a recent upstream kernel, if you're not already.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Linux net-2.6 build error for PPC
I recently grabbed the latest net-2.6 kernel for a powerpc test box and got this compile error. CC arch/powerpc/kernel/cputable.o CC arch/powerpc/kernel/ptrace.o CC arch/powerpc/kernel/syscalls.o CC arch/powerpc/kernel/irq.o CC arch/powerpc/kernel/align.o CC arch/powerpc/kernel/signal_32.o CC arch/powerpc/kernel/pmc.o CC arch/powerpc/kernel/vdso.o cc1: warnings being treated as errors arch/powerpc/kernel/vdso.c:78: warning: alignment of âso_data_storeâs greater than maximum object file alignment. Using 32768 make[1]: *** [arch/powerpc/kernel/vdso.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 [r...@localhost linux-2.6-net.git]# Any suggestions would be appreciated. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] scripts/get_maintainer: add emails based on keywords in the patch
On Fri, 2009-10-09 at 04:23 -0700, Joe Perches wrote: If this facility is desired by many others, it might be better to have a separate file of 'regex generates email' read at initialization. Perhaps it's better to use the existing MAINTAINERS file and extend it with a new K: for keyword entry. This patch is a bit longer than necessary because the MAINTAINERS initial descriptions are moved around a bit. Perhaps something like this: MAINTAINERS | 71 +--- scripts/get_maintainer.pl | 24 +++ 2 files changed, 57 insertions(+), 38 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index e1da925..9e1263f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -65,43 +65,47 @@ trivial patch so apply some common sense. 8. Happy hacking. - --- - -Maintainers List (try to look for most precise areas first) +Descriptions of section entries: + + P: Person (obsolete) + M: Mail patches to: FullName addr...@domain + L: Mailing list that is relevant to this area + W: Web-page with status/info + T: SCM tree type and location. Type is one of: git, hg, quilt, stgit. + S: Status, one of the following: + Supported: Someone is actually paid to look after this. + Maintained: Someone actually looks after it. + Odd Fixes: It has a maintainer but they don't have time to do + much other than throw the odd patch in. See below.. + Orphan: No current maintainer [but maybe you could take the + role as you write your new code]. + Obsolete:Old code. Something tagged obsolete generally means + it has been replaced by a better system and you + should be using that. + F: Files and directories with wildcard patterns. + A trailing slash includes all files and subdirectory files. + F: drivers/net/all files in and below drivers/net + F: drivers/net/* all files in drivers/net, but not below + F: */net/* all files in any top level directory/net + One pattern per line. Multiple F: lines acceptable. + X: Files and directories that are NOT maintained, same rules as F: + Files exclusions are tested before file matches. + Can be useful for excluding a specific subdirectory, for instance: + F: net/ + X: net/ipv6/ + matches all files in and below net excluding net/ipv6/ + K: Keyword perl regex pattern to match content in patch + All patterns are surrounded by \b + for instance: K: of_get_profile + will match patches that contain the word of_get_profile Note: For the hard of thinking, this list is meant to remain in alphabetical order. If you could add yourselves to it in alphabetical order that would be so much easier [Ed] -P: Person (obsolete) -M: Mail patches to: FullName addr...@domain -L: Mailing list that is relevant to this area -W: Web-page with status/info -T: SCM tree type and location. Type is one of: git, hg, quilt, stgit. -S: Status, one of the following: - - Supported: Someone is actually paid to look after this. - Maintained: Someone actually looks after it. - Odd Fixes: It has a maintainer but they don't have time to do - much other than throw the odd patch in. See below.. - Orphan: No current maintainer [but maybe you could take the - role as you write your new code]. - Obsolete: Old code. Something tagged obsolete generally means - it has been replaced by a better system and you - should be using that. +Maintainers List (try to look for most precise areas first) -F: Files and directories with wildcard patterns. - A trailing slash includes all files and subdirectory files. - F: drivers/net/all files in and below drivers/net - F: drivers/net/* all files in drivers/net, but not below - F: */net/* all files in any top level directory/net - One pattern per line. Multiple F: lines acceptable. -X: Files and directories that are NOT maintained, same rules as F: - Files exclusions are tested before file matches. - Can be useful for excluding a specific subdirectory, for instance: - F: net/ - X: net/ipv6/ - matches all files in and below net excluding net/ipv6/ + --- 3C505 NETWORK DRIVER M: Philip Blundell ph...@gnu.org @@ -3876,6 +3880,11 @@ S: Maintained F: Documentation/i2c/busses/i2c-ocores F: drivers/i2c/busses/i2c-ocores.c +OPEN FIRMWARE DEVICE TREE +L: devicetree-disc...@lists.ozlabs.org +S: Odd Fixes +K: of_get_property + OPROFILE M: Robert Richter
Re: linux-next: tree build failure
Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
also exposes the bug in kvmppc_account_exit_stat(). So to recap:
original: built but didn't work
Jan's: doesn't build
Rusty's: builds and works
Where do you want to go from here?
--
Hollis Blanchard
IBM Linux Technology Center
On Mon, 2009-10-05 at 07:58 +0100, Jan Beulich wrote:
Hollis Blanchard holl...@us.ibm.com 02.10.09 17:48
On Wed, 2009-09-30 at 07:35 +0100, Jan Beulich wrote:
The one Rusty suggested the other day may help here. I don't like it
as a drop-in replacement for BUILD_BUG_ON() though (due to it
deferring the error generated to the linking stage), I'd rather view
this as an improvement to MAYBE_BUILD_BUG_ON() (which should
then be used here).
Can you be more specific?
I have no idea what Rusty suggested where. I can't even guess what
I'm attaching Rusty's response I was referring to.
MAYBE_BUILD_BUG_ON() is supposed to do (sounds like a terrible name).
Agreed - but presumably better than just deleting the bogus instances
altogether...
Jan
email message attachment
Forwarded Message
From: Rusty Russell ru...@rustcorp.com.au
To: Jan Beulich jbeul...@novell.com
Cc: linux-ker...@vger.kernel.org
Subject: Re: [PATCH] fix BUILD_BUG_ON() and a couple of bogus uses
of it
Date: Wed, 23 Sep 2009 10:27:00 +0930
On Wed, 19 Aug 2009 01:29:25 am Jan Beulich wrote:
gcc permitting variable length arrays makes the current construct
used for BUILD_BUG_ON() useless, as that doesn't produce any diagnostic
if the controlling expression isn't really constant. Instead, this
patch makes it so that a bit field gets used here. Consequently, those
uses where the condition isn't really constant now also need fixing.
Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even
if the expression is compile time constant (__builtin_constant_p()
yields true), the array is still deemed of variable length by gcc, and
hence the whole expression doesn't have the intended effect.
Signed-off-by: Jan Beulich jbeul...@novell.com
We used to use an undefined symbol here; diagnostics are worse but it
catches
more stuff.
Perhaps a hybrid is the way to go?
#ifndef __OPTIMIZE__
#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
#else
/* If it's a constant, catch it at compile time, otherwise at link time. */
extern int __build_bug_on_failed;
#define BUILD_BUG_ON(condition) \
do {\
((void)sizeof(char[1 - 2*!!(condition)])); \
if (condition) __build_bug_on_failed = 1; \
} while(0)
#endif
Thanks,
Rusty.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/40x: Cleanups for HCU4 board
- hcu4.dts: Added definitions for 2 CAN (Intel 82527)
- hcu4.c: Some code for CPLD (special HW clock) and 2 CAN (Intel 82527)
Signed-off-by: Niklaus Giger niklaus.gi...@member.fsf.org
---
arch/powerpc/boot/dts/hcu4.dts| 193 ++---
arch/powerpc/platforms/40x/hcu4.c | 87 +
2 files changed, 200 insertions(+), 80 deletions(-)
diff --git a/arch/powerpc/boot/dts/hcu4.dts b/arch/powerpc/boot/dts/hcu4.dts
index 7988598..64ad122 100644
--- a/arch/powerpc/boot/dts/hcu4.dts
+++ b/arch/powerpc/boot/dts/hcu4.dts
@@ -1,164 +1,197 @@
/*
-* Device Tree Source for Netstal Maschinen HCU4
-* based on the IBM Walnut
-*
-* Copyright 2008
-* Niklaus Giger niklaus.gi...@member.fsf.org
-*
-* Copyright 2007 IBM Corp.
-* Josh Boyer jwbo...@linux.vnet.ibm.com
-*
-* This file is licensed under the terms of the GNU General Public
-* License version 2. This program is licensed as is without
-* any warranty of any kind, whether express or implied.
-*/
+ * Device Tree Source for Netstal Maschinen HCU4
+ * based on the IBM Walnut
+ *
+ * Copyright 2008-2009
+ * Niklaus Giger niklaus.gi...@member.fsf.org
+ *
+ * Copyright 2007 IBM Corp.
+ * Josh Boyer jwbo...@linux.vnet.ibm.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
/dts-v1/;
/ {
- #address-cells = 0x1;
- #size-cells = 0x1;
+ #address-cells = 1;
+ #size-cells = 1;
model = netstal,hcu4;
compatible = netstal,hcu4;
- dcr-parent = 0x1;
+ dcr-parent = {/cpus/c...@0};
aliases {
- ethernet0 = /plb/opb/ether...@ef600800;
- serial0 = /plb/opb/ser...@ef600300;
+ ethernet0 = EMAC;
+ serial0 = UART0;
};
cpus {
- #address-cells = 0x1;
- #size-cells = 0x0;
+ #address-cells = 1;
+ #size-cells = 0;
c...@0 {
device_type = cpu;
model = PowerPC,405GPr;
- reg = 0x0;
- clock-frequency = 0; /* Filled in by U-Boot
*/
- timebase-frequency = 0x0; /* Filled in by U-Boot
*/
- i-cache-line-size = 0x20;
- d-cache-line-size = 0x20;
- i-cache-size = 0x4000;
- d-cache-size = 0x4000;
+ reg = 0x;
+ clock-frequency = 0;/* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 16384;
+ d-cache-size = 16384;
dcr-controller;
dcr-access-method = native;
- linux,phandle = 0x1;
};
};
memory {
device_type = memory;
- reg = 0x0 0x0;/* Filled in by U-Boot */
+ reg = 0x 0x; /* Filled in by U-Boot */
};
UIC0: interrupt-controller {
compatible = ibm,uic;
interrupt-controller;
- cell-index = 0x0;
- dcr-reg = 0xc0 0x9;
- #address-cells = 0x0;
- #size-cells = 0x0;
- #interrupt-cells = 0x2;
- linux,phandle = 0x2;
+ cell-index = 0;
+ dcr-reg = 0x0c0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
};
plb {
compatible = ibm,plb3;
- #address-cells = 0x1;
- #size-cells = 0x1;
+ #address-cells = 1;
+ #size-cells = 1;
ranges;
- clock-frequency = 0x0;/* Filled in by U-Boot */
+ clock-frequency = 0; /* Filled in by U-Boot */
SDRAM0: memory-controller {
compatible = ibm,sdram-405gp;
- dcr-reg = 0x10 0x2;
+ dcr-reg = 0x010 0x002;
};
MAL: mcmal {
compatible = ibm,mcmal-405gp, ibm,mcmal;
- dcr-reg = 0x180 0x62;
- num-tx-chans = 0x1;
- num-rx-chans = 0x1;
- interrupt-parent = 0x2;
- interrupts = 0xb 0x4 0xc 0x4 0xa 0x4 0xd 0x4 0xe 0x4;
- linux,phandle = 0x3;
+ dcr-reg = 0x180 0x062;
+ num-tx-chans = 1;
+ num-rx-chans = 1;
+ interrupt-parent = UIC0;
+
Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
* Andrew Morton (a...@linux-foundation.org) wrote: On Fri, 2 Oct 2009 13:44:58 -0500 Robert Jennings r...@linux.vnet.ibm.com wrote: Memory balloon drivers can allocate a large amount of memory which is not movable but could be freed to accomodate memory hotplug remove. Prior to calling the memory hotplug notifier chain the memory in the pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the isolation will not proceed, causing the memory removal for that page range to fail. Rather than failing pageblock isolation if the the migrateteype is not MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock are owned by a registered balloon driver (or other entity) using a notifier chain. If all of the non-movable pages are owned by a balloon, they can be freed later through the memory notifier chain and the range can still be isolated in set_migratetype_isolate(). The patch looks sane enough to me. I expect that if the powerpc and s390 guys want to work on CMM over the next couple of months, they'd like this patch merged into 2.6.32. It's a bit larger and more involved than one would like, but I guess we can do that if suitable people (Mel? Kamezawa?) have had a close look and are OK with it. What do people think? I'd love to get it in 2.6.32 if that's possible. I have gone over the comments from Mel and Kamezawa I produced a new patchset. I just finished testing it (and I also tested with CONFIG_MEMORY_HOTPLUG_SPARSE=n) and it will be posted shortly. Has it been carefully compile- and run-time tested with CONFIG_MEMORY_HOTPLUG_SPARSE=n? Yes, I have compiled the kernel CONFIG_MEMORY_HOTPLUG_SPARSE=n and made sure that we didn't have any problems. --Robert Jennings ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2][v3] mm: add notifier in pageblock isolation for balloon drivers
Memory balloon drivers can allocate a large amount of memory which
is not movable but could be freed to accomodate memory hotplug remove.
Prior to calling the memory hotplug notifier chain the memory in
the pageblock is isolated. Currently, if the migrate type is not
MIGRATE_MOVABLE the isolation will not proceed, causing the memory
removal for that page range to fail.
Rather than failing pageblock isolation if the migrateteype is not
MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock,
and not on the LRU, are owned by a registered balloon driver (or other
entity) using a notifier chain. If all of the non-movable pages are
owned by a balloon, they can be freed later through the memory notifier
chain and the range can still be isolated in set_migratetype_isolate().
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
---
Testing:
* With the patch memory remove succeeds for pageblocks containing balloon
allocations. The balloon driver frees pages in the ranges being
taken offline. Prior to the patch, pageblocks with balloon allocations
could not be taken offline.
* Tested with CONFIG_MEMORY_HOTPLUG_SPARSE=n to ensure that the patches
did not affect that configuration.
Changes since v2:
* comments cleaned up based on patch reviews.
* documented variables in struct memory_isolate_notify.
* made search for active pages in set_isolate_pageblock safe if
CONFIG_HOLES_IN_ZONE is set.
* changed notifier chain from BLOCKING to ATOMIC.
* added check for pages on an LRU to be considered movable.
drivers/base/memory.c | 19
include/linux/memory.h | 27 +++
mm/page_alloc.c| 57 +++--
3 files changed, 96 insertions(+), 7 deletions(-)
Index: b/drivers/base/memory.c
===
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -63,6 +63,20 @@ void unregister_memory_notifier(struct n
}
EXPORT_SYMBOL(unregister_memory_notifier);
+static ATOMIC_NOTIFIER_HEAD(memory_isolate_chain);
+
+int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(register_memory_isolate_notifier);
+
+void unregister_memory_isolate_notifier(struct notifier_block *nb)
+{
+ atomic_notifier_chain_unregister(memory_isolate_chain, nb);
+}
+EXPORT_SYMBOL(unregister_memory_isolate_notifier);
+
/*
* register_memory - Setup a sysfs device for a memory block
*/
@@ -157,6 +171,11 @@ int memory_notify(unsigned long val, voi
return blocking_notifier_call_chain(memory_chain, val, v);
}
+int memory_isolate_notify(unsigned long val, void *v)
+{
+ return atomic_notifier_call_chain(memory_isolate_chain, val, v);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
Index: b/include/linux/memory.h
===
--- a/include/linux/memory.h
+++ b/include/linux/memory.h
@@ -50,6 +50,19 @@ struct memory_notify {
int status_change_nid;
};
+/*
+ * During pageblock isolation, count the number of pages within the
+ * range [start_pfn, start_pfn + nr_pages) which are owned by code
+ * in the notifier chain.
+ */
+#define MEM_ISOLATE_COUNT (10)
+
+struct memory_isolate_notify {
+ unsigned long start_pfn;/* Start of range to check */
+ unsigned int nr_pages; /* # pages in range to check */
+ unsigned int pages_found; /* # pages owned found by callbacks */
+};
+
struct notifier_block;
struct mem_section;
@@ -76,14 +89,28 @@ static inline int memory_notify(unsigned
{
return 0;
}
+static inline int register_memory_isolate_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+static inline void unregister_memory_isolate_notifier(struct notifier_block
*nb)
+{
+}
+static inline int memory_isolate_notify(unsigned long val, void *v)
+{
+ return 0;
+}
#else
extern int register_memory_notifier(struct notifier_block *nb);
extern void unregister_memory_notifier(struct notifier_block *nb);
+extern int register_memory_isolate_notifier(struct notifier_block *nb);
+extern void unregister_memory_isolate_notifier(struct notifier_block *nb);
extern int register_new_memory(int, struct mem_section *);
extern int unregister_memory_section(struct mem_section *);
extern int memory_dev_init(void);
extern int remove_memory_block(unsigned long, struct mem_section *, int);
extern int memory_notify(unsigned long val, void *v);
+extern int memory_isolate_notify(unsigned long val, void *v);
extern struct memory_block *find_memory_block(struct mem_section *);
#define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTIONPAGE_SHIFT)
enum mem_add_context { BOOT, HOTPLUG };
Index: b/mm/page_alloc.c
[PATCH 2/2][v3] powerpc: Make the CMM memory hotplug aware
The Collaborative Memory Manager (CMM) module allocates individual pages
over time that are not migratable. On a long running system this can
severely impact the ability to find enough pages to support a hotplug
memory remove operation.
This patch adds a memory isolation notifier and a memory hotplug notifier.
The memory isolation notifier will return the number of pages found
in the range specified. This is used to determine if all of the used
pages in a pageblock are owned by the balloon (or other entities in
the notifier chain). The hotplug notifier will free pages in the range
which is to be removed. The priority of this hotplug notifier is low
so that it will be called near last, this helps avoids removing loaned
pages in operations that fail due to other handlers.
CMM activity will be halted when hotplug remove operations are active
and resume activity after a delay period to allow the hypervisor time
to adjust.
Signed-off-by: Robert Jennings r...@linux.vnet.ibm.com
---
I'm not entirely sure of the ettiquette, but there are no changes to
this patch. I'm resending to keep it with the changes to the parent
patch.
arch/powerpc/platforms/pseries/cmm.c | 207 ++-
1 file changed, 201 insertions(+), 6 deletions(-)
Index: b/arch/powerpc/platforms/pseries/cmm.c
===
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -38,19 +38,28 @@
#include asm/mmu.h
#include asm/pgalloc.h
#include asm/uaccess.h
+#include linux/memory.h
#include plpar_wrappers.h
#define CMM_DRIVER_VERSION 1.0.0
#define CMM_DEFAULT_DELAY 1
+#define CMM_HOTPLUG_DELAY 5
#define CMM_DEBUG 0
#define CMM_DISABLE0
#define CMM_OOM_KB 1024
#define CMM_MIN_MEM_MB 256
#define KB2PAGES(_p) ((_p)(PAGE_SHIFT-10))
#define PAGES2KB(_p) ((_p)(PAGE_SHIFT-10))
+/*
+ * The priority level tries to ensure that this notifier is called as
+ * late as possible to reduce thrashing in the shared memory pool.
+ */
+#define CMM_MEM_HOTPLUG_PRI1
+#define CMM_MEM_ISOLATE_PRI15
static unsigned int delay = CMM_DEFAULT_DELAY;
+static unsigned int hotplug_delay = CMM_HOTPLUG_DELAY;
static unsigned int oom_kb = CMM_OOM_KB;
static unsigned int cmm_debug = CMM_DEBUG;
static unsigned int cmm_disabled = CMM_DISABLE;
@@ -65,6 +74,10 @@ MODULE_VERSION(CMM_DRIVER_VERSION);
module_param_named(delay, delay, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay, Delay (in seconds) between polls to query hypervisor
paging requests.
[Default= __stringify(CMM_DEFAULT_DELAY) ]);
+module_param_named(hotplug_delay, hotplug_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(delay, Delay (in seconds) after memory hotplug remove
+before activity resumes.
+[Default= __stringify(CMM_HOTPLUG_DELAY) ]);
module_param_named(oom_kb, oom_kb, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(oom_kb, Amount of memory in kb to free on OOM.
[Default= __stringify(CMM_OOM_KB) ]);
@@ -88,6 +101,8 @@ struct cmm_page_array {
static unsigned long loaned_pages;
static unsigned long loaned_pages_target;
static unsigned long oom_freed_pages;
+static atomic_t hotplug_active = ATOMIC_INIT(0);
+static atomic_t hotplug_occurred = ATOMIC_INIT(0);
static struct cmm_page_array *cmm_page_list;
static DEFINE_SPINLOCK(cmm_lock);
@@ -110,6 +125,9 @@ static long cmm_alloc_pages(long nr)
cmm_dbg(Begin request for %ld pages\n, nr);
while (nr) {
+ if (atomic_read(hotplug_active))
+ break;
+
addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!addr)
@@ -119,8 +137,10 @@ static long cmm_alloc_pages(long nr)
if (!pa || pa-index = CMM_NR_PAGES) {
/* Need a new page for the page list. */
spin_unlock(cmm_lock);
- npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO
| __GFP_NOWARN |
-
__GFP_NORETRY | __GFP_NOMEMALLOC);
+ npa = (struct cmm_page_array *)__get_free_page(
+ GFP_NOIO | __GFP_NOWARN |
+ __GFP_NORETRY | __GFP_NOMEMALLOC |
+ __GFP_MOVABLE);
if (!npa) {
pr_info(%s: Can not allocate new page list\n,
__func__);
free_page(addr);
@@ -273,9 +293,23 @@ static int cmm_thread(void *dummy)
while (1) {
timeleft = msleep_interruptible(delay * 1000);
- if (kthread_should_stop() || timeleft) {
- loaned_pages_target =
Re: [PATCH 1/2][v2] mm: add notifier in pageblock isolation for balloon drivers
On Fri, Oct 09, 2009 at 03:23:04PM -0500, Robert Jennings wrote: * Andrew Morton (a...@linux-foundation.org) wrote: On Fri, 2 Oct 2009 13:44:58 -0500 Robert Jennings r...@linux.vnet.ibm.com wrote: Memory balloon drivers can allocate a large amount of memory which is not movable but could be freed to accomodate memory hotplug remove. Prior to calling the memory hotplug notifier chain the memory in the pageblock is isolated. If the migrate type is not MIGRATE_MOVABLE the isolation will not proceed, causing the memory removal for that page range to fail. Rather than failing pageblock isolation if the the migrateteype is not MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock are owned by a registered balloon driver (or other entity) using a notifier chain. If all of the non-movable pages are owned by a balloon, they can be freed later through the memory notifier chain and the range can still be isolated in set_migratetype_isolate(). The patch looks sane enough to me. I expect that if the powerpc and s390 guys want to work on CMM over the next couple of months, they'd like this patch merged into 2.6.32. It's a bit larger and more involved than one would like, but I guess we can do that if suitable people (Mel? Kamezawa?) have had a close look and are OK with it. What do people think? I'd love to get it in 2.6.32 if that's possible. I have gone over the comments from Mel and Kamezawa I produced a new patchset. I just finished testing it (and I also tested with CONFIG_MEMORY_HOTPLUG_SPARSE=n) and it will be posted shortly. As you have tested this recently, would you be willing to post the results? While it's not a requirement of the patch, it would be nice to have an idea of how the effectiveness of memory hot-remove is improved when used with the powerpc balloon. This might convince others developers for balloons to register with the notifier. Total aside, I'm not overly clear why so much of balloon driver logic is in drivers and not in the core. At a casual glance, it would appear that balloon logic could be improved by combining it with similar logic as is used for lumpy reclaim. This comment is not intended to hurt the patch, but for the people working on CMM to consider if it hasn't been considered already. Has it been carefully compile- and run-time tested with CONFIG_MEMORY_HOTPLUG_SPARSE=n? Yes, I have compiled the kernel CONFIG_MEMORY_HOTPLUG_SPARSE=n and made sure that we didn't have any problems. The pfn_valid_within() was the biggie as far as the core is concerned. That sort of mistake causes fairly mad-looking oops. To be perfectly honest, I didn't review the powerpc-specific portion assuming that people are testing that and that there are developers more familiar with the area. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux net-2.6 build error for PPC
On Oct 9, 2009, at 12:49 PM, Ron Mercer wrote: I recently grabbed the latest net-2.6 kernel for a powerpc test box and got this compile error. CC arch/powerpc/kernel/cputable.o CC arch/powerpc/kernel/ptrace.o CC arch/powerpc/kernel/syscalls.o CC arch/powerpc/kernel/irq.o CC arch/powerpc/kernel/align.o CC arch/powerpc/kernel/signal_32.o CC arch/powerpc/kernel/pmc.o CC arch/powerpc/kernel/vdso.o cc1: warnings being treated as errors arch/powerpc/kernel/vdso.c:78: warning: alignment of âso_data_storeâs greater than maximum object file alignment. Using 32768 make[1]: *** [arch/powerpc/kernel/vdso.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 [r...@localhost linux-2.6-net.git]# Any suggestions would be appreciated. What config what compiler? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc/4xx: Add 16K FIFO size DTS entries on supported platforms
On Fri, 2009-10-09 at 07:50 -0400, Josh Boyer wrote: On Fri, Oct 09, 2009 at 01:15:54PM +1100, Benjamin Herrenschmidt wrote: On Thu, 2009-10-08 at 11:33 -0500, Dave Mitchell wrote: Adding tx/rx-fifo-size-gige to EMAC fields for evaluation kit DTS files where appropriate. Signed-off-by: Dave Mitchell dmitch...@appliedmicro.com Acked-by: Prodyut Hazarika phazar...@appliedmicro.com Acked-by: Victor Gallardo vgalla...@appliedmicro.com Acked-by: Loc Ho l...@appliedmicro.com --- v1-v2: local date/time was out-of-sync and thus mail was as well I'll have to wait for the EMAC patch to go in, so ping me if you don't see me take that one after that happens. I have some other DTS changes I'll be making soon. Mind if I pick it up in my tree to avoid headaches? I will, of course, wait until the EMAC patch is merged. Sure. Just assign it to yourself in PW Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pmac: Fix issues with sleep on some powerbooks
Since the change of how interrupts are disabled during suspend,
certain PowerBook models started exhibiting various issues during
suspend or resume from sleep.
I finally tracked it down to the code that runs various platform
functions (kind of little scripts extracted from the device-tree),
which uses our i2c and PMU drivers expecting interrutps to work,
and at a time where with the new scheme, they have been disabled.
This causes timeouts internally which for some reason results in
the PMU being unable to see the trackpad, among other issues, really
it depends on the machine. Most of the time, we fail to properly adjust
some clocks for suspend/resume so the results are not always
predictable.
This patch fixes it by using IRQF_TIMER for both the PMU and the I2C
interrupts. I prefer doing it this way than moving the call sites since
I really want those platform functions to still be called after all
drivers (and before sysdevs).
We also do a slight cleanup to via-pmu.c driver to make sure the
ADB autopoll mask is handled correctly when doing bus resets
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c
b/arch/powerpc/platforms/powermac/low_i2c.c
index 21226b7..414ca98 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -540,8 +540,11 @@ static struct pmac_i2c_host_kw *__init
kw_i2c_host_init(struct device_node *np)
/* Make sure IRQ is disabled */
kw_write_reg(reg_ier, 0);
- /* Request chip interrupt */
- if (request_irq(host-irq, kw_i2c_irq, 0, keywest i2c, host))
+ /* Request chip interrupt. We set IRQF_TIMER because we don't
+* want that interrupt disabled between the 2 passes of driver
+* suspend or we'll have issues running the pfuncs
+*/
+ if (request_irq(host-irq, kw_i2c_irq, IRQF_TIMER, keywest i2c, host))
host-irq = NO_IRQ;
printk(KERN_INFO KeyWest i2c @0x%08x irq %d %s\n,
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index b40fb9b..6f308a4 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -405,7 +405,11 @@ static int __init via_pmu_start(void)
printk(KERN_ERR via-pmu: can't map interrupt\n);
return -ENODEV;
}
- if (request_irq(irq, via_pmu_interrupt, 0, VIA-PMU, (void *)0)) {
+ /* We set IRQF_TIMER because we don't want the interrupt to be disabled
+* between the 2 passes of driver suspend, we control our own disabling
+* for that one
+*/
+ if (request_irq(irq, via_pmu_interrupt, IRQF_TIMER, VIA-PMU, (void
*)0)) {
printk(KERN_ERR via-pmu: can't request irq %d\n, irq);
return -ENODEV;
}
@@ -419,7 +423,7 @@ static int __init via_pmu_start(void)
gpio_irq = irq_of_parse_and_map(gpio_node, 0);
if (gpio_irq != NO_IRQ) {
- if (request_irq(gpio_irq, gpio1_interrupt, 0,
+ if (request_irq(gpio_irq, gpio1_interrupt, IRQF_TIMER,
GPIO1 ADB, (void *)0))
printk(KERN_ERR pmu: can't get irq %d
(GPIO1)\n, gpio_irq);
@@ -925,8 +929,7 @@ proc_write_options(struct file *file, const char __user
*buffer,
#ifdef CONFIG_ADB
/* Send an ADB command */
-static int
-pmu_send_request(struct adb_request *req, int sync)
+static int pmu_send_request(struct adb_request *req, int sync)
{
int i, ret;
@@ -1005,16 +1008,11 @@ pmu_send_request(struct adb_request *req, int sync)
}
/* Enable/disable autopolling */
-static int
-pmu_adb_autopoll(int devs)
+static int __pmu_adb_autopoll(int devs)
{
struct adb_request req;
- if ((vias == NULL) || (!pmu_fully_inited) || !pmu_has_adb)
- return -ENXIO;
-
if (devs) {
- adb_dev_map = devs;
pmu_request(req, NULL, 5, PMU_ADB_CMD, 0, 0x86,
adb_dev_map 8, adb_dev_map);
pmu_adb_flags = 2;
@@ -1027,9 +1025,17 @@ pmu_adb_autopoll(int devs)
return 0;
}
+static int pmu_adb_autopoll(int devs)
+{
+ if ((vias == NULL) || (!pmu_fully_inited) || !pmu_has_adb)
+ return -ENXIO;
+
+ adb_dev_map = devs;
+ return __pmu_adb_autopoll(devs);
+}
+
/* Reset the ADB bus */
-static int
-pmu_adb_reset_bus(void)
+static int pmu_adb_reset_bus(void)
{
struct adb_request req;
int save_autopoll = adb_dev_map;
@@ -1038,13 +1044,13 @@ pmu_adb_reset_bus(void)
return -ENXIO;
/* anyone got a better idea?? */
- pmu_adb_autopoll(0);
+ __pmu_adb_autopoll(0);
- req.nbytes = 5;
+ req.nbytes = 4;
req.done = NULL;
req.data[0] = PMU_ADB_CMD;
- req.data[1] = 0;
- req.data[2] =
Re: [PATCH 2/8] bitmap: Introduce bitmap_set, bitmap_clear, bitmap_find_next_zero_area
On Fri, 9 Oct 2009 17:29:15 +0900
Akinobu Mita akinobu.m...@gmail.com wrote:
This introduces new bitmap functions:
bitmap_set: Set specified bit area
bitmap_clear: Clear specified bit area
bitmap_find_next_zero_area: Find free bit area
These are stolen from iommu helper.
I changed the return value of bitmap_find_next_zero_area if there is
no zero area.
find_next_zero_area in iommu helper: returns -1
bitmap_find_next_zero_area: return = bitmap size
I'll plan to merge this patch into 2.6.32 so we can trickle all the
other patches into subsystems in an orderly fashion.
+void bitmap_set(unsigned long *map, int i, int len)
+{
+ int end = i + len;
+
+ while (i end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
This is really inefficient, isn't it? It's a pretty trivial matter to
romp through memory 32 or 64 bits at a time.
+EXPORT_SYMBOL(bitmap_set);
+
+void bitmap_clear(unsigned long *map, int start, int nr)
+{
+ int end = start + nr;
+
+ while (start end) {
+ __clear_bit(start, map);
+ start++;
+ }
+}
+EXPORT_SYMBOL(bitmap_clear);
Ditto.
+unsigned long bitmap_find_next_zero_area(unsigned long *map,
+ unsigned long size,
+ unsigned long start,
+ unsigned int nr,
+ unsigned long align_mask)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+
+ /* Align allocation */
+ index = (index + align_mask) ~align_mask;
+
+ end = index + nr;
+ if (end = size)
+ return end;
+ i = find_next_bit(map, end, index);
+ if (i end) {
+ start = i + 1;
+ goto again;
+ }
+ return index;
+}
+EXPORT_SYMBOL(bitmap_find_next_zero_area);
This needs documentation, please. It appears that `size' is the size
of the bitmap and `nr' is the number of zeroed bits we're looking for,
but an inattentive programmer could get those reversed.
Also the semantics of `align_mask' could benefit from spelling out. Is
the alignment with respect to memory boundaries or with respect to
`map' or with respect to map+start or what?
And why does align_mask exist at all? I was a bit surprised to see it
there. In which scenarios will it be non-zero?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
