Re: 2.6.27-rc8 boot failure
Badari Pulavarty writes: > I am not able to boot my Power5 box with 2.6.27-rc8 (defconfig). > However, I am able to boot with my own custom config. > > Known issue ? No, and I wasn't able to replicate it on a power5 partition here... Could you look up what is at 0xc097a02c in your vmlinux (not zImage)? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] properly reserve in bootmem the lmb reserved regions that cross NUMA nodes
Minor nits ...
One is, you add this helper to mm/page_alloc.c, which means that I'll
need some ack from Hugh or Andrew before I can merge that via the
powerpc tree... Unless there's another user, I'd rather keep the
helper function in powerpc code for now, it can be moved to common
code later if somebody needs something similar.
> + /* Mark reserved regions */
> + for (i = 0; i < lmb.reserved.cnt; i++) {
> + unsigned long physbase = lmb.reserved.region[i].base;
> + unsigned long size = lmb.reserved.region[i].size;
> + unsigned long start_pfn = physbase >> PAGE_SHIFT;
> + unsigned long end_pfn = ((physbase + size - 1) >> PAGE_SHIFT);
> + struct node_active_region *node_ar;
I'm not too happy wit the fact that something called "end_pfn" is
sometimes inclusive and sometime exclusive.
IE. From your implementation of get_node_active_region() it looks like
early_node_map[i].end_pfn isn't part of the range (exclusive) while
in your loop, the way you define end_pfn to be base + size - 1 means
it's part of the range (inclusive). That subtle distinction makes it
harder to understand the logic and is bug prone.
> + node_ar = get_node_active_region(start_pfn);
> + while (start_pfn < end_pfn && node_ar != NULL) {
> + /*
> + * if reserved region extends past active region
> + * then trim size to active region
> + */
> + if (end_pfn >= node_ar->end_pfn)
So the above test is correct, but it took me two more brain cells to
figure it out than necessary :-)
> + size = (node_ar->end_pfn << PAGE_SHIFT)
> + - (start_pfn << PAGE_SHIFT);
> + dbg("reserve_bootmem %lx %lx nid=%d\n", physbase, size,
> + node_ar->nid);
> + reserve_bootmem_node(NODE_DATA(node_ar->nid), physbase,
> + size, BOOTMEM_DEFAULT);
> + /*
> + * if reserved region extends past the active region
> + * then get next active region that contains
> + *this reserved region
> + */
> + if (end_pfn >= node_ar->end_pfn) {
> + start_pfn = node_ar->end_pfn;
> + physbase = start_pfn << PAGE_SHIFT;
> + node_ar = get_node_active_region(start_pfn);
> + } else
> + break;
> }
Minor nit but the above would look nicer if you wrote instead
if (end_pfn < node_ar->end_pfn)
break;
start_pfn = ...
> + }
> +
> + for_each_online_node(nid) {
> sparse_memory_present_with_active_regions(nid);
> }
> }
And you can remove the { and } above.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/2] pci: Add ability to mmap legacy_io on some platforms
On Fri, 2008-10-03 at 08:53 -0700, Jesse Barnes wrote: > Tony and/or Bjorn, do you want to take a look and make sure this is ok? If > so > I can take the whole thing into the PCI tree. Don't take patch 2/2, only 1/2. If/when you do, I'll then get the powerpc side patch via the powerpc tree, as I didn't quite manage to test it properly yet and I may want to polish a thing or two first. It's also likely to collide with other powerpc incoming stuff, better if I sort that out. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
BSP on Kernel2.4 needed for MPC8360E-MDS
Hi All, Is there any BSP on kernel 2.4 for MPC8360EMDS board? Thanks, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove CHRP and PMAC support from defconfigs, fix Kconfigs
On Fri, Sep 26, 2008 at 12:19 PM, Timur Tabi <[EMAIL PROTECTED]> wrote: > The Kconfig files for PowerPC CHRP and PMAC support had "default=y" for some > Kconfig options, and this caused support for CHRP and PMAC platforms to be > enabled incorrectly for several platforms. Fix the Kconfigs and the > affected defconfigs. > > Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> > --- > > This patch is for 2.6.28. Ben, please review and make sure I'm not being to > conservative or too aggressive. I don't know enough about CHRP and PMAC to > be sure I'm doing this right. Ping. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] properly reserve in bootmem the lmb reserved regions that cross NUMA nodes
If there are multiple reserved memory blocks via lmb_reserve() that are
contiguous addresses and on different NUMA nodes we are losing track of which
address ranges to reserve in bootmem on which node. I discovered this
when I only recently got to try 16GB huge pages on a system with more
then 2 nodes.
When scanning the device tree in early boot we call lmb_reserve() with
the addresses of the 16G pages that we find so that the memory doesn't
get used for something else. For example the addresses for the pages
could be 40, 44, 48, 4C, etc - 8 pages,
one on each of eight nodes. In the lmb after all the pages have been
reserved it will look something like the following:
lmb_dump_all:
memory.cnt= 0x2
memory.size = 0x3e8000
memory.region[0x0].base = 0x0
.size = 0x1e8000
memory.region[0x1].base = 0x40
.size = 0x20
reserved.cnt = 0x5
reserved.size = 0x3e8000
reserved.region[0x0].base = 0x0
.size = 0x7b5000
reserved.region[0x1].base = 0x2a0
.size = 0x78c000
reserved.region[0x2].base = 0x328c000
.size = 0x43000
reserved.region[0x3].base = 0xf4e8000
.size = 0xb18000
reserved.region[0x4].base = 0x40
.size = 0x20
The reserved.region[0x4] contains the 16G pages. In
arch/powerpc/mm/num.c: do_init_bootmem() we loop through each of the
node numbers looking for the reserved regions that belong to the
particular node. It is not able to identify region 0x4 as being a part
of each of the 8 nodes. It is assuming that a reserved region is only
on a single node.
This patch takes out the reserved region loop from inside
the loop that goes over each node. It looks up the active region containing
the start of the reserved region. If it extends past that active region then
it adjusts the size and gets the next active region containing it.
Signed-off-by: Jon Tollefson <[EMAIL PROTECTED]>
---
Changes:
-style changes as suggested by Adam Litke
Please consider for 2.6.28.
arch/powerpc/mm/numa.c | 63 -
include/linux/mm.h |2 +
mm/page_alloc.c| 19 ++
3 files changed, 57 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d9a1813..9a3b0c9 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -837,36 +837,45 @@ void __init do_init_bootmem(void)
start_pfn, end_pfn);
free_bootmem_with_active_regions(nid, end_pfn);
+ }
- /* Mark reserved regions on this node */
- for (i = 0; i < lmb.reserved.cnt; i++) {
- unsigned long physbase = lmb.reserved.region[i].base;
- unsigned long size = lmb.reserved.region[i].size;
- unsigned long start_paddr = start_pfn << PAGE_SHIFT;
- unsigned long end_paddr = end_pfn << PAGE_SHIFT;
-
- if (early_pfn_to_nid(physbase >> PAGE_SHIFT) != nid &&
- early_pfn_to_nid((physbase+size-1) >> PAGE_SHIFT)
!= nid)
- continue;
-
- if (physbase < end_paddr &&
- (physbase+size) > start_paddr) {
- /* overlaps */
- if (physbase < start_paddr) {
- size -= start_paddr - physbase;
- physbase = start_paddr;
- }
-
- if (size > end_paddr - physbase)
- size = end_paddr - physbase;
-
- dbg("reserve_bootmem %lx %lx\n", physbase,
- size);
- reserve_bootmem_node(NODE_DATA(nid), physbase,
-size, BOOTMEM_DEFAULT);
- }
+ /* Mark reserved regions */
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long physbase = lmb.reserved.region[i].base;
+ unsigned long size = lmb.reserved.region[i].size;
+ unsigned long start_pfn = physbase >> PAGE_SHIFT;
+ unsigned long end_pfn = ((physbase + size - 1) >> PAGE_SHIFT);
+ struct node_active_region *node_ar;
+
+ node_ar = get_node_active_region(start_pfn);
+ while (start_pfn < end_pfn && node_ar != NULL) {
+ /*
+* if reserved region extends past active region
+* then trim size to a
Re: [PATCH] pata_of_platform: fix no irq handling
On Mon, Oct 06, 2008 at 03:41:19PM -0500, Matt Sealey wrote: > There is a simple problem with the patch which is that an "IRQ 0" can and does > actually exist on a bunch of platforms, at least to the best of my knowledge. > > Checking for -1 (which means for definite, no irq at all, because it is > totally unambiguous, as a -1 IRQ numbering is "impossible") is more correct. This was discussed years ago. http://lkml.org/lkml/2005/11/22/159 http://lkml.org/lkml/2005/11/22/227 -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-rc8 boot failure
On Mon, 2008-10-06 at 11:05 +1100, Benjamin Herrenschmidt wrote: > On Fri, 2008-10-03 at 10:40 -0700, Badari Pulavarty wrote: > > Hi, > > > > I am not able to boot my Power5 box with 2.6.27-rc8 (defconfig). > > However, I am able to boot with my own custom config. > > > > Known issue ? > > Nope. It would be useful to know the difference between the 2 configs > tho :-) > > It -could- have something to do with the kernel size too. > > Cheers, > Ben. #diff .config .config.working 16,17c16 < CONFIG_ALTIVEC=y < CONFIG_VSX=y --- > # CONFIG_ALTIVEC is not set 60d58 < CONFIG_ARCH_SUSPEND_POSSIBLE=y 62,64c60,61 < CONFIG_PPC_DCR_MMIO=y < CONFIG_PPC_DCR=y < CONFIG_PPC_OF_PLATFORM_PCI=y --- > # CONFIG_PPC_DCR_MMIO is not set > # CONFIG_PPC_OF_PLATFORM_PCI is not set 78c75 < CONFIG_POSIX_MQUEUE=y --- > # CONFIG_POSIX_MQUEUE is not set 80,82c77 < CONFIG_TASKSTATS=y < CONFIG_TASK_DELAY_ACCT=y < # CONFIG_TASK_XACCT is not set --- > # CONFIG_TASKSTATS is not set 86c81 < CONFIG_LOG_BUF_SHIFT=17 --- > CONFIG_LOG_BUF_SHIFT=15 88,94c83,95 < # CONFIG_CGROUP_DEBUG is not set < # CONFIG_CGROUP_NS is not set < # CONFIG_CGROUP_DEVICE is not set < CONFIG_CPUSETS=y < # CONFIG_GROUP_SCHED is not set < # CONFIG_CGROUP_CPUACCT is not set < # CONFIG_RESOURCE_COUNTERS is not set --- > CONFIG_CGROUP_DEBUG=y > CONFIG_CGROUP_NS=y > CONFIG_CGROUP_DEVICE=y > # CONFIG_CPUSETS is not set > CONFIG_GROUP_SCHED=y > CONFIG_FAIR_GROUP_SCHED=y > CONFIG_RT_GROUP_SCHED=y > CONFIG_USER_SCHED=y > # CONFIG_CGROUP_SCHED is not set > CONFIG_CGROUP_CPUACCT=y > CONFIG_RESOURCE_COUNTERS=y > CONFIG_MM_OWNER=y > CONFIG_CGROUP_MEM_RES_CTLR=y 97d97 < CONFIG_PROC_PID_CPUSET=y 100,101c100,101 < # CONFIG_UTS_NS is not set < # CONFIG_IPC_NS is not set --- > CONFIG_UTS_NS=y > CONFIG_IPC_NS=y 103c103 < # CONFIG_PID_NS is not set --- > CONFIG_PID_NS=y 111c111 < CONFIG_KALLSYMS_ALL=y --- > # CONFIG_KALLSYMS_ALL is not set 118c118 < # CONFIG_COMPAT_BRK is not set --- > CONFIG_COMPAT_BRK=y 128,130c128,129 < CONFIG_SLUB_DEBUG=y < # CONFIG_SLAB is not set < CONFIG_SLUB=y --- > CONFIG_SLAB=y > # CONFIG_SLUB is not set 136c135 < # CONFIG_KPROBES is not set --- > CONFIG_KPROBES=y 137a137 > CONFIG_KRETPROBES=y 155,156c155,156 < CONFIG_MODVERSIONS=y < CONFIG_MODULE_SRCVERSION_ALL=y --- > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set 161c161 < CONFIG_BLK_DEV_BSG=y --- > # CONFIG_BLK_DEV_BSG is not set 172c172 < CONFIG_DEFAULT_AS=y --- > # CONFIG_DEFAULT_AS is not set 174c174 < # CONFIG_DEFAULT_CFQ is not set --- > CONFIG_DEFAULT_CFQ=y 176c176 < CONFIG_DEFAULT_IOSCHED="anticipatory" --- > CONFIG_DEFAULT_IOSCHED="cfq" 184c184 < CONFIG_PPC_SPLPAR=y --- > # CONFIG_PPC_SPLPAR is not set 186,198c186,189 < CONFIG_SCANLOG=m < CONFIG_LPARCFG=y < CONFIG_PPC_SMLPAR=y < CONFIG_CMM=y < CONFIG_PPC_ISERIES=y < < # < # iSeries device drivers < # < CONFIG_VIODASD=y < CONFIG_VIOCD=m < CONFIG_VIOTAPE=m < CONFIG_VIOPATH=y --- > CONFIG_SCANLOG=y > # CONFIG_LPARCFG is not set > # CONFIG_PPC_SMLPAR is not set > # CONFIG_PPC_ISERIES is not set 201,209c192,193 < CONFIG_PPC_MAPLE=y < CONFIG_PPC_PASEMI=y < < # < # PA Semi PWRficient options < # < CONFIG_PPC_PASEMI_IOMMU=y < # CONFIG_PPC_PASEMI_IOMMU_DMA_FORCE is not set < CONFIG_PPC_PASEMI_MDIO=y --- > # CONFIG_PPC_MAPLE is not set > # CONFIG_PPC_PASEMI is not set 211,230c195,198 < CONFIG_PPC_CELL=y < CONFIG_PPC_CELL_NATIVE=y < CONFIG_PPC_IBM_CELL_BLADE=y < CONFIG_PPC_CELLEB=y < < # < # Cell Broadband Engine options < # < CONFIG_SPU_FS=m < CONFIG_SPU_FS_64K_LS=y < # CONFIG_SPU_TRACE is not set < CONFIG_SPU_BASE=y < CONFIG_CBE_RAS=y < CONFIG_PPC_IBM_CELL_RESETBUTTON=y < CONFIG_PPC_IBM_CELL_POWERBUTTON=m < CONFIG_CBE_THERM=m < CONFIG_CBE_CPUFREQ=m < CONFIG_CBE_CPUFREQ_PMI=m < CONFIG_CBE_CPUFREQ_SPU_GOVERNOR=m < CONFIG_OPROFILE_CELL=y --- > # CONFIG_PPC_CELL is not set > # CONFIG_PPC_CELL_NATIVE is not set > # CONFIG_PPC_IBM_CELL_BLADE is not set > # CONFIG_PPC_CELLEB is not set 233,234c201 < CONFIG_UDBG_RTAS_CONSOLE=y < CONFIG_PPC_UDBG_BEAT=y --- > # CONFIG_UDBG_RTAS_CONSOLE is not set 244,246c211,212 < CONFIG_RTAS_FLASH=m < CONFIG_PPC_PMI=m < CONFIG_MMIO_NVRAM=y --- > # CONFIG_RTAS_FLASH is not set > # CONFIG_MMIO_NVRAM is not set 248d213 < CONFIG_MPIC_BROKEN_REGREAD=y 250c215 < CONFIG_IBMEBUS=y --- > # CONFIG_IBMEBUS is not set 253,276c218,220 < CONFIG_PPC_INDIRECT_IO=y < CONFIG_GENERIC_IOMAP=y < CONFIG_CPU_FREQ=y < CONFIG_CPU_FREQ_TABLE=y < # CONFIG_CPU_FREQ_DEBUG is not set < CONFIG_CPU_FREQ_STAT=y < # CONFIG_CPU_FREQ_STAT_DETAILS is not set < CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y < # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set < # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set < # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set < # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set < CONFIG_CPU_FREQ_GOV_PERFORMANCE=y < CONFIG_CPU_FREQ_GOV_POWERSAVE=y < CONFIG_CPU_FREQ_GOV_USERSPACE=y < # CONFIG_CPU_FREQ_GOV_ONDEMAND is not set < # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set < < # < # CPU Frequency driv
Re: USB support on mpc5200 broken
Benjamin Herrenschmidt wrote: This is what we were recommended to use at the time. There is a patch on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant with the Linux version of things, which implements every variation. It also implements a suggested patch which added a "big-endian" property (not built in to the compatible property, but another property). I don't see why THAT patch got reverted as it was a great idea that we all agreed was a great idea. I agree. Something needs to be fixed on the OHCI OF stuff, it should definitely cope with the "big-endian" property (which is a practice borrowed from Apple that I recommended I think back then) and I don't see any problem with having ohci-be in the "compatible" property, its trivial enough to cope in the driver and being anal about it on the kernel side doesn't really bring any benefit. I see a problem with having ohci-be being in there to the exclusion of fixed properties on existing hardware that are not easy to realise what changed (i.e. you upgrade your kernel, and not being an avid follower of linux-usb or linuxppc-dev, wonder why USB stopped working). It's not that easy for a lot of people who are not kernel developers to find out WHY it broke let alone HOW to fix it (edit the USB compatibility names list to re-add it, use efika.forth, edit a custom snippet in nvramrc or a forth boot script, hack chrp_fixups some more - in order of increasing brain death :) Care to send a patch ? I don't really have time to go into it right now but I will look into it. At some point I have to get my act together and release the latest version of efika.forth as some things did change between that and the latest Linux version... Linux development around here is getting really schizophrenic. Nobody is writing these decisions down even as comments in the source code.. That isn't entirely true. There's the ePAPR effort on power.org that is codifying a lot of that, and there are binding documents dropped in Documentation/powerpc. You know I don't believe in Power.org any more than I believe in the tooth fairy. Codifying ePAPR is just reverse engineering decisions made a year ago with the booting-without-of.txt and the existing code, and putting it into a document. It didn't solve this situation and it won't - ePAPR can't help codifying a board's device tree that was engineered, produced and will probably be discontinued before a decent version of ePAPR will be released. Just like ePAPR doesn't expect anyone conform to Apple device trees, ePAPR will not make Efika device trees suddenly work without "help" (which is why I wrote that forth script..) No; you can have little endian OHCI controllers on big endian machines. It's a property of the host controller, not the system architecture, just like PCI is always little endian (except when you have magic in hardware like Amiga PowerUP cards which endianswap for you :) In fact, you can have both kinds on the same machine. And all kinds of USB controllers at once. I have seen a Pegasos with a little endian UHCI, big endian OHCI, little endian OHCI in the same box. Very confusing for drivers. Don't get me started on the FireWire OHCI, which I think above "ohci-be" really conflicts with in terms of namespace. What I thought we all agreed on before was this; compatible = "usb-ohci, usb-ohci-be" big-endian Would be canonical. That way you can tell it's OHCI USB, it's big endian for compatibility and big-endian property just in case the driver forgot or was misled somehow (at least it should match on usb-ohci, usb-ohci-be, then check if usb-ohci-be is present, and then check for big-endian, and it will have a comprehensive knowledge..) There stands to be some discussion over whether mpc5200-usb-ohci or mpc5200-ohci or mpc5200-usb is valid or required or not. You still need to check for quirks (I am sure there ARE some) after all. I really wish it would be codified somewhere so that we could once and for all put in exactly what it should be, and not just change it at the whim of the latest patch (the reason we do not release firmware this often is because the burden of releasing firmware does not match the expectations of a 3-month-long kernel release where the decisions are overturned, reverted and having 15 firmware versions since release makes our life and your lives much harder when fixing these things down. Efika stayed as it was, so it can be consistently supported :) I think the thing to do somewhere is note that while ePAPR is the recommended practise, it's based on Open Firmware standards which already exist, and there are still Open Firmware standard firmwares which still exist, which may not be so easily updated as to just run the device tree compiler and attach it to a kernel, so when making decisions about naming or submitting patches about naming, check out the users of that peripheral and make sure you're not just submitting a patch assuming that everyone can update t
Re: [PATCH] properly reserve in bootmem the lmb reserved regions that cross numa nodes
Kumar Gala wrote: > > On Oct 6, 2008, at 10:42 AM, Jon Tollefson wrote: > >> Kumar Gala wrote: >>> Out of interest how to do you guys represent NUMA regions of memory in >>> the device tree? >>> >>> - k >> Looking at the source code in numa.c I see at the start of >> do_init_bootmem() that parse_numa_properties() is called. It appears to >> be looking at memory nodes and getting the node id from it. It gets an >> associativity property for the memory node and indexes that array with a >> 'min_common_depth' value to get the node id. >> >> This node id is then used to setup the active ranges in the >> early_node_map[]. >> >> Is this what you are asking about? There are others I am sure who know >> more about it then I though. > > I was wondering if this was documented anywhere (like in sPAPR)? > > - k I see some information on it in section "C.6.6". Jon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
There is a simple problem with the patch which is that an "IRQ 0" can and does actually exist on a bunch of platforms, at least to the best of my knowledge. Checking for -1 (which means for definite, no irq at all, because it is totally unambiguous, as a -1 IRQ numbering is "impossible") is more correct. The problem is the check against an unsigned value for interrupts (is there any reason why you would need 4 billion interrupts possible instead of just 2 billion?) although I must say, the patch will work, and probably 99.999% of people will never see a problem with it :) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Anton Vorontsov wrote: When no irq specified the pata_of_platform fills the irq_res with -1, which is wrong to do for two reasons: 1. By definition, 'no irq' should be IRQ 0, not some negative integer; 2. pata_platform checks for irq_res.start > 0, but since irq_res.start is unsigned type, the check will be true for `-1'. Reported-by: Steven A. Falco <[EMAIL PROTECTED]> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Resending again... drivers/ata/pata_of_platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c index 408da30..1f18ad9 100644 --- a/drivers/ata/pata_of_platform.c +++ b/drivers/ata/pata_of_platform.c @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct of_device *ofdev, ret = of_irq_to_resource(dn, 0, &irq_res); if (ret == NO_IRQ) - irq_res.start = irq_res.end = -1; + irq_res.start = irq_res.end = 0; else irq_res.flags = 0; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] OF: add fsl,mcu-mpc8349emitx to the exception list
On Mon, Oct 06, 2008 at 11:31:58AM -0600, Grant Likely wrote: > On Mon, Oct 06, 2008 at 09:28:31PM +0400, Anton Vorontsov wrote: > > On Wed, Oct 01, 2008 at 03:39:48PM +0400, Anton Vorontsov wrote: > > [...] > > > > > Any issues with this or the second patch? Can we merge them? > > > > > > > > I do not have the time to review these patches (and, honestly, have no > > > > interest in them.) So I will not merge them but I have no objection to > > > > them being merged by somebody else. > > > > > > Ok, thanks for the sincerity.. ;-) > > > > > > Kumar, could you pick up the two patches via the patchworks? > > > > > > [1/2] OF: add fsl,mcu-mpc8349emitx to the exception list > > > http://patchwork.ozlabs.org/patch/1105/ > > > > > Since I've been involved with the i2c of bindings, I can pick this one up. Much appreciated, thanks! > > > [2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver > > > http://patchwork.ozlabs.org/patch/1106/ > > But I'm not involved enough with this one, so it should go through > kumar. That's fine, the first and second patches could go separate trees since it won't break the build. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dma: add new dma_mapping_ops API sync_page
On Mon, 2008-10-06 at 11:30 -0500, Scott Wood wrote: > Remi Machet wrote: > > After continuing to work on the dma noncoherent code I realized that > > sync_page is not the best choice of API: > > -The API should preferably take a dma_addr_t in my opinion > > A virtual address will typically be needed to perform the flush; why > pass the bus address? Because it is a sync API. You want to make sure that a physical memory area is in sync with the caches, not the virtual address. This distinction can become important in the event where the page is mapped multiple times in the memory and the architecture does not take care of synchronizing the multiple mapping, the dma_mapping_ops code should be able to synchronize the multiple mapping. In most case it would be easy of course to go from virtual address to the page address, but not if the page is in high memory ... By the way I realized later on that scatter/gather structures contain 2 fields: dma_addr and dma_length that can be used to recover the bus address => no need for sync_sg anymore. Remi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] OF: add fsl,mcu-mpc8349emitx to the exception list
On Mon, Oct 06, 2008 at 09:28:31PM +0400, Anton Vorontsov wrote: > On Wed, Oct 01, 2008 at 03:39:48PM +0400, Anton Vorontsov wrote: > [...] > > > > Any issues with this or the second patch? Can we merge them? > > > > > > I do not have the time to review these patches (and, honestly, have no > > > interest in them.) So I will not merge them but I have no objection to > > > them being merged by somebody else. > > > > Ok, thanks for the sincerity.. ;-) > > > > Kumar, could you pick up the two patches via the patchworks? > > > > [1/2] OF: add fsl,mcu-mpc8349emitx to the exception list > > http://patchwork.ozlabs.org/patch/1105/ > > Since I've been involved with the i2c of bindings, I can pick this one up. > > [2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver > > http://patchwork.ozlabs.org/patch/1106/ But I'm not involved enough with this one, so it should go through kumar. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] OF: add fsl,mcu-mpc8349emitx to the exception list
On Wed, Oct 01, 2008 at 03:39:48PM +0400, Anton Vorontsov wrote: [...] > > > Any issues with this or the second patch? Can we merge them? > > > > I do not have the time to review these patches (and, honestly, have no > > interest in them.) So I will not merge them but I have no objection to > > them being merged by somebody else. > > Ok, thanks for the sincerity.. ;-) > > Kumar, could you pick up the two patches via the patchworks? > > [1/2] OF: add fsl,mcu-mpc8349emitx to the exception list > http://patchwork.ozlabs.org/patch/1105/ > > [2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver > http://patchwork.ozlabs.org/patch/1106/ > > Or should I resend them to you? Or should I resend them to Andrew? Ping? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] pata_of_platform: fix no irq handling
When no irq specified the pata_of_platform fills the irq_res with -1, which is wrong to do for two reasons: 1. By definition, 'no irq' should be IRQ 0, not some negative integer; 2. pata_platform checks for irq_res.start > 0, but since irq_res.start is unsigned type, the check will be true for `-1'. Reported-by: Steven A. Falco <[EMAIL PROTECTED]> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Resending again... drivers/ata/pata_of_platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c index 408da30..1f18ad9 100644 --- a/drivers/ata/pata_of_platform.c +++ b/drivers/ata/pata_of_platform.c @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct of_device *ofdev, ret = of_irq_to_resource(dn, 0, &irq_res); if (ret == NO_IRQ) - irq_res.start = irq_res.end = -1; + irq_res.start = irq_res.end = 0; else irq_res.flags = 0; -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc/83xx: don't probe broken PCI on mpc837x_mds boards
In the standalone setup the board's CPLD disables the PCI internal
arbiter, thus any access to the PCI bus will hang the board.
The common way to disable particular devices in the device tree is to
put the "status" property with any value other than "ok" or "okay"
into the device node we want to disable.
So, when there is no PCI arbiter on the bus the u-boot adds status =
"broken (no arbiter)" property into the PCI controller's node, and so
marks the PCI controller as unavailable.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
On Fri, Oct 03, 2008 at 12:51:41PM -0500, Kumar Gala wrote:
[...]
>>> yes, but should we just have "status = disabled" since that is the
>>> effect?
>>
>> I don't know, should we? For the unavailable/disabled case the status
>> can be anything but not 'ok' or 'okay' (the only status values for the
>> available devices). So if we can encode the reason, why not do this?
>
> that works for me, just add the fact to the commit msg that the "valid
> status's are 'ok' and 'okay' and everything else is treated as "not
> available or disabled"
Done.
arch/powerpc/platforms/83xx/mpc837x_mds.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c
b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index be62de2..8bb13c8 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
@@ -85,8 +85,14 @@ static void __init mpc837x_mds_setup_arch(void)
ppc_md.progress("mpc837x_mds_setup_arch()", 0);
#ifdef CONFIG_PCI
- for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
+ for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
+ if (!of_device_is_available(np)) {
+ pr_warning("%s: disabled by the firmware.\n",
+ np->full_name);
+ continue;
+ }
mpc83xx_add_bridge(np);
+ }
#endif
mpc837xmds_usb_cfg();
}
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/QE: implement QE Pin Multiplexing API
With this API we're able to set a QE pin to the GPIO mode or a dedicated
peripheral function.
The API relies on the fact that QE gpio controllers are registered. If
they aren't, the API won't work (gracefully though).
There is one caveat though: if anybody occupied the node->data before us,
or overwrote it, then bad things will happen. Luckily this is all in the
platform code that we fully control, so this should never happen.
I could implement more checks (for example we could create a list of
successfully registered QE controllers, and compare the node->data in the
qe_pin_request()), but this is unneeded if nobody is going to do silly
things behind our back.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/qe.h |9 ++
arch/powerpc/sysdev/qe_lib/gpio.c | 195 +
2 files changed, 204 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index edee15d..31ddbc9 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -112,6 +112,15 @@ extern int par_io_config_pin(u8 port, u8 pin, int dir, int
open_drain,
int assignment, int has_irq);
extern int par_io_data_set(u8 port, u8 pin, u8 val);
+/*
+ * Pin multiplexing functions.
+ */
+struct qe_pin;
+extern struct qe_pin *qe_pin_request(struct device_node *np, int index);
+extern void qe_pin_free(struct qe_pin *qe_pin);
+extern void qe_pin_set_gpio(struct qe_pin *qe_pin);
+extern void qe_pin_set_dedicated(struct qe_pin *pin);
+
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
enum qe_clock qe_clock_source(const char *source);
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 8e5a0bc..7f10b18 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,14 @@ struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
+ unsigned long pin_flags[QE_PIO_PINS];
+#define QE_PIN_REQUESTED 0
+
/* shadowed data register to clear/set bits safely */
u32 cpdata;
+
+ /* saved_regs used to restore dedicated functions */
+ struct qe_pio_regs saved_regs;
};
static inline struct qe_gpio_chip *
@@ -40,6 +47,12 @@ static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
struct qe_pio_regs __iomem *regs = mm_gc->regs;
qe_gc->cpdata = in_be32(®s->cpdata);
+ qe_gc->saved_regs.cpdata = qe_gc->cpdata;
+ qe_gc->saved_regs.cpdir1 = in_be32(®s->cpdir1);
+ qe_gc->saved_regs.cpdir2 = in_be32(®s->cpdir2);
+ qe_gc->saved_regs.cppar1 = in_be32(®s->cppar1);
+ qe_gc->saved_regs.cppar2 = in_be32(®s->cppar2);
+ qe_gc->saved_regs.cpodr = in_be32(®s->cpodr);
}
static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
@@ -103,6 +116,188 @@ static int qe_gpio_dir_out(struct gpio_chip *gc, unsigned
int gpio, int val)
return 0;
}
+struct qe_pin {
+ /*
+* The qe_gpio_chip name is unfortunate, we should change that to
+* something like qe_pio_controller. Someday.
+*/
+ struct qe_gpio_chip *controller;
+ int num;
+};
+
+/**
+ * qe_pin_request - Request a QE pin
+ * @np:device node to get a pin from
+ * @index: index of a pin in the device tree
+ * Context:non-atomic
+ *
+ * This function return qe_pin so that you could use it with the rest of
+ * the QE Pin Multiplexing API.
+ */
+struct qe_pin *qe_pin_request(struct device_node *np, int index)
+{
+ struct qe_pin *qe_pin;
+ struct device_node *gc;
+ struct of_gpio_chip *of_gc = NULL;
+ struct of_mm_gpio_chip *mm_gc;
+ struct qe_gpio_chip *qe_gc;
+ int err;
+ int size;
+ const void *gpio_spec;
+ const u32 *gpio_cells;
+ unsigned long flags;
+
+ qe_pin = kzalloc(sizeof(*qe_pin), GFP_KERNEL);
+ if (!qe_pin) {
+ pr_debug("%s: can't allocate memory\n", __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ err = of_parse_phandles_with_args(np, "gpios", "#gpio-cells", index,
+ &gc, &gpio_spec);
+ if (err) {
+ pr_debug("%s: can't parse gpios property\n", __func__);
+ goto err0;
+ }
+
+ if (!of_device_is_compatible(gc, "fsl,mpc8323-qe-pario-bank")) {
+ pr_debug("%s: tried to get a non-qe pin\n", __func__);
+ err = -EINVAL;
+ goto err1;
+ }
+
+ of_gc = gc->data;
+ if (!of_gc) {
+ pr_debug("%s: gpio controller %s isn't registered\n",
+np->full_name, gc->full_name);
+ err = -ENODEV;
+ goto err1;
+ }
+
+ gpio_cells = of_get_property(gc, "#gpi
[PATCH 1/2] OF: new helper: of_parse_phandles_with_args()
The helper is factored out of of_get_gpio(). Will be used by the QE
pin multiplexing functions (they need to parse the gpios = <> too).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/of/base.c | 111
drivers/of/gpio.c | 77 +++
include/linux/of.h |3 +
3 files changed, 130 insertions(+), 61 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..d31686d 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -473,3 +473,114 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
}
EXPORT_SYMBOL_GPL(of_modalias_node);
+/**
+ * of_parse_phandles_with_args - Find a node pointed by phandle in a list
+ * @np:pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name:property name that specifies phandles' arguments count
+ * @index: index of a phandle to parse out
+ * @out_node: pointer to device_node struct pointer (will be filled)
+ * @out_args: pointer to arguments pointer (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_node and out_args, on error returns
+ * appropriate errno value.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * #list-cells = <2>;
+ * }
+ *
+ * phandle2: node2 {
+ * #list-cells = <1>;
+ * }
+ *
+ * node3 {
+ * list = <&phandle1 1 2 &phandle2 3>;
+ * }
+ *
+ * To get a device_node of the `node2' node you may call this:
+ * of_parse_phandles_with_args(node3, "list", "#list-cells", 2, &node2, &args);
+ */
+int of_parse_phandles_with_args(struct device_node *np, const char *list_name,
+ const char *cells_name, int index,
+ struct device_node **out_node,
+ const void **out_args)
+{
+ int ret = -EINVAL;
+ const u32 *list;
+ u32 list_cells;
+ int size;
+ int i;
+ int cur_index = 0;
+ struct device_node *node = NULL;
+ const void *args;
+
+ list = of_get_property(np, list_name, &size);
+ if (!list) {
+ ret = -ENOENT;
+ goto err0;
+ }
+ list_cells = size / sizeof(u32);
+
+ for (i = 0; i < list_cells; cur_index++) {
+ const u32 *cells;
+ const phandle *phandle;
+
+ phandle = list + i;
+ args = phandle + 1;
+
+ /* one cell hole in the list = <>; */
+ if (!*phandle) {
+ if (cur_index == index)
+ return -ENOENT;
+ i++;
+ continue;
+ }
+
+ node = of_find_node_by_phandle(*phandle);
+ if (!node) {
+ pr_debug("%s: could not find phandle\n",
+np->full_name);
+ goto err0;
+ }
+
+ cells = of_get_property(node, cells_name, &size);
+ if (!cells || size != sizeof(*cells)) {
+ pr_debug("%s: could not get %s for %s\n",
+np->full_name, cells_name, node->full_name);
+ goto err1;
+ }
+
+ /* Next phandle is at phandle cells + #cells */
+ i += sizeof(*phandle) / sizeof(u32) + *cells;
+ if (i >= list_cells + 1) {
+ pr_debug("%s: insufficient arguments length\n",
+np->full_name);
+ goto err1;
+ }
+
+ if (cur_index == index)
+ break;
+
+ node = NULL;
+ of_node_put(node);
+ }
+
+ if (!node) {
+ ret = -ENOENT;
+ goto err0;
+ }
+
+ *out_node = node;
+ *out_args = args;
+
+ return 0;
+err1:
+ of_node_put(node);
+err0:
+ pr_debug("%s failed with status %d\n", __func__, ret);
+ return ret;
+}
+EXPORT_SYMBOL(of_parse_phandles_with_args);
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 1c9cab8..6d6e4c0 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -28,78 +28,33 @@
*/
int of_get_gpio(struct device_node *np, int index)
{
- int ret = -EINVAL;
+ int ret;
struct device_node *gc;
struct of_gpio_chip *of_gc = NULL;
int size;
- const u32 *gpios;
- u32 nr_cells;
- int i;
const void *gpio_spec;
const u32 *gpio_cells;
- int gpio_index = 0;
- gpios = of_get_property(np, "gpios", &size);
- if (!gpios) {
- ret = -ENOENT;
+ ret = of_parse_phandles_with_args(np, "gpios", "#gpio-cells", index,
+ &gc, &gpio_spec);
+ if (ret) {
+ p
[PATCH 0/2] QE pin multiplexing API
Hi all, The API is eveloved from the approach where I tried to put the qe_set_dedicated() function into the GPIO LIB framework, which wasn't good idea after all (see http://lkml.org/lkml/2008/9/24/289). So here is the new version. Since the patchset touches driver/of/ I need Acks from the OF guys for the first patch. Then I hope Kumar would merge the patchset to the powerpc-next. And after that I could ask Greg KH to merge the FHCI driver itself... Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dma: add new dma_mapping_ops API sync_page
Remi Machet wrote: After continuing to work on the dma noncoherent code I realized that sync_page is not the best choice of API: -The API should preferably take a dma_addr_t in my opinion A virtual address will typically be needed to perform the flush; why pass the bus address? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] properly reserve in bootmem the lmb reserved regions that cross numa nodes
On Oct 6, 2008, at 10:42 AM, Jon Tollefson wrote: Kumar Gala wrote: Out of interest how to do you guys represent NUMA regions of memory in the device tree? - k Looking at the source code in numa.c I see at the start of do_init_bootmem() that parse_numa_properties() is called. It appears to be looking at memory nodes and getting the node id from it. It gets an associativity property for the memory node and indexes that array with a 'min_common_depth' value to get the node id. This node id is then used to setup the active ranges in the early_node_map[]. Is this what you are asking about? There are others I am sure who know more about it then I though. I was wondering if this was documented anywhere (like in sPAPR)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ehea: Error in ehea_treat_poll_error: CQE Error for QP 16
System log shows a lot of "ehea: Error", see below, during system start up. Not sure what it is. I'd like to understand this, could someone points me the direction? My "Machine Type and Model ... ST9146802SS" reported from lscfg (p6 blade). OS is RHEL 5.2. Kernel level is 2.6.18-92.1.10.el5. Thanks. E. Hu ehea.modinfo filename: /lib/modules/2.6.18-92.1.10.el5/kernel/drivers/net/ehea/ehea.ko version:EHEA_0076-05 description:IBM eServer HEA Driver. author: Christoph Raisch <[EMAIL PROTECTED]> license:GPL srcversion: C481DB79B4694F406CF4AA7 depends: vermagic: 2.6.18-92.1.10.el5 SMP mod_unload gcc-4.1 parm: num_tx_qps:Number of TX-QPS (int) parm: msg_level:msg_level (int) parm: prop_carrier_state:Propagate carrier state of physical port to stack. 1:yes, 0:no. Default = 0 (int) parm: rq3_entries:Number of entries for Receive Queue 3 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq2_entries:Number of entries for Receive Queue 2 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq1_entries:Number of entries for Receive Queue 1 [2^x - 1], x = [6..14]. Default = 4095) (int) parm: sq_entries: Number of entries for the Send Queue [2^x - 1], x = [6..14]. Default = 1023) (int) parm: use_mcs: 0:NAPI, 1:Multiple receive queues, Default = 0 (int) parm: lro_max_aggr: LRO: Max packets to be aggregated. Default = 64 (int).. parm: use_lro: Large Receive Offload, 1: enable, 0: disable, Default = 0 (int). module_sig: 883f3504886ebc8736cb7d2578e3b1112b7ab09e3b2c69b141d16d1bbbd51ab063f7955335a49e80a0ba218c849673e067f7c0ccc9d7353cc1ce05997 system log Sep 29 09:35:35 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1400 ofs= 2000408e Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1410 ofs=0010 d6ec002a 0400 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1420 ofs=0020 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1430 ofs=0030 Sep 29 09:40:10 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2800 ofs= 2000408e Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2810 ofs=0010 d6ec002a 0800 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2820 ofs=0020 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2830 ofs=0030 Sep 29 10:08:17 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb600 ofs= 2000408e Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb610 ofs=0010 d6ec002a 0600 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb620 ofs=0020 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb630 ofs=0030 Sep 29 10:21:51 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2300 ofs= 2000408e Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2310 ofs=0010 d6ec002a 0300 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2320 ofs=0020 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2330 ofs=0030 Sep 29 16:16:23 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a800 ofs= 03000263 408040e0 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a810 ofs=0010 e10f002a 0800 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a820 ofs=0020 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a830 ofs=0030 Sep 29 21:50:04 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0700 ofs= 20804076 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0710 ofs=0010 fb42002a 0700 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0720 ofs=0020 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0730 ofs=0030 Sep 30 03:55:49 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error
Re: [PATCH] properly reserve in bootmem the lmb reserved regions that cross numa nodes
Kumar Gala wrote: > Out of interest how to do you guys represent NUMA regions of memory in > the device tree? > > - k Looking at the source code in numa.c I see at the start of do_init_bootmem() that parse_numa_properties() is called. It appears to be looking at memory nodes and getting the node id from it. It gets an associativity property for the memory node and indexes that array with a 'min_common_depth' value to get the node id. This node id is then used to setup the active ranges in the early_node_map[]. Is this what you are asking about? There are others I am sure who know more about it then I though. Jon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8315ERDB PCI Express support status?
On Oct 6, 2008, at 8:42 AM, Leon Woestenberg wrote: Hello all, can Freescale or any of the powerpc maintainers indicate to what extend PCI Express support for the MPC8315E processor has been merged to Linux mainline, or what is still needs review or attention? I could find u-boot and Linux patches provided by Freescale in their open-source patch pool: http://www.bitshrine.org/gpp/ http://www.bitshrine.org/gpp/linux-fsl-2.6.24.3-MPC8315ERDB-pcie-INTx-support.patch but I could not easily identify what has been merged upstream. My first goal (and hardware on my desk) would be to test an Intel PCIe PRO/1000 Ethernet adapter, as a start to add a custom PCIe FPGA device. No PCI-e support for 83xx has been merged in any mainline kernel. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8315ERDB PCI Express support status?
Hello all, can Freescale or any of the powerpc maintainers indicate to what extend PCI Express support for the MPC8315E processor has been merged to Linux mainline, or what is still needs review or attention? I could find u-boot and Linux patches provided by Freescale in their open-source patch pool: http://www.bitshrine.org/gpp/ http://www.bitshrine.org/gpp/linux-fsl-2.6.24.3-MPC8315ERDB-pcie-INTx-support.patch but I could not easily identify what has been merged upstream. My first goal (and hardware on my desk) would be to test an Intel PCIe PRO/1000 Ethernet adapter, as a start to add a custom PCIe FPGA device. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Before adding preiliminary support for Netstal HCU4 (PPC405 based) board
On Tue, 30 Sep 2008, Niklaus Giger wrote:
> The patch is against the master git of denx.de. It does not apply cleanly
> against linus' git as I cannot find there any include/asm-ppc subdirectory.
{arch/,include-asm-}ppc/ has been removed, in favor of arch/powerpc/.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre 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/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
