linux-next: powerpc build warning
Hi Paul, Today's linux-next build (powerpc allyesconfig) produced this warning: arch/powerpc/mm/numa.c: In function 'do_init_bootmem': arch/powerpc/mm/numa.c:932: warning: unused variable 'i' Caused by commit 4a6186696e7f15b3ea4dafcdb64ee0703e0e4487 (powerpc: Fix boot freeze on machine with empty memory node) which is now in Linus' tree. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpqyN656Psyo.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help enabling PCI endpoint on 460EX, host sees disabled
On Wed, 2008-12-10 at 16:17 -0800, Ira Snyder wrote: On Wed, Dec 10, 2008 at 05:29:53PM -0600, Ayman El-Khashab wrote: My system consists of a pair of 460EXs attached by way of both PCI-E and PCI. Ultimately my goal is to communicate between them via pci-e (is there anything out there that does this already?). I can't help you with that exact board, but I've written an ethernet over PCI driver for Linux and U-Boot. The Linux driver has been posted here on linuxppc-dev and on the lkml. Search for net: add PCINet driver and you'll find it. It won't work on your board, but it should serve as a good example about how to communicate over PCI. You are the third user asking for something like this recently. :) Too bad the mainline kernel developers seem to be mostly ignoring the driver I wrote. Don't get too disappointed... a lot of us are busy and things fall through the cracks.. it may just be that we had nothing bad to say about it :-) Seriously, if you feel you didn't get useful reviews or that nothing is picking it up, just holler, and nag us. We all have pretty full plates and things do slip or just forgotten :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Introduce ppc_pci_flags accessors
On Wed, 2008-12-10 at 19:53 -0500, Josh Boyer wrote: That's fine too. I think you can Michael can have a virtual arm-wrestling match to decide whether ppc_pci_has_flag or ppc_pci_flags_are_set wins ;) I vote for _has_flag() :-) I even wonder if we need the word flag in there at all, but then I'm just being anal ! Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
How to support 3GB pci address?
Hi, we want to design a system using mpc8548, and linking with an idt 16 ports PCIE switch. In the system, the total PCI address needed is about 3GB, so I want to know how to support it in linux. mpc8548 has 36-bit real address, and can support 32GB PCIE address space, but in linux, there is only 1GB kernel space, how to map the 3GB pci address to kernel? Is the 36-bit real address only used to support large memory(4GB) for muti-threads? Any suggestions please would be much appreciated! Thanks in advance for your help ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'merge' branch of 4xx tree
Hi Paul, I have one more small fix for 2.6.28 in my merge branch. It fixes an assembler error with some toolchains, notably ELDK. I've CC'd Linus in case you don't have anything else pending at the moment. josh The following changes since commit ab44f4627e2160cddbddbe8aa8b1d2b2e1559790: Paul Mackerras (1): Merge branch 'merge' of master.kernel.org:/.../galak/powerpc into merge are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge Josh Boyer (1): powerpc/40x: Add proper BOOTCFLAGS for cuboot-acadia arch/powerpc/boot/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] NOMMU: Rename PowerPC's struct vm_region
Rename PowerPC's struct vm_region so that I can introduce my own global version
for NOMMU. It's feasible that the PowerPC version may wish to use my global
one instead.
The NOMMU vm_region struct defines areas of the physical memory map that are
under mmap. This may include chunks of RAM or regions of memory mapped
devices, such as flash. It is also used to retain copies of file content so
that shareable private memory mappings of files can be made. As such, it may
be compatible with what is described in the banner comment for PowerPC's
vm_region struct.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
arch/powerpc/lib/dma-noncoherent.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/dma-noncoherent.c
b/arch/powerpc/lib/dma-noncoherent.c
index 31734c0..a55c6ca 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -77,26 +77,26 @@ static DEFINE_SPINLOCK(consistent_lock);
* the amount of RAM found at boot time.) I would imagine that get_vm_area()
* would have to initialise this each time prior to calling vm_region_alloc().
*/
-struct vm_region {
+struct ppc_vm_region {
struct list_headvm_list;
unsigned long vm_start;
unsigned long vm_end;
};
-static struct vm_region consistent_head = {
+static struct ppc_vm_region consistent_head = {
.vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
.vm_start = CONSISTENT_BASE,
.vm_end = CONSISTENT_END,
};
-static struct vm_region *
-vm_region_alloc(struct vm_region *head, size_t size, gfp_t gfp)
+static struct ppc_vm_region *
+ppc_vm_region_alloc(struct ppc_vm_region *head, size_t size, gfp_t gfp)
{
unsigned long addr = head-vm_start, end = head-vm_end - size;
unsigned long flags;
- struct vm_region *c, *new;
+ struct ppc_vm_region *c, *new;
- new = kmalloc(sizeof(struct vm_region), gfp);
+ new = kmalloc(sizeof(struct ppc_vm_region), gfp);
if (!new)
goto out;
@@ -130,9 +130,9 @@ vm_region_alloc(struct vm_region *head, size_t size, gfp_t
gfp)
return NULL;
}
-static struct vm_region *vm_region_find(struct vm_region *head, unsigned long
addr)
+static struct ppc_vm_region *ppc_vm_region_find(struct ppc_vm_region *head,
unsigned long addr)
{
- struct vm_region *c;
+ struct ppc_vm_region *c;
list_for_each_entry(c, head-vm_list, vm_list) {
if (c-vm_start == addr)
@@ -151,7 +151,7 @@ void *
__dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
{
struct page *page;
- struct vm_region *c;
+ struct ppc_vm_region *c;
unsigned long order;
u64 mask = 0x00ff, limit; /* ISA default */
@@ -191,7 +191,7 @@ __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t
gfp)
/*
* Allocate a virtual address in the consistent mapping region.
*/
- c = vm_region_alloc(consistent_head, size,
+ c = ppc_vm_region_alloc(consistent_head, size,
gfp ~(__GFP_DMA | __GFP_HIGHMEM));
if (c) {
unsigned long vaddr = c-vm_start;
@@ -239,7 +239,7 @@ EXPORT_SYMBOL(__dma_alloc_coherent);
*/
void __dma_free_coherent(size_t size, void *vaddr)
{
- struct vm_region *c;
+ struct ppc_vm_region *c;
unsigned long flags, addr;
pte_t *ptep;
@@ -247,7 +247,7 @@ void __dma_free_coherent(size_t size, void *vaddr)
spin_lock_irqsave(consistent_lock, flags);
- c = vm_region_find(consistent_head, (unsigned long)vaddr);
+ c = ppc_vm_region_find(consistent_head, (unsigned long)vaddr);
if (!c)
goto no_area;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC8610HPCD sound as module
Hello, I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs fine on this, with a catch: sound only works, when compiled in the kernel (see: http://www.alsa-project.org/db/?f=73fb074ce0b41463bb3f32aaa297a1e1f53caf2d ). When the exact same sound options are compiled as modules (see: http://www.alsa-project.org/db/?f=c353962950284d61bd16ac7d48032b8b5f598062 ), then sound card is not found. Both kernel configurations were based on mpc8610_hpcd_defconfig with some minor tweaks (some additional fs options to be able to boot SuSE Linux). The only difference between the two configs is that in the second case sound is modular. As far as I can see from comments in the sources, it should work also as a module. Any hints how to achieve that? Thanks, bye, CzP ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ADS5121 Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers\nUse ALARM interrupt to avoid waiting for data to come in
On Wed, 10 Dec 2008 19:49:58 +0100 Matteo Fortini [EMAIL PROTECTED] wrote: From d500e922b750a2bea554d32d8f12937f4da9c80a Mon Sep 17 00:00:00 2001 From: Matteo Fortini [EMAIL PROTECTED] Date: Wed, 10 Dec 2008 19:33:16 +0100 Subject: [PATCH] Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers Use ALARM interrupt to avoid waiting for data to come in Signed-off-by: Matteo Fortini [EMAIL PROTECTED] --- drivers/spi/mpc512x_psc_spi.c | 53 - 1 files changed, 31 insertions(+), 22 deletions(-) This patch is whitespace corrupted. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] NOMMU: Rename PowerPC's struct vm_region
On Thu, 11 Dec 2008 12:53:54 +
David Howells [EMAIL PROTECTED] wrote:
Rename PowerPC's struct vm_region so that I can introduce my own global
version
for NOMMU. It's feasible that the PowerPC version may wish to use my global
one instead.
The NOMMU vm_region struct defines areas of the physical memory map that are
under mmap. This may include chunks of RAM or regions of memory mapped
devices, such as flash. It is also used to retain copies of file content so
that shareable private memory mappings of files can be made. As such, it may
be compatible with what is described in the banner comment for PowerPC's
vm_region struct.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
arch/powerpc/lib/dma-noncoherent.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/dma-noncoherent.c
b/arch/powerpc/lib/dma-noncoherent.c
index 31734c0..a55c6ca 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -77,26 +77,26 @@ static DEFINE_SPINLOCK(consistent_lock);
* the amount of RAM found at boot time.) I would imagine that get_vm_area()
* would have to initialise this each time prior to calling
vm_region_alloc().
*/
-struct vm_region {
+struct ppc_vm_region {
struct list_headvm_list;
unsigned long vm_start;
unsigned long vm_end;
};
-static struct vm_region consistent_head = {
+static struct ppc_vm_region consistent_head = {
.vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
.vm_start = CONSISTENT_BASE,
.vm_end = CONSISTENT_END,
};
-static struct vm_region *
-vm_region_alloc(struct vm_region *head, size_t size, gfp_t gfp)
+static struct ppc_vm_region *
+ppc_vm_region_alloc(struct ppc_vm_region *head, size_t size, gfp_t gfp)
Is there a reason you renamed all the function names as well when they
are static?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] NOMMU: Rename PowerPC's struct vm_region
Josh Boyer [EMAIL PROTECTED] wrote: Is there a reason you renamed all the function names as well when they are static? Well, static functions can still conflict with a function of the same name that's declared globally in a header file, but mainly because M-x replace-string doesn't differentiate. David ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 VIRQ question
Benjamin Herrenschmidt wrote:
[EMAIL PROTECTED] {
device_type = board-control;
#address-cells = 1;
#size-cells = 1;
// Note: includes sub-devices like CAN, A/D, etc
reg = 0xf800 0x10;
fpga_ic: [EMAIL PROTECTED] {
device_type = fpga-int-ctlr;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
interrupts = 2 26 3; // IRQ2
BTW, this is wrong! Are the IRQ mappings on the MPC5200 documented
somewhere? I've looked and looked without much joy. Only by
experimentation did I discover that 1 2 3 corresponds to IRQ2.
The content of the interrupts property depends on a given PIC binding. I
don't know if Grant or Sylvain published their binding but in the
meantime, you can look at the code that decodes that stuff :-) It's in
arch/powerpc/platforms/mpc52xx_pic.c : mpc52xx_irqhost_xlate().
My understanding from a quick look at the code is that the first
number (called L1) is the category (0 = CRIT, 1 = MAIN, 2 = PERP, ...)
since I think inside the 52xx, interrupts are divided into such
categories coming from different sources. The second number would thus
be the number within that category.
It looks to me that the external IRQs 1..3 are of type main (1) and
number 1 to 3. That would give you a binding of 1 n s where n is
1..3 and s is the sense code
For mpc52xx, the sense code is 0=high level,1=rising edge,2=falling edge
and 3=low level (still from looking at the code).
The mpc52xx irq binding is indeed more complicated than most :-)
Thanks for the elucidation; I would think it useful to have this spelled
out somewhere - without having to dig through the [truly] awful MPC5200
manual! A simple bit of documentation can go a long way... e.g.
IRQ1 = 1 1 n
IRQ2 = 1 2 n
...
CAN0 = 2 11 0
... etc
This part is still a bit fuzzy. Where/how does my interrupt controller
driver get this VIRQ? Here's how I created my controller:
fpga_can_irq = irq_of_parse_and_map(fpga_ic, 0);
D_printk((%s: fpga_irq = %d\n, __func__, (u32) fpga_can_irq));
if (fpga_can_irq == 0) {
printk(KERN_ERR %s: Can't find FPGA Interrupt Controller IRQ,
__func__);
return -EINVAL;
}
if (request_irq(fpga_can_irq, fpga_irq_cascade, 0, FPGA CAN, 0)) {
printk(KERN_ERR %s: Can't attach to FPGA Interrupt Controller IRQ,
__func__);
return -EINVAL;
}
fpga_irq_host = irq_alloc_host(of_node_get(fpga_node),
IRQ_HOST_MAP_LINEAR,
16, fpga_irq_host_ops, -1);
When I try to get the interrupt number for the CAN sub-device,
I always get zero :-(
for_each_compatible_node(np, can, am,can) {
memset(r, 0, sizeof(r));
rc = of_address_to_resource(np, 0, r[0]);
if (rc) {
return rc;
}
rc = of_irq_to_resource(np, 0, r[1]);
if (rc) {
return rc;
}
}
Note: the of_address_to_resource() call works fine, but the
of_irq_to_resource() fails - always returns 0. Any ideas what
I'm doing wrong?
We should trace what your fpga_irq_host_ops are doing.
Add some debug to irq_of_parse_and_map() first. This function first
calls of_irq_map_one() which will walk the device-tree to match your
interrupt to a controller node (going through all the interrupt-map's on
the way if any, but you don't have any) and should return with
oirq.controller being the device-node of your fpga_ic. If not, then we
missed a bogon in the device-tree.
At this stage, if it hasn't failed, it will call
irq_create_of_mapping().
I traced through this and this is where it was failing.
unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
{
struct of_irq oirq;
if (of_irq_map_one(dev, index, oirq))
return NO_IRQ;
return irq_create_of_mapping(oirq.controller, oirq.specifier,
oirq.size);
}
Notice that of_irq_map_one() can fail for a myriad of reasons - all quiet
(without debugging on). This function simply masks those into sorry...
After a lot of looking I found this in mt DTS:
[EMAIL PROTECTED] {
compatible = am,can;
device_type = can;
interrupts = 0;
cell-index = 0;
interrupt_parent = fpga_ic;
reg = 0xf801 0x200;
};
See the bug? Truly not obvious, is it? and the fact that
'irq_of_parse_and_map()'
just tossed a sorry == NO_IRQ didn't help find it.
This line:
interrupt_parent = fpga_ic;
should read:
interrupt-parent = fpga_ic;
I fixed that and got the rest figured out.
Thanks for the help.
--
[RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
Make the generic uio-driver also accessible for of devices. It utilizes the
standard 'reg' and 'interrupt' properties. A typical usage would look like
this:
[EMAIL PROTECTED] {
compatible = generic-uio;
reg = 0x3000 0x20;
interrupts = 0xa;
interrupt-parent = fpga_irq_mux;
};
To achieve this, the probe function has been refactored, so it can be used by
platform and of code. Then, the of driver has been added.
Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
drivers/uio/uio_pdrv_genirq.c | 178 --
1 file changed, 154 insertions(+), 24 deletions(-)
Index: playground/drivers/uio/uio_pdrv_genirq.c
===
--- playground.orig/drivers/uio/uio_pdrv_genirq.c
+++ playground/drivers/uio/uio_pdrv_genirq.c
@@ -1,13 +1,15 @@
/*
* drivers/uio/uio_pdrv_genirq.c
*
- * Userspace I/O platform driver with generic IRQ handling code.
+ * Userspace I/O platform of driver with generic IRQ handling code.
*
* Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008 Wolfram Sang, Pengutronix e.K.
*
* Based on uio_pdrv.c by Uwe Kleine-Koenig,
* Copyright (C) 2008 by Digi International Inc.
* All rights reserved.
+ * Adding of_platform_driver based on xilinxfb.c by Grant Likely.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published by
@@ -20,6 +22,10 @@
#include linux/bitops.h
#include linux/interrupt.h
#include linux/stringify.h
+#if defined(CONFIG_OF)
+#include linux/of_device.h
+#include linux/of_platform.h
+#endif
#define DRIVER_NAME uio_pdrv_genirq
@@ -68,28 +74,18 @@
return 0;
}
-static int uio_pdrv_genirq_probe(struct platform_device *pdev)
+static int uio_pdrv_genirq_setup(struct device *dev, struct uio_info *uioinfo,
+ struct resource *resources, unsigned int num_resources)
{
- struct uio_info *uioinfo = pdev-dev.platform_data;
struct uio_pdrv_genirq_platdata *priv;
struct uio_mem *uiomem;
- int ret = -EINVAL;
- int i;
-
- if (!uioinfo || !uioinfo-name || !uioinfo-version) {
- dev_err(pdev-dev, missing platform_data\n);
- goto bad0;
- }
-
- if (uioinfo-handler || uioinfo-irqcontrol || uioinfo-irq_flags) {
- dev_err(pdev-dev, interrupt configuration error\n);
- goto bad0;
- }
+ unsigned int i;
+ int ret;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
- dev_err(pdev-dev, unable to kmalloc\n);
+ dev_err(dev, unable to kmalloc\n);
goto bad0;
}
@@ -99,14 +95,15 @@
uiomem = uioinfo-mem[0];
- for (i = 0; i pdev-num_resources; ++i) {
- struct resource *r = pdev-resource[i];
+ for (i = 0; i num_resources; ++i) {
+
+ struct resource *r = resources + i;
if (r-flags != IORESOURCE_MEM)
continue;
if (uiomem = uioinfo-mem[MAX_UIO_MAPS]) {
- dev_warn(pdev-dev, device has more than
+ dev_warn(dev, device has more than
__stringify(MAX_UIO_MAPS)
I/O memory resources.\n);
break;
@@ -137,13 +134,13 @@
uioinfo-irqcontrol = uio_pdrv_genirq_irqcontrol;
uioinfo-priv = priv;
- ret = uio_register_device(pdev-dev, priv-uioinfo);
+ ret = uio_register_device(dev, priv-uioinfo);
if (ret) {
- dev_err(pdev-dev, unable to register uio device\n);
+ dev_err(dev, unable to register uio device\n);
goto bad1;
}
- platform_set_drvdata(pdev, priv);
+ dev_set_drvdata(dev, priv);
return 0;
bad1:
kfree(priv);
@@ -151,6 +148,24 @@
return ret;
}
+static int uio_pdrv_genirq_probe(struct platform_device *pdev)
+{
+ struct uio_info *uioinfo = pdev-dev.platform_data;
+
+ if (!uioinfo || !uioinfo-name || !uioinfo-version) {
+ dev_err(pdev-dev, missing platform_data\n);
+ return -EINVAL;
+ }
+
+ if (uioinfo-handler || uioinfo-irqcontrol || uioinfo-irq_flags) {
+ dev_err(pdev-dev, interrupt configuration error\n);
+ return -EINVAL;
+ }
+
+ return uio_pdrv_genirq_setup(pdev-dev, uioinfo, pdev-resource,
+ pdev-num_resources);
+}
+
static int uio_pdrv_genirq_remove(struct platform_device *pdev)
{
struct uio_pdrv_genirq_platdata *priv = platform_get_drvdata(pdev);
@@ -169,20 +184,135 @@
},
};
+/* -
+ * OF bus binding
+ */
Re: MPC8610HPCD sound as module
On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik [EMAIL PROTECTED] wrote: Hello, I have an MPC8610HPCD system. The latest stable kernel (2.6.27.8) runs fine on this, with a catch: sound only works, when compiled in the kernel That's because the driver doesn't support being compiled as a module. The Kconfig, as *I* wrote it, only allows for in-kernel compilation. The only way you could have gotten my drivers to compile as a module is if you hacked the Kconfig. As far as I can see from comments in the sources, it should work also as a module. Any hints how to achieve that? The ASoC V2 version of the driver supports loading as a module. ASoC V1 does not support loading sound drivers as modules, which is why I didn't implement that support in the V1 drivers. The 2.6.27 kernel has ASoC V1. ASoC V2 won't be integrated into the mainline until at least 2.6.29, and maybe even 2.6.30. The ASoC V2 repository is available at http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git under the asoc-v2-dev branch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Paul, Please pull the 'next' branch of the 4xx tree to pick up some initial commits for 2.6.29. There are a large number of patches from Ben for some MMU rework that will effect 4xx, but I think most of those are going in either through you directly, or through Kumar. I have a couple of other commits I need to test out, so expect a future pull request as well. josh The following changes since commit 361425fc32422c9716fc69e52455b7d44fc02c18: Haiying Wang (1): powerpc/85xx: Create dts for each core in CAMP mode for MPC8572DS are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Benjamin Herrenschmidt (1): powerpc/4xx: Add support for ISA holes on 4xx PCI/X/E Hollis Blanchard (1): powerpc/kvm: update KVM config options in ppc44x_defconfig Stefan Roese (1): powerpc/4xx: Add L2 cache node to AMCC Canyonlands dts file Stephen Rothwell (1): powerpc/44x: update ppc44x_defconfig arch/powerpc/boot/dts/bamboo.dts |3 +- arch/powerpc/boot/dts/canyonlands.dts | 14 ++ arch/powerpc/configs/ppc44x_defconfig | 12 +- arch/powerpc/sysdev/ppc4xx_pci.c | 306 ++--- 4 files changed, 230 insertions(+), 105 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
Mark Brown wrote: ASoC v1 supports loading drivers as modules (and this is fairly heavily used), though as you say the MPC8610 drivers don't support that. Well, at the time I wrote the drivers, I didn't see an easy way to support modules, since V1 drivers typically have lots of hard-coded references to global variables in other files. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
On Thu, Dec 11, 2008 at 09:40:55AM -0600, Timur Tabi wrote:
Mark Brown wrote:
ASoC v1 supports loading drivers as modules (and this is fairly heavily
used), though as you say the MPC8610 drivers don't support that.
Well, at the time I wrote the drivers, I didn't see an easy way to support
modules, since V1 drivers typically have lots of hard-coded references to
global
variables in other files.
The only references should be machine-{codec,ssi} and ssi-platform.
There's a reasonable chance that your drivers would work fine if you
just marked them all as tristate, though since they're written rather
differently to other ASoC drivers it's possible something will break.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
Mark Brown wrote:
The only references should be machine-{codec,ssi} and ssi-platform.
There's a reasonable chance that your drivers would work fine if you
just marked them all as tristate, though since they're written rather
differently to other ASoC drivers it's possible something will break.
And since I fixed the code in the V2 drivers, I have no interest in fixing it in
the V1 drivers, which are officially in maintenance mode -- only critical bug
fixes, no new features.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
On Thu, Dec 11, 2008 at 09:12:54AM -0600, Timur Tabi wrote: On Thu, Dec 11, 2008 at 7:18 AM, Peter Czanik [EMAIL PROTECTED] wrote: As far as I can see from comments in the sources, it should work also as a module. Any hints how to achieve that? The ASoC V2 version of the driver supports loading as a module. ASoC V1 does not support loading sound drivers as modules, which is why I didn't implement that support in the V1 drivers. The 2.6.27 kernel ASoC v1 supports loading drivers as modules (and this is fairly heavily used), though as you say the MPC8610 drivers don't support that. has ASoC V1. ASoC V2 won't be integrated into the mainline until at least 2.6.29, and maybe even 2.6.30. The ASoC V2 repository is available at http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git under the asoc-v2-dev branch. At the minute there's code queued for merge which defers card instantiation until DAIs and platforms have registered, allowing the various parts of the system to probe through the normal mechanisms. That's the most substantial of the outstanding changes. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to support 3GB pci address?
On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote: Hi, we want to design a system using mpc8548, and linking with an idt 16 ports PCIE switch. In the system, the total PCI address needed is about 3GB, so I want to know how to support it in linux. mpc8548 has 36-bit real address, and can support 32GB PCIE address space, but in linux, there is only 1GB kernel space, how to map the 3GB pci address to kernel? Is the 36-bit real address only used to support large memory(4GB) for muti- threads? Any suggestions please would be much appreciated! Thanks in advance for your help The 36-bit support is current (in tree) in complete. Work is in progress to add swiotlb support to PPC which will generically enable what you want to accomplish. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help enabling PCI endpoint on 460EX, host sees disabled
On Thu, Dec 11, 2008 at 10:04:28PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-12-10 at 16:17 -0800, Ira Snyder wrote: On Wed, Dec 10, 2008 at 05:29:53PM -0600, Ayman El-Khashab wrote: My system consists of a pair of 460EXs attached by way of both PCI-E and PCI. Ultimately my goal is to communicate between them via pci-e (is there anything out there that does this already?). I can't help you with that exact board, but I've written an ethernet over PCI driver for Linux and U-Boot. The Linux driver has been posted here on linuxppc-dev and on the lkml. Search for net: add PCINet driver and you'll find it. It won't work on your board, but it should serve as a good example about how to communicate over PCI. You are the third user asking for something like this recently. :) Too bad the mainline kernel developers seem to be mostly ignoring the driver I wrote. Don't get too disappointed... a lot of us are busy and things fall through the cracks.. it may just be that we had nothing bad to say about it :-) Seriously, if you feel you didn't get useful reviews or that nothing is picking it up, just holler, and nag us. We all have pretty full plates and things do slip or just forgotten :-) Thanks Ben. I'm still working on various issues with the hardware. Soon I'll be able to easily test several boards in the same system at the same time. Once I've proven that works, I'll start nagging :) Is there a better subject line I should use to get attention, or should I just start CC'ing people? Sorry if I sounded negative in my post. It's just a little discouraging when you don't get lots of feedback. I REALLY appreciate all of the work you and everyone else is doing. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
: [PATCH] Add_460SX_Initial_Framework
Josh,
I will be handling this patch from now on. I will modify the patch and
answer your queries soon.
Thanks,
Marri
Message: 2
Date: Mon, 1 Dec 2008 20:32:56 -0500
From: Josh Boyer jwbo...@linux.vnet.ibm.com
Subject: Re: [PATCH] Add_460SX_Initial_Framework
To: mmadishe...@amcc.com
Cc: linuxppc-dev@ozlabs.org
Message-ID: 20081202013256.gb25...@zod.rchland.ibm.com
Content-Type: text/plain; charset=us-ascii
On Mon, Dec 01, 2008 at 03:37:15PM -0800, mmadishe...@amcc.com wrote:
From: Madhulika Madishetty mmadishe...@amcc.com
This patch contains the initial framework for AMCC Redwood board.
Signed-off-by: Madhulika Madishetty mmadishe...@amcc.com, Tirumala
Reddy
Marri tma...@amcc.com,
Feng Kan f...@amcc.com, Vidhyananth Venkatasamy
vvenkatas...@amcc.com,
Preetesh Parekh ppar...@amcc.com
Acked-by: Loc Ho l...@amcc.com, Feng Kan f...@amcc.com
One Signed-off-by: per person, per line please. Don't use a single
with multiple names.
---
arch/powerpc/boot/dts/redwood_amcc.dts | 247 +++
arch/powerpc/configs/44x/redwood_defconfig | 1082
Parts of your patch are word-wrapped.
diff --git a/arch/powerpc/boot/dts/redwood_amcc.dts
b/arch/powerpc/boot/dts/redwood_amcc.dts
new file mode 100644
index 000..e4f5efd
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood_amcc.dts
Any particular reason you chose to call this redwood_amcc.dts? None
of the other boards do that.
Also, what possessed AMCC to create an entirely new board called
Redwood when there is already a 4xx board called Redwood? I realize
this isn't really something you can control, and the old board isn't
supported any longer, but still... yell at your marketing people or
something :).
@@ -0,0 +1,247 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC tma...@amcc.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
If this is really a dts-v1, I would expect all the values here to
look differently. See below.
+
+/ {
+ #address-cells = 2;
+ #size-cells = 1;
+ model = amcc,redwood;
+ compatible = amcc,redwood;
+ dcr-parent = /cpus/c...@0;
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,460SX;
+ reg = 0;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot
*/
+ i-cache-line-size = 20;
+ d-cache-line-size = 20;
Here. You have a i/d-cache line size of 20 bytes? That's odd...
+ i-cache-size = 8000;
+ d-cache-size = 8000;
And you have a cache size of 8000 bytes? Also odd. I would expect
these
lines to look like:
i-cache-line-size = 0x20;
i-cache-size = 0x8000;
or
i-cache-line-size = 32;
i-cache-size = 32768;
Please go through and verify all the values are properly filled out.
I'm
not even sure how this works with newer dtc versions.
+ dcr-controller;
+ dcr-access-method = native;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0 0; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0c0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0d0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 1e 4 1f 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0e0 009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = a 4 b 4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = ibm,uic-460sx,ibm,uic;
+ interrupt-controller;
+ cell-index = 3;
+ dcr-reg = 0f0 009;
+ #address-cells = 0;
+
[PATCH 1/2] remove unused i var
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c |1 -
1 file changed, 1 deletion(-)
diff -puN arch/powerpc/mm/numa.c~remove-unused-i-var arch/powerpc/mm/numa.c
--- linux-2.6.git/arch/powerpc/mm/numa.c~remove-unused-i-var2008-12-11
09:12:57.0 -0800
+++ linux-2.6.git-dave/arch/powerpc/mm/numa.c 2008-12-11 09:12:57.0
-0800
@@ -929,7 +929,6 @@ static void mark_reserved_regions_for_ni
void __init do_init_bootmem(void)
{
int nid;
- unsigned int i;
min_low_pfn = 0;
max_low_pfn = lmb_end_of_DRAM() PAGE_SHIFT;
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] Fix a bug and cleanup NUMA boot-time code
The first patch in this series is a genuine bug fix. The rest are really just an RFC. Jon introduced a bug a while ago. I introduced another when trying to fix Jon's bug. I refuse to accept personal blame for this and, instead, blame the code. :) The reset of the series are cleanups that I think will help clarify the code in numa.c and work to ensure that the next bonehead like me is not as able to easily muck up the code. :) The cleanups increase in impact and intrusiveness as the series goes along, so please consider them an RFC. But, what I really want to figure out is a safer way to initialize NODE_DATA() and start using it as we bring up bootmem on all the nodes. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] fix bootmem reservation on uninitialized node
careful_allocation() was calling into the bootemem allocator for
nodes which had not been fully initialized and caused a previous
bug. http://patchwork.ozlabs.org/patch/10528/ So, I merged a
few broken out loops in do_init_bootmem() to fix it. That changed
the code ordering.
I think this bug is triggered by having reserved areas for a node
which are spanned by another node's contents. In the
mark_reserved_regions_for_nid() code, we attempt to reserve the
area for a node before we have allocated the NODE_DATA() for that
nid. We do this since I reordered that loop. I suck.
This may only present on some systems that have 16GB pages
reserved. But, it can probably happen on any system that is
trying to reserve large swaths of memory that happen to span other
nodes' contents.
This patch ensures that we do not touch bootmem for any node which
has not been initialized.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
linux-2.6.git-dave/arch/powerpc/mm/numa.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff -puN arch/powerpc/mm/numa.c~fix-bad-node-reserve arch/powerpc/mm/numa.c
--- linux-2.6.git/arch/powerpc/mm/numa.c~fix-bad-node-reserve 2008-12-10
14:54:18.0 -0800
+++ linux-2.6.git-dave/arch/powerpc/mm/numa.c 2008-12-10 14:55:33.0
-0800
@@ -901,10 +901,17 @@ static void mark_reserved_regions_for_ni
if (end_pfn node_ar.end_pfn)
reserve_size = (node_ar.end_pfn PAGE_SHIFT)
- (start_pfn PAGE_SHIFT);
- dbg(reserve_bootmem %lx %lx nid=%d\n, physbase,
- reserve_size, node_ar.nid);
- reserve_bootmem_node(NODE_DATA(node_ar.nid), physbase,
- reserve_size, BOOTMEM_DEFAULT);
+ /*
+* Only worry about *this* node, others may not
+* yet have valid NODE_DATA().
+*/
+ if (node_ar.nid == nid) {
+ dbg(reserve_bootmem %lx %lx nid=%d\n,
+ physbase, reserve_size, node_ar.nid);
+ reserve_bootmem_node(NODE_DATA(node_ar.nid),
+ physbase, reserve_size,
+ BOOTMEM_DEFAULT);
+ }
/*
* if reserved region is contained in the active region
* then done.
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RESEND] [PATCH] ADS5121 Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers\nUse ALARM interrupt to avoid waiting for data to come in
This patch is to avoid breaking some drivers, in my case the ADS7846
touchscreen one, which use 1 char messages.
If you put the dummy byte after the 1 char message, you get part of the
answer to the message in the rxbuf of the message, which is thrown away.
The solution is to put the dummy byte before the message, so that the
slave doesn't respond.
It also optimizes the interrupt handling, by using the alarm function of
the FIFO, to wait until the rx FIFO has received enough bytes, instead
of waiting until the tx FIFO is empty.
Signed-off-by: Matteo Fortini m.fort...@selcomgroup.com
---
drivers/spi/mpc512x_psc_spi.c | 50
+++-
1 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/mpc512x_psc_spi.c b/drivers/spi/mpc512x_psc_spi.c
index 1fd7ad4..eace796 100644
--- a/drivers/spi/mpc512x_psc_spi.c
+++ b/drivers/spi/mpc512x_psc_spi.c
@@ -175,6 +175,7 @@ static int mpc512x_psc_spi_transfer_rxtx(struct
spi_device *spi,
u8 data;
size_t fifosz;
int rxcount;
+int txcount;
/*
* The number of bytes that can be sent at a time
@@ -183,41 +184,49 @@ static int mpc512x_psc_spi_transfer_rxtx(struct
spi_device *spi,
fifosz = MPC512x_PSC_FIFO_SZ(in_be32(fifo-txsz));
count = min(fifosz, len);
+txcount = 0;
+/*
+ * Insert a dummy byte before a message of len 1 to make it at
least 2 bytes long
+ * to be able to set EOF correctly
+ */
+if (t-len == 1) {
+out_8(fifo-txdata_8, 0);
+txcount++;
+}
for (i = count; i 0; i--) {
if (len == EOFBYTE || t-len == 1)
setbits32(fifo-txcmd, MPC512x_PSC_FIFO_EOF);
data = tx_buf ? *tx_buf++ : 0;
out_8(fifo-txdata_8, data);
-if (t-len == 1)
-out_8(fifo-txdata_8, 0);
+txcount++;
len--;
}
INIT_COMPLETION(mps-done);
-/* interrupt on tx fifo empty */
-out_be32(fifo-txisr, MPC512x_PSC_FIFO_EMPTY);
-out_be32(fifo-tximr, MPC512x_PSC_FIFO_EMPTY);
-
-/* enable transmiter/receiver */
-out_8(psc-command, MPC52xx_PSC_TX_ENABLE |
MPC52xx_PSC_RX_ENABLE);
+/* Enable FIFO_ALARM interrupts for rx_fifo */
+out_be32(fifo-rxalarm, txcount);
+out_be32(fifo-rxisr, MPC512x_PSC_FIFO_ALARM);
+out_be32(fifo-rximr, MPC512x_PSC_FIFO_ALARM);
-wait_for_completion(mps-done);
+/* Disable tx_fifo interrupts */
+out_be32(fifo-txisr, 0x);
+out_be32(fifo-tximr, 0);
-mdelay(1);
+out_8(psc-command, MPC52xx_PSC_TX_ENABLE |
MPC52xx_PSC_RX_ENABLE);
-/* rx fifo should have count bytes in it */
-rxcount = in_be32(fifo-rxcnt);
-if (rxcount != count)
-mdelay(1);
+wait_for_completion (mps-done);
rxcount = in_be32(fifo-rxcnt);
-if (rxcount != count t-len != 1)
+if (rxcount != txcount)
printk(KERN_WARNING expected %d bytes in rx fifo
- but got %d\n, count, rxcount);
-
+but got %d\n, txcount, rxcount);
rxcount = min(rxcount, count);
{
+/* Throw away possible initial dummy byte */
+if (t-len == 1) {
+(void)in_8(fifo-rxdata_8);
+}
for (i = rxcount; i 0; i--) {
data = in_8(fifo-rxdata_8);
if (rx_buf)
@@ -418,10 +427,9 @@ static irqreturn_t mpc512x_psc_spi_isr(int irq,
void *dev_id)
struct mpc512x_psc_fifo __iomem *fifo = mps-fifo;
/* clear interrupt and wake up the work queue */
-if (in_be32(fifo-txisr)
- in_be32(fifo-tximr) MPC512x_PSC_FIFO_EMPTY) {
-out_be32(fifo-txisr, MPC512x_PSC_FIFO_EMPTY);
-out_be32(fifo-tximr, 0);
+if (in_be32(fifo-rxisr) in_be32(fifo-rximr)
MPC512x_PSC_FIFO_ALARM) {
+out_be32(fifo-rxisr, MPC512x_PSC_FIFO_ALARM);
+out_be32(fifo-rximr, 0);
complete(mps-done);
return IRQ_HANDLED;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND] [PATCH] ADS5121 Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers\nUse ALARM interrupt to avoid waiting for data to come in
On Thu, 11 Dec 2008 19:39:21 +0100 Matteo Fortini m.fort...@selcomgroup.com wrote: This patch is to avoid breaking some drivers, in my case the ADS7846 touchscreen one, which use 1 char messages. If you put the dummy byte after the 1 char message, you get part of the answer to the message in the rxbuf of the message, which is thrown away. The solution is to put the dummy byte before the message, so that the slave doesn't respond. It also optimizes the interrupt handling, by using the alarm function of the FIFO, to wait until the rx FIFO has received enough bytes, instead of waiting until the tx FIFO is empty. Signed-off-by: Matteo Fortini m.fort...@selcomgroup.com --- drivers/spi/mpc512x_psc_spi.c | 50 +++- 1 files changed, 29 insertions(+), 21 deletions(-) This still seems to be whitespace corrupted. Also, that file doesn't even exist in any upstream kernel I can find. What tree did you diff this from? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
On Thu, Dec 11, 2008 at 09:45:26AM -0600, Timur Tabi wrote: And since I fixed the code in the V2 drivers, I have no interest in fixing it in the V1 drivers, which are officially in maintenance mode -- only critical bug fixes, no new features. Well, from that point of view now would be a good time for you to start backporting your newer code. The concept of having the core wait for subdevices to probe is now there which was the major win from the point of view of integration with the device tree. What's there now also has the changes you wanted without the use of templates in the ASoC core so you can do a single memory allocation for devices rather than having to fill out templates and have the core do allocations for you. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] check for GIQ indicator before calling set-indicator
Since Factor out cpu joining/unjoining the GIQ
(b4963255ad5a426f04a0bb15c4315fa4bb40cde9) the WARN_ON in
xics_set_cpu_giq() is being triggered during boot on JS20 because the
GIQ indicator is not available on that platform. While the warning is
harmless and the system runs normally, it's nicer to check for the
existence of the indicator before trying to manipulate it.
Implement rtas_indicator_present(), which searches the
/rtas/rtas-indicators property for the given indicator token, and use
this function in xics_set_cpu_giq().
Also use a WARN statement in xics_set_cpu_giq to get better
information on failure.
Signed-off-by: Nathan Lynch n...@pobox.com
---
arch/powerpc/include/asm/rtas.h |1 +
arch/powerpc/kernel/rtas.c| 26 ++
arch/powerpc/platforms/pseries/xics.c | 15 ---
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 8eaa7b2..e0175be 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -168,6 +168,7 @@ extern void rtas_os_term(char *str);
extern int rtas_get_sensor(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int *setlevel);
+extern bool rtas_indicator_present(int token, int *maxindex);
extern int rtas_set_indicator(int indicator, int index, int new_value);
extern int rtas_set_indicator_fast(int indicator, int index, int new_value);
extern void rtas_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 1f8505c..fdfe14c 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -566,6 +566,32 @@ int rtas_get_sensor(int sensor, int index, int *state)
}
EXPORT_SYMBOL(rtas_get_sensor);
+bool rtas_indicator_present(int token, int *maxindex)
+{
+ int proplen, count, i;
+ const struct indicator_elem {
+ u32 token;
+ u32 maxindex;
+ } *indicators;
+
+ indicators = of_get_property(rtas.dev, rtas-indicators, proplen);
+ if (!indicators)
+ return false;
+
+ count = proplen / sizeof(struct indicator_elem);
+
+ for (i = 0; i count; i++) {
+ if (indicators[i].token != token)
+ continue;
+ if (maxindex)
+ *maxindex = indicators[i].maxindex;
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(rtas_indicator_present);
+
int rtas_set_indicator(int indicator, int index, int new_value)
{
int token = rtas_token(set-indicator);
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index e190477..37f5986 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -728,9 +728,18 @@ static void xics_set_cpu_priority(unsigned char cppr)
/* Have the calling processor join or leave the specified global queue */
static void xics_set_cpu_giq(unsigned int gserver, unsigned int join)
{
- int status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
- (1UL interrupt_server_size) - 1 - gserver, join);
- WARN_ON(status 0);
+ int index;
+ int status;
+
+ if (!rtas_indicator_present(GLOBAL_INTERRUPT_QUEUE, NULL))
+ return;
+
+ index = (1UL interrupt_server_size) - 1 - gserver;
+
+ status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE, index, join);
+
+ WARN(status 0, set-indicator(%d, %d, %u) returned %d\n,
+GLOBAL_INTERRUPT_QUEUE, index, join, status);
}
void xics_setup_cpu(void)
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8610HPCD sound as module
Mark Brown wrote: Well, from that point of view now would be a good time for you to start backporting your newer code. The concept of having the core wait for subdevices to probe is now there which was the major win from the point of view of integration with the device tree. What's there now also has the changes you wanted without the use of templates in the ASoC core so you can do a single memory allocation for devices rather than having to fill out templates and have the core do allocations for you. Okee dokee. I'll start working on it next month. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Introduce ppc_pci_flags accessors
Currently there are a number of platforms that open code access to
the ppc_pci_flags global variable. However, that variable is not
present if CONFIG_PCI is not set, which can lead to a build break.
This introduces a number of accessor functions that are defined
to be empty in the case of CONFIG_PCI being disabled. The
various platform files in the kernel are updated to use these.
Signed-off-by: Josh Boyer jwbo...@linux.vnet.ibm.com
---
v2: Make accessors static inline functions and rename flag_is_set to has_flag
arch/powerpc/include/asm/pci-bridge.h | 26 +-
arch/powerpc/include/asm/pci.h |4 ++--
arch/powerpc/platforms/40x/ep405.c |2 +-
arch/powerpc/platforms/40x/kilauea.c |2 +-
arch/powerpc/platforms/40x/ppc40x_simple.c |2 +-
arch/powerpc/platforms/44x/ebony.c |2 +-
arch/powerpc/platforms/44x/ppc44x_simple.c |2 +-
arch/powerpc/platforms/44x/sam440ep.c |2 +-
arch/powerpc/platforms/52xx/mpc52xx_pci.c |2 +-
arch/powerpc/platforms/82xx/pq2.c |2 +-
arch/powerpc/platforms/chrp/pci.c |2 +-
arch/powerpc/platforms/powermac/pci.c |6 +++---
arch/powerpc/sysdev/fsl_pci.c |4 ++--
arch/powerpc/sysdev/grackle.c |2 +-
14 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index fa8b3b7..84007af 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -13,7 +13,6 @@
struct device_node;
-extern unsigned int ppc_pci_flags;
enum {
/* Force re-assigning all resources (ignore firmware
* setup completely)
@@ -36,6 +35,31 @@ enum {
/* ... except for domain 0 */
PPC_PCI_COMPAT_DOMAIN_0 = 0x0020,
};
+#ifdef CONFIG_PCI
+extern unsigned int ppc_pci_flags;
+
+static inline void ppc_pci_set_flags(int flags)
+{
+ ppc_pci_flags = flags;
+}
+
+static inline void ppc_pci_add_flags(int flags)
+{
+ ppc_pci_flags |= flags;
+}
+
+static inline int ppc_pci_has_flag(int flag)
+{
+ return (ppc_pci_flags flag);
+}
+#else
+static inline void ppc_pci_set_flags(int flags) { }
+static inline void ppc_pci_add_flags(int flags) { }
+static inline int ppc_pci_has_flag(int flag)
+{
+ return 0;
+}
+#endif
/*
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 1c721a6..3548159 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -38,8 +38,8 @@ struct pci_dev;
* Set this to 1 if you want the kernel to re-assign all PCI
* bus numbers (don't do that on ppc64 yet !)
*/
-#define pcibios_assign_all_busses()(ppc_pci_flags \
-PPC_PCI_REASSIGN_ALL_BUS)
+#define pcibios_assign_all_busses() \
+ (ppc_pci_has_flag(PPC_PCI_REASSIGN_ALL_BUS))
#define pcibios_scan_all_fns(a, b) 0
static inline void pcibios_set_master(struct pci_dev *dev)
diff --git a/arch/powerpc/platforms/40x/ep405.c
b/arch/powerpc/platforms/40x/ep405.c
index ae2e7f6..4058fd1 100644
--- a/arch/powerpc/platforms/40x/ep405.c
+++ b/arch/powerpc/platforms/40x/ep405.c
@@ -100,7 +100,7 @@ static void __init ep405_setup_arch(void)
/* Find init the BCSR CPLD */
ep405_init_bcsr();
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
}
static int __init ep405_probe(void)
diff --git a/arch/powerpc/platforms/40x/kilauea.c
b/arch/powerpc/platforms/40x/kilauea.c
index 1dd24ff..fd7d934 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -44,7 +44,7 @@ static int __init kilauea_probe(void)
if (!of_flat_dt_is_compatible(root, amcc,kilauea))
return 0;
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
return 1;
}
diff --git a/arch/powerpc/platforms/40x/ppc40x_simple.c
b/arch/powerpc/platforms/40x/ppc40x_simple.c
index 4498a86..f40ac9b 100644
--- a/arch/powerpc/platforms/40x/ppc40x_simple.c
+++ b/arch/powerpc/platforms/40x/ppc40x_simple.c
@@ -61,7 +61,7 @@ static int __init ppc40x_probe(void)
for (i = 0; i ARRAY_SIZE(board); i++) {
if (of_flat_dt_is_compatible(root, board[i])) {
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
return 1;
}
}
diff --git a/arch/powerpc/platforms/44x/ebony.c
b/arch/powerpc/platforms/44x/ebony.c
index a0e8fe4..88b9117 100644
--- a/arch/powerpc/platforms/44x/ebony.c
+++ b/arch/powerpc/platforms/44x/ebony.c
@@ -54,7 +54,7 @@ static int __init ebony_probe(void)
if (!of_flat_dt_is_compatible(root, ibm,ebony))
return 0;
- ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
Re: [PATCH][v2] fork_init: fix division by zero
On Wed, 10 Dec 2008 19:50:51 +0300
Yuri Tikhonov y...@emcraft.com wrote:
The following patch fixes divide-by-zero error for the
cases of really big PAGE_SIZEs (e.g. 256KB on ppc44x).
Support for big page sizes on 44x is not present in the
current kernel yet, but coming soon.
Also this patch fixes the comment for the max_threads
settings, as this didn't match the things actually done
in the code.
Signed-off-by: Yuri Tikhonov y...@emcraft.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
kernel/fork.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 8d6a7dd..638eb7f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -181,10 +181,14 @@ void __init fork_init(unsigned long mempages)
/*
* The default maximum number of threads is set to a safe
- * value: the thread structures can take up at most half
- * of memory.
+ * value: the thread structures can take up at most
+ * (1/8) part of memory.
*/
+#if (8 * THREAD_SIZE) PAGE_SIZE
max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+#else
+ max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
+#endif
The expression you've chosen here can be quite inacccurate, because
((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number. The way to
preserve accuracy is
max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE);
so how about avoiding the nasty ifdefs and doing
--- a/kernel/fork.c~fork_init-fix-division-by-zero
+++ a/kernel/fork.c
@@ -69,6 +69,7 @@
#include asm/mmu_context.h
#include asm/cacheflush.h
#include asm/tlbflush.h
+#include asm/div64.h
/*
* Protected counters by write_lock_irq(tasklist_lock)
@@ -185,10 +186,15 @@ void __init fork_init(unsigned long memp
/*
* The default maximum number of threads is set to a safe
-* value: the thread structures can take up at most half
-* of memory.
+* value: the thread structures can take up at most
+* (1/8) part of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ {
+ /* max_threads = (mempages * PAGE_SIZE) / THREAD_SIZE / 8; */
+ u64 m = mempages * PAGE_SIZE;
+ do_div(m, THREAD_SIZE * 8);
+ max_threads = m;
+ }
/*
* we need to allow at least 20 threads to boot a system
_
?
The code is also inaccurate because it assumes that whatever allocator
is used for threads will pack the thread_structs into pages with best
possible density, which isn't necessarily the case. Let's not worry
about that.
OT:
max_threads is widly wrong anyway.
- the caller passes in num_physpages, which includes highmem. And we
can't allocate thread structs from highmem.
- num_physpages includes kernel pages and other stuff which can never
be allocated via the page allocator.
A suitable fix would be to switch the caller to the strangely-named
nr_free_buffer_pages().
If you grep the tree for `num_physpages', you will find a splendid
number of similar bugs. num_physpages should be unexported, burnt,
deleted, etc. It's just an invitation to write buggy code.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Thu, Dec 11, 2008 at 12:16:35PM -0800, Andrew Morton wrote: +#if (8 * THREAD_SIZE) PAGE_SIZE max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); +#else + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE)); +#endif The expression you've chosen here can be quite inacccurate, because ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number. The way to preserve accuracy is max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE); so how about avoiding the nasty ifdefs and doing Are you sure? Do they actually cross the page boundaries? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Thu, 11 Dec 2008 20:28:00 + Al Viro v...@zeniv.linux.org.uk wrote: On Thu, Dec 11, 2008 at 12:16:35PM -0800, Andrew Morton wrote: +#if (8 * THREAD_SIZE) PAGE_SIZE max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE); +#else + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE)); +#endif The expression you've chosen here can be quite inacccurate, because ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number. The way to preserve accuracy is max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE); so how about avoiding the nasty ifdefs and doing Are you sure? No, not at all. It's all too hard. Which is why I'm looking for simplification. Do they actually cross the page boundaries? Some flavours of slab have at times done an order-1 allocation for objects which would fit into an order-0 page (etc) if it looks like that will be beneficial from a packing POV. I'm unsure whether that still happens - I tried to get it stamped out for reliability reasons. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Thu, Dec 11, 2008 at 04:05:37PM +0100, Wolfram Sang wrote:
Make the generic uio-driver also accessible for of devices. It utilizes the
standard 'reg' and 'interrupt' properties. A typical usage would look like
this:
fpga...@3000 {
compatible = generic-uio;
reg = 0x3000 0x20;
interrupts = 0xa;
interrupt-parent = fpga_irq_mux;
};
To achieve this, the probe function has been refactored, so it can be used by
platform and of code. Then, the of driver has been added.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
drivers/uio/uio_pdrv_genirq.c | 178
--
1 file changed, 154 insertions(+), 24 deletions(-)
Index: playground/drivers/uio/uio_pdrv_genirq.c
===
--- playground.orig/drivers/uio/uio_pdrv_genirq.c
+++ playground/drivers/uio/uio_pdrv_genirq.c
@@ -1,13 +1,15 @@
/*
* drivers/uio/uio_pdrv_genirq.c
*
- * Userspace I/O platform driver with generic IRQ handling code.
+ * Userspace I/O platform of driver with generic IRQ handling code.
*
* Copyright (C) 2008 Magnus Damm
+ * Copyright (C) 2008 Wolfram Sang, Pengutronix e.K.
*
* Based on uio_pdrv.c by Uwe Kleine-Koenig,
* Copyright (C) 2008 by Digi International Inc.
* All rights reserved.
+ * Adding of_platform_driver based on xilinxfb.c by Grant Likely.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 as published
by
@@ -20,6 +22,10 @@
#include linux/bitops.h
#include linux/interrupt.h
#include linux/stringify.h
+#if defined(CONFIG_OF)
+#include linux/of_device.h
+#include linux/of_platform.h
+#endif
You should never need to test a config variable in order to know to
include a header file or not.
+/* -
+ * OF bus binding
+ */
+
+#if defined(CONFIG_OF)
Same goes here, don't put #if in .c files please.
thanks,
greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC5200 VIRQ question
On Thu, 2008-12-11 at 07:59 -0700, Gary Thomas wrote: Notice that of_irq_map_one() can fail for a myriad of reasons - all quiet (without debugging on). This function simply masks those into sorry... Right, it's not verbose on failure for various reasons. Most failures because something went wrong -before- the failure. IE. Your missing interrupt parent would make it go to the parent etc... and it would fail later on for a totally different reason than the original missing interrupt parent. Also, there's a number of older machines out there with crap device-trees on which we know it will fail. The PCI code has a fallback mechanism for them. However, there's pretty extensive debug output that you can enable explicitely in that file. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] leds: Support OpenFirmware led bindings
On Wed, 10 Dec 2008, Anton Vorontsov wrote: +gpio_direction_output(led_dat-gpio, led_dat-active_low); This can fail (yeah, the original code didn't check return value either). I've added a check. +unsigned int flags; I think it would be better to use `enum of_gpio_flags' type here, just for clarity. You're right, I forgot to change this after the of_get_gpio patch was changed. +ret = create_gpio_led(led, pdata-led_data[pdata-num_leds++], + ofdev-dev, NULL); +if (ret 0) of_node_put(np); is missing here. of_node_put(child) you mean. It's easy to forget this when one exits one of these iterators early, since there's no explicit get or put otherwise. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 2/4] leds: Add option to have GPIO LEDs start on
Yes, there is the default-on trigger but there are problems with that.
For one, it's a inefficient way to do it and requires led trigger support
to be compiled in.
But the real reason is that is produces a glitch on the LED. The GPIO is
allocate with the LED *off*, then *later* when then trigger runs it is
turned back on. If the LED was already on via the GPIO's reset default or
action of the firmware, this produces a glitch where the LED goes from on
to off to on. While normally this is fast enough that it wouldn't be
noticeable to a human observer, there are still serious problems.
One is that there may be something else on the GPIO line, like a hardware
alarm or watchdog, that is fast enough to notice the glitch.
Another is that the kernel may panic before the LED is turned back on, thus
hanging with the LED in the wrong state. This is not just speculation, but
actually happened to me with an embedded system that has an LED which
should turn off when the kernel finishes booting, which was left in the
incorrect state due to a bug in the OF LED binding code.
The platform device binding gains a field in the platform data
default_state that controls this. The OpenFirmware binding uses a
property named default-state that can be set to on or off. The
default if the property isn't present is off.
Signed-off-by: Trent Piepho tpie...@freescale.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Documentation/powerpc/dts-bindings/gpio/led.txt |9 -
drivers/leds/leds-gpio.c|8 ++--
include/linux/leds.h|1 +
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 4fe14de..5df384d 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -16,10 +16,15 @@ LED sub-node properties:
string defining the trigger assigned to the LED. Current triggers are:
backlight - LED will act as a back-light, controlled by the framebuffer
system
-default-on - LED will turn on
+default-on - LED will turn on, but see default-state below
heartbeat - LED double flashes at a load average based rate
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
+- default-state: (optional) The initial state of the LED. Valid
+ values are on and off. If the LED is already on or off and the
+ default-state property is set the to same value, then no glitch
+ should be produced where the LED momentarily turns off (or on).
+ The default is off if this property is not present.
Examples:
@@ -36,8 +41,10 @@ run-control {
compatible = gpio-leds;
red {
gpios = mpc8572 6 0;
+ default-state = off;
};
green {
gpios = mpc8572 7 0;
+ default-state = on;
};
}
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index be4d6aa..1ad96d2 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -92,9 +92,10 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.blink_set = gpio_blink_set;
}
led_dat-cdev.brightness_set = gpio_led_set;
- led_dat-cdev.brightness = LED_OFF;
+ led_dat-cdev.brightness = template-default_state ? LED_FULL : LED_OFF;
- ret = gpio_direction_output(led_dat-gpio, led_dat-active_low);
+ ret = gpio_direction_output(led_dat-gpio,
+ led_dat-active_low ^ template-default_state);
if (ret 0)
goto err;
@@ -261,12 +262,15 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
memset(led, 0, sizeof(led));
for_each_child_of_node(np, child) {
enum of_gpio_flags flags;
+ const char *state;
led.gpio = of_get_gpio_flags(child, 0, flags);
led.active_low = flags OF_GPIO_ACTIVE_LOW;
led.name = of_get_property(child, label, NULL) ? :
child-name;
led.default_trigger =
of_get_property(child, linux,default-trigger, NULL);
+ state = of_get_property(child, default-state, NULL);
+ led.default_state = state !strcmp(state, on);
ret = create_gpio_led(led, pdata-led_data[pdata-num_leds++],
ofdev-dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d3a73f5..caa3987 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,6 +138,7 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
+ u8 default_state;
};
struct gpio_led_platform_data {
--
1.5.4.1
[PATCH v2 1/4] leds: Support OpenFirmware led bindings
Add bindings to support LEDs defined as of_platform devices in addition to
the existing bindings for platform devices.
New options in Kconfig allow the platform binding code and/or the
of_platform code to be turned on. The of_platform code is of course only
available on archs that have OF support.
The existing probe and remove methods are refactored to use new functions
create_gpio_led(), to create and register one led, and delete_gpio_led(),
to unregister and free one led. The new probe and remove methods for the
of_platform driver can then share most of the common probe and remove code
with the platform driver.
The suspend and resume methods aren't shared, but they are very short. The
actual led driving code is the same for LEDs created by either binding.
The OF bindings are based on patch by Anton Vorontsov
avoront...@ru.mvista.com. They have been extended to allow multiple LEDs
per device.
Signed-off-by: Trent Piepho tpie...@freescale.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Sean MacLennan smaclen...@pikatech.com
CC: devicetree-disc...@ozlabs.org
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 46 -
drivers/leds/Kconfig| 21 ++-
drivers/leds/leds-gpio.c| 237 ++-
3 files changed, 250 insertions(+), 54 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index ff51f4c..4fe14de 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -1,15 +1,43 @@
-LED connected to GPIO
+LEDs connected to GPIO lines
Required properties:
-- compatible : should be gpio-led.
-- label : (optional) the label for this LED. If omitted, the label is
+- compatible : should be gpio-leds.
+
+Each LED is represented as a sub-node of the gpio-leds device. Each
+node's name represents the name of the corresponding LED.
+
+LED sub-node properties:
+- gpios : Should specify the LED's GPIO, see Specifying GPIO information
+ for devices in Documentation/powerpc/booting-without-of.txt. Active
+ low LEDs should be indicated using flags in the GPIO specifier.
+- label : (optional) The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
-- gpios : should specify LED GPIO.
+- linux,default-trigger : (optional) This parameter, if present, is a
+ string defining the trigger assigned to the LED. Current triggers are:
+backlight - LED will act as a back-light, controlled by the framebuffer
+ system
+default-on - LED will turn on
+heartbeat - LED double flashes at a load average based rate
+ide-disk - LED indicates disk activity
+timer - LED flashes at a fixed, configurable rate
-Example:
+Examples:
-...@0 {
- compatible = gpio-led;
- label = hdd;
- gpios = mcu_pio 0 1;
+leds {
+ compatible = gpio-leds;
+ hdd {
+ label = IDE Activity;
+ gpios = mcu_pio 0 1; /* Active low */
+ linux,default-trigger = ide-disk;
+ };
};
+
+run-control {
+ compatible = gpio-leds;
+ red {
+ gpios = mpc8572 6 0;
+ };
+ green {
+ gpios = mpc8572 7 0;
+ };
+}
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e7fb7d2..6c6dc96 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -111,7 +111,26 @@ config LEDS_GPIO
help
This option enables support for the LEDs connected to GPIO
outputs. To be useful the particular board must have LEDs
- and they must be connected to the GPIO lines.
+ and they must be connected to the GPIO lines. The LEDs must be
+ defined as platform devices and/or OpenFirmware platform devices.
+ The code to use these bindings can be selected below.
+
+config LEDS_GPIO_PLATFORM
+ bool Platform device bindings for GPIO LEDs
+ depends on LEDS_GPIO
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ platform devices. If you don't know what this means, say yes.
+
+config LEDS_GPIO_OF
+ bool OpenFirmware platform device bindings for GPIO LEDs
+ depends on LEDS_GPIO OF_DEVICE
+ default y
+ help
+ Let the leds-gpio driver drive LEDs which have been defined as
+ of_platform devices. For instance, LEDs which are listed in a dts
+ file.
config LEDS_HP_DISK
tristate LED Support for disk protection LED on HP notebooks
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index b13bd29..be4d6aa 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2007 8D Technologies inc.
* Raphael Assenat r...@8d.com
+ * Copyright (C) 2008 Freescale Semiconductor, Inc.
*
* This program is free software; you can
[PATCH v2 3/4] leds: Let GPIO LEDs keep their current state
Let GPIO LEDs get their initial value from whatever the current state of
the GPIO line is. On some systems the LEDs are put into some state by the
firmware or hardware before Linux boots, and it is desired to have them
keep this state which is otherwise unknown to Linux.
This requires that the underlying GPIO driver support reading the value of
output GPIOs. Some drivers support this and some do not.
The platform data for the platform device binding gets a new field
'keep_state' which turns this on. keep_state overrides default_state.
For the OpenFirmware bindings, the default-state property gains a new
allowable setting keep.
Signed-off-by: Trent Piepho tpie...@freescale.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 16
drivers/leds/leds-gpio.c| 12
include/linux/leds.h|3 ++-
3 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
index 5df384d..064db92 100644
--- a/Documentation/powerpc/dts-bindings/gpio/led.txt
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -21,10 +21,12 @@ LED sub-node properties:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
- default-state: (optional) The initial state of the LED. Valid
- values are on and off. If the LED is already on or off and the
- default-state property is set the to same value, then no glitch
- should be produced where the LED momentarily turns off (or on).
- The default is off if this property is not present.
+ values are on, off, and keep. If the LED is already on or off
+ and the default-state property is set the to same value, then no
+ glitch should be produced where the LED momentarily turns off (or
+ on). The keep setting will keep the LED at whatever its current
+ state is, without producing a glitch. The default is off if this
+ property is not present.
Examples:
@@ -35,6 +37,12 @@ leds {
gpios = mcu_pio 0 1; /* Active low */
linux,default-trigger = ide-disk;
};
+
+ fault {
+ gpios = mcu_pio 1 0;
+ /* Keep LED on if BIOS detected hardware fault */
+ default-state = keep;
+ };
};
run-control {
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 1ad96d2..bb9d9ff 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -76,7 +76,7 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
struct gpio_led_data *led_dat, struct device *parent,
int (*blink_set)(unsigned, unsigned long *, unsigned long *))
{
- int ret;
+ int ret, state;
ret = gpio_request(template-gpio, template-name);
if (ret 0)
@@ -92,10 +92,13 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.blink_set = gpio_blink_set;
}
led_dat-cdev.brightness_set = gpio_led_set;
- led_dat-cdev.brightness = template-default_state ? LED_FULL : LED_OFF;
+ if (template-keep_state)
+ state = !!gpio_get_value(led_dat-gpio) ^ led_dat-active_low;
+ else
+ state = template-default_state;
+ led_dat-cdev.brightness = state ? LED_FULL : LED_OFF;
- ret = gpio_direction_output(led_dat-gpio,
- led_dat-active_low ^ template-default_state);
+ ret = gpio_direction_output(led_dat-gpio, led_dat-active_low ^ state);
if (ret 0)
goto err;
@@ -271,6 +274,7 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
of_get_property(child, linux,default-trigger, NULL);
state = of_get_property(child, default-state, NULL);
led.default_state = state !strcmp(state, on);
+ led.keep_state = state !strcmp(state, keep);
ret = create_gpio_led(led, pdata-led_data[pdata-num_leds++],
ofdev-dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index caa3987..c51b625 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,7 +138,8 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
- u8 default_state;
+ u8 default_state; /* 0 = off, 1 = on */
+ u8 keep_state; /* overrides default_state */
};
struct gpio_led_platform_data {
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 4/4] leds: Use tristate property in platform data
Replace the two boolean properties default_state and keep_state with a
single tristate property that can be set to
LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP). This ends up being more complicated,
requires more code, and makes developers remember not just the name of the
field to set but also the symbolic constant to set it to. Yet despite
these shortcomings it remains more popular.
Signed-off-by: Trent Piepho tpie...@freescale.com
---
drivers/leds/leds-gpio.c | 15 +++
include/linux/leds.h |7 +--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index bb9d9ff..2d1b71f 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -92,10 +92,10 @@ static int __devinit create_gpio_led(const struct gpio_led
*template,
led_dat-cdev.blink_set = gpio_blink_set;
}
led_dat-cdev.brightness_set = gpio_led_set;
- if (template-keep_state)
+ if (template-default_state == LEDS_GPIO_DEFSTATE_KEEP)
state = !!gpio_get_value(led_dat-gpio) ^ led_dat-active_low;
else
- state = template-default_state;
+ state = (template-default_state == LEDS_GPIO_DEFSTATE_ON);
led_dat-cdev.brightness = state ? LED_FULL : LED_OFF;
ret = gpio_direction_output(led_dat-gpio, led_dat-active_low ^ state);
@@ -273,8 +273,15 @@ static int __devinit of_gpio_leds_probe(struct of_device
*ofdev,
led.default_trigger =
of_get_property(child, linux,default-trigger, NULL);
state = of_get_property(child, default-state, NULL);
- led.default_state = state !strcmp(state, on);
- led.keep_state = state !strcmp(state, keep);
+ if (state) {
+ if (!strcmp(state, keep)) {
+ led.default_state = LEDS_GPIO_DEFSTATE_KEEP;
+ } else if(!strcmp(state, on)) {
+ led.default_state = LEDS_GPIO_DEFSTATE_ON;
+ } else {
+ led.default_state = LEDS_GPIO_DEFSTATE_OFF;
+ }
+ }
ret = create_gpio_led(led, pdata-led_data[pdata-num_leds++],
ofdev-dev, NULL);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index c51b625..f4a125c 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -138,9 +138,12 @@ struct gpio_led {
const char *default_trigger;
unsignedgpio;
u8 active_low;
- u8 default_state; /* 0 = off, 1 = on */
- u8 keep_state; /* overrides default_state */
+ u8 default_state;
+ /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
};
+#define LEDS_GPIO_DEFSTATE_OFF 0
+#define LEDS_GPIO_DEFSTATE_ON 1
+#define LEDS_GPIO_DEFSTATE_KEEP2
struct gpio_led_platform_data {
int num_leds;
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND] [PATCH] ADS5121 Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers\nUse ALARM interrupt to avoid waiting for data to come in
On Thu, 11 Dec 2008 22:57:56 +0100 Matteo Fortini m.fort...@selcomgroup.com wrote: I rechecked it and I should have taken away all the only-whitespace changes. No, I mean the patch is corrupted. Your mailer has taken tabs and turned them into spaces. Thunderbird sucks. The diffs are from the ads5121 branch from Denx. OK. You should send this to Denx then. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND] [PATCH] ADS5121 Fix: put dummy byte to enable fixing EOF bug to first place in order not to break some drivers\nUse ALARM interrupt to avoid waiting for data to come in
I rechecked it and I should have taken away all the only-whitespace changes. The diffs are from the ads5121 branch from Denx. Regards, M Josh Boyer ha scritto: On Thu, 11 Dec 2008 19:39:21 +0100 Matteo Fortini m.fort...@selcomgroup.com wrote: This patch is to avoid breaking some drivers, in my case the ADS7846 touchscreen one, which use 1 char messages. If you put the dummy byte after the 1 char message, you get part of the answer to the message in the rxbuf of the message, which is thrown away. The solution is to put the dummy byte before the message, so that the slave doesn't respond. It also optimizes the interrupt handling, by using the alarm function of the FIFO, to wait until the rx FIFO has received enough bytes, instead of waiting until the tx FIFO is empty. Signed-off-by: Matteo Fortini m.fort...@selcomgroup.com --- drivers/spi/mpc512x_psc_spi.c | 50 +++- 1 files changed, 29 insertions(+), 21 deletions(-) This still seems to be whitespace corrupted. Also, that file doesn't even exist in any upstream kernel I can find. What tree did you diff this from? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH][v2] fork_init: fix division by zero
Hello Andrew,
On Thursday, December 11, 2008 you wrote:
[snip]
The expression you've chosen here can be quite inacccurate, because
((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number.
But why is it bad? We do multiplication to 'mempages', not division.
All the numbers in the multiplier are the power of 2, so both
expressions:
mempages * (PAGE_SIZE / (8 * THREAD_SIZE))
and
max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE)
are finally equal.
The way to preserve accuracy is
max_threads = (mempages * PAGE_SIZE) / (8 * THREAD_SIZE);
so how about avoiding the nasty ifdefs and doing
I'm OK with the approach below, but, leading resulting to the same,
this involves some overhead to the code where there was no this
overhead before this patch: e.g. your implementation is finally boils
down to ~5 times more processor instructions than there were before,
plus operations with stack for the 'm' variable.
On the other hand, my approach with nasty (I agree) ifdefs doesn't
lead to overheads to the code which does not need this: i.e. the most
common situation of small PAGE_SIZEs. Big PAGE_SIZE is the exception,
so I believe that the more common cases should not suffer because of
this.
--- a/kernel/fork.c~fork_init-fix-division-by-zero
+++ a/kernel/fork.c
@@ -69,6 +69,7 @@
#include asm/mmu_context.h
#include asm/cacheflush.h
#include asm/tlbflush.h
+#include asm/div64.h
/*
* Protected counters by write_lock_irq(tasklist_lock)
@@ -185,10 +186,15 @@ void __init fork_init(unsigned long memp
/*
* The default maximum number of threads is set to a safe
-* value: the thread structures can take up at most half
-* of memory.
+* value: the thread structures can take up at most
+* (1/8) part of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ {
+ /* max_threads = (mempages * PAGE_SIZE) / THREAD_SIZE / 8; */
+ u64 m = mempages * PAGE_SIZE;
+ do_div(m, THREAD_SIZE * 8);
+ max_threads = m;
+ }
/*
* we need to allow at least 20 threads to boot a system
_
?
The code is also inaccurate because it assumes that whatever allocator
is used for threads will pack the thread_structs into pages with best
possible density, which isn't necessarily the case. Let's not worry
about that.
OT:
max_threads is widly wrong anyway.
- the caller passes in num_physpages, which includes highmem. And we
can't allocate thread structs from highmem.
- num_physpages includes kernel pages and other stuff which can never
be allocated via the page allocator.
A suitable fix would be to switch the caller to the strangely-named
nr_free_buffer_pages().
If you grep the tree for `num_physpages', you will find a splendid
number of similar bugs. num_physpages should be unexported, burnt,
deleted, etc. It's just an invitation to write buggy code.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re[2]: [PATCH][v2] fork_init: fix division by zero
On Fri, 12 Dec 2008 01:22:32 +0300 Yuri Tikhonov y...@emcraft.com wrote: so how about avoiding the nasty ifdefs and doing I'm OK with the approach below, but, leading resulting to the same, this involves some overhead to the code where there was no this overhead before this patch: e.g. your implementation is finally boils down to ~5 times more processor instructions than there were before, plus operations with stack for the 'm' variable. On the other hand, my approach with nasty (I agree) ifdefs doesn't lead to overheads to the code which does not need this: i.e. the most common situation of small PAGE_SIZEs. Big PAGE_SIZE is the exception, so I believe that the more common cases should not suffer because of this. yes, but... --- a/kernel/fork.c~fork_init-fix-division-by-zero +++ a/kernel/fork.c @@ -69,6 +69,7 @@ #include asm/mmu_context.h #include asm/cacheflush.h #include asm/tlbflush.h +#include asm/div64.h /* * Protected counters by write_lock_irq(tasklist_lock) @@ -185,10 +186,15 @@ void __init fork_init(unsigned long memp This is __init code and it gets thrown away after bootup. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help enabling PCI endpoint on 460EX, host sees disabled
I'm still working on various issues with the hardware. Soon I'll be able to easily test several boards in the same system at the same time. Once I've proven that works, I'll start nagging :) Is there a better subject line I should use to get attention, or should I just start CC'ing people? Not really. CC relevant lists like linuxppc-dev and netdev. If nothing happens after a while, maybe ping me and/or jeff garzik privately. Sorry if I sounded negative in my post. It's just a little discouraging when you don't get lots of feedback. I REALLY appreciate all of the work you and everyone else is doing. Well, it's annoying and heh, I don't get much feedback either on some of my stuff :-) But there's a limited amount of people who can do useful reviews and those are generally already very busy so ... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problem building kernel
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git and after
configuring with menuconfig I am seeing these errors. I feel like this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search.
Any ideas? What other information would be helpful?
BOOTCC arch/powerpc/boot/redboot-83xx.o
BOOTCC arch/powerpc/boot/cuboot-sam440ep.o
BOOTCC arch/powerpc/boot/cuboot-acadia.o
{standard input}: Assembler messages:
{standard input}:278: Error: Unrecognized opcode: `mtdcr'
{standard input}:282: Error: Unrecognized opcode: `mfdcr'
{standard input}:289: Error: Unrecognized opcode: `mtdcr'
{standard input}:293: Error: Unrecognized opcode: `mfdcr'
{standard input}:312: Error: Unrecognized opcode: `mtdcr'
{standard input}:316: Error: Unrecognized opcode: `mfdcr'
make[2]: *** [arch/powerpc/boot/cuboot-acadia.o] Error 1
make[1]: *** [zImage] Error 2
make: *** [sub-make] Error 2
Ron
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc: Fix bogus cache flushing on all 40x and BookE processors v2
On Mon, 08 Dec 2008 16:39:52 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all these processors. The result is that update_mmu_cache() would flush the cache for all pages mapped to userspace which is totally unnecessary on those processors since we already handle flushing on execute in the page fault path. This should provide a nice speed up ;-) Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com Kumar, feel free to take this through your tree. josh --- This one fixes the E500 definition and uses a bit that works for 32-bit processors arch/powerpc/include/asm/cputable.h | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/cputable.h 2008-12-03 13:32:53.0 +1100 +++ linux-work/arch/powerpc/include/asm/cputable.h2008-12-08 15:42:13.0 +1100 @@ -163,6 +163,7 @@ extern const char *powerpc_base_platform #define CPU_FTR_SPE ASM_CONST(0x0200) #define CPU_FTR_NEED_PAIRED_STWCXASM_CONST(0x0400) #define CPU_FTR_LWSYNC ASM_CONST(0x0800) +#define CPU_FTR_NOEXECUTEASM_CONST(0x1000) /* * Add the 64-bit processor unique features in the top half of the word; @@ -177,7 +178,6 @@ extern const char *powerpc_base_platform #define CPU_FTR_SLB LONG_ASM_CONST(0x0001) #define CPU_FTR_16M_PAGE LONG_ASM_CONST(0x0002) #define CPU_FTR_TLBIEL LONG_ASM_CONST(0x0004) -#define CPU_FTR_NOEXECUTELONG_ASM_CONST(0x0008) #define CPU_FTR_IABR LONG_ASM_CONST(0x0020) #define CPU_FTR_MMCRA LONG_ASM_CONST(0x0040) #define CPU_FTR_CTRL LONG_ASM_CONST(0x0080) @@ -367,19 +367,20 @@ extern const char *powerpc_base_platform #define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE) #define CPU_FTRS_8XX (CPU_FTR_USE_TB) -#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN) -#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN) +#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) +#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E200(CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \ CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \ - CPU_FTR_UNIFIED_ID_CACHE) + CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500(CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ - CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN) + CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \ + CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500_2 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_BIG_PHYS | \ - CPU_FTR_NODSISRALIGN) + CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500MC (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_BIG_PHYS | CPU_FTR_NODSISRALIGN | \ - CPU_FTR_L2CSR | CPU_FTR_LWSYNC) + CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE) #define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN) /* 64-bit CPUs */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem building kernel
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git
and after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search.
Any ideas? What other information would be helpful?
BOOTCC arch/powerpc/boot/redboot-83xx.o
BOOTCC arch/powerpc/boot/cuboot-sam440ep.o
BOOTCC arch/powerpc/boot/cuboot-acadia.o
{standard input}: Assembler messages:
{standard input}:278: Error: Unrecognized opcode: `mtdcr'
{standard input}:282: Error: Unrecognized opcode: `mfdcr'
{standard input}:289: Error: Unrecognized opcode: `mtdcr'
{standard input}:293: Error: Unrecognized opcode: `mfdcr'
{standard input}:312: Error: Unrecognized opcode: `mtdcr'
{standard input}:316: Error: Unrecognized opcode: `mfdcr'
make[2]: *** [arch/powerpc/boot/cuboot-acadia.o] Error 1
make[1]: *** [zImage] Error 2
make: *** [sub-make] Error 2
Ron
I swear Josh or Grant fixed this.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem building kernel
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git
and after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search.
Any ideas? What other information would be helpful?
BOOTCC arch/powerpc/boot/redboot-83xx.o
BOOTCC arch/powerpc/boot/cuboot-sam440ep.o
BOOTCC arch/powerpc/boot/cuboot-acadia.o
{standard input}: Assembler messages:
{standard input}:278: Error: Unrecognized opcode: `mtdcr'
{standard input}:282: Error: Unrecognized opcode: `mfdcr'
{standard input}:289: Error: Unrecognized opcode: `mtdcr'
{standard input}:293: Error: Unrecognized opcode: `mfdcr'
{standard input}:312: Error: Unrecognized opcode: `mtdcr'
{standard input}:316: Error: Unrecognized opcode: `mfdcr'
make[2]: *** [arch/powerpc/boot/cuboot-acadia.o] Error 1
make[1]: *** [zImage] Error 2
make: *** [sub-make] Error 2
Ron
Try the following patch:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8fc6d72..483f78d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -39,6 +39,7 @@ DTS_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem building kernel
Thank you. That took care of it. I knew it was something small.
Ron
- Original Message
From: Kumar Gala ga...@kernel.crashing.org
To: Ron Madrid ron_mad...@sbcglobal.net
Cc: linuxppc-dev@ozlabs.org
Sent: Thursday, December 11, 2008 4:21:26 PM
Subject: Re: Problem building kernel
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git
and after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search.
Any ideas? What other information would be helpful?
BOOTCC arch/powerpc/boot/redboot-83xx.o
BOOTCC arch/powerpc/boot/cuboot-sam440ep.o
BOOTCC arch/powerpc/boot/cuboot-acadia.o
{standard input}: Assembler messages:
{standard input}:278: Error: Unrecognized opcode: `mtdcr'
{standard input}:282: Error: Unrecognized opcode: `mfdcr'
{standard input}:289: Error: Unrecognized opcode: `mtdcr'
{standard input}:293: Error: Unrecognized opcode: `mfdcr'
{standard input}:312: Error: Unrecognized opcode: `mtdcr'
{standard input}:316: Error: Unrecognized opcode: `mfdcr'
make[2]: *** [arch/powerpc/boot/cuboot-acadia.o] Error 1
make[1]: *** [zImage] Error 2
make: *** [sub-make] Error 2
Ron
Try the following patch:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8fc6d72..483f78d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -39,6 +39,7 @@ DTS_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem building kernel
On Thu, Dec 11, 2008 at 06:19:20PM -0600, Kumar Gala wrote:
On Dec 11, 2008, at 5:48 PM, Ron Madrid wrote:
Hello all,
I got the latest kernel from git://git.denx.de/linux-2.6-denx.git and
after
configuring with menuconfig I am seeing these errors. I feel like
this
could be something simple that I am just unaware of, but I'm not sure
and haven't been able to find anything useful when doing a web search.
Any ideas? What other information would be helpful?
BOOTCC arch/powerpc/boot/redboot-83xx.o
BOOTCC arch/powerpc/boot/cuboot-sam440ep.o
BOOTCC arch/powerpc/boot/cuboot-acadia.o
{standard input}: Assembler messages:
{standard input}:278: Error: Unrecognized opcode: `mtdcr'
{standard input}:282: Error: Unrecognized opcode: `mfdcr'
{standard input}:289: Error: Unrecognized opcode: `mtdcr'
{standard input}:293: Error: Unrecognized opcode: `mfdcr'
{standard input}:312: Error: Unrecognized opcode: `mtdcr'
{standard input}:316: Error: Unrecognized opcode: `mfdcr'
make[2]: *** [arch/powerpc/boot/cuboot-acadia.o] Error 1
make[1]: *** [zImage] Error 2
make: *** [sub-make] Error 2
Ron
I swear Josh or Grant fixed this.
I did. I sent a pull request to Paul today for this exact commit.
I had it sitting in the wrong branch of my tree. Sorry about that.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem building kernel
Dear Ron Madrid, In message 454690.60670...@web83505.mail.sp1.yahoo.com you wrote: Thank you. That took care of it. I knew it was something small. It's fixed in our tree now, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I'd like to meet the man who invented sex and see what he's working on now. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Friday 12 December 2008 07:43, Andrew Morton wrote: On Thu, 11 Dec 2008 20:28:00 + Do they actually cross the page boundaries? Some flavours of slab have at times done an order-1 allocation for objects which would fit into an order-0 page (etc) if it looks like that will be beneficial from a packing POV. I'm unsure whether that still happens - I tried to get it stamped out for reliability reasons. Hmph, SLUB uses order-3 allocations for 832 byte sized objects by default here (mm struct). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Fri, 12 Dec 2008 12:31:33 +1000 Nick Piggin nickpig...@yahoo.com.au wrote: On Friday 12 December 2008 07:43, Andrew Morton wrote: On Thu, 11 Dec 2008 20:28:00 + Do they actually cross the page boundaries? Some flavours of slab have at times done an order-1 allocation for objects which would fit into an order-0 page (etc) if it looks like that will be beneficial from a packing POV. I'm unsure whether that still happens - I tried to get it stamped out for reliability reasons. Hmph, SLUB uses order-3 allocations for 832 byte sized objects by default here (mm struct). That sucks, but at least it's = PAGE_ALLOC_COSTLY_ORDER. It's fortunate that everyone has more than 128GB of memory. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
On Friday 12 December 2008 13:47, Andrew Morton wrote: On Fri, 12 Dec 2008 12:31:33 +1000 Nick Piggin nickpig...@yahoo.com.au wrote: On Friday 12 December 2008 07:43, Andrew Morton wrote: On Thu, 11 Dec 2008 20:28:00 + Do they actually cross the page boundaries? Some flavours of slab have at times done an order-1 allocation for objects which would fit into an order-0 page (etc) if it looks like that will be beneficial from a packing POV. I'm unsure whether that still happens - I tried to get it stamped out for reliability reasons. Hmph, SLUB uses order-3 allocations for 832 byte sized objects by default here (mm struct). That sucks, but at least it's = PAGE_ALLOC_COSTLY_ORDER. Which is somewhat arbitrary a value. order-1 is costly compared to order-0... After running my system here for a while and doing various things with it, I have the ability to allocate 898 order-0 pages (3592K), or 36 order-3 pages (1152K). Not as bad as I expected, but the system's only been up for an hour, and not exactly doing anything unusual (and it has nearly 30MB free, out of 4GB). It's fortunate that everyone has more than 128GB of memory. And that SLAB still works quite well :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to support 3GB pci address?
On Thu, 11 Dec 2008, Kumar Gala wrote: On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote: In the system, the total PCI address needed is about 3GB, so I want to know how to support it in linux. mpc8548 has 36-bit real address, and can support 32GB PCIE address space, but in linux, there is only 1GB kernel space, how to map the 3GB pci address to kernel? Is the 36-bit real address only used to support large memory(4GB) for muti-threads? The 36-bit support is current (in tree) in complete. Work is in progress to add swiotlb support to PPC which will generically enable what you want to accomplish. Don't the ATMU windows in the pcie controller serve as a IOMMU, making swiotlb unnecessary and wasteful? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to support 3GB pci address?
On Dec 11, 2008, at 10:07 PM, Trent Piepho wrote: On Thu, 11 Dec 2008, Kumar Gala wrote: On Dec 11, 2008, at 6:04 AM, maillist.kernel wrote: In the system, the total PCI address needed is about 3GB, so I want to know how to support it in linux. mpc8548 has 36-bit real address, and can support 32GB PCIE address space, but in linux, there is only 1GB kernel space, how to map the 3GB pci address to kernel? Is the 36-bit real address only used to support large memory(4GB) for muti-threads? The 36-bit support is current (in tree) in complete. Work is in progress to add swiotlb support to PPC which will generically enable what you want to accomplish. Don't the ATMU windows in the pcie controller serve as a IOMMU, making swiotlb unnecessary and wasteful? Nope. You have no way to tell when to switch a window as you have no idea when a device might DMA data. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
