* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Paul Mackerras @ 2007-07-17 11:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Wei.Zhang
In-Reply-To: <B2EA074C-5D8E-4E13-B6BF-E81FBA52E76E@kernel.crashing.org>
Segher Boessenkool writes:
> The device tree describes _all_ hardware in the system,
> not just the things that are somewhat harder to probe
> for.
Actually, for embedded systems, the device tree is really only
required to describe the things that it's useful for the Linux kernel
to know.
The point of the device tree for embedded systems is to provide
configuration information, not to be able to claim compliance with
some set of legalistic requirements. :)
I think in some cases we have gone a little over the top in trying to
put everything in the device tree, in fact. Ultimately I think it has
to be up to the more experienced embedded developers to say how much
detail in the device tree is actually helpful and how much is dead
weight.
Paul.
^ permalink raw reply
* regarding cpm_uart and platform_bus_type
From: Alexandros Kostopoulos @ 2007-07-17 11:55 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I was wondering, since arch/powerpc is now based on device trees,
shouldn't the cpm_uart driver (or at least a branch of it for
arch/powerpc) be changed to use of_platform_bus_type instead of
platform_bus_type? In my opinion, cpm_uart driver should take all its
configuration (uart address base, ints etc) from dts (via the of_platform
code) without any intervention from board specific code. In any case,
given the current situation, how can I pass cpm_uart the address/irq of
the uarts? by hardcoding it in my board specific code? mpc82xx_ads.c
doesn't seem to have such code, and I was wondering how SCC uarts work in
this platform? Who initializes them?
thank you
Alex
^ permalink raw reply
* Re: hvc_iseries not working
From: Olaf Hering @ 2007-07-17 12:02 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev
In-Reply-To: <1184600356.22547.121.camel@farscape.rchland.ibm.com>
On Mon, Jul 16, Will Schmidt wrote:
> On Fri, 2007-07-13 at 19:05 +0200, Olaf Hering wrote:
> > 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4
> > 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on
> > a i820 with v5r3.
> > 2.6.22 boots ok with CONFIG_VIOCONS
>
> When it works, do you have more than one processor assigned to the
> partition?
The partition does not change, only the kernel (And iseries_defconfig) changes.
The partition has a single cpu assigned, 0.8 %
^ permalink raw reply
* Re: regarding cpm_uart and platform_bus_type
From: Alexandros Kostopoulos @ 2007-07-17 12:15 UTC (permalink / raw)
To: Alexandros Kostopoulos, linuxppc-dev
In-Reply-To: <op.tvlxc2sjnhx3hy@phoenix>
Hm, it seems that, after all, cpm_uart works fine without any board
specific code whatsoever. Sorry about the fuss. My mistake
Regards
Alex
On Tue, 17 Jul 2007 14:55:30 +0300, Alexandros Kostopoulos
<akostop@inaccessnetworks.com> wrote:
> Hi all,
>
> I was wondering, since arch/powerpc is now based on device trees,
> shouldn't the cpm_uart driver (or at least a branch of it for
> arch/powerpc) be changed to use of_platform_bus_type instead of
> platform_bus_type? In my opinion, cpm_uart driver should take all its
> configuration (uart address base, ints etc) from dts (via the
> of_platform code) without any intervention from board specific code. In
> any case, given the current situation, how can I pass cpm_uart the
> address/irq of the uarts? by hardcoding it in my board specific code?
> mpc82xx_ads.c doesn't seem to have such code, and I was wondering how
> SCC uarts work in this platform? Who initializes them?
>
> thank you
>
> Alex
^ permalink raw reply
* 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
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