* 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: [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 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] 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 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: 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
* [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
* [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] 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
* 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
* 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 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: 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] 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] 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: 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: 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
* 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: [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
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Mark Zhan @ 2007-07-17 6:58 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707170327.41648.arnd@arndb.de>
Hi Arnd,
On Tue, 2007-07-17 at 03:27 +0200, Arnd Bergmann wrote:
> > +static struct resource m48t59_resources[] = {
> > + {
> > + .start = SBCPQ2_RTC_BASE,
> > + .end = SBCPQ2_RTC_BASE + SBCPQ2_RTC_SIZE - 1,
> > + .flags = IORESOURCE_MEM,
> > + }, {
> > + .start = SBCPQ2_M48T59_IRQ,
> > + .end = SBCPQ2_M48T59_IRQ,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + { },
> > +};
>
> This is the kind of information that belongs into the device tree,
> not hardcoded into the board code.
>
ok, I will move them into device tree.
> > +/**
> > + * sbcpq2_pdev_init - Register the platform device for sbcpq2 board
> > + */
> > +static int __init sbcpq2_platdev_init(void)
> > +{
> > + struct irq_desc *desc = irq_desc + SBCPQ2_M48T59_IRQ;
>
> same for the interrupt number. Worse, this looks broken
> because the descriptor array describes virtual interrupt
> numbers, while SBCPQ2_M48T59_IRQ must be a physical number.
> These are often the same, but there is no guarantee.
>
> In order to get a virtual interrupt number for a given device,
> you need to call irq_of_parse_and_map().
>
> > + /* Install a dummy irq chip for M48T59 RTC irq */
> > + if (desc->chip == &no_irq_chip)
> > + set_irq_handler(SBCPQ2_M48T59_IRQ, desc->handle_irq);
> > +
> > + /* Register all platform devices for sbcpq2 */
> > + platform_add_devices(sbcpq2_devices, ARRAY_SIZE(sbcpq2_devices));
> > + return 0;
> > +}
> > +arch_initcall(sbcpq2_platdev_init);
>
>
> > +/*
> > + * 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:-)
> > +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?
> > +static void __init sbcpq2_setup_arch(void)
> > +{
> > + struct device_node *np;
> > + volatile memctl_cpm2_t *mc;
>
> not volatile, but __iomem!
>
Fixed.
> > + unsigned char * eeprom_base;
> > + int i = 0;
> > +
> > +#ifdef CONFIG_CPM2
> > + cpm2_reset();
> > +#endif
> > +
> > + /*
> > + * Make sure that we have the right CS# setting
> > + */
> > + mc = &cpm2_immr->im_memctl;
> > +
> > + /* 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. The reason why they are needed is because some
legacy u-boot for this board probably was setting up the wrong memory
map.
>
> > + model = (char *)of_get_property(np, "model", NULL);
> > + if (!model)
> > + continue;
>
> The cast is not needed here.
> > +
> > + id = of_get_property(np, "device-id", NULL);
> > + if (!id)
> > + continue;
> > +
> > + macaddr = (unsigned char *)of_get_mac_address(np);
> > + if (!macaddr)
> > + continue;
>
> or here.
Both cast are removed.
>
> > + if (strstr(model, "FCC"))
> > + eeprom_ofs = SBCPQ2_FCC1_MACADDR_OFS;
> > + else if (strstr(model, "SCC"))
> > + eeprom_ofs = SBCPQ2_SCC1_MACADDR_OFS;
> > + eeprom_ofs += ((*id) - 1) * 6;
>
> of_device_is_compatible()
>
>
> > + for (j = 0; j < 6; j++)
> > + *(macaddr + j) = *(eeprom_base + eeprom_ofs + j);
>
> in_8().
OK. in_8() will be used.
>
> > + }
> > + iounmap(eeprom_base);
> > +}
> > +
> > +/*
> > + * Called very early, device-tree isn't unflattened
> > + */
> > +static int __init sbcpq2_probe(void)
> > +{
> > + /* We always match for now, eventually we should look at
> > + * the flat dev tree to ensure this is the board we are
> > + * supposed to run on
> > + */
> > + return 1;
> > +}
>
> Don't write why the code is wrong -- just fix it.
>
> > +/* For our show_cpuinfo hooks. */
> > +#define CPUINFO_VENDOR "Wind River"
> > +#define CPUINFO_MACHINE "SBC PowerQUICCII 82xx"
>
> Not in a header file please.
>
> > +/*
> > + * Wind River SBC PowerQUICCII 82xx Physical Memory Map (CS0 for OnBoard Flash)
> > + *
> > + * 0x00000000 - 0x07FFFFFF CS2, 128 MB DIMM SDRAM
> > + * 0x08000000 - 0x0FFFFFFF CS3, 128 MB DIMM SDRAM
> > + * 0x12000000 - 0x12100000 CS8, ATM
> > + * 0x20000000 - 0x20FFFFFF CS4, 16 MB Local Bus SDRAM
> > + * 0x21000000 - 0x21001FFF CS7, Control EPLD
> > + * 0x22000000 - 0x22001FFF CS5, 8KB EEPROM
> > + * 0x22002000 - 0x22003FFF CS5, visionPORT
> > + * 0x22004000 - 0x22005FFF CS5, User Switches
> > + * 0x22006000 - 0x22007FFF CS5, STATUS
> > + * 0x22008000 - 0x22009FFF CS5, i8259 interrupt controller
> > + * 0x2200A000 - 0x2200BFFF CS5, LED (Seven Segment Display)
> > + * 0x80000000 - 0x80001FFF CS11, RTC
> > + * 0xE0000000 - 0xE3FFFFFF CS6, 64 MB DIMM Flash
> > + * 0xE4000000 - 0xE7FFFFFF CS1, 64 MB DIMM Flash
> > + * 0xFE000000 - 0xFFFFFFFF CS0, 2 MB Boot Flash
> > + * 0xF0000000 - 0xF0020000 MPC82xx Internal Registers Space
> > + */
> > +#define SBCPQ2_SDRAM_BASE 0x00000000
> > +#define SBCPQ2_SDRAM_SIZE 0x10000000
> > +
> > +#define SBCPQ2_LOCAL_SDRAM_BASE 0x20000000
> > +#define SBCPQ2_LOCAL_SDRAM_SIZE 0x1000000
> > +
> > +#define SBCPQ2_EPLD_BASE 0x21000000
> > +#define SBCPQ2_EPLD_SIZE 0x2000
> > +
> > +#define SBCPQ2_EEPROM_BASE 0x22000000
> > +#define SBCPQ2_EEPROM_SIZE 0x2000
> > +
> > +/* User Switches SW5 */
> > +#define SBCPQ2_USER_SW_BASE 0x22004000
> > +#define SBCPQ2_USER_SW_SIZE 0x2000
> > +
> > +#define SBCPQ2_STATUS_BASE 0x22006000
> > +#define SBCPQ2_STATUS_SIZE 0x2000
> > +
> > +#define SBCPQ2_I8259_BASE 0x22008000
> > +#define SBCPQ2_I8259_SIZE 0x2000
> > +
> > +/* Seven Segment Display LED D46 */
> > +#define SBCPQ2_LED_BASE 0x2200A000
> > +#define SBCPQ2_LED_SIZE 0x2000
> > +
> > +#define SBCPQ2_RTC_BASE 0x80000000
> > +#define SBCPQ2_RTC_SIZE 0x2000
> > +
> > +#define SBCPQ2_BOOT_FLASH_BASE 0xFE000000
> > +#define SBCPQ2_BOOT_FLASH_SIZE 0x00200000
> > +
> > +#define SBCPQ2_DIMM_FLASH_BASE 0xE0000000
> > +#define SBCPQ2_DIMM_FLASH_SIZE 0x04000000
> > +
> > +#define CPM_MAP_ADDR 0xF0000000
> > +#define CPM_IRQ_OFFSET 0
>
> All this is in the device tree already, so don't duplicate it here.
>
> > +/*
> > + * The offset of ethernet MAC addr within EEPROM
> > + */
> > +#define SBCPQ2_FCC1_MACADDR_OFS 0x60
> > +#define SBCPQ2_FCC2_MACADDR_OFS 0x66
> > +#define SBCPQ2_FCC3_MACADDR_OFS 0x72
> > +#define SBCPQ2_SCC1_MACADDR_OFS 0x78
>
> Likewise, the mac address is in the device tree, so no need
> to tell the kernel how to read it.
>
> > +/*
> > + * The following IRQs are routed to i8259 PIC.
> > + *
> > + * NOTE: i8259 PIC is cascaded to SIU_INT_IRQ6 of CPM2 interrupt controller
> > + */
> > +#define SBCPQ2_PC_IRQA (NR_SIU_INTS+0)
> > +#define SBCPQ2_PC_IRQB (NR_SIU_INTS+1)
> > +#define SBCPQ2_MPC185_IRQ (NR_SIU_INTS+2)
> > +#define SBCPQ2_ATM_IRQ (NR_SIU_INTS+3)
> > +#define SBCPQ2_PIRQA (NR_SIU_INTS+4)
> > +#define SBCPQ2_PIRQB (NR_SIU_INTS+5)
> > +#define SBCPQ2_PIRQC (NR_SIU_INTS+6)
> > +#define SBCPQ2_PIRQD (NR_SIU_INTS+7)
>
> Again, these are in the device tree, so don't put them here.
>
> > +/* cpm serial driver works with constants below */
> > +#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
> > +#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
> > +#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
> > +#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
> > +#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
> > +#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
>
> What are these for? If you need them in the device driver, just put
> them in there, not in a header file. Also, you should make
> sure not to pollute the global name space, so they should
> be named SBCPQ2_SIU_INT_* to make it clear that they are board
> specific.
>
> > +#ifdef CONFIG_SBCPQ2
> > +#include <platforms/82xx/sbcpq2.h>
> > +#endif
>
> Never put #ifdef around an #include.
>
> > +
> > #ifdef CONFIG_PCI_8260
> > #include <platforms/82xx/m82xx_pci.h>
> > #endif
>
> Kill this #ifdef as well while you're there. If you get name space
> conflicts, just rename the symbols to make them unique.
>
> > +/ {
> > + model = "SBCPQ2";
> > + compatible = "mpc82xx";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + linux,phandle = <100>;
>
> Don't put explicit phandles here. If you need a reference, do it
> symbolically.
>
> Arnd <><
^ permalink raw reply
* Re: [PATCH 0/3] 82xx: Add the support for Wind River SBC PowerQUICCII
From: Vitaly Bordug @ 2007-07-17 6:41 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus
In-Reply-To: <1184649903.10499.49.camel@mark>
On Tue, 17 Jul 2007 13:25:03 +0800
Mark Zhan wrote:
> Hi Vitaly,
>
> When you will send out your 8xx/82xx series patches?
>
As I mentioned, they are not mine but Scott's. And should appear shortly according to him...
> Thanks
> Mark Zhan
> On Tue, 2007-07-17 at 04:44 +0400, Vitaly Bordug wrote:
> > On Mon, 16 Jul 2007 17:01:28 +0800
> > Mark Zhan wrote:
> >
> > > These 3 patches add the powerpc support of Wind River SBC
> > > PowerQUICCII.
> > >
> > I am sorry, but this would intercept with big 8xx/82xx series from
> > Scott Wood I am reviewing now. it makes the initial merged code
> > more maintainable and powerpc-friendly, but would have some rework
> > required in upcoming patches for new BSPs.
> >
> > OTOH, it would make all the changes below very short and apparent.
> > Of course, if something would block those series this one can be
> > considered to merge.
> >
> >
> > > 1) Currently, some mpc82xx platform hooks in mpc82xx_ads.c are
> > > actually not specific to ads board. So the 1st patch makes them be
> > > shared by different 82xx boards.
> > >
> > > 2) The 2nd patch make 'cpm_uart_of_init' be able to parse SMC
> > > uart in DTS
> > >
> > > 3) The 3rd patch is the platform codes, defconfig and dts for Wind
> > > River SBC PowerQUICCII 82xx board.
> > >
> > > Any comment is welcome.
> > >
> > > Thanks
> > > Mark Zhan
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
> >
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 10/10] IB/ehca: Support large page MRs
From: Joachim Fenkes @ 2007-07-17 6:29 UTC (permalink / raw)
To: Roland Dreier
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <adatzs3u1sa.fsf@cisco.com>
Roland Dreier <rdreier@cisco.com> wrote on 17.07.2007 05:50:13:
> > > Why the module parameter? Is there any reason a user would want to
> > > turn this off? Or conversely, why is it off by default?
> >
> > We're pretty confident this new feature works, but as with all new
and
> > possibly experimental features, there are chances it might explode
your
> > machine when activated. So, like with the scaling code, we want the
user
> > to make the conscious decision of using this code instead of
activating it
> > by default.
>
> OK, I guess. So can we expect to, say, change the default to turning
> it on for 2.6.24 and remove the option entirely (so it's always on) in
> 2.6.25?
Deal.
Joachim
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: suresh suresh @ 2007-07-17 5:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded, Siva Prasad
In-Reply-To: <469B9825.6070507@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
Thanks....
MPC8280 has internal memory space which contains Dualport(Dp) RAM. In the
DpRAM we allocate some tables and these has to store pointer of the buffers
which are allocated in external memory. Core will use this pointer to access
the buffers, basically these buffers are used for DMA.
Using IMMR register we can get physical address of the internal memory. Now
can I store the address return by the kmalloc() function? or I should
convert it into physical?
Please help me how to resove this address translation.
Regards,
Suresh
On 7/16/07, Scott Wood <scottwood@freescale.com> wrote:
>
> Siva Prasad wrote:
> > It returns kernel virtual address. If you use this buffer space for DMA,
> > please use appropriate flags. You may use __pa(address) or
> > virt_to_phys() to convert virtual to physical.
>
> No, you may not -- physical and DMA addresses are not always identical.
> Use the DMA mapping API.
>
> -Scott
>
>
[-- Attachment #2: Type: text/html, Size: 1281 bytes --]
^ permalink raw reply
* Re: [ofa-general] Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
From: Shirley Ma @ 2007-07-17 5:57 UTC (permalink / raw)
To: Roland Dreier
Cc: Joachim Fenkes, LKML, LinuxPPC-Dev, general-bounces,
Hoang-Nam Nguyen, OF-General, Stefan Roscher
In-Reply-To: <ada1wf7vgfb.fsf@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hello Roland,
>I still haven't seen much code using the feature or
>even any anecdotal information about the performance impact.
The multiple links performance has been significant improved according to
the prototype IPoIB-UD mode test for eHCA driver esepcially for two links
on the same adapter. I haven't tried mthca (PCI-X and PCI-E) yet.
Thanks
Shirley
[-- Attachment #2: Type: text/html, Size: 446 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] 82xx: some 82xx platform hook functions can be shared by different boards
From: Mark Zhan @ 2007-07-17 5:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707170259.47098.arnd@arndb.de>
On Tue, 2007-07-17 at 02:59 +0200, Arnd Bergmann wrote:
> On Monday 16 July 2007, Mark Zhan wrote:
>
> > @@ -96,7 +94,7 @@
> > pvid = mfspr(SPRN_PVR);
> > svid = mfspr(SPRN_SVR);
> >
> > - seq_printf(m, "Vendor\t\t: Freescale Semiconductor\n");
> > + seq_printf(m, "Vendor\t\t: %s\n", CPUINFO_VENDOR);
> > seq_printf(m, "Machine\t\t: %s\n", CPUINFO_MACHINE);
> > seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> > seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>
> This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
> comes from a platform specific header file, so you can not
> use these definitions in platform independent code without
> breaking multiplatform kernels.
>
> One possible solution would be a platform specific show_cpuinfo()
> function that calls a generic 82xx version and passes in the
> two values. Even better would be to just dump whatever string
> you find in the /model property in the device tree.
>
OK, Got what you said. I will fix it.
> > +
> > +#define RMR_CSRE 0x00000001
> > +
> > +void mpc82xx_restart(char *cmd)
> > +{
> > + __volatile__ unsigned char dummy;
> > +
> > + local_irq_disable();
> > + ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= RMR_CSRE;
> > +
> > + /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
> > + mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
> > + dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
> > + printk("Restart failed\n");
> > + while (1) ;
> > +}
>
> I know you're just moving that code, but it looks horribly wrong
> nonetheless. cpm2_immr is an __iomem variable, so you must not
> dereference it but instead should use the in_8() macro to
> access it.
>
> Once you get that right, you don't need the volatile variable
> any more.
OK. will fix it.
>
> > +void mpc82xx_halt(void)
> > +{
> > + local_irq_disable();
> > + while (1) ;
> > +}
>
> Here, as in the function above, there should at least be a cpu_relax()
> in the final loop. If the CPU has a nap functionality or something
> similar, that would be even better.
Not sure if mpc82xx has such kind of functionality. Based on the current
definition of cpu_relax(), it is only meaningful for ppc64.
>
> 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