Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
Nice, looks like I forgot to add the new drivers/pci/of.c file :-)
Here's a new patch. Also added linux-pci to the CC list.
And this one removes a lot more cruft from the powermac code while at
it, and moves the core matching logic to drivers/of/of_pci.c...
From 917ea61d6afcf443ca467d0a6ffa00d5c6e21bb3 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Mon, 4 Apr 2011 14:38:13 +1000
Subject: [PATCH] of: Match PCI devices to OF nodes dynamically
powerpc has two different ways of matching PCI devices to their
corresponding OF node (if any) for historical reasons. The ppc64 one
does a scan looking for matching bus/dev/fn, while the ppc32 one does a
scan looking only for matching dev/fn on each level in order to be
agnostic to busses being renumbered (which Linux does on some
platforms).
This removes both and instead moves the matching code to the PCI core
itself. It's the most logical place to do it: when a pci_dev is created,
we know the parent and thus can do a single level scan for the matching
device_node (if any).
The benefit is that all archs now get the matching for free. There's one
hook the arch might want to provide to match a PHB bus to its device
node. A default weak implementation is provided that looks for the
parent device device node, but it's not entirely reliable on powerpc for
various reasons so powerpc provides its own.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/pci-bridge.h | 35 +++--
arch/powerpc/include/asm/pci.h|3 +-
arch/powerpc/include/asm/prom.h | 14 ---
arch/powerpc/kernel/pci-common.c | 11 ++-
arch/powerpc/kernel/pci_32.c | 148 +++--
arch/powerpc/kernel/pci_dn.c | 47 ---
arch/powerpc/kernel/pci_of_scan.c |9 +--
arch/powerpc/platforms/powermac/pci.c |3 +-
arch/sparc/kernel/pci.c |2 +-
drivers/of/of_pci.c | 36
drivers/pci/Makefile |2 +
drivers/pci/hotplug/rpadlpar_core.c |2 +-
drivers/pci/of.c | 60 +
drivers/pci/probe.c |8 ++-
include/linux/of_pci.h|5 +
include/linux/pci.h | 17
16 files changed, 165 insertions(+), 237 deletions(-)
create mode 100644 drivers/pci/of.c
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 5e156e0..6912c45 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -169,18 +169,22 @@ static inline struct pci_controller
*pci_bus_to_host(const struct pci_bus *bus)
return bus-sysdata;
}
-#ifndef CONFIG_PPC64
+static inline struct device_node *pci_device_to_OF_node(struct pci_dev *dev)
+{
+ return dev-dev.of_node;
+}
static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
{
- struct pci_controller *host;
-
- if (bus-self)
- return pci_device_to_OF_node(bus-self);
- host = pci_bus_to_host(bus);
- return host ? host-dn : NULL;
+ return bus-dev.of_node;
}
+#ifndef CONFIG_PPC64
+
+extern int pci_device_from_OF_node(struct device_node *node,
+ u8* bus, u8* devfn);
+extern void pci_create_OF_bus_map(void);
+
static inline int isa_vaddr_is_ioport(void __iomem *address)
{
/* No specific ISA handling on ppc32 at this stage, it
@@ -223,17 +227,8 @@ struct pci_dn {
/* Get the pointer to a device_node's pci_dn */
#define PCI_DN(dn) ((struct pci_dn *) (dn)-data)
-extern struct device_node *fetch_dev_dn(struct pci_dev *dev);
extern void * update_dn_pci_info(struct device_node *dn, void *data);
-/* Get a device_node from a pci_dev. This code must be fast except
- * in the case where the sysdata is incorrect and needs to be fixed
- * up (this will only happen once). */
-static inline struct device_node *pci_device_to_OF_node(struct pci_dev *dev)
-{
- return dev-dev.of_node ? dev-dev.of_node : fetch_dev_dn(dev);
-}
-
static inline int pci_device_from_OF_node(struct device_node *np,
u8 *bus, u8 *devfn)
{
@@ -244,14 +239,6 @@ static inline int pci_device_from_OF_node(struct
device_node *np,
return 0;
}
-static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
-{
- if (bus-self)
- return pci_device_to_OF_node(bus-self);
- else
- return bus-dev.of_node; /* Must be root bus (PHB) */
-}
-
/** Find the bus corresponding to the indicated device node */
extern struct pci_bus *pcibios_find_pci_bus(struct device_node *dn);
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 7d77909..1f52268 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -179,8 +179,7 @@ extern int remove_phb_dynamic(struct
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Mon, 04 Apr 2011 13:27:10 +1000
+struct device_node * __weak pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+ /* This should only be called for PHBs */
+ if (WARN_ON(bus-self || bus-parent))
+ return NULL;
This WARN_ON() will always trigger on sparc, because we use the OF
device tree object at the parent of the PCI bus devices we create
for the PCI controller domains.
I'm really surprised you don't link the PCI bus roots into the rest of
the global device hierarchy on powerpc.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v13 02/10] USB/ppc4xx: Add Synopsys DWC OTG driver framework
On Sun, Apr 03, 2011 at 04:16:50PM -0700, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
Platform probing is in dwc_otg_apmppc.c.
Driver parameter and parameter checking are in dwc_otg_param.c.
Signed-off-by: Tirumala R Marri tma...@apm.com
Signed-off-by: Fushen Chen fc...@apm.com
Signed-off-by: Mark Miesfeld mmiesf...@apm.com
---
drivers/usb/dwc/apmppc.c | 414
++
drivers/usb/dwc/driver.h | 76 +
drivers/usb/dwc/param.c | 180
3 files changed, 670 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/dwc/apmppc.c
create mode 100644 drivers/usb/dwc/driver.h
create mode 100644 drivers/usb/dwc/param.c
diff --git a/drivers/usb/dwc/apmppc.c b/drivers/usb/dwc/apmppc.c
new file mode 100644
index 000..ffbe6dd
--- /dev/null
+++ b/drivers/usb/dwc/apmppc.c
@@ -0,0 +1,414 @@
+/*
+ * DesignWare HS OTG controller driver
+ * Copyright (C) 2006 Synopsys, Inc.
+ * Portions Copyright (C) 2010 Applied Micro Circuits Corporation.
+ *
+ * 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 the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses
+ * or write to the Free Software Foundation, Inc., 51 Franklin Street,
+ * Suite 500, Boston, MA 02110-1335 USA.
+ *
+ * Based on Synopsys driver version 2.60a
+ * Modified by Mark Miesfeld mmiesf...@apm.com
+ * Modified by Stefan Roese s...@denx.de, DENX Software Engineering
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS
IS
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL SYNOPSYS, INC. BE LIABLE FOR ANY DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+
+/*
+ * The dwc_otg module provides the initialization and cleanup entry
+ * points for the dwcotg driver. This module will be dynamically installed
+ * after Linux is booted using the insmod command. When the module is
+ * installed, the dwc_otg_driver_init function is called. When the module is
+ * removed (using rmmod), the dwc_otg_driver_cleanup function is called.
+ *
+ * This module also defines a data structure for the dwc_otg driver, which is
+ * used in conjunction with the standard device structure. These
+ * structures allow the OTG driver to comply with the standard Linux driver
+ * model in which devices and drivers are registered with a bus driver. This
+ * has the benefit that Linux can expose attributes of the driver and device
+ * in its special sysfs file system. Users can then read or write files in
+ * this file system to perform diagnostics on the driver components or the
+ * device.
+ */
+
+#include linux/of_platform.h
+
+#include driver.h
+
+#define DWC_DRIVER_VERSION 1.05
+#define DWC_DRIVER_DESC HS OTG USB Controller driver
+static const char dwc_driver_name[] = dwc_otg;
+
+/**
+ * This function is the top level interrupt handler for the Common
+ * (Device and host modes) interrupts.
+ */
+static irqreturn_t dwc_otg_common_irq(int _irq, void *dev)
+{
+ struct dwc_otg_device *dwc_dev = dev;
+ int retval;
+
+ retval = dwc_otg_handle_common_intr(dwc_dev-core_if);
no lock needed ? What if you get another IRQ while you're calling
dwc_otg_handle_common_intr() ??
+ return IRQ_RETVAL(retval);
+}
+
+/**
+ * This function is the interrupt handler for the OverCurrent condition
+ * from the external charge pump (if enabled)
+ */
this comment is completely unnecessary. Same goes for most all other
functions. The ones which would be nice to keep, should be converted to
kerneldoc so we can extract documentation from source code if we
need/want.
+static irqreturn_t dwc_otg_externalchgpump_irq(int _irq, void *dev)
+{
+ struct dwc_otg_device *dwc_dev = dev;
+
+ if (dwc_otg_is_host_mode(dwc_dev-core_if)) {
+ struct dwc_hcd *dwc_hcd;
+ u32 hprt0 = 0;
+
+
Re: [PATCH v13 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
Hi, On Sun, Apr 03, 2011 at 04:16:53PM -0700, tma...@apm.com wrote: +const char *op_state_str(enum usb_otg_state state) please don't introduce yet another version of this. Make the ones available generic. Place a static inline const char *otg_state_string(struct otg_transceiver *x) on include/linux/usb/otg.h +/** + * This function enables the controller's Global Interrupt in the AHB Config + * register. + */ useless comments :-) or convert to kerneldoc. -- balbi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v13 07/10] USB/ppc4xx: Add Synopsys DWC OTG PCD function
Hi,
On Sun, Apr 03, 2011 at 04:17:10PM -0700, tma...@apm.com wrote:
+static const struct usb_gadget_ops dwc_otg_pcd_ops = {
+ .get_frame = dwc_otg_pcd_get_frame,
+ .wakeup = dwc_otg_pcd_wakeup,
+ /* not selfpowered */
will you really have a board running this top operating system which is
Bus powered ? Unless you're forcing all your boards to come with USB
charging I guess you should implement set_selfpowered.
--
balbi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v13 09/10] USB ppc4xx: Add Synopsys DWC OTG driver kernel configuration and Makefile
On Sun, Apr 03, 2011 at 04:17:24PM -0700, tma...@apm.com wrote: From: Tirumala Marri tma...@apm.com Add Synopsys DesignWare HS USB OTG driver kernel configuration. Synopsys OTG driver may operate in host only, device only, or OTG mode. The driver also allows user configure the core to use its internal DMA or Slave (PIO) mode. Signed-off-by: Tirumala R Marri tma...@apm.com Signed-off-by: Fushen Chen fc...@apm.com Signed-off-by: Mark Miesfeld mmiesf...@apm.com --- drivers/Makefile |1 + drivers/usb/Kconfig |2 + drivers/usb/dwc/Kconfig | 84 ++ drivers/usb/dwc/Makefile | 19 ++ 4 files changed, 106 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/dwc/Kconfig create mode 100644 drivers/usb/dwc/Makefile diff --git a/drivers/Makefile b/drivers/Makefile index a125e0b..d4133a6 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_PARIDE)+= block/paride/ obj-$(CONFIG_TC) += tc/ obj-$(CONFIG_UWB)+= uwb/ obj-$(CONFIG_USB_OTG_UTILS) += usb/otg/ +obj-$(CONFIG_USB_DWC_OTG)+= usb/dwc/ another one ? Greg, I know MUSB is also wrong, but can we avoid adding more guys to drivers/Makefile and use drivers/usb/Makefile instead ? Promise I'll send a patch to MUSB for next merge window :-) -- balbi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v13 08/10] USB ppc4xx: Add Synopsys DWC OTG PCD interrupt function
On Sun, Apr 03, 2011 at 04:17:13PM -0700, tma...@apm.com wrote: +void start_next_request(struct pcd_ep *ep) this will probably cause namespace clashes at some point. prepent with dwc_ or make it static. -- balbi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
On Mon, Apr 4, 2011 at 1:37 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: powerpc has two different ways of matching PCI devices to their corresponding OF node (if any) for historical reasons. The ppc64 one does a scan looking for matching bus/dev/fn, while the ppc32 one does a scan looking only for matching dev/fn on each level in order to be agnostic to busses being renumbered (which Linux does on some platforms). This removes both and instead moves the matching code to the PCI core itself. It's the most logical place to do it: when a pci_dev is created, we know the parent and thus can do a single level scan for the matching device_node (if any). Some of this is reminiscent of the ACPI/PCI binding we do on x86/ia64, e.g., acpi_get_pci_dev() and the stuff in drivers/acpi/glue.c. Have you looked at that to see if there's any hope of covering both OF and ACPI with something more generic? Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: problem PCIe LSI detected at 32 device addresses (ppc460ex)
On Sun, Apr 03, 2011 at 06:22:13PM -0500, Ayman El-Khashab wrote: On Sun, Apr 03, 2011 at 04:09:26PM -0600, Grant Likely wrote: On Sun, Apr 3, 2011 at 3:52 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: Ok, I've narrowed the scope of the problem some. ?I moved forward to a more recent kernel (2.6.31 to 2.6.36) and that resolved the problem of the controller showing up as every device on the bus. However, from 2.6.37 to the current HEAD, I have not been able to build a kernel to run on the 460EX. ?I tried 2.6.37, 2.6.38, and the HEAD and all result in the following kernel panic. ?I am not sure how to proceed here. ?I suppose we can stick with 2.6.36 since it works, but I'd like to understand what it might take to remedy this. Smells like somebody changed something with the OF flash code... Josh, Grant, any idea what's up there ? Not sure, more information would be helpful. Ayman, if you do a 'git log v2.6.36.. drivers/mtd/maps/physmap_of.c', then you'll see a list of commits touching the mtd driver. Would you be able to do a 'git checkout sha1-id' on each of those are report back on at what point things stop working? Actually, a full bisect between 2.6.36 and 2.6.37 would be best, but this is a good start if you're limited on time. Once you find the first commit where it fails, do a 'git checkout sha1~1' to confirm that it is in fact the commit that causes the breakage. I can try to find the commit tomorrow. In the interim, i've pasted the dts below. The board was originally based on the canyonlands, but we've made some changes, mostly to the pcie. we run the 1-l port in endpoint mode, we have a chain of plx switches and devices on the 4-l port. One item that I don't think would matter, but is not too common is that we are booting these over the pci bus from another PPCs memory. I only mention this since this failure is during boot, though everything should by local to the cpu by this time. Can you also post your device tree please? Here is the device tree for our custom board. Hmmm, considering that there is no device node for NAND in this tree, something is definitely wrong. The NAND driver should not be getting probed. If you can do a git bisect on the kernel it will go a long way to figuring out what is wrong. I suspect that it is related to merging of_platform_bus_type into the platform_bus_type. It looks like a device is getting incorrectly matched to the driver, but I don't know why. It would also help to add this code to 2.6.38 and send me the log output: g. diff --git a/drivers/of/platform.c b/drivers/of/platform.c index c01cd1a..e9ac215 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -56,6 +56,8 @@ static int platform_driver_probe_shim(struct platform_device *pdev) * come up empty. Return -EINVAL in this case so other drivers get * the chance to bind. */ match = of_match_device(pdev-dev.driver-of_match_table, pdev-dev); + dev_info(pdev-dev, match to of_platform_driver, node:%s\n, + pdev-dev.of_node ? pdev-dev.of_node-full_name : !none!); return match ? ofpdrv-probe(pdev, match) : -EINVAL; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
On Mon, 2011-04-04 at 00:48 -0700, David Miller wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Mon, 04 Apr 2011 13:27:10 +1000
+struct device_node * __weak pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+ /* This should only be called for PHBs */
+ if (WARN_ON(bus-self || bus-parent))
+ return NULL;
This WARN_ON() will always trigger on sparc, because we use the OF
device tree object at the parent of the PCI bus devices we create
for the PCI controller domains.
I'm really surprised you don't link the PCI bus roots into the rest of
the global device hierarchy on powerpc.
But in the above test bus-parent is the struct pci_bus * parent, not
the struct device * nor struct device_node * parent... That
shouldn't be linked to anything on a PHB.
To answer your other point, we do link PHBs on some platforms, not
others. Historical stuff here. Most of our platforms discover PCI
bridges very early from setup_arch() before we have any struct device
around. Mostly because that's how we always did and there's some
subtle/nasty corner cases to deal with if we change that.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Tue, 05 Apr 2011 07:03:17 +1000
On Mon, 2011-04-04 at 00:48 -0700, David Miller wrote:
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Mon, 04 Apr 2011 13:27:10 +1000
+struct device_node * __weak pcibios_get_phb_of_node(struct pci_bus *bus)
+{
+ /* This should only be called for PHBs */
+ if (WARN_ON(bus-self || bus-parent))
+ return NULL;
This WARN_ON() will always trigger on sparc, because we use the OF
device tree object at the parent of the PCI bus devices we create
for the PCI controller domains.
I'm really surprised you don't link the PCI bus roots into the rest of
the global device hierarchy on powerpc.
But in the above test bus-parent is the struct pci_bus * parent, not
the struct device * nor struct device_node * parent... That
shouldn't be linked to anything on a PHB.
Aha, ok, then it shouldn't trigger on sparc, thanks for explaining.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
On Mon, 2011-04-04 at 09:25 -0600, Bjorn Helgaas wrote: Some of this is reminiscent of the ACPI/PCI binding we do on x86/ia64, e.g., acpi_get_pci_dev() and the stuff in drivers/acpi/glue.c. Have you looked at that to see if there's any hope of covering both OF and ACPI with something more generic? I haven't but I will have a look. Thanks. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pegasos i8042 broken again
Ok, I got fed up about it. The patch referred above is obviously wrong since
it leaves interrupts at 0 when a device_type or name of 8042 is found,
so what about the following?
I can ship it with a signed-off-by and proper comments a bit later if people
agree.
Compiled and tested, otherwise I couldn't even type this message :-)
Shouldn't that be a pegasos specific quirk in chrp/setup.c ?
Cheers,
Ben.
Regards,
Gabriel
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 9d4882a..06865ac 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -599,6 +599,10 @@ int check_legacy_ioport(unsigned long base_port)
* name instead */
if (!np)
np = of_find_node_by_name(NULL, 8042);
+ if (np) {
+ of_i8042_kbd_irq = 1;
+ of_i8042_aux_irq = 12;
+ }
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, fdc);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pegasos i8042 broken again
On Sun, Oct 10, 2010 at 06:35:47PM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2010-10-09 at 20:37 -0500, pac...@kosh.dhis.org wrote:
Pegasos has no keyboard again. I blame commit
540c6c392f01887dcc96bef0a41e63e6c1334f01, which tries to find i8042 IRQs in
the device-tree but doesn't fall back to the old hardcoded 1 and 12 in all
failure cases.
Specifically, the case where the device-tree contains nothing matching
pnpPNP,303 or pnpPNP,f03 doesn't seem to be handled well. It sort of falls
through to the old code, but leaves the IRQs set to 0.
The last time something like this happened, I submitted a patch:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2007-July/039988.html
which got committed, but afterward I was scolded for working around a bug
instead of fixing it in nvramrc.
This time I just won't send my workaround patch, at least until it's decided
that the kernel should be made to understand the device-tree as is.
If it's decided instead that the firmware should be patched... well I just
don't feel comfortable inventing my own patch for nvramrc, since it's
written
in a language I don't know and presumably could brick the machine if I get
it
wrong. Also I'm not even sure what the kernel is expecting to find there.
Those things really suck. They absolutely refuse to fix their FW for
reasons I never quite managed to figure out.
At this stage, I'd say the best is to add yet another pegasos workaround
in prom_init that adds the missing compatible property.
Ok, I got fed up about it. The patch referred above is obviously wrong since
it leaves interrupts at 0 when a device_type or name of 8042 is found,
so what about the following?
I can ship it with a signed-off-by and proper comments a bit later if people
agree.
Compiled and tested, otherwise I couldn't even type this message :-)
Regards,
Gabriel
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 9d4882a..06865ac 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -599,6 +599,10 @@ int check_legacy_ioport(unsigned long base_port)
* name instead */
if (!np)
np = of_find_node_by_name(NULL, 8042);
+ if (np) {
+ of_i8042_kbd_irq = 1;
+ of_i8042_aux_irq = 12;
+ }
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, fdc);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pegasos i8042 broken again
On Tue, Apr 05, 2011 at 08:28:50AM +1000, Benjamin Herrenschmidt wrote:
Ok, I got fed up about it. The patch referred above is obviously wrong since
it leaves interrupts at 0 when a device_type or name of 8042 is found,
so what about the following?
I can ship it with a signed-off-by and proper comments a bit later if
people agree.
Compiled and tested, otherwise I couldn't even type this message :-)
Shouldn't that be a pegasos specific quirk in chrp/setup.c ?
In this case I don't think so:
1) The code looks for the pnp id for the 8042 controllers and tries
to fill the interrupt fields from OF/DT, but falls back to defaults
1 and 12 if it does not get them.
2) Then it tries to find device_type of 8042 or node name of 8042
and returns success if it finds them, but in this case leaves
the interrupt numbers at zero. Note that in this case the code does
not even attempt to get interrupt information from OF/DT, this looks
like a fallback case where filling with defaults seems reasonable.
Actually, it is not filling with defaults which seems wrong since
the other case always provides interrupt information.
Regards,
Gabriel
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 9d4882a..06865ac 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -599,6 +599,10 @@ int check_legacy_ioport(unsigned long base_port)
* name instead */
if (!np)
np = of_find_node_by_name(NULL, 8042);
+ if (np) {
+ of_i8042_kbd_irq = 1;
+ of_i8042_aux_irq = 12;
+ }
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, fdc);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pegasos i8042 broken again
Gabriel Paubert writes: Ok, I got fed up about it. The patch referred above is obviously wrong since it leaves interrupts at 0 when a device_type or name of 8042 is found, so what about the following? Looks like the workaround I was using for a while. In the original report I said I wasn't sending my kernel workaround patch because of the previous disagreements about whether the kernel should work around this type of bug. (In fact the current difficulty is the result of changes being made without considering the special case that was created by my first workaround... what a mess.) I also said I wasn't comfortable hacking the Forth-based part of the boot sequence because I didn't know the language. As it turned out, learning Forth was much easier than getting any guidance from the kernel people on how to proceed with a workaround, so I wrote this: === CUT HERE === /isa/8042 find-device : open true ; : close ; : decode-unit ( addr len -- phys ) 1 if abort invalid unit address then c@ dup ascii 0 = if drop 0 exit then ascii 1 = if 1 exit then abort invalid unit address ; : encode-unit ( phys -- addr len ) dup 0 = if 0 exit then 1 = if 1 exit then abort invalid unit address ; 1 encode-int 3 encode-int encode+ d# 12 encode-int encode+ 3 encode-int encode+ interrupts property 0 0 0 /isa/8042 begin-package keyboard device-name keyboard device-type pnpPNP,303 encode-string compatible property 0 encode-int reg property end-package 0 0 1 /isa/8042 begin-package mouse device-name mouse device-type pnpPNP,f03 encode-string compatible property 1 encode-int reg property end-package === CUT HERE === Along with the previous device tree patch (pegasos-dts-20071018), this should present the kernel with a properly filled-out 8042 device-tree node, preventing the need for any more patching the next time the kernel changes its mind about how to initialize the keyboard driver. -- Alan Curry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
Hi, I've had the following funny crashes on PPC machines, with cataleptic X server as a consequence: kernel: [drm] Setting GART location based on new memory map kernel: Oops: Exception in kernel mode, sig: 4 [#1] kernel: CHRP kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource kernel: NIP: c05648fc LR: c0226f58 CTR: 0008 kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38) kernel: MSR: 00089032 EE,ME,IR,DR CR: 48044482 XER: kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000 kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 c0509e6c kernel: GPR08: 28044488 101f3d8c bf8166b4 2c00 kernel: GPR16: 101b9458 1006f1a0 101ebe0c 0001 101ebe08 df9efc20 df9efc00 kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a0 df9ef800 kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4 kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4 kernel: Call Trace: kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable) kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4 kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710 kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70 kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38 kernel: --- Exception: c01 at 0xfc54a78 kernel: LR = 0xfc549dc kernel: Instruction dump: kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132 kernel: 006c6962 786b6266 696c652e 736f2e31 002f7573 722f6c69 622f6c69 62786b62 kernel: ---[ end trace ed79daba161e31d9 ]--- As you can see, the processor is trying to execute ASCII strings like /usr/lib/libxkb and has trouble digesting them :-) The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp which are inlined inside radeon_cp_init. The trouble is that radeon_cp_init_microcode calls platform_device_register_simple which is a simple inline wrapper around platform_device_register_resndata, which happens to be already freed and overwritten with something looking like a list of filenames, since I have a non modular kernel. For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 which simply added an _init_or_module section attribute to platform_device_register_resndata, and X is up again... Now it may be that it is the ioctl that does not have the right to do this. Actually I thought that the name radeon_cp that is registered there would appear somwhere under /sys (or /proc) but failed to find it... Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
On Mon, 2011-04-04 at 09:25 -0600, Bjorn Helgaas wrote: Some of this is reminiscent of the ACPI/PCI binding we do on x86/ia64, e.g., acpi_get_pci_dev() and the stuff in drivers/acpi/glue.c. Have you looked at that to see if there's any hope of covering both OF and ACPI with something more generic? Hrm, the ACPI stuff is quite different (to some extent akin to what power used to do) form what I can tell. You basically traverse the ACPI tree do perform a matching after the fact. The idea with my patch is really to populate things as they get discovered, which makes the code much simpler. Since we have the pointer to the OF device node in the generic struct device nowadays, if we populate things that way, by the time we discover a device we already have at hand the OF device node of the parent bus, so it's a single/simpler one level search to locate the device itself and populate it's node as well, done once for all. I suppose you could do something similar for ACPI, but I wouldn't try to make a common infrastructure at that point, especially since there is the possibility on x86 to have both OF device-trees and ACPI :-) Note that I don't really provide a direct/good equivalent of your acpi_get_pci_dev() ... the matching is mostly used the other way around, ie a driver for a pci_dev wanting to peek a some properties in the corresponding OF device_node. ppc32 has some reverse mapping stuff but it's pretty crappy (and on my to-fixup list for after that patch goes in) and in fact it would be reasonably easy from now on to implement it as well, but so far there is no real demand. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] of: Match PCI devices to OF nodes generically
On Mon, Apr 04, 2011 at 05:37:44PM +1000, Benjamin Herrenschmidt wrote:
Nice, looks like I forgot to add the new drivers/pci/of.c file :-)
Here's a new patch. Also added linux-pci to the CC list.
And this one removes a lot more cruft from the powermac code while at
it, and moves the core matching logic to drivers/of/of_pci.c...
From 917ea61d6afcf443ca467d0a6ffa00d5c6e21bb3 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Mon, 4 Apr 2011 14:38:13 +1000
Subject: [PATCH] of: Match PCI devices to OF nodes dynamically
powerpc has two different ways of matching PCI devices to their
corresponding OF node (if any) for historical reasons. The ppc64 one
does a scan looking for matching bus/dev/fn, while the ppc32 one does a
scan looking only for matching dev/fn on each level in order to be
agnostic to busses being renumbered (which Linux does on some
platforms).
This removes both and instead moves the matching code to the PCI core
itself. It's the most logical place to do it: when a pci_dev is created,
we know the parent and thus can do a single level scan for the matching
device_node (if any).
The benefit is that all archs now get the matching for free. There's one
hook the arch might want to provide to match a PHB bus to its device
node. A default weak implementation is provided that looks for the
parent device device node, but it's not entirely reliable on powerpc for
various reasons so powerpc provides its own.
Awesome. I'm looking at doing pretty much exactly the same thing for
USB and platform_devices on SoCs. I'm glad to see this for pci.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/pci-bridge.h | 35 +++--
arch/powerpc/include/asm/pci.h|3 +-
arch/powerpc/include/asm/prom.h | 14 ---
arch/powerpc/kernel/pci-common.c | 11 ++-
arch/powerpc/kernel/pci_32.c | 148
+++--
arch/powerpc/kernel/pci_dn.c | 47 ---
arch/powerpc/kernel/pci_of_scan.c |9 +--
arch/powerpc/platforms/powermac/pci.c |3 +-
arch/sparc/kernel/pci.c |2 +-
drivers/of/of_pci.c | 36
drivers/pci/Makefile |2 +
drivers/pci/hotplug/rpadlpar_core.c |2 +-
drivers/pci/of.c | 60 +
drivers/pci/probe.c |8 ++-
include/linux/of_pci.h|5 +
include/linux/pci.h | 17
16 files changed, 165 insertions(+), 237 deletions(-)
create mode 100644 drivers/pci/of.c
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index 5e156e0..6912c45 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -169,18 +169,22 @@ static inline struct pci_controller
*pci_bus_to_host(const struct pci_bus *bus)
return bus-sysdata;
}
-#ifndef CONFIG_PPC64
+static inline struct device_node *pci_device_to_OF_node(struct pci_dev *dev)
+{
+ return dev-dev.of_node;
+}
static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
{
- struct pci_controller *host;
-
- if (bus-self)
- return pci_device_to_OF_node(bus-self);
- host = pci_bus_to_host(bus);
- return host ? host-dn : NULL;
+ return bus-dev.of_node;
}
Should these two inlines move to include/linux/of_pci.h? Microblaze
defines it differently, but I don't think it should be. Sparc also
has a different variant in arch/sparc/kernel/pci.c, but not in
arch/sparc/kernel/pcic.c. It looks to me like this should be the
common case unless a specific platform needs otherwise.
+#ifndef CONFIG_PPC64
+
+extern int pci_device_from_OF_node(struct device_node *node,
+u8* bus, u8* devfn);
+extern void pci_create_OF_bus_map(void);
+
static inline int isa_vaddr_is_ioport(void __iomem *address)
{
/* No specific ISA handling on ppc32 at this stage, it
@@ -223,17 +227,8 @@ struct pci_dn {
/* Get the pointer to a device_node's pci_dn */
#define PCI_DN(dn) ((struct pci_dn *) (dn)-data)
-extern struct device_node *fetch_dev_dn(struct pci_dev *dev);
extern void * update_dn_pci_info(struct device_node *dn, void *data);
-/* Get a device_node from a pci_dev. This code must be fast except
- * in the case where the sysdata is incorrect and needs to be fixed
- * up (this will only happen once). */
-static inline struct device_node *pci_device_to_OF_node(struct pci_dev *dev)
-{
- return dev-dev.of_node ? dev-dev.of_node : fetch_dev_dn(dev);
-}
-
static inline int pci_device_from_OF_node(struct device_node *np,
u8 *bus, u8 *devfn)
{
@@ -244,14 +239,6 @@ static inline int pci_device_from_OF_node(struct
device_node *np,
return 0;
}
[git pull] Please pull powerpc.git merge branch
The following changes since commit c0bb9e45f3a7f67fc358946727bc3d5f23d0f55d: kdump: Allow shrinking of kdump region to be overridden (2011-04-01 16:14:30 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge Kumar Gala (1): edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores Prabhakar Kushwaha (1): powerpc/85xx: Update dts for PCIe memory maps to match u-boot of Px020RDB arch/powerpc/boot/dts/p1020rdb.dts| 12 +- arch/powerpc/boot/dts/p2020rdb.dts| 12 +- arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |4 +- arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 10 drivers/edac/mpc85xx_edac.c | 27 +--- 5 files changed, 38 insertions(+), 27 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
