* RE: [PATCH] USB_DR host support for FSL MPC831x
From: Li Yang-r58472 @ 2007-07-17 12:18 UTC (permalink / raw)
To: Vitaly Bordug, Greg KH; +Cc: linuxppc-dev
In-Reply-To: <20070717005832.23019.99739.stgit@localhost.localdomain>
Hi Vitaly,
I believe that your patch is addresses by my patch in 2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
ehci_fsl-update-for-mpc831x-support.patch
- Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Vitaly Bordug
> Sent: Tuesday, July 17, 2007 8:59 AM
> To: Greg KH
> Cc: linuxppc-dev@ozlabs.org
> Subject: [PATCH] USB_DR host support for FSL MPC831x
>=20
>=20
> Modifies fsl_ehci code so that to get USB host working on=20
> mpc831x platform. Verified with MPC8313RDB reference board.
>=20
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>=20
> ---
>=20
> arch/powerpc/boot/dts/mpc8313erdb.dts | 1 +
> drivers/usb/host/ehci-fsl.c | 4 +++-
> drivers/usb/host/ehci-hcd.c | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts=20
> b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 1b351dc..c330e79 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -90,6 +90,7 @@
> interrupt-parent =3D < &ipic >;
> interrupts =3D <26 8>;
> phy_type =3D "utmi_wide";
> + control_init =3D <00000280>; // UTMI ext=20
> 48 MHz clk
> };
> =20
> mdio@24520 {
> diff --git a/drivers/usb/host/ehci-fsl.c=20
> b/drivers/usb/host/ehci-fsl.c index c7a7c59..3e3187b 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct=20
> usb_hcd *hcd)
> struct ehci_hcd *ehci =3D hcd_to_ehci(hcd);
> struct fsl_usb2_platform_data *pdata;
> void __iomem *non_ehci =3D hcd->regs;
> + u32 temp;
> =20
> pdata =3D
> (struct fsl_usb2_platform_data *)hcd->self.controller->
> platform_data;
> /* Enable PHY interface in the control reg. */
> - out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x00000004);
> + temp =3D in_be32(non_ehci + FSL_SOC_USB_CTRL);
> + out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
> out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
> =20
> #if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> diff --git a/drivers/usb/host/ehci-hcd.c=20
> b/drivers/usb/host/ehci-hcd.c index 099aff6..994a127 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
> #define PCI_DRIVER ehci_pci_driver
> #endif
> =20
> -#ifdef CONFIG_MPC834x
> +#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
> #include "ehci-fsl.c"
> #define PLATFORM_DRIVER ehci_fsl_driver
> #endif
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* RE: [PATCH] USB_DR device support for FSL MPC831x
From: Li Yang-r58472 @ 2007-07-17 12:21 UTC (permalink / raw)
To: Vitaly Bordug, Greg KH; +Cc: linuxppc-dev
In-Reply-To: <20070717005849.23036.21497.stgit@localhost.localdomain>
Hi Vitaly,
The max_ep_nr will be read from DCCPARAMS register with my patch in
2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
fsl_usb2_udc-get-max-ep-number-from-dccparams-register.patch
- Leo
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Vitaly Bordug
> Sent: Tuesday, July 17, 2007 8:59 AM
> To: Greg KH
> Cc: linuxppc-dev@ozlabs.org
> Subject: [PATCH] USB_DR device support for FSL MPC831x
>=20
>=20
> This adds support for USB device mode on mpc831x series.=20
> Devicetree node modification is required to make it work -=20
>=20
> dr_mode =3D"peripheral";
>=20
> which should be commented out if host mode is desired onboot.
>=20
> Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
>=20
> ---
>=20
> arch/powerpc/sysdev/fsl_soc.c | 1 +
> include/linux/fsl_devices.h | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_soc.c=20
> b/arch/powerpc/sysdev/fsl_soc.c index c0ddc80..27a1510 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -514,6 +514,7 @@ static int __init fsl_usb_of_init(void)
> }
> } else if (prop && !strcmp(prop, "peripheral")) {
> usb_data.operating_mode =3D FSL_USB2_DR_DEVICE;
> + usb_data.max_ep_nr =3D *(unsigned=20
> int*)of_get_property(np,=20
> +"max_ep_nr",NULL);
> usb_dev_dr_client =3D=20
> platform_device_register_simple(
> "fsl-usb2-udc", i, r, 2);
> if (IS_ERR(usb_dev_dr_client)) {
> diff --git a/include/linux/fsl_devices.h=20
> b/include/linux/fsl_devices.h index 12e631f..a3feb34 100644
> --- a/include/linux/fsl_devices.h
> +++ b/include/linux/fsl_devices.h
> @@ -103,6 +103,7 @@ struct fsl_usb2_platform_data {
> enum fsl_usb2_operating_modes operating_mode;
> enum fsl_usb2_phy_modes phy_mode;
> unsigned int port_enables;
> + unsigned int max_ep_nr;
> };
> =20
> /* Flags in fsl_usb2_mph_platform_data */
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [PATCH] POWERPC: Correct misspelled config variable in arch/powerpc/Kconfig.
From: Paul Mackerras @ 2007-07-17 12:32 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Linux PPC Mailing List
In-Reply-To: <Pine.LNX.4.64.0707141820150.9894@localhost.localdomain>
Robert P. J. Day writes:
> -config CONFIG_CHECK_CACHE_COHERENCY
> +config CHECK_CACHE_COHERENCY
Please also fix the occurrence in
arch/powerpc/platforms/embedded6xx/Kconfig.
Paul.
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 12:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1184647742.10499.34.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
> On Tue, 2007-07-17 at 03:02 +0200, Arnd Bergmann wrote:
> > On Monday 16 July 2007, Mark Zhan wrote:
> > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpm_uart_data.uart_clk =3D ppc_proc_fre=
q;
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (strstr(model, "SMC")) {
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpm_uart_dev =3D platfo=
rm_device_register_simple("fsl-cpm-smc:uart",
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, &r[0], 3);
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else if (strstr(model, "SCC")) {
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cpm_uart_dev =3D platfo=
rm_device_register_simple("fsl-cpm-scc:uart",
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i, &r[0], 3);
> > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> >
> > You should probably use of_device_is_compatible() to check
> > if a given device can be used by a particular driver.
>
> I think, the function of_find_compatible_node(), which is called in the
> for loop, has already done that. So definitely, no need to call
> of_device_is_compatible() any more.
It's a little more complicated than that. The "compatible" property should
indicate the exact interface of that device, so the "model" does not really
matter here. I don't know the difference between smc and scc, but if you
need to register them as different pplatform devices, they should
normally also have different names in "compatible", possibly in addition
to the existing one.
If the compatible property contains "fsl,cpm-smc\0cpm_uart", you can scan f=
or
either of them. The loop will iterate over all cpm_uart compatible devices,
while the later test will look for an fsl,cpm-smc compatible device.
Arnd <><
^ permalink raw reply
* Re: [PATCH] POWERPC: add support of the GiGE switch for mpc8313RDB via fixed PHY
From: Segher Boessenkool @ 2007-07-17 13:09 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717004936.21700.67900.stgit@localhost.localdomain>
> This utilises pretend phy, making access to it via device tree.
> GiGE switch
> is connected to TSEC1 with fixed gigE link, so we need to emulate it
> via artificial PHY to make it work.
Even if "pretend phy" in the device tree would be a good
idea (and it's not)...
> #size-cells = <0>;
> phy1: ethernet-phy@1 {
> interrupt-parent = < &ipic >;
> + compatible = "fixed";
...you cannot seriously believe you are allowed to claim
the name "fixed" for it.
NAK.
Segher
^ permalink raw reply
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Arnd Bergmann @ 2007-07-17 12:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1184655499.18501.17.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
> Hi Arnd,
>
> > > +/*
> > > + * For SBCPQ2 board, the interrupt of M48T59 RTC chip
> > > + * will generate a machine check exception. We use a
> > > + * fake irq to give the platform machine_check_exception() hook
> > > + * a chance to call the driver ISR. If IRQ_HANDLED is returned,
> > > + * then we will survive from the machine check exception.
> > > + */
> > > +static int sbcpq2_mach_check(struct pt_regs *regs)
> > > +{
> > > + int recover = 0;
> > > + struct irq_desc *desc = irq_desc + SBCPQ2_M48T59_IRQ;
> > > +
> > > + struct irqaction *action = desc->action;
> > > +
> > > + while (action && (action->dev_id != &m48t59_rtc))
> > > + action = action->next;
> > > +
> > > + /* Try to call m48t59 RTC driver ISR */
> > > + if (action && action->handler)
> > > + recover = action->handler(SBCPQ2_M48T59_IRQ, &m48t59_rtc);
> > > +
> > > + return recover;
> > > +}
> >
> > What you do here looks really scary, but maybe I'm just misunderstanding
> > it completely. Why don't you just register your rtc handler function
> > as the machine check handler instead of going through various indirections?
> >
>
> The rtc M48T59 driver is not specific to my board, it is probably used
> by other board. So I can't register the rtc intr handler as the mcheck
> exception handler. And in the other side, there are also other machine
> check sources, right?
>
> So here I add a platform mcheck hook for rtc intr handler. Yeah, it is
> really scary and confusing:-)
I think it would really be easier to just make the m48t59 irq handler
a global function, and keep it out of the regular interrupt logic.
Then your sbcpq2_mach_check() basically becomes trivial like
static int sbcpq2_mach_check(struct pt_regs *regs)
{
return m48t59_irq(NO_IRQ, NULL);
}
This has the advantage that you don't need to wait for the
m48t59 driver to be initialized first, instead you will just
get a link failure it that driver is not already built into the
kernel.
> > > +static void __init sbcpq2_init_IRQ(void)
> > > +{
> > > + struct device_node *np;
> > > + struct resource res;
> > > +
> > > + np = of_find_compatible_node(NULL, "cpm-pic", "CPM2");
> > > + if (np == NULL) {
> > > + printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
> > > + return;
> > > + }
> >
> > This looks like your device tree is wrong. Shouldn't the interrupt
> > controller have device_type="interrupt-controller" and a specific
> > compatible property instead of having the name in the device_type?
> >
>
> Here, I just copy the codes from mpc82xx_ads, is there anything wrong?
I just checked the Recommended Practice document for interrupt mapping
and it seems that it's ok. The interrupt controller needs to have
an property named "interrupt-controller", but does not need a specific
device_type. So it appears to be correct here.
> > > + /* Boot Flash is the on-board flash */
> > > + mc->memc_br0 = (SBCPQ2_BOOT_FLASH_BASE & 0xFFFF8000) | 0x0801;
> > > + mc->memc_or0 = 0xFFE00896;
> >
> > consequently, this needs to use out_be32 or similar.
> > Where does SBCPQ2_BOOT_FLASH_BASE come from? Shouldn't that be set
> > up by the boot loader to match the device tree?
>
> Fixed. out_be32 is used.
btw, it would be good if you can run your code through the 'sparse'
checker. It will warn about this type of problem. I think I saw all
that you have added here, but I may have missed some, and sparse
can also find other problems. Just install the tool as it comes
with your distro and build the kernel with the 'C=1' make option.
> The reason why they are needed is because some
> legacy u-boot for this board probably was setting up the wrong memory
> map.
Hmm, will those legacy u-boot version be able to even boot this kernel?
The device tree looks like it needs to have some variables set by u-boot,
so I'd guess you don't need to worry about old versions that don't
set those either.
Arnd <><
^ permalink raw reply
* [PATCH] adb: replace sleep notifier with platform driver suspend/resume hooks
From: Johannes Berg @ 2007-07-17 13:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This patch replaces the pmu sleep notifier that adb had with
suspend/resume hooks in a new platform driver/device.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/macintosh/adb.c | 96 ++++++++++++++++++++++++++++--------------------
1 file changed, 57 insertions(+), 39 deletions(-)
--- wireless-dev.orig/drivers/macintosh/adb.c 2007-07-17 14:01:59.660964463 +0200
+++ wireless-dev/drivers/macintosh/adb.c 2007-07-17 14:05:20.650964463 +0200
@@ -89,14 +89,6 @@ static int sleepy_trackpad;
static int autopoll_devs;
int __adb_probe_sync;
-#ifdef CONFIG_PM
-static void adb_notify_sleep(struct pmu_sleep_notifier *self, int when);
-static struct pmu_sleep_notifier adb_sleep_notifier = {
- adb_notify_sleep,
- SLEEP_LEVEL_ADB,
-};
-#endif
-
static int adb_scan_bus(void);
static int do_adb_reset_bus(void);
static void adbdev_init(void);
@@ -281,6 +273,36 @@ adb_reset_bus(void)
return 0;
}
+#ifdef CONFIG_PM
+/*
+ * notify clients before sleep
+ */
+static int adb_suspend(struct platform_device *dev, pm_message_t state)
+{
+ adb_got_sleep = 1;
+ /* We need to get a lock on the probe thread */
+ down(&adb_probe_mutex);
+ /* Stop autopoll */
+ if (adb_controller->autopoll)
+ adb_controller->autopoll(0);
+ blocking_notifier_call_chain(&adb_client_list, ADB_MSG_POWERDOWN, NULL);
+
+ return 0;
+}
+
+/*
+ * reset bus after sleep
+ */
+static int adb_resume(struct platform_device *dev)
+{
+ adb_got_sleep = 0;
+ up(&adb_probe_mutex);
+ adb_reset_bus();
+
+ return 0;
+}
+#endif /* CONFIG_PM */
+
int __init adb_init(void)
{
struct adb_driver *driver;
@@ -313,14 +335,12 @@ int __init adb_init(void)
printk(KERN_WARNING "Warning: no ADB interface detected\n");
adb_controller = NULL;
} else {
-#ifdef CONFIG_PM
- pmu_register_sleep_notifier(&adb_sleep_notifier);
-#endif /* CONFIG_PM */
#ifdef CONFIG_PPC
if (machine_is_compatible("AAPL,PowerBook1998") ||
machine_is_compatible("PowerBook1,1"))
sleepy_trackpad = 1;
#endif /* CONFIG_PPC */
+
init_completion(&adb_probe_task_comp);
adbdev_init();
adb_reset_bus();
@@ -330,33 +350,6 @@ int __init adb_init(void)
__initcall(adb_init);
-#ifdef CONFIG_PM
-/*
- * notify clients before sleep and reset bus afterwards
- */
-void
-adb_notify_sleep(struct pmu_sleep_notifier *self, int when)
-{
- switch (when) {
- case PBOOK_SLEEP_REQUEST:
- adb_got_sleep = 1;
- /* We need to get a lock on the probe thread */
- down(&adb_probe_mutex);
- /* Stop autopoll */
- if (adb_controller->autopoll)
- adb_controller->autopoll(0);
- blocking_notifier_call_chain(&adb_client_list,
- ADB_MSG_POWERDOWN, NULL);
- break;
- case PBOOK_WAKE:
- adb_got_sleep = 0;
- up(&adb_probe_mutex);
- adb_reset_bus();
- break;
- }
-}
-#endif /* CONFIG_PM */
-
static int
do_adb_reset_bus(void)
{
@@ -864,7 +857,29 @@ static const struct file_operations adb_
.release = adb_release,
};
-static void
+static struct platform_driver adb_pfdrv = {
+ .driver = {
+ .name = "adb",
+ },
+#ifdef CONFIG_PM
+ .suspend = adb_suspend,
+ .resume = adb_resume,
+#endif
+};
+
+static struct platform_device adb_pfdev = {
+ .name = "adb",
+};
+
+static int __init
+adb_dummy_probe(struct platform_device *dev)
+{
+ if (dev == &adb_pfdev)
+ return 0;
+ return -ENODEV;
+}
+
+static void __init
adbdev_init(void)
{
if (register_chrdev(ADB_MAJOR, "adb", &adb_fops)) {
@@ -876,4 +891,7 @@ adbdev_init(void)
if (IS_ERR(adb_dev_class))
return;
class_device_create(adb_dev_class, NULL, MKDEV(ADB_MAJOR, 0), NULL, "adb");
+
+ platform_device_register(&adb_pfdev);
+ platform_driver_probe(&adb_pfdrv, adb_dummy_probe);
}
^ permalink raw reply
* [PATCH] remove awacs dmasound
From: Johannes Berg @ 2007-07-17 13:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Adrian Bunk
In-Reply-To: <17969.56735.644629.328360@cargo.ozlabs.ibm.com>
This patch kills the obsolete awacs dmasound because it is in
the way of doing power management improvements since it uses
ancient API.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Adrian Bunk <bunk@stusta.de>
---
This patch contains only the patch for the first two files here, please
remove the other ones manually:
git rm -- sound/oss/dmasound/awacs_defs.h
git rm -- sound/oss/dmasound/dac3550a.c
git rm -- sound/oss/dmasound/dmasound_awacs.c
git rm -- sound/oss/dmasound/tas3001c.c
git rm -- sound/oss/dmasound/tas3001c.h
git rm -- sound/oss/dmasound/tas3001c_tables.c
git rm -- sound/oss/dmasound/tas3004.c
git rm -- sound/oss/dmasound/tas3004.h
git rm -- sound/oss/dmasound/tas3004_tables.c
git rm -- sound/oss/dmasound/tas_common.c
git rm -- sound/oss/dmasound/tas_common.h
git rm -- sound/oss/dmasound/tas_eq_prefs.h
git rm -- sound/oss/dmasound/tas_ioctl.h
git rm -- sound/oss/dmasound/trans_16.c
sound/oss/dmasound/Kconfig | 14
sound/oss/dmasound/Makefile | 6
sound/oss/dmasound/awacs_defs.h | 251 --
sound/oss/dmasound/dac3550a.c | 209 --
sound/oss/dmasound/dmasound_awacs.c | 3215 -----------------------------------
sound/oss/dmasound/tas3001c.c | 849 ---------
sound/oss/dmasound/tas3001c.h | 64
sound/oss/dmasound/tas3001c_tables.c | 375 ----
sound/oss/dmasound/tas3004.c | 1138 ------------
sound/oss/dmasound/tas3004.h | 77
sound/oss/dmasound/tas3004_tables.c | 301 ---
sound/oss/dmasound/tas_common.c | 214 --
sound/oss/dmasound/tas_common.h | 284 ---
sound/oss/dmasound/tas_eq_prefs.h | 24
sound/oss/dmasound/tas_ioctl.h | 24
sound/oss/dmasound/trans_16.c | 898 ---------
16 files changed, 7943 deletions(-)
--- wireless-dev.orig/sound/oss/dmasound/Makefile 2007-05-01 11:35:44.664734191 +0200
+++ wireless-dev/sound/oss/dmasound/Makefile 2007-05-01 11:36:26.054734191 +0200
@@ -2,12 +2,6 @@
# Makefile for the DMA sound driver
#
-dmasound_pmac-y += dmasound_awacs.o \
- trans_16.o dac3550a.o tas_common.o \
- tas3001c.o tas3001c_tables.o \
- tas3004.o tas3004_tables.o
-
obj-$(CONFIG_DMASOUND_ATARI) += dmasound_core.o dmasound_atari.o
-obj-$(CONFIG_DMASOUND_PMAC) += dmasound_core.o dmasound_pmac.o
obj-$(CONFIG_DMASOUND_PAULA) += dmasound_core.o dmasound_paula.o
obj-$(CONFIG_DMASOUND_Q40) += dmasound_core.o dmasound_q40.o
^ permalink raw reply
* [PATCH] via-pmu: kill sleep notifiers completely
From: Johannes Berg @ 2007-07-17 13:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
This patch kills off the remnants of the ancient sleep notifiers.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/macintosh/via-pmu.c | 71 --------------------------------------------
include/linux/pmu.h | 36 ----------------------
2 files changed, 107 deletions(-)
--- wireless-dev.orig/drivers/macintosh/via-pmu.c 2007-07-17 14:01:58.990964463 +0200
+++ wireless-dev/drivers/macintosh/via-pmu.c 2007-07-17 14:05:22.150964463 +0200
@@ -177,7 +177,6 @@ static struct proc_dir_entry *proc_pmu_b
int __fake_sleep;
int asleep;
-BLOCKING_NOTIFIER_HEAD(sleep_notifier_list);
#ifdef CONFIG_ADB
static int adb_dev_map;
@@ -1738,67 +1737,7 @@ pmu_present(void)
return via != 0;
}
-#ifdef CONFIG_PM
-
-static LIST_HEAD(sleep_notifiers);
-
-int
-pmu_register_sleep_notifier(struct pmu_sleep_notifier *n)
-{
- struct list_head *list;
- struct pmu_sleep_notifier *notifier;
-
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
- if (n->priority > notifier->priority)
- break;
- }
- __list_add(&n->list, list->prev, list);
- return 0;
-}
-EXPORT_SYMBOL(pmu_register_sleep_notifier);
-
-int
-pmu_unregister_sleep_notifier(struct pmu_sleep_notifier* n)
-{
- if (n->list.next == 0)
- return -ENOENT;
- list_del(&n->list);
- n->list.next = NULL;
- return 0;
-}
-EXPORT_SYMBOL(pmu_unregister_sleep_notifier);
-#endif /* CONFIG_PM */
-
#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
-
-/* Sleep is broadcast last-to-first */
-static void broadcast_sleep(int when)
-{
- struct list_head *list;
- struct pmu_sleep_notifier *notifier;
-
- for (list = sleep_notifiers.prev; list != &sleep_notifiers;
- list = list->prev) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
- notifier->notifier_call(notifier, when);
- }
-}
-
-/* Wake is broadcast first-to-last */
-static void broadcast_wake(void)
-{
- struct list_head *list;
- struct pmu_sleep_notifier *notifier;
-
- for (list = sleep_notifiers.next; list != &sleep_notifiers;
- list = list->next) {
- notifier = list_entry(list, struct pmu_sleep_notifier, list);
- notifier->notifier_call(notifier, PBOOK_WAKE);
- }
-}
-
/*
* This struct is used to store config register values for
* PCI devices which may get powered off when we sleep.
@@ -2003,9 +1942,6 @@ pmac_suspend_devices(void)
pm_prepare_console();
- /* Notify old-style device drivers */
- broadcast_sleep(PBOOK_SLEEP_REQUEST);
-
/* Sync the disks. */
/* XXX It would be nice to have some way to ensure that
* nobody is dirtying any new buffers while we wait. That
@@ -2014,12 +1950,9 @@ pmac_suspend_devices(void)
*/
sys_sync();
- broadcast_sleep(PBOOK_SLEEP_NOW);
-
/* Send suspend call to devices, hold the device core's dpm_sem */
ret = device_suspend(PMSG_SUSPEND);
if (ret) {
- broadcast_wake();
printk(KERN_ERR "Driver sleep failed\n");
return -EBUSY;
}
@@ -2060,7 +1993,6 @@ pmac_suspend_devices(void)
local_irq_enable();
preempt_enable();
device_resume();
- broadcast_wake();
printk(KERN_ERR "Driver powerdown failed\n");
return -EBUSY;
}
@@ -2114,9 +2046,6 @@ pmac_wakeup_devices(void)
/* Resume devices */
device_resume();
- /* Notify old style drivers */
- broadcast_wake();
-
pm_restore_console();
return 0;
--- wireless-dev.orig/include/linux/pmu.h 2007-07-17 14:01:59.030964463 +0200
+++ wireless-dev/include/linux/pmu.h 2007-07-17 14:05:22.150964463 +0200
@@ -159,42 +159,6 @@ extern void pmu_unlock(void);
extern int pmu_present(void);
extern int pmu_get_model(void);
-#ifdef CONFIG_PM
-/*
- * Stuff for putting the powerbook to sleep and waking it again.
- *
- */
-#include <linux/list.h>
-
-struct pmu_sleep_notifier
-{
- void (*notifier_call)(struct pmu_sleep_notifier *self, int when);
- int priority;
- struct list_head list;
-};
-
-/* Code values for calling sleep/wakeup handlers
- */
-#define PBOOK_SLEEP_REQUEST 1
-#define PBOOK_SLEEP_NOW 2
-#define PBOOK_WAKE 3
-
-/* priority levels in notifiers */
-#define SLEEP_LEVEL_VIDEO 100 /* Video driver (first wake) */
-#define SLEEP_LEVEL_MEDIABAY 90 /* Media bay driver */
-#define SLEEP_LEVEL_BLOCK 80 /* IDE, SCSI */
-#define SLEEP_LEVEL_NET 70 /* bmac, gmac */
-#define SLEEP_LEVEL_MISC 60 /* Anything else */
-#define SLEEP_LEVEL_USERLAND 55 /* Reserved for apm_emu */
-#define SLEEP_LEVEL_ADB 50 /* ADB (async) */
-#define SLEEP_LEVEL_SOUND 40 /* Sound driver (blocking) */
-
-/* special register notifier functions */
-int pmu_register_sleep_notifier(struct pmu_sleep_notifier* notifier);
-int pmu_unregister_sleep_notifier(struct pmu_sleep_notifier* notifier);
-
-#endif /* CONFIG_PM */
-
#define PMU_MAX_BATTERIES 2
/* values for pmu_power_flags */
^ permalink raw reply
* Re: [PATCH] remove awacs dmasound
From: Adrian Bunk @ 2007-07-17 13:37 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1184678911.27780.5.camel@johannes.berg>
On Tue, Jul 17, 2007 at 03:28:31PM +0200, Johannes Berg wrote:
> This patch kills the obsolete awacs dmasound because it is in
> the way of doing power management improvements since it uses
> ancient API.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Adrian Bunk <bunk@stusta.de>
>
> ---
> This patch contains only the patch for the first two files here, please
> remove the other ones manually:
>
> git rm -- sound/oss/dmasound/awacs_defs.h
> git rm -- sound/oss/dmasound/dac3550a.c
> git rm -- sound/oss/dmasound/dmasound_awacs.c
> git rm -- sound/oss/dmasound/tas3001c.c
> git rm -- sound/oss/dmasound/tas3001c.h
> git rm -- sound/oss/dmasound/tas3001c_tables.c
> git rm -- sound/oss/dmasound/tas3004.c
> git rm -- sound/oss/dmasound/tas3004.h
> git rm -- sound/oss/dmasound/tas3004_tables.c
> git rm -- sound/oss/dmasound/tas_common.c
> git rm -- sound/oss/dmasound/tas_common.h
> git rm -- sound/oss/dmasound/tas_eq_prefs.h
> git rm -- sound/oss/dmasound/tas_ioctl.h
> git rm -- sound/oss/dmasound/trans_16.c
>
> sound/oss/dmasound/Kconfig | 14
That's not in your patch, most likely because it's already removed as
scheduled.
> sound/oss/dmasound/Makefile | 6
> sound/oss/dmasound/awacs_defs.h | 251 --
> sound/oss/dmasound/dac3550a.c | 209 --
> sound/oss/dmasound/dmasound_awacs.c | 3215 -----------------------------------
> sound/oss/dmasound/tas3001c.c | 849 ---------
> sound/oss/dmasound/tas3001c.h | 64
> sound/oss/dmasound/tas3001c_tables.c | 375 ----
> sound/oss/dmasound/tas3004.c | 1138 ------------
> sound/oss/dmasound/tas3004.h | 77
> sound/oss/dmasound/tas3004_tables.c | 301 ---
> sound/oss/dmasound/tas_common.c | 214 --
> sound/oss/dmasound/tas_common.h | 284 ---
> sound/oss/dmasound/tas_eq_prefs.h | 24
> sound/oss/dmasound/tas_ioctl.h | 24
> sound/oss/dmasound/trans_16.c | 898 ---------
> 16 files changed, 7943 deletions(-)
>...
The option is already removed from the Kconfig file, and the code
removal is scheduled for 2.6.24. I'll take care of this (I'll send
a patch through Andrew).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Mark Zhan @ 2007-07-17 13:41 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707171419.05061.arnd@arndb.de>
> > The rtc M48T59 driver is not specific to my board, it is probably used
> > by other board. So I can't register the rtc intr handler as the mcheck
> > exception handler. And in the other side, there are also other machine
> > check sources, right?
> >
> > So here I add a platform mcheck hook for rtc intr handler. Yeah, it is
> > really scary and confusing:-)
>
> I think it would really be easier to just make the m48t59 irq handler
> a global function, and keep it out of the regular interrupt logic.
>
> Then your sbcpq2_mach_check() basically becomes trivial like
>
> static int sbcpq2_mach_check(struct pt_regs *regs)
> {
> return m48t59_irq(NO_IRQ, NULL);
> }
>
> This has the advantage that you don't need to wait for the
> m48t59 driver to be initialized first, instead you will just
> get a link failure it that driver is not already built into the
> kernel.
>
Since the rtc m48t59 driver has already gone into the -mm source tree,
and I think, it is an ugly way to make the irq handler a global
function:-)
If the driver is not built-in, and I still get the mach check exception,
it will turn out that other factors are causing mach check exception,
then just like my original codes, the kernel will not survive this
machine check, right?
> > > > +static void __init sbcpq2_init_IRQ(void)
> > > > +{
> > > > + struct device_node *np;
> > > > + struct resource res;
> > > > +
> > > > + np = of_find_compatible_node(NULL, "cpm-pic", "CPM2");
> > > > + if (np == NULL) {
> > > > + printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
> > > > + return;
> > > > + }
> > >
> > > This looks like your device tree is wrong. Shouldn't the interrupt
> > > controller have device_type="interrupt-controller" and a specific
> > > compatible property instead of having the name in the device_type?
> > >
> >
> > Here, I just copy the codes from mpc82xx_ads, is there anything wrong?
>
> I just checked the Recommended Practice document for interrupt mapping
> and it seems that it's ok. The interrupt controller needs to have
> an property named "interrupt-controller", but does not need a specific
> device_type. So it appears to be correct here.
>
Thanks a lot for your good adivce, I will try.
> > > > + /* Boot Flash is the on-board flash */
> > > > + mc->memc_br0 = (SBCPQ2_BOOT_FLASH_BASE & 0xFFFF8000) | 0x0801;
> > > > + mc->memc_or0 = 0xFFE00896;
> > >
> > > consequently, this needs to use out_be32 or similar.
> > > Where does SBCPQ2_BOOT_FLASH_BASE come from? Shouldn't that be set
> > > up by the boot loader to match the device tree?
> >
> > Fixed. out_be32 is used.
>
> btw, it would be good if you can run your code through the 'sparse'
> checker. It will warn about this type of problem. I think I saw all
> that you have added here, but I may have missed some, and sparse
> can also find other problems. Just install the tool as it comes
> with your distro and build the kernel with the 'C=1' make option.
>
> > The reason why they are needed is because some
> > legacy u-boot for this board probably was setting up the wrong memory
> > map.
>
> Hmm, will those legacy u-boot version be able to even boot this kernel?
> The device tree looks like it needs to have some variables set by u-boot,
> so I'd guess you don't need to worry about old versions that don't
> set those either.
Actually, the current u-boot 1.2.0 for this board is ported from that
legacy one, and I don't check the details to assure that u-boot's setup
is all right. So here I just want to double assure everything goes
correct.
Thanks
Mark Zhan
^ permalink raw reply
* Re: [PATCH] remove awacs dmasound
From: Johannes Berg @ 2007-07-17 13:43 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717133752.GC3801@stusta.de>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
On Tue, 2007-07-17 at 15:37 +0200, Adrian Bunk wrote:
> > sound/oss/dmasound/Kconfig | 14
>
> That's not in your patch, most likely because it's already removed as
> scheduled.
Ah, good point, I just removed it manually from the patch knowing that
it was gone from the config.
> The option is already removed from the Kconfig file, and the code
> removal is scheduled for 2.6.24. I'll take care of this (I'll send
> a patch through Andrew).
Alright. It uses the sleep notifiers I wanted to remove so I didn't want
to leave it even if it's not selectable.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Mark Zhan @ 2007-07-17 13:53 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707171406.03455.arnd@arndb.de>
On Tue, 2007-07-17 at 14:06 +0200, Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
> > On Tue, 2007-07-17 at 03:02 +0200, Arnd Bergmann wrote:
> > > On Monday 16 July 2007, Mark Zhan wrote:
> > > > - cpm_uart_data.uart_clk = ppc_proc_freq;
> > > > + if (strstr(model, "SMC")) {
> > > > + cpm_uart_dev = platform_device_register_simple("fsl-cpm-smc:uart",
> > > > + i, &r[0], 3);
> > > > + } else if (strstr(model, "SCC")) {
> > > > + cpm_uart_dev = platform_device_register_simple("fsl-cpm-scc:uart",
> > > > + i, &r[0], 3);
> > > > + }
> > >
> > > You should probably use of_device_is_compatible() to check
> > > if a given device can be used by a particular driver.
> >
> > I think, the function of_find_compatible_node(), which is called in the
> > for loop, has already done that. So definitely, no need to call
> > of_device_is_compatible() any more.
>
> It's a little more complicated than that. The "compatible" property should
> indicate the exact interface of that device, so the "model" does not really
> matter here. I don't know the difference between smc and scc, but if you
> need to register them as different pplatform devices, they should
> normally also have different names in "compatible", possibly in addition
> to the existing one.
>
> If the compatible property contains "fsl,cpm-smc\0cpm_uart", you can scan for
> either of them. The loop will iterate over all cpm_uart compatible devices,
> while the later test will look for an fsl,cpm-smc compatible device.
Arnd,
Yes, basically I agree what you say. That should be the right way.
but, the current situation is that: in all DTS files that are using smc
or scc as uart device, all device node definitions have the same
"compatible" property -- "cpm_uart"
So what I do here is just following the upstream source tree.
Thanks
Mark Zhan
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 13:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1184680385.18501.51.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
> Yes, basically I agree what you say. That should be the right way.
>
> but, the current situation is that: in all DTS files that are using smc
> or scc as uart device, all device node definitions have the same
> "compatible" property -- "cpm_uart"
>
> So what I do here is just following the upstream source tree.
>
Well, AFAICS, all of them currently use scc. The 8xx platforms don't
even build correctly in the mainline kernel, so I guess it would
be good to change them to also list fsl,cpm-smc in the compatible
property.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Arnd Bergmann @ 2007-07-17 13:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <1184679661.18501.41.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> Since the rtc m48t59 driver has already gone into the -mm source tree,
> and I think, it is an ugly way to make the irq handler a global
> function:-)
>
> If the driver is not built-in, and I still get the mach check exception,
> it will turn out that other factors are causing mach check exception,
> then just like my original codes, the kernel will not survive this
> machine check, right?
Ok, I missed the point that you also have real machine check events
to care about.
One issue remains though: you still need to have a virtual irq number,
not just make up a IRQ, as there is nothing that guarantees this to work.
Since you already create your own irq_host, you can probably just
give the fake irq the number '1' here, which is local to that host.
Then you call irq_create_mapping() to create the virtual interrupt
number that you pass to the platform_device.
Arnd <><
^ permalink raw reply
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-17 14:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <1184622446.25235.89.camel@localhost.localdomain>
>>>>> + #address-cells =3D <0>;
>>>>> + #size-cells =3D <0>;
>>>>
>>>> No need for these.
>>>
>>> Isn't a good practice to put #address-cells in interrupt controller
>>> nodes?
>>
>> It is not.
>
> Well, that's debatable... but yes, a strict reading of the spec would
> say that you should put neither #address-cells nor #size-cells in a =20=
> leaf
> interrupt controller.
Yes.
>>> If the device tree has an interrupt map defined the interrupt
>>> parent 'unit interrupt specifier' has to be interpreted according
>>> to the #address-cells of the interrupt parent.
>>
>> And "#address-cells" is defaulted to 0 if it is absent,
>> for the purpose of interrupt mapping (but not for its
>> other purposes).
>
> This is a bit confusing though,
Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
simply has no unit address part, in an interrupt domain that
doesn't correspond to a "normal" bus. But saying it like this
is a little bit inexact, and it uses more words.
> which is why I tend to prefer having it
> explicitely in the interrupt controller node :-)
Which is simply incorrect.
> I tend to dislike
> "magic" defaults, we've had problems with them in the past and will =20=
> have
> in the future, I much prefer having things explicit whenever possible.
You mean, the magic default values you used for #address-cells
and #size-cells? That was simply a bug, someone forgot to read
the documentation...
>> That "typical practice" is inspired by the need to explicitly
>> put #address-cells and #size-cells into the device tree if you
>> want Linux to properly parse the device tree, even if the default
>> values would work perfectly (if Linux would work correctly,
>> that is).
>
> Linux does handle default values in some areas. The problem with =20
> default
> values is that they are badly defined
For this? No way:
[=46rom the base spec]:
=93#address-cells=94 S
Standard property name to define the package=92s address format.
prop-encoded-array: Integer, encoded with encode-int.
This property applies to packages that define a physical
address space, i.e., those packages with =93decode-unit=94
methods. The property value specifies the number of cells
that are used to encode a physical address within that
address space. The value of this property affects the other
functions, commands, and methods that deal with physical
addresses. In a package with a =93decode-unit=94 method, a =
missing
=93#address-cells=94 property signifies that the number of
address cells is two.
See? The flat device tree unfortunately has no decode-unit, but
it is still pretty clear which nodes "define a physical address
space" and which do not.
There is nothing badly defined here.
Nothing in the "interrupt mapping" spec redefines #address-cells
(OF isn't all that stupid you know); it simply says that a /unit
interrupt specifier/ has no /unit address/ part if there is no
#address-cells. The algorithm in paragraph 7 makes it super
clear how exactly this should work.
> and the spec contains gray areas
> and contradictions as to what the default values should be in some
> circumstances.
In some areas, perhaps. And it would be nice to bring those
areas to the attention of the working group, instead of just
to complain.
There is no such issue in this area, anyway.
> As a general matter, I dislike default values because
> they somewhat require background knowledge of what default values =20
> should
> be in different contexts to "read" a device-tree.
Of course, you need way more than that knowledge to properly
parse or read a device tree *at all*.
> To be simple, I
> believe default values are a bad idea.
Linux will have to keep supporting them for "real OF", so
requiring an explicit #address-cells where its value is 2
doesn't really help much. I'm not opposed to this though,
for flat device trees at least (I think it's a good thing
for OF trees as well, but for different reasons; and that's
beside the point here).
On the other hand, requiring an #address-cells where it is
supposed to be absent, and you only want it so you can wrap
your head around the interrupt mapping recommended practice
in a more confusing and confused way, is simply WRONG.
>> There are no child nodes, and no binding that says there can
>> be any; neither #address-cells not #size-cells should be there.
>
> You are being way too pedantic here.
No I'm not.
> The interrupt-tree uses those two properties, thus "there is
> no child node" is open to interpretation.
It isn't. Not a bus -> no child node in the device tree.
The interrupt tree is a completely separate thing.
> There is no child device node, but there are child interrupt nodes, =20=
> and
> since the interrupt-tree uses #address/size-cells,
It doesn't.
> it does make some sense to specify them.
If it would, the interrupt mapping spec would have had to say
how the semantics of #address-cells were changed (and they
weren't, and they shouldn't, and this is such a laughable idea
I wonder why anyone would suggest it did).
What the interrupt mapping spec defines is how to _use_ the
value of #address-cells, and how to interpret its absence;
what should be put in #address-cells for separate nodes is
defined elsewhere (namely, in the base spec, and in relevant
device bindings).
> Yes, there is a default value when absent, but the simple fact that =20=
> the
> default is different depending if you are doing a device walk or an
> interrupt tree walk is very confusing.
Yes, perhaps there shouldn't be a default value for #a
in the device structure; this is legacy compatibility
though, way way way too late to change this. You can do
this for the flat device tree though, since a) there are
no legacy trees around that you care about, and b) you
need to do something to get around the fact you don't have
decode-unit and encode-unit anyway, so little changes
around that area should be expected.
> As I said above, the default
> values are a source of more problem than anything else and I tend to
> think they should be banned.
You cannot ban them in the Linux code. With that in mind,
what good would it do? There are thousands of cases where
absence of a property signifies something that you simply
*cannot* forbid, period. So why do it to this one?
> I would personally be inclined to define that whatever spec we come up
> with always require #address-cells/#size-cells for any node that can
> have either device children
That is fine, for the flat device tree. Note that this would
be implicit in all separate device bindings, anyway.
> or interrupt children,
Nope. I hope I explained my reasoning.
> and ban default values alltogether.
That is simply impossible.
Segher
^ permalink raw reply
* [PATCH] Add StorCenter DTS first draft.
From: Jon Loeliger @ 2007-07-17 14:22 UTC (permalink / raw)
To: linuxppc-dev
Based on the Kurobox DTS files.
Signed-off-by: Oyvind Repvik <nail@nslu2-linux.org>
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Comments welcome, of course.
arch/powerpc/boot/dts/storcenter.dts | 142 ++++++++++++++++++++++++++++++++++
1 files changed, 142 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/storcenter.dts
diff --git a/arch/powerpc/boot/dts/storcenter.dts b/arch/powerpc/boot/dts/storcenter.dts
new file mode 100644
index 0000000..87193fa
--- /dev/null
+++ b/arch/powerpc/boot/dts/storcenter.dts
@@ -0,0 +1,142 @@
+/*
+ * Device Tree Source for IOMEGA StorCenter
+ *
+ * Copyright 2007 Oyvind Repvik, Jon Loeliger
+ *
+ * Based on the Kurobox DTS by G. Liakhovetski <g.liakhovetski@gmx.de>
+ *
+ * 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.
+ *
+ * build using:
+ * dtc -f -b 0 -I dts -O dtb -o storcenter.dtb storcenter.dts
+ */
+
+/ {
+ model = "StorCenter";
+ compatible = "storcenter";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,603e { /* Really 8241 */
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <d# 200000000>; /* Hz */
+ timebase-frequency = <d# 33333333>; /* Hz */
+ bus-frequency = <0>;
+ /* Following required by dtc but not used */
+ i-cache-line-size = <0>;
+ d-cache-line-size = <0>;
+ i-cache-size = <4000>;
+ d-cache-size = <4000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 04000000>; /* 64MB @ 0x0 */
+ };
+
+ flash@ff800000 {
+ device_type = "rom";
+ compatible = "direct-mapped";
+ probe-type = "CFI";
+ reg = <ff800000 00800000>;
+ bank-width = <1>;
+ partitions = <
+ 00000000 0000E000
+ 0000E000 00002000
+ 00010000 00040000
+ 00050000 00200000
+ 00250000 004B0000
+ 00700000 00020000
+ 00720000 00010000
+ 00730000 00010000
+ 00740000 000B0000
+ >;
+ partition-names = "uboot2env", "dtb", "uboot2",
+ "emkernel", "emfs", "uboot1",
+ "empty", "uboot1-env", "SysConf";
+ };
+
+
+ soc10x {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ compatible = "mpc10x";
+ store-gathering = <0>; /* 0 == off, !0 == on */
+ reg = <80000000 00100000>;
+ ranges = <80000000 80000000 70000000 /* pci mem space */
+ fdf00000 fdf00000 00100000 /* EUMB */
+ fe000000 fe000000 00c00000 /* pci i/o space */
+ fec00000 fec00000 00300000 /* pci cfg regs */
+ fef00000 fef00000 00100000>; /* pci iack */
+
+ i2c@fdf03000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <fdf03000 1000>;
+ interrupts = <5 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@fdf04500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <fdf04500 8>;
+ clock-frequency = <d# 100000000>; /* Hz */
+ current-speed = <d# 115200>;
+ interrupts = <9 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ serial@fdf04600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <fdf04600 8>;
+ clock-frequency = <d# 100000000>; /* Hz */
+ current-speed = <d# 19200>;
+ interrupts = <a 2>;
+ interrupt-parent = <&mpic>;
+ };
+
+ mpic: pic@fdf40000 {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ device_type = "open-pic";
+ compatible = "chrp,open-pic";
+ interrupt-controller;
+ reg = <fdf40000 40000>;
+ built-in;
+ };
+
+ pci@fe800000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "mpc10x-pci";
+ reg = <fe800000 400000>;
+ ranges = <01000000 0 0 fe000000 0 00c00000
+ 02000000 0 80000000 80000000 0 70000000>;
+ bus-range = <0 ff>;
+ clock-frequency = <d# 100000000>; /* Hz */
+ interrupt-parent = <&mpic>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x15 - ETH */
+ 7800 0 0 1 &mpic 0 1
+ 7800 0 0 2 &mpic 0 1
+ 7800 0 0 3 &mpic 0 1
+ 7800 0 0 4 &mpic 0 1
+ >;
+ };
+ };
+};
--
1.5.2.2.249.g45fd
^ permalink raw reply related
* Re: [RFC][PATCH 6/8] Walnut DTS
From: Segher Boessenkool @ 2007-07-17 14:26 UTC (permalink / raw)
To: Josh Boyer; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <20070717023957.GL3925@crusty.rchland.ibm.com>
> Right. See, there are people like me that don't know what the
> default values
> are/should be. Having them explicitly listed, even if it's
> redundant, serves
> as a good learning aid.
_Only_ if it's redundant. Not if it has a meaning different
from having the property not there at all.
> Now, realistically I do know what the default is in this case. But
> I only
> learned that recently. With hopefully more people starting to port
> things
> over to arch/powerpc it might be a good idea to document them at
> least.
Definitely, we need more good examples, and maybe some
public stonings or something like that.
> Otherwise, I fear we'd wind up repeating ourselves over and over.
>
> Could we get a 'thou shalt not rely on defaults' added to
> booting-without-of.txt? Or maybe something less draconian ;).
Such a statement is too vague to be meaningful. It would
be a good idea in separate cases; but _do_ describe it more
carefully than just talking about "defaults", and _do_ put
a comment at any such entry that this is different from how
Open Firmware defines this, so that people looking at the
Linux code won't get hopelessly confused.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Mark Zhan @ 2007-07-17 14:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200707171506.43102.arnd@arndb.de>
On Tue, 2007-07-17 at 15:06 +0200, Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
> > Yes, basically I agree what you say. That should be the right way.
> >
> > but, the current situation is that: in all DTS files that are using smc
> > or scc as uart device, all device node definitions have the same
> > "compatible" property -- "cpm_uart"
> >
> > So what I do here is just following the upstream source tree.
> >
>
> Well, AFAICS, all of them currently use scc. The 8xx platforms don't
> even build correctly in the mainline kernel, so I guess it would
> be good to change them to also list fsl,cpm-smc in the compatible
> property.
That probably could be done by another series of patches, and I really
don't want to introduce those kinds of patches in my BSP patches. I
don't know if the 8xx/82xx series patches from Scott Wood will cover
this issue or not. We can wait for them to see where thing will go.
Thanks
mark zhan
^ permalink raw reply
* Machine check exception. 2.6.20 powerpc tree.
From: Ramirez-Ortiz, Jorge @ 2007-07-17 14:21 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1881 bytes --]
Running our multithreaded application on ppc8548 (E500 core) generates a
machine check exception when trying to access some ASIC's registers
mapped on the PCI space (This application maps a PCI device to access
its registers)
machine_check_exception: task my_process, MCSR=0x10008, NIP=0x10153530
Machine check in user mode.
Caused by (from MCSR=10008): Guarded Load or Cache-Inhibited stwcx.
Bus - Read Data Bus Error
Here is the assembly dump of the region of code containing the offending
instruction in user-space, with SRR0 pointing us at 0x10153530 when the
exception is raised:
0x10153528 <_ZN2vk7in_le32EPVKj+16>: lwz r0,8(r31)
0x1015352c <_ZN2vk7in_le32EPVKj+20>: lwz r9,8(r31)
0x10153530 <_ZN2vk7in_le32EPVKj+24>: lwbrx r0,0,r0
0x10153534 <_ZN2vk7in_le32EPVKj+28>: twi 0,r0,0
0x10153538 <_ZN2vk7in_le32EPVKj+32>: isync
All this is fully reproducible, the offending code is repeatedly the
byte-reverse load within the (m)mapped PCI memory segment. The offset
within the segment may vary, even if most of the hits seem to be taken
when reading 0x20030-0x20034 offsets from 0x80000000 PCI address space
(which is mapped to the application via /dev/mem)
/proc/pid/maps reports the following mappings to /dev/mem, with the
first one being an ASIC on the PCI space whose registers we are trying
to access, and the second one being system memory (this system memory is
out of kernel visibility...we use 'mem=256M' as a kernel parameter...):
303a9000-304a9000 rw-s 80000000 00:0c 2087 /dev/mem
304a9000-404a9000 rw-s 10000000 00:0c 2087 /dev/mem
Has anybody experienced something similar using a kernel based on a
2.6.20 powerpc tree?
Many thanks
jorge
______________________________
Jorge Ramirez-Ortiz
[-- Attachment #2: Type: text/html, Size: 7708 bytes --]
^ permalink raw reply
* Re: [PATCH] USB_DR host support for FSL MPC831x
From: Vitaly Bordug @ 2007-07-17 14:52 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Greg KH, linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890F06271@zch01exm26.fsl.freescale.net>
On Tue, 17 Jul 2007 20:18:35 +0800
"Li Yang-r58472" <LeoLi@freescale.com> wrote:
> Hi Vitaly,
>
> I believe that your patch is addresses by my patch in 2.6.23 queue:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
> ehci_fsl-update-for-mpc831x-support.patch
>
okay, nm then. I'll revalidate with these 2 patches
and come up with something ontop if it won't work.
> - Leo
>
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> > [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
> > On Behalf Of Vitaly Bordug
> > Sent: Tuesday, July 17, 2007 8:59 AM
> > To: Greg KH
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: [PATCH] USB_DR host support for FSL MPC831x
> >
> >
> > Modifies fsl_ehci code so that to get USB host working on
> > mpc831x platform. Verified with MPC8313RDB reference board.
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> >
> > ---
> >
> > arch/powerpc/boot/dts/mpc8313erdb.dts | 1 +
> > drivers/usb/host/ehci-fsl.c | 4 +++-
> > drivers/usb/host/ehci-hcd.c | 2 +-
> > 3 files changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
> > b/arch/powerpc/boot/dts/mpc8313erdb.dts
> > index 1b351dc..c330e79 100644
> > --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> > +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> > @@ -90,6 +90,7 @@
> > interrupt-parent = < &ipic >;
> > interrupts = <26 8>;
> > phy_type = "utmi_wide";
> > + control_init = <00000280>; // UTMI ext
> > 48 MHz clk
> > };
> >
> > mdio@24520 {
> > diff --git a/drivers/usb/host/ehci-fsl.c
> > b/drivers/usb/host/ehci-fsl.c index c7a7c59..3e3187b 100644
> > --- a/drivers/usb/host/ehci-fsl.c
> > +++ b/drivers/usb/host/ehci-fsl.c
> > @@ -185,12 +185,14 @@ static void mpc83xx_usb_setup(struct
> > usb_hcd *hcd)
> > struct ehci_hcd *ehci = hcd_to_ehci(hcd);
> > struct fsl_usb2_platform_data *pdata;
> > void __iomem *non_ehci = hcd->regs;
> > + u32 temp;
> >
> > pdata =
> > (struct fsl_usb2_platform_data *)hcd->self.controller->
> > platform_data;
> > /* Enable PHY interface in the control reg. */
> > - out_be32(non_ehci + FSL_SOC_USB_CTRL, 0x00000004);
> > + temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
> > + out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
> > out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
> >
> > #if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
> > diff --git a/drivers/usb/host/ehci-hcd.c
> > b/drivers/usb/host/ehci-hcd.c index 099aff6..994a127 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
> > #define PCI_DRIVER ehci_pci_driver
> > #endif
> >
> > -#ifdef CONFIG_MPC834x
> > +#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
> > #include "ehci-fsl.c"
> > #define PLATFORM_DRIVER ehci_fsl_driver
> > #endif
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
--
Sincerely,
Vitaly
^ permalink raw reply
* Memory Corruption in Linux kernel MPC8347 revision 3
From: Boris Shteinbock @ 2007-07-17 14:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 7772 bytes --]
Hi Everyone.
I am working on the Linux port for MPC8347 revision 3 custom build board
with DDR2 memory.
I've successfully ported U-boot (latest git) and the kernel itself,
however during kernel boot I am encountering serious memory corruption
errors. The log for one of the examples is at the bottom of this
message.
Basically, the corruption is always happening somewhere at memory
management intensive tasks such as networking, JFFS2 mounting etc.
As far as I can see, it is not related to some specific driver, because
even it happens even at kernel configured at absolute minimum, ( console
serial driver only and even without it)
The place of the corruption depends on kernel configuration.
The DDR2 memory controller is configured correctly as far as I can tell,
since :
1. DDR2 controller register values are taken from VxWorks bootrom
that works on this board without any problems.
2. u-boot mtest passes successfully
3. u-boot alternative mtest passes successfully
4. My own custom mem tests in u-boot pass successfully
5. If I manage two boot the board into shell prompt (with absolute
minimum configuration) memtester application is also successful.
The minimum configuration that is one I am able to boot into shell is a
kernel configured with serial console and small busybox JFFS2 file
system in the flash. In this configuration, the boot fails the first
time JFFS2 root FS is mounted. However it does boot after reset.
I've tried different kernels with the same results starting from, I
think, 2.6.16 up to 2.6.22
I tried the kernel that is provided by Freescale for 834x reference
boards. ( with my board support of course)
I tried booting both OF flat trees (powerpc) and bd_t based builds (ppc)
I've also tried all memory management options :
SLAB, SLOB and SLUB (in the latest kernel). They all failed at some
point of time, so the assumption is that the problem is not in the
memory management facilities.
The board manufacturer swears that DDR2 memory controller values are
correct and should work perfectly.
So now I almost out of options and I am seeking your help.
Any type of input on this issue would be greatly appreciated.
Thanks,
Boris
PS. Note that an below example represents failure during DHCP
autoconfiguration. However the similar error happens even when
networking is disabled completely. just in a different place.
=> bootm
## Booting image at 00400000 ...
Image Name: Linux-.6.21.5
Created: 2007-07-10 14:20:19 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 898361 Bytes = 877.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FA3CF8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF41
bd address = 0x07FA3FBC
memstart = 0x00000000
memsize = 0x08000000
flashstart = 0xFE000000
flashsize = 0x02000000
flashoffset = 0x00033000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 528 MHz
busfreq = 264 MHz
ethaddr = 00:04:9F:EF:23:35
eth1addr = 00:E0:0C:00:7E:25
IP addr = 10.2.222.20
baudrate = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
!!!! of_flat_tree = 00000000
Booting without OF Flat tree
Linux version .6.21.5 (me@localhost) (gcc version
4.0.0 (DENX ELDK 4.1 4.0.0)) #24 Tue Jul 10 17:20:09 IDT 2007
Zone PFN ranges:
DMA 0 -> 32768
Normal 32768 -> 32768
early_node_map[1] active PFN ranges
0: 0 -> 32768
Built 1 zonelists. Total pages: 32512
Kernel command line: console=ttyS0,115200 root=/dev/mtdblock1
rootfstype=jffs2 ip=dhcp
IPIC (128 IRQ sources, 8 External IRQs) at fe000700
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127744k available (1584k kernel code, 444k data, 84k init, 0k
highmem)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
Setup MTD partitions
Generic PHY: Registered new driver
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 9) is a 16550A
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 10) is a 16550A
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:04:9f:ef:23:35
eth0: Running with NAPI disabled
eth0: 64/64 RX/TX BD ring size
Broadcom BCM5241: Registered new driver
physmap platform flash device: 02000000 at fe000000
physmap-flash.0: Found 1 x16 devices at 0x0 in 8-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
Using physmap partition information
Creating 2 MTD partitions on "physmap-flash.0":
0x00000000-0x00100000 : "uboot"
0x00100000-0x02000000 : "rootfs"
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
!!!! Gianfar init_phy. phy_id = 0:01
!!!! phy_attach. phy_id = 0:01
!!!! phy_attach device found. phy_id = 0:01
Sending DHCP requests .<3>slab: Internal list corruption detected in
cache 'files_cache'(21), slabp c0344000(16). Hexdump:
000: 00 10 01 00 00 20 02 00 00 00 00 70 c0 34 40 70
010: 00 00 00 10 00 00 ff 10 00 00 00 00 ff ff ff fe
020: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
030: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
040: ff ff ff fe ff ff ff fe ff ff ff fe ff ff ff fe
050: ff ff ff fe ff ff ff fe ff ff ff fd 00 00 00 11
060: 00 00 00 12 00 00 00 13 00 00 00 14 ff ff ff ff
------------[ cut here ]------------
kernel BUG at mm/slab.c:2936!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C0050F80 LR: C0050F80 CTR: 00000000
REGS: c034fe00 TRAP: 0700 Not tainted (.6.21.5)
MSR: 00021032 <ME,IR,DR> CR: 24004002 XER: 00000000
TASK = c032a3c0[3] 'events/0' THREAD: c034e000
GPR00: C0050F80 C034FEB0 C032A3C0 00000001 00000DF5 FFFFFFFF C00F5B54
00000010
GPR08: C01D0000 C01E0000 00000DF5 00000DF5 00000000 00F1C5DB 07FFD000
FFFFFFFF
GPR16: 00000001 00000000 00000000 00800000 00000000 007FFF00 00000000
C033DAA0
GPR24: C0339C90 00000007 00000000 C01B0000 C01B0000 C0344000 C033DAA0
00000070
NIP [C0050F80] check_slabp+0xe4/0x11c
LR [C0050F80] check_slabp+0xe4/0x11c
Call Trace:
[C034FEB0] [C0050F80] check_slabp+0xe4/0x11c (unreliable)
[C034FED0] [C0051450] free_block+0x88/0x138
[C034FF00] [C0052188] drain_array+0xa0/0xe0
[C034FF20] [C0052228] cache_reap+0x60/0x144
[C034FF40] [C00257B0] run_workqueue+0xd0/0x170
[C034FF60] [C0025960] worker_thread+0x110/0x144
[C034FFC0] [C00298E4] kthread+0x74/0xb0
[C034FFF0] [C0005F38] kernel_thread+0x44/0x60
Instruction dump:
387b6538 7c9df8ae 4bfc2b49 3bff0001 813e0020 5529103a 3929001c 7f9f4840
419cffcc 3c60c01b 3863336c 4bfc2b25 <0fe00000> 48000000 80030020
2f800000
[-- Attachment #2: Type: text/html, Size: 9637 bytes --]
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Segher Boessenkool @ 2007-07-17 14:57 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IAnwC-0003Xm-6U@jdl.com>
> Comments welcome, of course.
Well you asked for it :-)
> +/ {
> + model = "StorCenter";
If you can find a real model number, put it in here,
instead.
> + compatible = "storcenter";
Needs a manufacturer name in there.
> + PowerPC,603e { /* Really 8241 */
So say "PowerPC,8241@0", or "PowerPC,e300@0" (or whatever
the CPU core in there is), or simply "cpu@0", following
the generic naming recommended practice.
> + bus-frequency = <0>;
Is this filled in anywhere? Please document that, if so.
> + /* Following required by dtc but not used */
> + i-cache-line-size = <0>;
> + d-cache-line-size = <0>;
> + i-cache-size = <4000>;
> + d-cache-size = <4000>;
Not used _by the Linux kernel_, it's required by the
PowerPC binding. Perhaps that should be modified
for flat device tree use, there are many more required
properties that no flat tree has anyway.
> + flash@ff800000 {
> + device_type = "rom";
I'm sure you know I find this "rom" binding to be crap.
However, I didn't yet write up the "cfi" binding, so I
can't complain ;-)
> + partitions = <
> + 00000000 0000E000
> + 0000E000 00002000
> + 00010000 00040000
> + 00050000 00200000
> + 00250000 004B0000
> + 00700000 00020000
> + 00720000 00010000
> + 00730000 00010000
> + 00740000 000B0000
> + >;
Nothing from 7f0000 to 7fffff?
> + soc10x {
Bad name. Where is the binding for this? I don't think
I saw it before.
> + compatible = "mpc10x";
"manufacturer,106-host" or similar. But this isn't an 10x
at all, is it?
> + store-gathering = <0>; /* 0 == off, !0 == on */
Don't define this as "!0", but as "1".
> + i2c@fdf03000 {
> + device_type = "i2c";
No device_type, there is no I2C binding.
> + compatible = "fsl-i2c";
Needs to be more specific.
> + mpic: pic@fdf40000 {
interrupt-controller@fdf40000
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
No #address-cells here.
> + device_type = "open-pic";
device_type = "interrupt-controller" I believe, unless
the mpic binding does something weird.
> + pci@fe800000 {
> + clock-frequency = <d# 100000000>; /* Hz */
100MHz PCI? Interesting.
> + interrupt-map = <
> + /* IDSEL 0x15 - ETH */
> + 7800 0 0 1 &mpic 0 1
7800 isn't device 0x15. I think you meant 15.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Segher Boessenkool @ 2007-07-17 15:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707171406.03455.arnd@arndb.de>
>>>> + if (strstr(model, "SMC")) {
>>>> + cpm_uart_dev =
>>>> platform_device_register_simple("fsl-cpm-smc:uart",
>>>> + i, &r
>>>> [0], 3);
>>>> + } else if (strstr(model, "SCC")) {
>>> You should probably use of_device_is_compatible() to check
>>> if a given device can be used by a particular driver.
>>
>> I think, the function of_find_compatible_node(), which is called
>> in the
>> for loop, has already done that. So definitely, no need to call
>> of_device_is_compatible() any more.
>
> It's a little more complicated than that. The "compatible" property
> should
> indicate the exact interface of that device, so the "model" does
> not really
> matter here.
"model" is meant to be an exact manufacturer model number.
This can be used for workaround code or such if the "compatible"
entry isn't specific enough. You should try to make sure your
"compatible" entries are, though.
Oh, and strstr() is asking for trouble. Just do a full
compare.
> I don't know the difference between smc and scc, but if you
> need to register them as different pplatform devices, they should
> normally also have different names in "compatible", possibly in
> addition
> to the existing one.
Either that, or if they are identical device, just used in
different ways / connected differently, show that via some
other properties or such.
> If the compatible property contains "fsl,cpm-smc\0cpm_uart", you
> can scan for
> either of them. The loop will iterate over all cpm_uart compatible
> devices,
> while the later test will look for an fsl,cpm-smc compatible device.
Well, "fsl,cpm-uart" (note the two differences), but yes.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 14:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184682576.18501.62.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> > Well, AFAICS, all of them currently use scc. The 8xx platforms don't
> > even build correctly in the mainline kernel, so I guess it would
> > be good to change them to also list fsl,cpm-smc in the compatible
> > property.
>
> That probably could be done by another series of patches, and I really
> don't want to introduce those kinds of patches in my BSP patches. I
> don't know if the 8xx/82xx series patches from Scott Wood will cover
> this issue or not.
I guess he can best answer that himself. Scott, what are your plans
to deal with the different types of cpm ports?
Arnd <><
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox