Re: [PATCH] [POWERPC] Optimize counting distinct entries in the relocation sections
On Monday 12 November 2007 17:00:43 Paul Mackerras wrote: Emil Medve writes: (Not sure why the relocation tables could contain lots of duplicates and why they are not trimmed at compile time by the linker. In some test cases, out of 35K relocation entries only 1.5K were distinct/unique) Presumably you have lots of calls to the same function, or lots of references to the same variable. Yes, and objdump -r is your friend here. It might be worth checking that we're counting relocs in a section we actually care about (ie. it's SHF_ALLOC). It'd be a shame to optimize this only to find it could be fixed with a one-liner. The first is to use the st_other field in the symbol to record whether we have seen a R_PPC_REL24 reloc referring to the symbol with r_addend=0. That would make count_relocs of complexity O(N) for N relocs. Just note when you implement this: there may be two PLT entries per symbol: one for init code and one for core code. But that's just two bits. If Paul is right about r_addend=0 being common, you can simply count unique occurences of that, and add all the r_addend != 0 cases as if they were unique (note: it's fine to over-estimate). As far as your proposed patch is concerned, I don't like having a function called count_relocs changing the array of relocations. At the very least it needs a different name. Yes, and it should also return u32 not uint32_t if you're going to change the return type. Cheers, Rusty. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Silence an annoying boot message
Please use pr_debug() instead. Feel free to change the only other DBG() user in the file as well, and take out the define of it And for those who wonder where those DBG() come from, it's mostly me, from a time when either pr_debug wasn't around, or because I wanted to hook it to udbg_printf or other low level facilities before we had early debug console. There is no good reason to keep those around nowadays except bad habit :-) Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pcspkr device, pnpPNP,100
On Mon, 12 Nov 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote: Using this scheme, which platforms should select the pcspkr hardware? Run a poll :-) I suppose at least chrp/prep/pegasos And definitely not Amiga/APUS ;-) With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pcspkr device, pnpPNP,100
On 11/12/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Mon, 12 Nov 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote: Using this scheme, which platforms should select the pcspkr hardware? Run a poll :-) I suppose at least chrp/prep/pegasos And definitely not Amiga/APUS ;-) I found this device tree that has the pnpPNP,100 device for an Amiga. http://www.nabble.com/Re:-Problem-with-OF-interrupt-parsing-code-p12988017.html With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pcspkr device, pnpPNP,100
On Mon, 12 Nov 2007, Jon Smirl wrote: On 11/12/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Mon, 12 Nov 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote: Using this scheme, which platforms should select the pcspkr hardware? Run a poll :-) I suppose at least chrp/prep/pegasos And definitely not Amiga/APUS ;-) I found this device tree that has the pnpPNP,100 device for an Amiga. http://www.nabble.com/Re:-Problem-with-OF-interrupt-parsing-code-p12988017.html Ah yes, the AmigaOne. That's more a rebranded CHRP box... Has nothing to do with CONFIG_AMIGA. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC Update: New /dts-v1/ support!
Folks,
Dave and I have finally comes to an agreement [*1*] about
the new format for some literals in DTS files as supported
by the Device Tree Compiler.
With that, I have just pushed out some changes to the DTC
repository on jdl.com [*2*] that supports the new /dts-v1/
formatted files with C-like literal support.
I encourage everyone to upgrade to this version of the DTC
as soon as they can. Log messages for the three relevant
commits implementing it are below [*3*].
Please let me know if you have any problems with it!
Thanks,
jdl
[*1*] He beat me senseless until I relented.
[*2*] git://jdl.com/software/dtc.git
[*3*]
commit 91967acabdfbff8b44fd3a19f432bc6e690df8cc
Author: David Gibson [EMAIL PROTECTED]
Date: Wed Nov 7 11:17:37 2007 +1100
dtc: -Odts produces v1 output
This patch alters the -Odts mode output so that it uses dts-v1 format.
This means that dtc -Idts -Odts used on a v0 dts file will convert
that file to v1.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
commit 9138db565adeb2fbba3181fb589f1c9a3f818dde
Author: David Gibson [EMAIL PROTECTED]
Date: Wed Nov 7 11:17:17 2007 +1100
dtc: Switch dtc to C-style literals
dtc: Switch dtc to C-style literals
This patch introduces a new version of dts file, distinguished from
older files by starting with the special token /dts-v1/. dts files in
the new version take C-style literals instead of the old bare hex or
OF-style base notation. In addition, the range for of memreserve entries
(/memreserve/ f-f) is no longer recognized in the new format.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
commit 9ed27a2aac6f716d48854763a6d79f6a9857
Author: David Gibson [EMAIL PROTECTED]
Date: Wed Nov 7 11:16:19 2007 +1100
dtc: Simplify lexing/parsing of literals vs. node/property names
The current scheme of having CELLDATA and MEMRESERVE states to
recognize hex literals instead of node or property names is
arse-backwards. The patch switches things around so that literals are
lexed in normal states, and property/node names are only recognized in
the special PROPNODENAME state, which is only entered after a { or a
;, and is left as soon as we scan a property/node name or a keyword.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Signed-off-by: Jon Loeliger [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pcspkr device, pnpPNP,100
Original-Nachricht Datum: Mon, 12 Nov 2007 14:57:13 +0100 (CET) Von: Geert Uytterhoeven [EMAIL PROTECTED] An: Jon Smirl [EMAIL PROTECTED] CC: PowerPC dev list Linuxppc-dev@ozlabs.org Betreff: Re: pcspkr device, pnpPNP,100 On Mon, 12 Nov 2007, Jon Smirl wrote: On 11/12/07, Geert Uytterhoeven [EMAIL PROTECTED] wrote: On Mon, 12 Nov 2007, Benjamin Herrenschmidt wrote: On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote: Run a poll :-) I suppose at least chrp/prep/pegasos And definitely not Amiga/APUS ;-) I found this device tree that has the pnpPNP,100 device for an Amiga. http://www.nabble.com/Re:-Problem-with-OF-interrupt-parsing-code-p12988017.html Ah yes, the AmigaOne. That's more a rebranded CHRP box... Has nothing to do with CONFIG_AMIGA. Right. And it's not even officially supported in the kernel yet (unfortunately). regards, Gerhard -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC440EPx on Sequoia: /proc/iomem acts weird
This is on arch/powerpc. I traced through the linked lists in resource.c. Here is a partial list, with the addresses changed to single upper-case letters for readability. Also N is a null pointer: r=A p=N s=N c=K r=K p=A s=M c=P r=M p=A s=R c=N r=R p=A s=B c=N r=B p=B s=J c=B r=J p=A s=C c=N r=C p=A s=D c=N r=D p=A s=E c=N r=E p=A s=F c=N r=F p=A s=G c=N r=G p=A s=H c=N r=H p=A s=N c=N r=B p=B s=J c=B r=J p=A s=C c=N r=C p=A s=D c=N r is the resource itself, p is the parent, s is the sibling, and c is the child. As you can see, most nodes point back to parent A, and have null children. But one node, B, points to itself both as parent and child. I believe this is the problem, but I haven't confirmed that, nor have I determined how the list gets into this state. Steve Stefan Roese wrote: Hi Steve, On Friday 09 November 2007, Steven A. Falco wrote: I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia. Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it further. Is this arch/ppc or arch/powerpc? I remember fixing this a while ago in arch/ppc: commit 67a35ce785b1d11d09bf528c166ea26d489a4bd6 Author: Stefan Roese [EMAIL PROTECTED] Date: Thu Aug 2 14:15:22 2007 +0200 ppc: Fix problem with recursive NDFC platform_device resource management This change fixes a problem with a resursive platform_device resource management of the AMCC 4xx NDFC. Without this fix a cat /proc/iomem leads to an infinite loop of printing the ndfc-nand.0 resource. Signed-off-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do not depend on MAX_ORDER when grouping pages by mobility
On (12/11/07 13:21), Stephen Rothwell didst pronounce: I discovered recently that a kernel built with ppc64_defconfig no longer boots on legacy iSeries. It did in 2.6.23. I bisected down the commit d9c2340052278d8eb2ffb16b0484f8f794def4de (Do not depend on MAX_ORDER when grouping pages by mobility) which fails while its parent is ok. Also, an iseries_defconfig kernel will boot. The reason it seem is because on PowerPC 64 with CONFIG_HUGETLB_PAGE, HPAGE_SHIFT is not constant and its value is determined at runtime early. Ok, that in itself is ok. IA-64 does something similar. For legacy iSeries HPAGE_SHIFT remains 0 which means that HUGETLB_PAGE_ORDER becomes -PAGE_SHIFT and things degenerate badly. D'oh. That would have problems for sure. I can enable CONFIG_HUGETLB_PAGE_SIZE_VARIABLE for PowerPC 64, but I still need to know a good value for HPAGE_SHIFT. Do you have a suggestion? Is there a better way to fix this problem? There are places in the PowerPC code that assume that HPAGE_SHIFT == 0 means that we have no huge pages. How about the following both in terms of taste and whether it works or not? === Ordinarily, the size of a pageblock is determined from the hugepage size. On PPC64, the hugepage size is determined at runtime based on the ability of the machine. If the machine does not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order being set to -PAGE_SHIFT and a crash results shortly afterwards. This patch checks that HPAGE_SHIFT is a sensible value before using the hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible value of pageblock_order. Signed-off-by: Mel Gorman [EMAIL PROTECTED] --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 18f397c..232c298 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER default 9 if PPC_64K_PAGES default 13 +config HUGETLB_PAGE_SIZE_VARIABLE + bool + depends on HUGETLB_PAGE + default y + config MATH_EMULATION bool Math emulation depends on 4xx || 8xx || E200 || PPC_MPC832x || E500 diff --git a/mm/page_alloc.c b/mm/page_alloc.c index da69d83..14e0ac3 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -3386,7 +3386,16 @@ static void __meminit free_area_init_core(struct pglist_data *pgdat, if (!size) continue; - set_pageblock_order(HUGETLB_PAGE_ORDER); + /* +* If HPAGE_SHIFT is a sensible value, base the size of a +* pageblock on the hugepage size. Otherwise MAX_ORDER-1 +* is a sensible choice +*/ + if (HPAGE_SHIFT PAGE_SHIFT) + set_pageblock_order(HUGETLB_PAGE_ORDER); + else + set_pageblock_order(MAX_ORDER-1); + setup_usemap(pgdat, zone, size); ret = init_currently_empty_zone(zone, zone_start_pfn, size, MEMMAP_EARLY); -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. - Don't remove the pmu_polled_request() debug code. It's very useful for debugging and I don't want to have to re-invent it. Heh, ok. Plus I also need to test it on some exotic hardware :-) Obviously. I don't have any of that. I'd appreciate if somebody could test on a 3400 powerbook to see if that pci config space save/restore stuff is really necessary or even interferes with the regular stuff. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] PMU: replace information ioctls and schedule for removal
On Mon, 2007-11-12 at 07:55 +1100, Benjamin Herrenschmidt wrote: On Thu, 2007-11-08 at 13:02 +0100, Johannes Berg wrote: This patch adds sysfs attributes to the PMU to allow getting the information on the PMU type and whether adb is present from there instead of via the ioctl. The ioctl is made optional and scheduled for removal. Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- While there, maybe also expose the PMU version ? Does anybody need that? I'm not against adding it but we never showed it and I haven't seen anyone ask for it. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Optimize counting distinct entries in the relocation sections
Hello Paul, Actually I notice that count_relocs is counting all relocs, not just the R_PPC_REL24 ones, which are all that we actually care about in sizing the PLT. And I would be willing to bet that every single R_PPC_REL24 reloc has r_addend == 0. I'll count only the R_PPC_REL24 and I'll validate if they have r_addend == 0. Also I notice that even with your patch, the actual process of doing the relocations will take time proportional to the product of the number of PLT entries times the number of R_PPC_REL24 relocations, since we do a linear search through the PLT entries each time. The reason I started working on this patch was because the kernel detected a soft lockup in count_relocs(). It didn't complain about other parts so I did nothing about them. So, two approaches suggest themselves. Both optimize the r_addend=0 case and fall back to something like the current code if r_addend is not zero. The first is to use the st_other field in the symbol to record whether we have seen a R_PPC_REL24 reloc referring to the symbol with r_addend=0. That would make count_relocs of complexity O(N) for N relocs. Will look into it. The second is to allocate an array with 1 pointer per symbol that points to the PLT entry (if any) for the symbol. The count_relocs scan can then use that array to store a 'seen before' flag to make its scan O(N), and do_plt_call can then later use the same array to find PLT entries without needing the linear scan. This uses extra memory (which could be 'significant' for small boards) and I was trying to avoid that. As far as your proposed patch is concerned, I don't like having a function called count_relocs changing the array of relocations. At the very least it needs a different name. But I also think we can do better than O(N * log N), as I have explained above, if my assertion that r_addend=0 in all the cases we care about is correct. The array of relocations is not changed in count_relocs() but in get_plt_size(). Thanks for your time and patience, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Merge dtc and libfdt upstream source
On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote: This very large patch incorporates a copy of dtc (including libfdt) into the kernel source, in arch/powerpc/boot/dtc-src. This patch only imports the upstream sources verbatim, later patches are needed to actually link it into the kernel Makefiles and use the embedded code during the kernel build. Maybe it should go somewhere outside arch/powerpc, so it can be used by other architectures down the road. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] sungem: fix suspend regression due to NAPI changes
Commit bea3348e (the NAPI changes) made sungem unconditionally enable
NAPI when resuming and unconditionally disable when suspending, this,
however, makes napi_disable() hang when suspending when the interface
was taken down before suspend because taking the interface down also
disables NAPI. This patch makes touching the napi struct in
suspend/resume code paths depend on having the interface up, thereby
fixing the hang on suspend.
The patch also moves the napi_disable() in gem_close() under the lock so
that the NAPI state is always modified atomically together with the
opened variable.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
drivers/net/sungem.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
--- everything.orig/drivers/net/sungem.c2007-11-12 18:22:49.948748047
+0100
+++ everything/drivers/net/sungem.c 2007-11-12 18:24:30.708748481 +0100
@@ -2333,10 +2333,10 @@ static int gem_close(struct net_device *
{
struct gem *gp = dev-priv;
- napi_disable(gp-napi);
-
mutex_lock(gp-pm_mutex);
+ napi_disable(gp-napi);
+
gp-opened = 0;
if (!gp-asleep)
gem_do_stop(dev, 0);
@@ -2355,8 +2355,6 @@ static int gem_suspend(struct pci_dev *p
mutex_lock(gp-pm_mutex);
- napi_disable(gp-napi);
-
printk(KERN_INFO %s: suspending, WakeOnLan %s\n,
dev-name,
(gp-wake_on_lan gp-opened) ? enabled : disabled);
@@ -2370,6 +2368,8 @@ static int gem_suspend(struct pci_dev *p
/* If the driver is opened, we stop the MAC */
if (gp-opened) {
+ napi_disable(gp-napi);
+
/* Stop traffic, mark us closed */
netif_device_detach(dev);
@@ -2460,6 +2460,7 @@ static int gem_resume(struct pci_dev *pd
/* Re-attach net device */
netif_device_attach(dev);
+ napi_enable(gp-napi);
}
spin_lock_irqsave(gp-lock, flags);
@@ -2479,8 +2480,6 @@ static int gem_resume(struct pci_dev *pd
spin_unlock(gp-tx_lock);
spin_unlock_irqrestore(gp-lock, flags);
- napi_enable(gp-napi);
-
mutex_unlock(gp-pm_mutex);
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/4] Merge dtc and libfdt upstream source
-Original Message- From: [EMAIL PROTECTED] g [mailto:[EMAIL PROTECTED] zlabs.org] On Behalf Of Scott Wood Sent: Monday, November 12, 2007 9:13 AM To: David Gibson Cc: linuxppc-dev@ozlabs.org; Paul Mackerras Subject: Re: [PATCH 1/4] Merge dtc and libfdt upstream source On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote: This very large patch incorporates a copy of dtc (including libfdt) into the kernel source, in arch/powerpc/boot/dtc-src. This patch only imports the upstream sources verbatim, later patches are needed to actually link it into the kernel Makefiles and use the embedded code during the kernel build. Maybe it should go somewhere outside arch/powerpc, so it can be used by other architectures down the road. -Scott I second that... Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PPC440EPx on Sequoia: /proc/iomem acts weird
First I will say that I don't understand resources well enough to suggest a fix. But I have done a little poking around. In file arch/powerpc/platforms/44x/ppc4xx-nand.c I see one struct resource, which is referenced by two struct platform_device items (ndfc_dev and nand_dev). In routine ppc4xx_setup_nand_node() we have two calls to platform_device_register(): platform_device_register(ndfc_dev); platform_device_register(nand_dev); If I comment out the second one, then there is no loop in the resource tree, and I can cat /proc/iomem just fine. If both calls are present, then cat /proc/iomem loops forever. So, just a wild guess - should there be two struct resources, one for each platform_device, or is there some other way to break the loop in the tree? Steve Stefan Roese wrote: Hi Steve, On Friday 09 November 2007, Steven A. Falco wrote: I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia. Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it further. Is this arch/ppc or arch/powerpc? I remember fixing this a while ago in arch/ppc: commit 67a35ce785b1d11d09bf528c166ea26d489a4bd6 Author: Stefan Roese [EMAIL PROTECTED] Date: Thu Aug 2 14:15:22 2007 +0200 ppc: Fix problem with recursive NDFC platform_device resource management This change fixes a problem with a resursive platform_device resource management of the AMCC 4xx NDFC. Without this fix a cat /proc/iomem leads to an infinite loop of printing the ndfc-nand.0 resource. Signed-off-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 12 Nov 2007, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Isn't it true that the freezer _already_ isn't enabled on PPC? So leaving it off wouldn't break anything more than it is broken now. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] powermac: proper sleep management
On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. Obviously. I don't have any of that. I'd appreciate if somebody could test on a 3400 powerbook to see if that pci config space save/restore stuff is really necessary or even interferes with the regular stuff. Might not be that necessary anymore nowadays, the generic code ought to do it, but I'll give a go, I have one of those (paulus old one) though last I tried, the HD was dead. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/cbe_cpufreq.c |3 ++- arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c |3 ++- arch/powerpc/platforms/cell/cbe_regs.c|4 ++-- arch/powerpc/platforms/cell/iommu.c |2 +- arch/powerpc/platforms/cell/setup.c |2 +- 5 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c index 13d5a87..ec7c8f4 100644 --- a/arch/powerpc/platforms/cell/cbe_cpufreq.c +++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c @@ -21,8 +21,9 @@ */ #include linux/cpufreq.h +#include linux/of_platform.h + #include asm/machdep.h -#include asm/of_platform.h #include asm/prom.h #include asm/cell-regs.h #include cbe_cpufreq.h diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c index 6a2c1b0..69288f6 100644 --- a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c +++ b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c @@ -23,7 +23,8 @@ #include linux/kernel.h #include linux/types.h #include linux/timer.h -#include asm/of_platform.h +#include linux/of_platform.h + #include asm/processor.h #include asm/prom.h #include asm/pmi.h diff --git a/arch/powerpc/platforms/cell/cbe_regs.c b/arch/powerpc/platforms/cell/cbe_regs.c index 16a9b07..a839c6c 100644 --- a/arch/powerpc/platforms/cell/cbe_regs.c +++ b/arch/powerpc/platforms/cell/cbe_regs.c @@ -9,13 +9,13 @@ #include linux/percpu.h #include linux/types.h #include linux/module.h +#include linux/of_device.h +#include linux/of_platform.h #include asm/io.h #include asm/pgtable.h #include asm/prom.h #include asm/ptrace.h -#include asm/of_device.h -#include asm/of_platform.h #include asm/cell-regs.h /* diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c index faabc3f..179ba2e 100644 --- a/arch/powerpc/platforms/cell/iommu.c +++ b/arch/powerpc/platforms/cell/iommu.c @@ -26,13 +26,13 @@ #include linux/init.h #include linux/interrupt.h #include linux/notifier.h +#include linux/of_platform.h #include asm/prom.h #include asm/iommu.h #include asm/machdep.h #include asm/pci-bridge.h #include asm/udbg.h -#include asm/of_platform.h #include asm/lmb.h #include asm/cell-regs.h diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c index 98e7ef8..4f6347c 100644 --- a/arch/powerpc/platforms/cell/setup.c +++ b/arch/powerpc/platforms/cell/setup.c @@ -30,6 +30,7 @@ #include linux/console.h #include linux/mutex.h #include linux/memory_hotplug.h +#include linux/of_platform.h #include asm/mmu.h #include asm/processor.h @@ -51,7 +52,6 @@ #include asm/spu_priv1.h #include asm/udbg.h #include asm/mpic.h -#include asm/of_platform.h #include asm/cell-regs.h #include interrupt.h -- 1.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. (It's true that USB drivers in general aren't written to operate in a freezerless system-suspend environment. That's a harder problem and it will have to be fixed driver-by-driver, over time. The same may be true for lots of non-USB char device drivers as well. Pick your favorite char device driver: How will it behave if a user task submits an I/O request after the device has been suspended?) Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Mon, 2007-11-12 at 15:40 -0500, Alan Stern wrote: On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote: Looks good to me, +/- a couple of things: - We _REALLY_ want the freezer to be optional and not enabled by default on PowerPC. Maybe make it a compile option ? Well, Alan is going to tell you that USB will break. If we need confirmation for that I can do the test he suggested to you or Paul a while ago. Then USB is broken today on powermacs and need to be fixed. We had a clear agreement at KS this year that the freezer was at best a band-aid and that drivers -had- to be fixed to cope regardless. More accurately, freezing user tasks is at best a band-aid. However some kernel threads do need to be frozen, and keeping the freezer around for their use makes sense. It has less overhead -- I think -- than adding new code to do the freezing in each of these threads. I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar ethernet device
On 11/11/07, Jon Smirl [EMAIL PROTECTED] wrote:
On 11/11/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
The real solution is that gianfar support belongs in a device driver,
not in a common file. That whole fsl_soc.c file is a catch-all of
things that belong in device drivers. I haven't looked at every line
in it, but 90%+ of the code should be moved into device drivers.
I'm preparing a patch that moves the i2c driver out of fsl_soc.c and
into i2c_mpc.c.
The problem is how do you instantiate it. I'm working on some solution
for that but it's not there yet.
What's an example of a device that can't be instantiated?
Are there powerpc platforms without device trees?
Standard of_platform driver works fine to instantiate the i2c driver
on mpc5200.
static struct of_device_id mpc_i2c_of_match[] = {
{
.compatible = fsl-i2c,
},
};
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
/* Structure for a device driver */
static struct of_platform_driver mpc_i2c_driver = {
.match_table= mpc_i2c_of_match,
.probe = mpc_i2c_probe,
.remove = __devexit_p(mpc_i2c_remove),
.driver = {
.owner = THIS_MODULE,
.name = DRV_NAME,
},
};
static int __init mpc_i2c_init(void)
{
int rv;
rv = of_register_platform_driver(mpc_i2c_driver);
if (rv) {
printk(KERN_ERR DRV_NAME of_register_platform_driver failed
(%i)\n, rv);
return rv;
}
return 0;
}
module_init(mpc_i2c_init);
--
i2c and alsa soc core instantiate like this, asoc v2 is not in tree
yet. These cores used to create platform drivers, but that was wrong,
they don't have any hardware associated with them.
static int __init i2c_init(void)
{
int retval;
retval = bus_register(i2c_bus_type);
if (retval)
return retval;
return class_register(i2c_adapter_class);
}
subsys_initcall(i2c_init);
--
Jon Smirl
[EMAIL PROTECTED]
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [linux-pm] Re: [RFC] powermac: proper sleep management
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote: I remember fixing various issues so that khubd would be safe when non frozen (among other things) a while ago. Did you guys break it all again ? Sorry, I don't know what fixes you're referring to. But come to think of it, some changes I added to the PM core a few months ago (locking every device prior to system sleep) would also make khubd and ksuspend_usbd safe, since they acquire the device lock before trying to resume anything. So I take back what I said. It's no longer true that those two USB kernel threads need to be frozen for system sleep. (I should test and make sure that really works...) But aren't there other kernel threads scattered around that still want to be frozen? For instance, drivers/misc/tifm_core.c calls create_freezeable_workqueue(). And set_freezable() gets called in lots of places. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
Stephen Rothwell wrote:
On Fri, 09 Nov 2007 18:12:02 +0100 Marian Balakowicz [EMAIL PROTECTED]
wrote:
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
+static int __init mpc5200_simple_probe(void)
+{
+unsigned long node = of_get_flat_dt_root();
You need to include asm/prom.h to use the flattened device tree accessors.
Right, but this one is already included in mpc52xx.h.
+/* list of the supported boards */
+const char *board[] = {
+tqc,tqm5200,
+promess,motionpro,
+schindler,cm5200,
+NULL
+};
Make that static.
Board table is no longer needed after kernel is initialized, it would
be nice to declare it static and __initdata, but that would be quite
ugly as it's a table of pointers and each string would require
separate statement too. If we don't do it then what's the benefit of
making it static?
Cheers,
m.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
Grant Likely wrote: On 11/9/07, Grant Likely [EMAIL PROTECTED] wrote: On 11/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote: Please review, and if everything is ok schedule for 2.6.24-rc3. Just to be clear, I won't be picking up these changes until the 2.6.25 merge window. The .24 tree is closed for new board support patches and is in bug fix only mode. Ummm; on rereading this (after getting gently nudged on IRC) I realize my reply was both inaccurate and just plain rude. Sorry about that, it was unintentional. Not a problem, really, no worries. Yes, I'll be picking up your patches into my tree fairly soon (before the .25 merge window opens), but I cannot ask Paul to pick it up for 2.6.24 because .24 is only open for bug fixes. Understand, thanks! Cheers, Marian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
Wolfgang Denk wrote:
In message [EMAIL PROTECTED] you wrote:
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
...
+const char *board[] = {
+tqc,tqm5200,
+promess,motionpro,
+schindler,cm5200,
+NULL
+};
would it make sense to sort this list alphabetiacally? At the moment
we can setill easily find each board, but assume that list grows to 50
boards names...
Yes, that may be helpful, will change that.
Cheers,
Marian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Optimize counting distinct entries in therelocation sections
Hello Paul, Actually I notice that count_relocs is counting all relocs, not just the R_PPC_REL24 ones, which are all that we actually care about in sizing the PLT. And I would be willing to bet that every single R_PPC_REL24 reloc has r_addend == 0. I'll count only the R_PPC_REL24 and I'll validate if they have r_addend == 0. Seems like there are R_PPC_REL24 with r_addend != 0. Within a set of 41 modules (featuring 5457 R_PPC_REL24 relocations) already included within the kernel tree I found 37 such relocations (R_PPC_REL24) with r_addend != 0. In my test case, from 35K relocations, 7K are R_PPC_REL24 and from those only 8 have r_addend != 0. Also I notice that even with your patch, the actual process of doing the relocations will take time proportional to the product of the number of PLT entries times the number of R_PPC_REL24 relocations, since we do a linear search through the PLT entries each time. The reason I started working on this patch was because the kernel detected a soft lockup in count_relocs(). It didn't complain about other parts so I did nothing about them. Since the time hog in my case (and other's cases, reflected by the previous patches) seems to be count_relocs(), would it be acceptable as an incremental improvement to fix this now and address the relocation process performance (later) if needed? I'll resubmit the patch incorporating some of the feedback from you and Rusty. Cheers, Emil. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sungem: fix suspend regression due to NAPI changes
On Mon, 2007-11-12 at 18:45 +0100, Johannes Berg wrote:
Commit bea3348e (the NAPI changes) made sungem unconditionally enable
NAPI when resuming and unconditionally disable when suspending, this,
however, makes napi_disable() hang when suspending when the interface
was taken down before suspend because taking the interface down also
disables NAPI. This patch makes touching the napi struct in
suspend/resume code paths depend on having the interface up, thereby
fixing the hang on suspend.
The patch also moves the napi_disable() in gem_close() under the lock so
that the NAPI state is always modified atomically together with the
opened variable.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Thanks for fixing that !
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
---
drivers/net/sungem.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
--- everything.orig/drivers/net/sungem.c 2007-11-12 18:22:49.948748047
+0100
+++ everything/drivers/net/sungem.c 2007-11-12 18:24:30.708748481 +0100
@@ -2333,10 +2333,10 @@ static int gem_close(struct net_device *
{
struct gem *gp = dev-priv;
- napi_disable(gp-napi);
-
mutex_lock(gp-pm_mutex);
+ napi_disable(gp-napi);
+
gp-opened = 0;
if (!gp-asleep)
gem_do_stop(dev, 0);
@@ -2355,8 +2355,6 @@ static int gem_suspend(struct pci_dev *p
mutex_lock(gp-pm_mutex);
- napi_disable(gp-napi);
-
printk(KERN_INFO %s: suspending, WakeOnLan %s\n,
dev-name,
(gp-wake_on_lan gp-opened) ? enabled : disabled);
@@ -2370,6 +2368,8 @@ static int gem_suspend(struct pci_dev *p
/* If the driver is opened, we stop the MAC */
if (gp-opened) {
+ napi_disable(gp-napi);
+
/* Stop traffic, mark us closed */
netif_device_detach(dev);
@@ -2460,6 +2460,7 @@ static int gem_resume(struct pci_dev *pd
/* Re-attach net device */
netif_device_attach(dev);
+ napi_enable(gp-napi);
}
spin_lock_irqsave(gp-lock, flags);
@@ -2479,8 +2480,6 @@ static int gem_resume(struct pci_dev *pd
spin_unlock(gp-tx_lock);
spin_unlock_irqrestore(gp-lock, flags);
- napi_enable(gp-napi);
-
mutex_unlock(gp-pm_mutex);
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Merge dtc and libfdt upstream source
On Mon, Nov 12, 2007 at 11:12:40AM -0600, Scott Wood wrote: On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote: This very large patch incorporates a copy of dtc (including libfdt) into the kernel source, in arch/powerpc/boot/dtc-src. This patch only imports the upstream sources verbatim, later patches are needed to actually link it into the kernel Makefiles and use the embedded code during the kernel build. Maybe it should go somewhere outside arch/powerpc, so it can be used by other architectures down the road. If other architectures want to use it down the road, we can move it down the road. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] remove prod_processor()
prod_processor() is unused, and that's a good thing, since it does not
supply the required proc id parameter to H_PROD.
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/plpar_wrappers.h |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h
b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index d003c80..d8680b5 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -8,11 +8,6 @@ static inline long poll_pending(void)
return plpar_hcall_norets(H_POLL_PENDING);
}
-static inline long prod_processor(void)
-{
- return plpar_hcall_norets(H_PROD);
-}
-
static inline long cede_processor(void)
{
return plpar_hcall_norets(H_CEDE);
--
1.5.3.4.206.g58ba4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
dtc: Add missing dependencies for tests
At present, the Makefiles will not rebuild trees.o or the dtb files derived from it if testdata.h is updated. This is incorrect, and is because of missing dependency information. This patch fixes the problem by making sure that dependency information is generated from trees.S and dumptrees.c. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/Makefile === --- dtc.orig/Makefile 2007-11-12 17:57:11.0 +1100 +++ dtc/Makefile2007-11-12 17:57:23.0 +1100 @@ -188,6 +188,10 @@ clean: libfdt_clean tests_clean @$(VECHO) DEP $ $(CC) $(CPPFLAGS) -MM -MG -MT $*.o $@ $ $@ +%.d: %.S + @$(VECHO) DEP $ + $(CC) $(CPPFLAGS) -MM -MG -MT $*.o $@ $ $@ + %.i: %.c @$(VECHO) CPP $@ $(CC) $(CPPFLAGS) -E $ $@ Index: dtc/tests/Makefile.tests === --- dtc.orig/tests/Makefile.tests 2007-11-12 17:56:29.0 +1100 +++ dtc/tests/Makefile.tests2007-11-12 18:02:44.0 +1100 @@ -21,7 +21,8 @@ TESTS_TREES = $(TESTS_TREES_L:%=$(TESTS_ TESTS_TARGETS = $(TESTS) $(TESTS_TREES) -TESTS_DEPFILES = $(TESTS:%=%.d) $(TESTS_PREFIX)testutils.d +TESTS_DEPFILES = $(TESTS:%=%.d) \ + $(addprefix $(TESTS_PREFIX),testutils.d trees.d dumptrees.d) TESTS_CLEANFILES_L = *.output vgcore.* *.dtb *.test.dts TESTS_CLEANFILES = $(TESTS_CLEANFILES_L:%=$(TESTS_PREFIX)%) -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[1/2] libfdt: Add phandle related functions
This patch adds fdt_get_phandle() and fdt_node_offset_by_phandle() functions to libfdt. fdt_get_phandle() will retreive the phandle value of a given node, and fdt_node_offset_by_phandle() will locate a node given a phandle. Signed-off-by: David Gibson [EMAIL PROTECTED] Index: dtc/libfdt/libfdt.h === --- dtc.orig/libfdt/libfdt.h2007-11-12 19:11:55.0 +1100 +++ dtc/libfdt/libfdt.h 2007-11-12 20:11:12.0 +1100 @@ -78,29 +78,32 @@ /* FDT_ERR_BADPATH: Function was passed a badly formatted path * (e.g. missing a leading / for a function which requires an * absolute path) */ -#define FDT_ERR_BADSTATE 6 +#define FDT_ERR_BADPHANDLE 6 + /* FDT_ERR_BADPHANDLE: Function was passed an invalid phandle +* value. phandle values of 0 and -1 are not permitted. */ +#define FDT_ERR_BADSTATE 7 /* FDT_ERR_BADSTATE: Function was passed an incomplete device * tree created by the sequential-write functions, which is * not sufficiently complete for the requested operation. */ /* Error codes: codes for bad device tree blobs */ -#define FDT_ERR_TRUNCATED 7 +#define FDT_ERR_TRUNCATED 8 /* FDT_ERR_TRUNCATED: Structure block of the given device tree * ends without an FDT_END tag. */ -#define FDT_ERR_BADMAGIC 8 +#define FDT_ERR_BADMAGIC 9 /* FDT_ERR_BADMAGIC: Given device tree appears not to be a * device tree at all - it is missing the flattened device * tree magic number. */ -#define FDT_ERR_BADVERSION 9 +#define FDT_ERR_BADVERSION 10 /* FDT_ERR_BADVERSION: Given device tree has a version which * can't be handled by the requested operation. For * read-write functions, this may mean that fdt_open_into() is * required to convert the tree to the expected version. */ -#define FDT_ERR_BADSTRUCTURE 10 +#define FDT_ERR_BADSTRUCTURE 11 /* FDT_ERR_BADSTRUCTURE: Given device tree has a corrupt * structure block or other serious error (e.g. misnested * nodes, or subnodes preceding properties). */ -#define FDT_ERR_BADLAYOUT 11 +#define FDT_ERR_BADLAYOUT 12 /* FDT_ERR_BADLAYOUT: For read-write functions, the given * device tree has it's sub-blocks in an order that the * function can't handle (memory reserve map, then structure, @@ -108,12 +111,12 @@ * into a form suitable for the read-write operations. */ /* Can't happen error indicating a bug in libfdt */ -#define FDT_ERR_INTERNAL 12 +#define FDT_ERR_INTERNAL 13 /* FDT_ERR_INTERNAL: libfdt has failed an internal assertion. * Should never be returned, if it is, it indicates a bug in * libfdt itself. */ -#define FDT_ERR_MAX12 +#define FDT_ERR_MAX13 /**/ /* Low-level functions (you probably don't need these)*/ @@ -412,6 +415,20 @@ } /** + * fdt_get_phandle - retreive the phandle of a given node + * @fdt: pointer to the device tree blob + * @nodeoffset: structure block offset of the node + * + * fdt_get_phandle() retrieves the phandle of the device tree node at + * structure block offset nodeoffset. + * + * returns: + * the phandle of the node at nodeoffset, on succes (!= 0, != -1) + * 0, if the node has no phandle, or another error occurs + */ +uint32_t fdt_get_phandle(const void *fdt, int nodeoffset); + +/** * fdt_get_path - determine the full path of a node * @fdt: pointer to the device tree blob * @nodeoffset: offset of the node whose path to find @@ -558,6 +575,27 @@ const void *propval, int proplen); /** + * fdt_node_offset_by_phandle - find the node with a given phandle + * @fdt: pointer to the device tree blob + * @phandle: phandle value + * + * fdt_node_offset_by_prop_value() returns the offset of the node + * which has the given phandle value. If there is more than one node + * in the tree with the given phandle (an invalid tree), results are + * undefined. + * + * returns: + * structure block offset of the located node (= 0), on success + * -FDT_ERR_NOTFOUND, no node with that phandle exists + * -FDT_ERR_BADPHANDLE, given phandle value was invalid (0 or -1) + * -FDT_ERR_BADMAGIC, + * -FDT_ERR_BADVERSION, + * -FDT_ERR_BADSTATE, + * -FDT_ERR_BADSTRUCTURE, standard meanings + */ +int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle); + +/** * fdt_node_check_compatible: check a node's compatible property * @fdt: pointer to the device tree blob * @nodeoffset: offset of a tree node Index: dtc/tests/testdata.h === --- dtc.orig/tests/testdata.h 2007-11-12 19:11:55.0 +1100 +++ dtc/tests/testdata.h2007-11-12
[2/2] dtc: Add testcase for dtc references
This patch adds a testcase for dtc's reference-to-phandle
functionality.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/tests/references.dts
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/references.dts2007-11-12 20:47:05.0 +1100
@@ -0,0 +1,23 @@
+/dts-v1/;
+
+/ {
+ /* Explicit phandles */
+ n1: node1 {
+ linux,phandle = 0x2000;
+ ref = /node2; /* reference precedes target */
+ lref = n2;
+ };
+ n2: node2 {
+ linux,phandle = 0x1;
+ ref = /node1; /* reference after target */
+ lref = n1;
+ };
+
+ /* Implicit phandles */
+ n3: node3 {
+ ref = /node4;
+ lref = n4;
+ };
+ n4: node4 {
+ };
+};
Index: dtc/tests/Makefile.tests
===
--- dtc.orig/tests/Makefile.tests 2007-11-12 20:49:56.0 +1100
+++ dtc/tests/Makefile.tests2007-11-12 20:50:01.0 +1100
@@ -9,7 +9,8 @@
sw_tree1 \
move_and_save mangle-layout \
open_pack rw_tree1 setprop del_property del_node \
- string_escapes dtbs_equal_ordered
+ string_escapes references \
+ dtbs_equal_ordered
LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
LIBTREE_TESTS_L = truncated_property
Index: dtc/tests/references.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/references.c 2007-11-12 21:23:33.0 +1100
@@ -0,0 +1,100 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for phandle references in dtc
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include stdint.h
+
+#include fdt.h
+#include libfdt.h
+
+#include tests.h
+#include testdata.h
+
+void check_ref(const void *fdt, int node, uint32_t checkref)
+{
+ const uint32_t *p;
+ uint32_t ref;
+ int len;
+
+ p = fdt_getprop(fdt, node, ref, len);
+ if (!p)
+ FAIL(fdt_getprop(%d, \ref\): %s, node, fdt_strerror(len));
+ if (len != sizeof(*p))
+ FAIL('ref' in node at %d has wrong size (%d instead of %d),
+node, len, sizeof(*p));
+ ref = fdt32_to_cpu(*p);
+ if (ref != checkref)
+ FAIL('ref' in node at %d has value 0x%x instead of 0x%x,
+node, ref, checkref);
+
+ p = fdt_getprop(fdt, node, lref, len);
+ if (!p)
+ FAIL(fdt_getprop(%d, \lref\): %s, node, fdt_strerror(len));
+ if (len != sizeof(*p))
+ FAIL('lref' in node at %d has wrong size (%d instead of %d),
+node, len, sizeof(*p));
+ ref = fdt32_to_cpu(*p);
+ if (ref != checkref)
+ FAIL('lref' in node at %d has value 0x%x instead of 0x%x,
+node, ref, checkref);
+}
+
+int main(int argc, char *argv[])
+{
+ void *fdt;
+ int n1, n2, n3, n4;
+ uint32_t h1, h2, h4;
+
+ test_init(argc, argv);
+ fdt = load_blob_arg(argc, argv);
+
+ n1 = fdt_path_offset(fdt, /node1);
+ if (n1 0)
+ FAIL(fdt_path_offset(/node1): %s, fdt_strerror(n1));
+ n2 = fdt_path_offset(fdt, /node2);
+ if (n2 0)
+ FAIL(fdt_path_offset(/node2): %s, fdt_strerror(n2));
+ n3 = fdt_path_offset(fdt, /node3);
+ if (n3 0)
+ FAIL(fdt_path_offset(/node3): %s, fdt_strerror(n3));
+ n4 = fdt_path_offset(fdt, /node4);
+ if (n4 0)
+ FAIL(fdt_path_offset(/node4): %s, fdt_strerror(n4));
+
+ h1 = fdt_get_phandle(fdt, n1);
+ h2 = fdt_get_phandle(fdt, n2);
+ h4 = fdt_get_phandle(fdt, n4);
+
+ if (h1 != 0x2000)
+ FAIL(/node1 has wrong phandle, 0x%x instead of 0x%x,
+h1, 0x2000);
+ if (h2 != 0x1)
+ FAIL(/node2 has wrong phandle, 0x%x instead of 0x%x,
+h2, 0x1);
+ if ((h4 == 0x2000) || (h4 == 0x1) || (h4 == 0))
+ FAIL(/node4 has bad
Re: [RFC] PMU: replace information ioctls and schedule for removal
Johannes Berg writes: Does anybody need that? I'm not against adding it but we never showed it and I haven't seen anyone ask for it. pmud uses the PMU version, but I think it gets it by issuing a PMU command. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
Hi Jon, Thanks for this. On Mon, 12 Nov 2007 14:26:51 -0600 Jon Loeliger [EMAIL PROTECTED] wrote: From: Jon Loeliger [EMAIL PROTECTED] Signed-off-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Stephen Rothwell [EMAIL PROTECTED] Built a ppc64_defconfig -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp40tW1SxQzg.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
On Mon, 12 Nov 2007 23:22:16 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
On Fri, 09 Nov 2007 18:12:02 +0100 Marian Balakowicz [EMAIL PROTECTED]
wrote:
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
+static int __init mpc5200_simple_probe(void)
+{
+ unsigned long node = of_get_flat_dt_root();
You need to include asm/prom.h to use the flattened device tree accessors.
Right, but this one is already included in mpc52xx.h.
But you should directly include it since you are using stuff declared in
there. Depending on indirect includes is fragile (someone might take it
out of mpc52xx.h one day).
+ /* list of the supported boards */
+ const char *board[] = {
+ tqc,tqm5200,
+ promess,motionpro,
+ schindler,cm5200,
+ NULL
+ };
Make that static.
Board table is no longer needed after kernel is initialized, it would
be nice to declare it static and __initdata, but that would be quite
ugly as it's a table of pointers and each string would require
separate statement too. If we don't do it then what's the benefit of
making it static?
Except the way it currently is, the data stays in the kernel image. If
you declared it static and __initdata then at least the table would
actually go away at run time. True, to make the strings go away is
harder.
Doesn't actually matter much.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpfoKFrnduPS.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] sungem: fix suspend regression due to NAPI changes
From: Benjamin Herrenschmidt [EMAIL PROTECTED] Date: Tue, 13 Nov 2007 09:32:46 +1100 On Mon, 2007-11-12 at 18:45 +0100, Johannes Berg wrote: Commit bea3348e (the NAPI changes) made sungem unconditionally enable NAPI when resuming and unconditionally disable when suspending, this, however, makes napi_disable() hang when suspending when the interface was taken down before suspend because taking the interface down also disables NAPI. This patch makes touching the napi struct in suspend/resume code paths depend on having the interface up, thereby fixing the hang on suspend. The patch also moves the napi_disable() in gem_close() under the lock so that the NAPI state is always modified atomically together with the opened variable. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Thanks for fixing that ! Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Indeed, thanks a lot Johannes. Patch applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix early btext debug on PowerMac
The early btext debug wouldn't work on PowerMac when booted from BootX due to the code looking for the wrong property name. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/kernel/btext.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Index: linux-work/arch/powerpc/kernel/btext.c === --- linux-work.orig/arch/powerpc/kernel/btext.c 2007-11-13 13:39:09.0 +1100 +++ linux-work/arch/powerpc/kernel/btext.c 2007-11-13 13:43:23.0 +1100 @@ -186,7 +186,9 @@ int btext_initialize(struct device_node pitch = *prop; if (pitch == 1) pitch = 0x1000; - prop = of_get_property(np, address, NULL); + prop = of_get_property(np, linux,bootx-addr, NULL); + if (prop == NULL) + prop = of_get_property(np, address, NULL); if (prop) address = *prop; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Optimize counting distinct entries in therelocation sections
Medve Emilian writes: Seems like there are R_PPC_REL24 with r_addend != 0. Within a set of 41 modules (featuring 5457 R_PPC_REL24 relocations) already included within the kernel tree I found 37 such relocations (R_PPC_REL24) with r_addend != 0. In my test case, from 35K relocations, 7K are R_PPC_REL24 and from those only 8 have r_addend != 0. I did a quick scan and the ones with r_addend != 0 all seem to be references to .text from the .init.text, .exit.text or .fixup sections. Assuming we can get those allocated near each other they shouldn't need trampolines. Rusty, do we manage to put .init.text and .fixup near .text? Also, do you know what we see in r_info for a relocation that is relative to a section rather than a symbol? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
printk/console_init
Hi, I am using 2.6.19 Linux on 8641D based system. I am using early printk's and it works fine until console_init() is executed. After that it does not, as the early printk's get disabled, which is fine. However, I don't see any prints after that at all, that are based on regular printk statements. I looked directly into the memory at __log_buf and found all the print messages. It is just not coming out to the serial port properly. It would be great if some one can tell me various parameters that I need to consider changing, to successfully port the serial driver for a new board. Based on the early printk's, I am getting the following messages... Using MPC86xx HPCN machine description Total memory = 1024MB; using 2048kB for hash table (at cfe0) Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #115 SMP Mon Nov 12 18:21:43 PST 2007 Found legacy serial port 0 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] mem=ff704500, taddr=ff704500, irq=1a, clk=1496250, speed=0 Found MPC86xx PCIE host bridge at 0xff708000. Firmware bus number: 0-254 Found MPC86xx PCIE host bridge at 0xff709000. Firmware bus number: 0-255 MPC86xx HPCN board from Freescale Semiconductor Zone PFN ranges: DMA 0 - 196608 Normal 196608 - 196608 HighMem196608 - 262144 early_node_map[1] active PFN ranges 0:0 - 262144 start_kernel: 8 2200. Built 1 zonelists. Total pages: 260096 Kernel command line: console=ttyS0,115200 root=/dev/sda8 mpic: Setting up MPIC MPIC version 1.2 at ff74, max 2 CPUs mpic: ISU size: 16, shift: 4, mask: f mpic: Initializing for 80 sources PID hash table entries: 4096 (order: 12, 16384 bytes) time_init: decrementer frequency = 150.00 MHz time_init: processor frequency = 1496.25 MHz Nothing gets printed after this ... Thanks Siva ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: mv64x60 - Fix PCI MEM-System Mem window setup
Mark A. Greer writes: mv64x60_config_pci_windows() is now changed to make the windows match as described above. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] Are any of this series required for 2.6.24? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Silence an annoying boot message
vmemmap_populate will printk (with KERN_WARNING) for a lot of pages if CONFIG_SPARSEMEM_VMEMMAP is enabled (at least it does on iSeries). Use pr_debug for it instead. Replace the only other use of DBG in this file with pr_debug as well. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- arch/powerpc/mm/init_64.c | 16 1 files changed, 4 insertions(+), 12 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c index d9c82d3..c0f5cff 100644 --- a/arch/powerpc/mm/init_64.c +++ b/arch/powerpc/mm/init_64.c @@ -19,8 +19,6 @@ * */ -#undef DEBUG - #include linux/signal.h #include linux/sched.h #include linux/kernel.h @@ -66,12 +64,6 @@ #include mmu_decl.h -#ifdef DEBUG -#define DBG(fmt...) printk(fmt) -#else -#define DBG(fmt...) -#endif - #if PGTABLE_RANGE USER_VSID_RANGE #warning Limited user VSID range means pagetable space is wasted #endif @@ -175,8 +167,8 @@ void pgtable_cache_init(void) int size = pgtable_cache_size[i]; const char *name = pgtable_cache_name[i]; - DBG(Allocating page table cache %s (#%d) - for size: %08x...\n, name, i, size); + pr_debug(Allocating page table cache %s (#%d) + for size: %08x...\n, name, i, size); pgtable_cache[i] = kmem_cache_create(name, size, size, SLAB_PANIC, @@ -239,8 +231,8 @@ int __meminit vmemmap_populate(struct page *start_page, if (!p) return -ENOMEM; - printk(KERN_WARNING vmemmap %08lx allocated at %p, - physical %08lx.\n, start, p, __pa(p)); + pr_debug(vmemmap %08lx allocated at %p, physical %08lx.\n, + start, p, __pa(p)); mapped = htab_bolt_mapping(start, start + page_size, __pa(p), mode_rw, mmu_linear_psize, -- 1.5.3.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Make isa_mem_base common to 32 and 64 bits
This defines isa_mem_base on both 32 and 64 bits (it used to be 32 bits only). This avoids a few ifdef's in later patches and potentially can allow support for VGA text mode on 64 bits powerpc. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Small cleanup pre-requisite for my next patch arch/powerpc/kernel/pci-common.c |4 arch/powerpc/kernel/pci_32.c |1 - include/asm-powerpc/io.h |5 +++-- 3 files changed, 7 insertions(+), 3 deletions(-) Index: linux-work/arch/powerpc/kernel/pci-common.c === --- linux-work.orig/arch/powerpc/kernel/pci-common.c2007-11-13 14:11:11.0 +1100 +++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 14:15:43.0 +1100 @@ -52,6 +52,10 @@ int global_phb_number; /* Global phb co extern struct list_head hose_list; +/* ISA Memory physical address (or 0 if none) */ +resource_size_t isa_mem_base= 0; + + /* * pci_controller(phb) initialized common variables. */ Index: linux-work/include/asm-powerpc/io.h === --- linux-work.orig/include/asm-powerpc/io.h2007-11-13 14:12:01.0 +1100 +++ linux-work/include/asm-powerpc/io.h 2007-11-13 14:12:48.0 +1100 @@ -50,15 +50,16 @@ extern int check_legacy_ioport(unsigned #define PCI_DRAM_OFFSETpci_dram_offset #else #define _IO_BASE pci_io_base -#define _ISA_MEM_BASE 0 +#define _ISA_MEM_BASE isa_mem_base #define PCI_DRAM_OFFSET0 #endif extern unsigned long isa_io_base; -extern unsigned long isa_mem_base; extern unsigned long pci_io_base; extern unsigned long pci_dram_offset; +extern resource_size_t isa_mem_base; + #if defined(CONFIG_PPC32) defined(CONFIG_PPC_INDIRECT_IO) #error CONFIG_PPC_INDIRECT_IO is not yet supported on 32 bits #endif Index: linux-work/arch/powerpc/kernel/pci_32.c === --- linux-work.orig/arch/powerpc/kernel/pci_32.c2007-11-13 14:16:15.0 +1100 +++ linux-work/arch/powerpc/kernel/pci_32.c 2007-11-13 14:16:17.0 +1100 @@ -32,7 +32,6 @@ #endif unsigned long isa_io_base = 0; -unsigned long isa_mem_base= 0; unsigned long pci_dram_offset = 0; int pcibios_assign_bus_offset = 1; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Merge pci_process_bridge_OF_ranges()
This patch merges the 32 and 64 bits implementations of
pci_process_bridge_OF_ranges(). The new function is cleaner than both
the old ones supports 64 bits ranges on ppc32 which is necessary for
the 4xx port.
It also adds some better (hopefully) output to the kernel log which
should help disagnose problems and makes better use of existing OF
parsing helpers (avoiding a few bugs of both implementations along
the way).
There are still a few unfortunate ifdef's but there is no way around
these for now at least not until some other bits of the PCI code are
made common.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and
a BriQ. Please let me know if it misbehaves anywhere else.
arch/powerpc/kernel/pci-common.c | 176 +++
arch/powerpc/kernel/pci_32.c | 114 -
arch/powerpc/kernel/pci_64.c | 93
include/asm-powerpc/pci-bridge.h |1
4 files changed, 177 insertions(+), 207 deletions(-)
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2007-11-13
14:15:43.0 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2007-11-13 14:41:54.0
+1100
@@ -479,3 +479,179 @@ void pci_resource_to_user(const struct p
*start = rsrc-start - offset;
*end = rsrc-end - offset;
}
+
+/**
+ * pci_process_bridge_OF_ranges - Parse PCI bridge resources from device tree
+ * @hose: newly allocated pci_controller to be setup
+ * @dev: device node of the host bridge
+ * @primary: set if primary bus (32 bits only, soon to be deprecated)
+ *
+ * This function will parse the ranges property of a PCI host bridge device
+ * node and setup the resource mapping of a pci controller based on its
+ * content.
+ *
+ * Life would be boring if it wasn't for a few issues that we have to deal
+ * with here:
+ *
+ * - We can only cope with one IO space range and up to 3 Memory space
+ * ranges. However, some machines (thanks Apple !) tend to split their
+ * space into lots of small contiguous ranges. So we have to coalesce.
+ *
+ * - We can only cope with all memory ranges having the same offset
+ * between CPU addresses and PCI addresses. Unfortunately, some bridges
+ * are setup for a large 1:1 mapping along with a small window which
+ * maps PCI address 0 to some arbitrary high address of the CPU space in
+ * order to give access to the ISA memory hole.
+ * The way out of here that I've chosen for now is to always set the
+ * offset based on the first resource found, then override it if we
+ * have a different offset and the previous was set by an ISA hole.
+ *
+ * - Some busses have IO space not starting at 0, which causes trouble with
+ * the way we do our IO resource renumbering. The code somewhat deals with
+ * it for 64 bits but I would expect problems on 32 bits.
+ *
+ * - Some 32 bits platforms such as 4xx can have physical space larger than
+ * 32 bits so we need to use 64 bits values for the parsing
+ */
+void __devinit pci_process_bridge_OF_ranges(struct pci_controller *hose,
+ struct device_node *dev,
+ int primary)
+{
+ const u32 *ranges;
+ int rlen;
+ int pna = of_n_addr_cells(dev);
+ int np = pna + 5;
+ int memno = 0, isa_hole = -1;
+ u32 pci_space;
+ unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
+ unsigned long long isa_mb = 0;
+ struct resource *res;
+
+ printk(KERN_INFO PCI host bridge %s %s ranges:\n,
+ dev-full_name, primary ? (primary) : );
+
+ /* Get ranges property */
+ ranges = of_get_property(dev, ranges, rlen);
+ if (ranges == NULL)
+ return;
+
+ /* Parse it */
+ while ((rlen -= np * 4) = 0) {
+ /* Read next ranges element */
+ pci_space = ranges[0];
+ pci_addr = of_read_number(ranges + 1, 2);
+ cpu_addr = of_translate_address(dev, ranges + 3);
+ size = of_read_number(ranges + pna + 3, 2);
+ ranges += np;
+ if (cpu_addr == OF_BAD_ADDR || size == 0)
+ continue;
+
+ /* Now consume following elements while they are contiguous */
+ for (;rlen = np * sizeof(u32); ranges += np, rlen -= np * 4) {
+ if (ranges[0] != pci_space)
+ break;
+ pci_next = of_read_number(ranges + 1, 2);
+ cpu_next = of_translate_address(dev, ranges + 3);
+ if (pci_next != pci_addr + size ||
+ cpu_next != cpu_addr + size)
+ break;
+
Re: [PATCH] [POWERPC] Silence an annoying boot message
On Tue, Nov 13, 2007 at 03:41:49PM +1100, Stephen Rothwell wrote: vmemmap_populate will printk (with KERN_WARNING) for a lot of pages if CONFIG_SPARSEMEM_VMEMMAP is enabled (at least it does on iSeries). Use pr_debug for it instead. Replace the only other use of DBG in this file with pr_debug as well. Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fix multiple bugs in rtas_ibm_suspend_me code
Nathan Lynch writes: There are several issues with the rtas_ibm_suspend_me code, which enables platform-assisted suspension of an LPAR for migration or hibernation as covered in PAPR 2.2. On a uniprocessor configuration, with this patch I get: CC arch/powerpc/kernel/rtas.o /home/paulus/kernel/powerpc/arch/powerpc/kernel/rtas.c: In function ‘rtas_percpu_suspend_me’: /home/paulus/kernel/powerpc/arch/powerpc/kernel/rtas.c:702: error: implicit declaration of function ‘get_hard_smp_processor_id’ make[2]: *** [arch/powerpc/kernel/rtas.o] Error 1 I think you need to #include asm/smp.h in rtas.c. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Merge pci_process_bridge_OF_ranges()
On Tue, 13 Nov 2007 15:43:51 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and a BriQ. Please let me know if it misbehaves anywhere else. It seems to work fine on my legacy iSeries (iseries_defconfig and ppc64_defconfig), though I only have one PCI device. Due to another patch I have, I changed pci_io_size to be a reasource_size_t on 64 bit as well which should be a noop as it was unsigned long. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpA4bccDVdun.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][POWERPC] pSeries: remove dependency on pci_dn bussubno
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/iommu.c | 24 +++-
1 files changed, 7 insertions(+), 17 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index d4e9d85..ebb9313 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -296,11 +296,12 @@ static void iommu_table_setparms(struct pci_controller
*phb,
static void iommu_table_setparms_lpar(struct pci_controller *phb,
struct device_node *dn,
struct iommu_table *tbl,
- const void *dma_window)
+ const void *dma_window,
+ int bussubno)
{
unsigned long offset, size;
- tbl-it_busno = PCI_DN(dn)-bussubno;
+ tbl-it_busno = bussubno;
of_parse_dma_window(dn, dma_window, tbl-it_index, offset, size);
tbl-it_base = 0;
@@ -420,17 +421,10 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus
*bus)
pdn-full_name, ppci-iommu_table);
if (!ppci-iommu_table) {
- /* Bussubno hasn't been copied yet.
-* Do it now because iommu_table_setparms_lpar needs it.
-*/
-
- ppci-bussubno = bus-number;
-
tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
ppci-phb-node);
-
- iommu_table_setparms_lpar(ppci-phb, pdn, tbl, dma_window);
-
+ iommu_table_setparms_lpar(ppci-phb, pdn, tbl, dma_window,
+ bus-number);
ppci-iommu_table = iommu_init_table(tbl, ppci-phb-node);
DBG( created table: %p\n, ppci-iommu_table);
}
@@ -523,14 +517,10 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev
*dev)
pci = PCI_DN(pdn);
if (!pci-iommu_table) {
- /* iommu_table_setparms_lpar needs bussubno. */
- pci-bussubno = pci-phb-bus-number;
-
tbl = kmalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
pci-phb-node);
-
- iommu_table_setparms_lpar(pci-phb, pdn, tbl, dma_window);
-
+ iommu_table_setparms_lpar(pci-phb, pdn, tbl, dma_window,
+ pci-phb-bus-number);
pci-iommu_table = iommu_init_table(tbl, pci-phb-node);
DBG( created table: %p\n, pci-iommu_table);
} else {
--
1.5.3.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] clean up pci-bidge.h
No semantic changes.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
include/asm-powerpc/pci-bridge.h | 95 +-
1 files changed, 42 insertions(+), 53 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
index dc31845..d28185e 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -1,16 +1,17 @@
#ifndef _ASM_POWERPC_PCI_BRIDGE_H
#define _ASM_POWERPC_PCI_BRIDGE_H
#ifdef __KERNEL__
-
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
#include linux/pci.h
#include linux/list.h
#include linux/ioport.h
#ifndef CONFIG_PPC64
-
-struct device_node;
-struct pci_controller;
-
/*
* Structure of a PCI controller (host bridge)
*/
@@ -51,11 +52,11 @@ struct pci_controller {
* set.
* BIG_ENDIAN - cfg_addr is a big endian register
*/
-#define PPC_INDIRECT_TYPE_SET_CFG_TYPE (0x0001)
-#define PPC_INDIRECT_TYPE_EXT_REG (0x0002)
-#define PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS (0x0004)
-#define PPC_INDIRECT_TYPE_NO_PCIE_LINK (0x0008)
-#define PPC_INDIRECT_TYPE_BIG_ENDIAN (0x0010)
+#define PPC_INDIRECT_TYPE_SET_CFG_TYPE 0x0001
+#define PPC_INDIRECT_TYPE_EXT_REG 0x0002
+#define PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS 0x0004
+#define PPC_INDIRECT_TYPE_NO_PCIE_LINK 0x0008
+#define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x0010
u32 indirect_type;
/* Currently, we limit ourselves to 1 IO range and 3 mem
@@ -81,18 +82,18 @@ static inline int isa_vaddr_is_ioport(void __iomem *address)
/* These are used for config access before all the PCI probing
has been done. */
-int early_read_config_byte(struct pci_controller *hose, int bus, int dev_fn,
- int where, u8 *val);
-int early_read_config_word(struct pci_controller *hose, int bus, int dev_fn,
- int where, u16 *val);
-int early_read_config_dword(struct pci_controller *hose, int bus, int dev_fn,
- int where, u32 *val);
-int early_write_config_byte(struct pci_controller *hose, int bus, int dev_fn,
- int where, u8 val);
-int early_write_config_word(struct pci_controller *hose, int bus, int dev_fn,
- int where, u16 val);
-int early_write_config_dword(struct pci_controller *hose, int bus, int dev_fn,
-int where, u32 val);
+extern int early_read_config_byte(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u8 *val);
+extern int early_read_config_word(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u16 *val);
+extern int early_read_config_dword(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u32 *val);
+extern int early_write_config_byte(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u8 val);
+extern int early_write_config_word(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u16 val);
+extern int early_write_config_dword(struct pci_controller *hose, int bus,
+ int dev_fn, int where, u32 val);
extern int early_find_capability(struct pci_controller *hose, int bus,
int dev_fn, int cap);
@@ -104,15 +105,7 @@ extern void setup_grackle(struct pci_controller *hose);
extern void __init update_bridge_resource(struct pci_dev *dev,
struct resource *res);
-#else
-
-
-/*
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
+#else /* CONFIG_PPC64 */
/*
* Structure of a PCI controller (host bridge)
@@ -159,8 +152,8 @@ struct pci_controller {
* PCI stuff, for nodes representing PCI devices, pointed to
* by device_node-data.
*/
-struct pci_controller;
struct iommu_table;
+struct device_node;
struct pci_dn {
int busno; /* pci bus number */
@@ -179,9 +172,9 @@ struct pci_dn {
int eeh_mode; /* See eeh.h for possible EEH_MODEs */
int eeh_config_addr;
int eeh_pe_config_addr; /* new-style partition endpoint address */
- int eeh_check_count;/* # times driver ignored error */
- int eeh_freeze_count; /* # times this device froze up. */
- int eeh_false_positives;/* # times this
[PATCH 2/2] [POWERPC] consolidate struct pci_controller
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
include/asm-powerpc/pci-bridge.h | 65 +-
1 files changed, 22 insertions(+), 43 deletions(-)
This one clashes slightly with Benh's Merge pci_process_bridge_OF_ranges()
patch.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
index d28185e..b4e2a81 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -11,33 +11,44 @@
#include linux/list.h
#include linux/ioport.h
-#ifndef CONFIG_PPC64
/*
* Structure of a PCI controller (host bridge)
*/
struct pci_controller {
struct pci_bus *bus;
char is_dynamic;
+#ifdef CONFIG_PPC64
+ int node;
+#endif
void *arch_data;
struct list_head list_node;
struct device *parent;
int first_busno;
int last_busno;
+#ifndef CONFIG_PPC64
int self_busno;
+#endif
void __iomem *io_base_virt;
+#ifdef CONFIG_PPC64
+ void *io_base_alloc;
+#endif
resource_size_t io_base_phys;
/* Some machines (PReP) have a non 1:1 mapping of
* the PCI memory space in the CPU bus space
*/
resource_size_t pci_mem_offset;
+#ifdef CONFIG_PPC64
+ unsigned long pci_io_size;
+#endif
struct pci_ops *ops;
volatile unsigned int __iomem *cfg_addr;
volatile void __iomem *cfg_data;
+#ifndef CONFIG_PPC64
/*
* Used for variants of PCI indirect handling and possible quirks:
* SET_CFG_TYPE - used on 4xx or any PHB that does explicit type0/1
@@ -58,15 +69,24 @@ struct pci_controller {
#define PPC_INDIRECT_TYPE_NO_PCIE_LINK 0x0008
#define PPC_INDIRECT_TYPE_BIG_ENDIAN 0x0010
u32 indirect_type;
-
+#endif /* !CONFIG_PPC64 */
/* Currently, we limit ourselves to 1 IO range and 3 mem
* ranges since the common pci_bus structure can't handle more
*/
struct resource io_resource;
struct resource mem_resources[3];
int global_number; /* PCI domain number */
+#ifdef CONFIG_PPC64
+ unsigned long buid;
+ unsigned long dma_window_base_cur;
+ unsigned long dma_window_size;
+
+ void *private_data;
+#endif /* CONFIG_PPC64 */
};
+#ifndef CONFIG_PPC64
+
static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
{
return bus-sysdata;
@@ -108,47 +128,6 @@ extern void __init update_bridge_resource(struct pci_dev
*dev,
#else /* CONFIG_PPC64 */
/*
- * Structure of a PCI controller (host bridge)
- */
-struct pci_controller {
- struct pci_bus *bus;
- char is_dynamic;
- int node;
- void *arch_data;
- struct list_head list_node;
- struct device *parent;
-
- int first_busno;
- int last_busno;
-
- void __iomem *io_base_virt;
- void *io_base_alloc;
- resource_size_t io_base_phys;
-
- /* Some machines have a non 1:1 mapping of
-* the PCI memory space in the CPU bus space
-*/
- resource_size_t pci_mem_offset;
- unsigned long pci_io_size;
-
- struct pci_ops *ops;
- volatile unsigned int __iomem *cfg_addr;
- volatile void __iomem *cfg_data;
-
- /* Currently, we limit ourselves to 1 IO range and 3 mem
-* ranges since the common pci_bus structure can't handle more
-*/
- struct resource io_resource;
- struct resource mem_resources[3];
- int global_number;
- unsigned long buid;
- unsigned long dma_window_base_cur;
- unsigned long dma_window_size;
-
- void *private_data;
-};
-
-/*
* PCI stuff, for nodes representing PCI devices, pointed to
* by device_node-data.
*/
--
1.5.3.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Merge pci_process_bridge_OF_ranges()
On Tue, Nov 13, 2007 at 03:43:51PM +1100, Benjamin Herrenschmidt wrote: Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Tested on a few pSeries, PowerMac G5, and a 32 bits PowerMacs and a BriQ. Please let me know if it misbehaves anywhere else. Looks good on the eval boards I tested here. Acked-by: Olof Johansson [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
