LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
From: Valentine Barshak @ 2007-11-14 12:31 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1195011796.28865.28.camel@pasglop>

Benjamin Herrenschmidt wrote:
> On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote:
>> Hrm.  I *think* I'm convinced this is safe, although acking in a
>> callback which doesn't say it acks is rather yucky.  Essentially this
>> code is trading flow readability (because just reading
>> handle_level_irq will tell you something other than what it does in
>> our case) for smaller code size.  I'm not sure if this is a good trade
>> or not.
>>

It's not just code size. Actually, I was having problems with Ingo's 
real-time patch, that works on all platforms that use generic hard irq 
handlers and doesn't work just on 4xx since we use a custom one here.
And I thought that using generic handlers would be easier to maintain.
I agree that ack'ing in a callback which doesn't say it ack's looks odd, 
but ack'ing level-triggered interrupts is quirky on UIC itself. So, I 
just thought that adding a couple of quirks to mask_ack and unmask 
callbacks was not that bad.

>> There's also one definite problem: according to the discussions I had
>> with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what
>> we want for edge interrupts.
>>
>> Apparently handle_edge_irq is only for edge interrupts on "broken"
>> PICs which won't latch new interrupts while the irq is masked.  UIC is
>> not in this category, so handle_level_irq is actually what we want,
>> even for an edge irq.
>>
>> Yes, I thought the naming was more than a little confusing, too.
> 
> Hrm... handle_edge_irq works for both and you have a small performance
> benefit in not masking, and thus using handle_edge_irq, so I don't
> totally agree here. Basically, what handle_edge_irq() does is lazy
> masking. Now there -is- an issue here is that if you do lazy masking,
> you need to be able to re-emit in some convenient way.

With the ack quirks added we can use handle_level_irq for edge-triggered 
interrupts. I'll test and resubmit the patch.

> 
> Ben.
> 
> 

Thanks,
Valentine.

^ permalink raw reply

* [PATCH] powermac: fix warning in time.c
From: Johannes Berg @ 2007-11-13 18:17 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list

arch/powerpc/platforms/powermac/time.c:88: warning: =E2=80=98to_rtc_time=E2=
=80=99 defined but not used

Somehow this warning has always bothered me. This patch fixes it by
making the relevant code depend on the users.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 arch/powerpc/platforms/powermac/time.c |    2 ++
 1 file changed, 2 insertions(+)

--- linux-2.6-git.orig/arch/powerpc/platforms/powermac/time.c	2007-11-13 19=
:07:32.243563123 +0100
+++ linux-2.6-git/arch/powerpc/platforms/powermac/time.c	2007-11-13 19:08:2=
7.154561404 +0100
@@ -84,12 +84,14 @@ long __init pmac_time_init(void)
 	return delta;
 }
=20
+#if defined(CONFIG_ADB_CUDA) || defined(CONFIG_ADB_PMU)
 static void to_rtc_time(unsigned long now, struct rtc_time *tm)
 {
 	to_tm(now, tm);
 	tm->tm_year -=3D 1900;
 	tm->tm_mon -=3D 1;
 }
+#endif
=20
 static unsigned long from_rtc_time(struct rtc_time *tm)
 {

^ permalink raw reply

* [PATCH] PMU: don't lock_kernel()
From: Johannes Berg @ 2007-11-13 19:07 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list

I see nothing that this lock_kernel() actually protects against
so remove it.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please queue to whatever branch you feel appropriate.

 drivers/macintosh/via-pmu.c |    3 ---
 1 file changed, 3 deletions(-)

--- everything.orig/drivers/macintosh/via-pmu.c	2007-11-13 19:32:01.728726509 +0100
+++ everything/drivers/macintosh/via-pmu.c	2007-11-13 19:32:03.058713543 +0100
@@ -33,7 +33,6 @@
 #include <linux/adb.h>
 #include <linux/pmu.h>
 #include <linux/cuda.h>
-#include <linux/smp_lock.h>
 #include <linux/module.h>
 #include <linux/spinlock.h>
 #include <linux/pm.h>
@@ -2547,7 +2546,6 @@ pmu_release(struct inode *inode, struct 
 	struct pmu_private *pp = file->private_data;
 	unsigned long flags;
 
-	lock_kernel();
 	if (pp != 0) {
 		file->private_data = NULL;
 		spin_lock_irqsave(&all_pvt_lock, flags);
@@ -2561,7 +2559,6 @@ pmu_release(struct inode *inode, struct 
 
 		kfree(pp);
 	}
-	unlock_kernel();
 	return 0;
 }
 

^ permalink raw reply

* [PATCH] PMU: remove dead code
From: Johannes Berg @ 2007-11-13 19:08 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list

Some code in via-pmu.c is never compiled because of "compile options"
within the file. Remove the code completely.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
 drivers/macintosh/via-pmu.c |   42 +-----------------------------------------
 1 file changed, 1 insertion(+), 41 deletions(-)

--- everything.orig/drivers/macintosh/via-pmu.c	2007-11-13 19:32:03.058713543 +0100
+++ everything/drivers/macintosh/via-pmu.c	2007-11-13 19:32:05.968717936 +0100
@@ -64,9 +64,7 @@
 #include "via-pmu-event.h"
 
 /* Some compile options */
-#undef SUSPEND_USES_PMU
 #define DEBUG_SLEEP
-#undef HACKED_PCI_SAVE
 
 /* Misc minor number allocated for /dev/pmu */
 #define PMU_MINOR		154
@@ -1255,9 +1253,7 @@ void
 pmu_suspend(void)
 {
 	unsigned long flags;
-#ifdef SUSPEND_USES_PMU
-	struct adb_request *req;
-#endif
+
 	if (!via)
 		return;
 	
@@ -1275,17 +1271,10 @@ pmu_suspend(void)
 		via_pmu_interrupt(0, NULL);
 		spin_lock_irqsave(&pmu_lock, flags);
 		if (!adb_int_pending && pmu_state == idle && !req_awaiting_reply) {
-#ifdef SUSPEND_USES_PMU
-			pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, 0);
-			spin_unlock_irqrestore(&pmu_lock, flags);
-			while(!req.complete)
-				pmu_poll();
-#else /* SUSPEND_USES_PMU */
 			if (gpio_irq >= 0)
 				disable_irq_nosync(gpio_irq);
 			out_8(&via[IER], CB1_INT | IER_CLR);
 			spin_unlock_irqrestore(&pmu_lock, flags);
-#endif /* SUSPEND_USES_PMU */
 			break;
 		}
 	} while (1);
@@ -1306,18 +1295,11 @@ pmu_resume(void)
 		return;
 	}
 	adb_int_pending = 1;
-#ifdef SUSPEND_USES_PMU
-	pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, pmu_intr_mask);
-	spin_unlock_irqrestore(&pmu_lock, flags);
-	while(!req.complete)
-		pmu_poll();
-#else /* SUSPEND_USES_PMU */
 	if (gpio_irq >= 0)
 		enable_irq(gpio_irq);
 	out_8(&via[IER], CB1_INT | IER_SET);
 	spin_unlock_irqrestore(&pmu_lock, flags);
 	pmu_poll();
-#endif /* SUSPEND_USES_PMU */
 }
 
 /* Interrupt data could be the result data from an ADB cmd */
@@ -1803,14 +1785,10 @@ static void broadcast_wake(void)
  * PCI devices which may get powered off when we sleep.
  */
 static struct pci_save {
-#ifndef HACKED_PCI_SAVE
 	u16	command;
 	u16	cache_lat;
 	u16	intr;
 	u32	rom_address;
-#else
-	u32	config[16];
-#endif	
 } *pbook_pci_saves;
 static int pbook_npci_saves;
 
@@ -1856,16 +1834,10 @@ pbook_pci_save(void)
 			pci_dev_put(pd);
 			return;
 		}
-#ifndef HACKED_PCI_SAVE
 		pci_read_config_word(pd, PCI_COMMAND, &ps->command);
 		pci_read_config_word(pd, PCI_CACHE_LINE_SIZE, &ps->cache_lat);
 		pci_read_config_word(pd, PCI_INTERRUPT_LINE, &ps->intr);
 		pci_read_config_dword(pd, PCI_ROM_ADDRESS, &ps->rom_address);
-#else
-		int i;
-		for (i=1;i<16;i++)
-			pci_read_config_dword(pd, i<<4, &ps->config[i]);
-#endif
 		++ps;
 	}
 }
@@ -1884,17 +1856,6 @@ pbook_pci_restore(void)
 	int j;
 
 	while ((pd = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pd)) != NULL) {
-#ifdef HACKED_PCI_SAVE
-		int i;
-		if (npci-- == 0) {
-			pci_dev_put(pd);
-			return;
-		}
-		ps++;
-		for (i=2;i<16;i++)
-			pci_write_config_dword(pd, i<<4, ps->config[i]);
-		pci_write_config_dword(pd, 4, ps->config[1]);
-#else
 		if (npci-- == 0)
 			return;
 		ps++;
@@ -1918,7 +1879,6 @@ pbook_pci_restore(void)
 			pci_write_config_word(pd, PCI_COMMAND, ps->command);
 			break;
 		}
-#endif	
 	}
 }
 

^ permalink raw reply

* Xilinx EMAC Lite driver
From: Petr Žejdl @ 2007-11-14 12:32 UTC (permalink / raw)
  To: linuxppc-embedded

Hi All,

I'm running vanilla kernel 2.6.23.1 on Memec board (ppc405, ML300
compatible) with ethernet Xilinx EMAC Lite. What I need is the driver
for EMAC Lite. I was looking around without any luck. Do You know any
solution? Or should I write a new one?

Thanks,
Petr

^ permalink raw reply

* [PATCH v2] PMU: replace information ioctls and schedule for removal
From: Johannes Berg @ 2007-11-13 19:11 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list

This patch adds sysfs attributes to the PMU to allow getting
the information on the PMU type and whether adb is present from
there instead of via the ioctl. The ioctl is made optional and
scheduled for removal.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
v2 adds the firmware version to sysfs.

 Documentation/feature-removal-schedule.txt |    8 ++++
 drivers/macintosh/Kconfig                  |   11 ++++++
 drivers/macintosh/via-pmu.c                |   48 +++++++++++++++++++++++++++++
 3 files changed, 67 insertions(+)

--- everything.orig/drivers/macintosh/via-pmu.c	2007-11-13 19:32:37.618723850 +0100
+++ everything/drivers/macintosh/via-pmu.c	2007-11-13 19:35:43.718712837 +0100
@@ -2533,10 +2533,12 @@ pmu_ioctl(struct inode * inode, struct f
 #endif /* CONFIG_INPUT_ADBHID */
 #endif /* CONFIG_PMAC_BACKLIGHT_LEGACY */
 
+#ifdef CONFIG_DEPRECATED_PMU_INFO_IOCTLS
 	case PMU_IOC_GET_MODEL:
 	    	return put_user(pmu_kind, argp);
 	case PMU_IOC_HAS_ADB:
 		return put_user(pmu_has_adb, argp);
+#endif
 	}
 	return error;
 }
@@ -2680,6 +2682,51 @@ static int pmu_sys_resume(struct sys_dev
 
 #endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
 
+static ssize_t show_kind(struct sys_device *sysdev, char *buf)
+{
+	return sprintf(buf, "%d\n", pmu_kind);
+}
+
+static ssize_t show_has_adb(struct sys_device *sysdev, char *buf)
+{
+	return sprintf(buf, "%d\n", pmu_has_adb);
+}
+
+static ssize_t show_pmu_version(struct sys_device *sysdev, char *buf)
+{
+	return sprintf(buf, "%d\n", pmu_version);
+}
+
+static SYSDEV_ATTR(kind, 0444, show_kind, NULL);
+static SYSDEV_ATTR(has_adb, 0444, show_has_adb, NULL);
+static SYSDEV_ATTR(firmware_version, 0444, show_pmu_version, NULL);
+
+int pmu_sys_add(struct sys_device *sysdev)
+{
+	int err;
+
+	err = sysdev_create_file(sysdev, &attr_kind);
+	if (err)
+		goto out;
+
+	err = sysdev_create_file(sysdev, &attr_has_adb);
+	if (err)
+		goto out_remove_kind;
+
+	err = sysdev_create_file(sysdev, &attr_firmware_version);
+	if (err)
+		goto out_remove_adb;
+
+	return 0;
+
+ out_remove_adb:
+	sysdev_remove_file(sysdev, &attr_has_adb);
+ out_remove_kind:
+	sysdev_remove_file(sysdev, &attr_kind);
+ out:
+	return err;
+}
+
 static struct sysdev_class pmu_sysclass = {
 	set_kset_name("pmu"),
 };
@@ -2693,6 +2740,7 @@ static struct sysdev_driver driver_pmu =
 	.suspend	= &pmu_sys_suspend,
 	.resume		= &pmu_sys_resume,
 #endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+	.add		= &pmu_sys_add,
 };
 
 static int __init init_pmu_sysfs(void)
--- everything.orig/Documentation/feature-removal-schedule.txt	2007-11-13 19:31:42.458723687 +0100
+++ everything/Documentation/feature-removal-schedule.txt	2007-11-13 19:32:40.728716851 +0100
@@ -342,3 +342,11 @@ Why:	This driver has been marked obsolet
 Who:	Stephen Hemminger <shemminger@linux-foundation.org>
 
 ---------------------------
+
+What:	/dev/pmu information ioctls
+When:	January 2010
+Files:	drivers/macintosh/via-pmu.c
+Why:	The PMU information can be obtained from sysfs now.
+Who:	Johannes Berg <johannes@sipsolutions.net>
+
+---------------------------
--- everything.orig/drivers/macintosh/Kconfig	2007-11-13 19:31:42.388718641 +0100
+++ everything/drivers/macintosh/Kconfig	2007-11-13 19:32:40.728716851 +0100
@@ -87,6 +87,17 @@ config ADB_PMU
 	  this device; you should do so if your machine is one of those
 	  mentioned above.
 
+config DEPRECATED_PMU_INFO_IOCTLS
+	bool "Support deprecated PMU information ioctl"
+	depends on ADB_PMU
+	default y
+	help
+	  The PMU ioctl supports getting information on the type of PMU and
+	  whether an ADB is present. This information is also available in
+	  sysfs so this ioctl is no longer needed.
+
+	  If in doubt, say Y even if you will not use the ioctl.
+
 config ADB_PMU_LED
 	bool "Support for the Power/iBook front LED"
 	depends on ADB_PMU

^ permalink raw reply

* [PATCH] powermac: proper sleep management
From: Johannes Berg @ 2007-11-13 19:25 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev list, linux-pm

This adds platform_suspend_ops for PMU based machines, directly in
the PMU driver. This finally allows suspending via /sys/power/state
on powerbooks.

The patch also replaces the PMU ioctl with a simple call to
pm_suspend(PM_SUSPEND_MEM) and puts the sleep-related PMU ioctls onto
the feature-removal schedule, to be removed in early 2010 (just
over two years from now).

Additionally, it cleans up some debug code.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
 Documentation/feature-removal-schedule.txt |   10 
 drivers/macintosh/Kconfig                  |   12 
 drivers/macintosh/via-pmu.c                |  462 +++++++++++++----------------
 3 files changed, 241 insertions(+), 243 deletions(-)

--- everything.orig/drivers/macintosh/via-pmu.c	2007-11-13 20:16:51.196263726 +0100
+++ everything/drivers/macintosh/via-pmu.c	2007-11-13 20:24:29.056252331 +0100
@@ -10,13 +10,13 @@
  *
  * Copyright (C) 1998 Paul Mackerras and Fabio Riccardi.
  * Copyright (C) 2001-2002 Benjamin Herrenschmidt
+ * Copyright (C) 2006-2007 Johannes Berg
  *
  * THIS DRIVER IS BECOMING A TOTAL MESS !
  *  - Cleanup atomically disabling reply to PMU events after
  *    a sleep or a freq. switch
- *  - Move sleep code out of here to pmac_pm, merge into new
- *    common PM infrastructure
- *  - Save/Restore PCI space properly
+ *  - check if powerbook 3400 really needs the extra PCI
+ *    save/restore code we have
  *
  */
 #include <stdarg.h>
@@ -64,7 +64,7 @@
 #include "via-pmu-event.h"
 
 /* Some compile options */
-#define DEBUG_SLEEP
+#undef DEBUG_SLEEP
 
 /* Misc minor number allocated for /dev/pmu */
 #define PMU_MINOR		154
@@ -149,12 +149,9 @@ static spinlock_t pmu_lock;
 static u8 pmu_intr_mask;
 static int pmu_version;
 static int drop_interrupts;
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 static int option_lid_wakeup = 1;
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
-#if (defined(CONFIG_PM_SLEEP)&&defined(CONFIG_PPC32))||defined(CONFIG_PMAC_BACKLIGHT_LEGACY)
-static int sleep_in_progress;
-#endif
+#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
 static unsigned long async_req_locks;
 static unsigned int pmu_irq_stats[11];
 
@@ -220,7 +217,7 @@ extern void enable_kernel_fp(void);
 
 #ifdef DEBUG_SLEEP
 int pmu_polled_request(struct adb_request *req);
-int pmu_wink(struct adb_request *req);
+void pmu_blink(int n);
 #endif
 
 /*
@@ -871,7 +868,7 @@ proc_read_options(char *page, char **sta
 {
 	char *p = page;
 
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 	if (pmu_kind == PMU_KEYLARGO_BASED &&
 	    pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
 		p += sprintf(p, "lid_wakeup=%d\n", option_lid_wakeup);
@@ -912,7 +909,7 @@ proc_write_options(struct file *file, co
 	*(val++) = 0;
 	while(*val == ' ')
 		val++;
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 	if (pmu_kind == PMU_KEYLARGO_BASED &&
 	    pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
 		if (!strcmp(label, "lid_wakeup"))
@@ -1718,7 +1715,7 @@ pmu_present(void)
 	return via != 0;
 }
 
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 /*
  * This struct is used to store config register values for
  * PCI devices which may get powered off when we sleep.
@@ -1821,42 +1818,6 @@ pbook_pci_restore(void)
 	}
 }
 
-#ifdef DEBUG_SLEEP
-/* N.B. This doesn't work on the 3400 */
-void 
-pmu_blink(int n)
-{
-	struct adb_request req;
-
-	memset(&req, 0, sizeof(req));
-
-	for (; n > 0; --n) {
-		req.nbytes = 4;
-		req.done = NULL;
-		req.data[0] = 0xee;
-		req.data[1] = 4;
-		req.data[2] = 0;
-		req.data[3] = 1;
-		req.reply[0] = ADB_RET_OK;
-		req.reply_len = 1;
-		req.reply_expected = 0;
-		pmu_polled_request(&req);
-		mdelay(50);
-		req.nbytes = 4;
-		req.done = NULL;
-		req.data[0] = 0xee;
-		req.data[1] = 4;
-		req.data[2] = 0;
-		req.data[3] = 0;
-		req.reply[0] = ADB_RET_OK;
-		req.reply_len = 1;
-		req.reply_expected = 0;
-		pmu_polled_request(&req);
-		mdelay(50);
-	}
-	mdelay(50);
-}
-#endif
 
 /*
  * Put the powerbook to sleep.
@@ -1894,122 +1855,6 @@ restore_via_state(void)
 
 extern void pmu_backlight_set_sleep(int sleep);
 
-static int
-pmac_suspend_devices(void)
-{
-	int ret;
-
-	pm_prepare_console();
-	
-	/* 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
-	 * could be achieved using the refrigerator for processes
-	 * that swsusp uses
-	 */
-	sys_sync();
-
-	/* Send suspend call to devices, hold the device core's dpm_sem */
-	ret = device_suspend(PMSG_SUSPEND);
-	if (ret) {
-		printk(KERN_ERR "Driver sleep failed\n");
-		return -EBUSY;
-	}
-
-#ifdef CONFIG_PMAC_BACKLIGHT
-	/* Tell backlight code not to muck around with the chip anymore */
-	pmu_backlight_set_sleep(1);
-#endif
-
-	/* Call platform functions marked "on sleep" */
-	pmac_pfunc_i2c_suspend();
-	pmac_pfunc_base_suspend();
-
-	/* Stop preemption */
-	preempt_disable();
-
-	/* Make sure the decrementer won't interrupt us */
-	asm volatile("mtdec %0" : : "r" (0x7fffffff));
-	/* Make sure any pending DEC interrupt occurring while we did
-	 * the above didn't re-enable the DEC */
-	mb();
-	asm volatile("mtdec %0" : : "r" (0x7fffffff));
-
-	/* We can now disable MSR_EE. This code of course works properly only
-	 * on UP machines... For SMP, if we ever implement sleep, we'll have to
-	 * stop the "other" CPUs way before we do all that stuff.
-	 */
-	local_irq_disable();
-
-	/* Broadcast power down irq
-	 * This isn't that useful in most cases (only directly wired devices can
-	 * use this but still... This will take care of sysdev's as well, so
-	 * we exit from here with local irqs disabled and PIC off.
-	 */
-	ret = device_power_down(PMSG_SUSPEND);
-	if (ret) {
-		wakeup_decrementer();
-		local_irq_enable();
-		preempt_enable();
-		device_resume();
-		printk(KERN_ERR "Driver powerdown failed\n");
-		return -EBUSY;
-	}
-
-	/* Wait for completion of async requests */
-	while (!batt_req.complete)
-		pmu_poll();
-
-	/* Giveup the lazy FPU & vec so we don't have to back them
-	 * up from the low level code
-	 */
-	enable_kernel_fp();
-
-#ifdef CONFIG_ALTIVEC
-	if (cpu_has_feature(CPU_FTR_ALTIVEC))
-		enable_kernel_altivec();
-#endif /* CONFIG_ALTIVEC */
-
-	return 0;
-}
-
-static int
-pmac_wakeup_devices(void)
-{
-	mdelay(100);
-
-#ifdef CONFIG_PMAC_BACKLIGHT
-	/* Tell backlight code it can use the chip again */
-	pmu_backlight_set_sleep(0);
-#endif
-
-	/* Power back up system devices (including the PIC) */
-	device_power_up();
-
-	/* Force a poll of ADB interrupts */
-	adb_int_pending = 1;
-	via_pmu_interrupt(0, NULL);
-
-	/* Restart jiffies & scheduling */
-	wakeup_decrementer();
-
-	/* Re-enable local CPU interrupts */
-	local_irq_enable();
-	mdelay(10);
-	preempt_enable();
-
-	/* Call platform functions marked "on wake" */
-	pmac_pfunc_base_resume();
-	pmac_pfunc_i2c_resume();
-
-	/* Resume devices */
-	device_resume();
-
-	pm_restore_console();
-
-	return 0;
-}
-
 #define	GRACKLE_PM	(1<<7)
 #define GRACKLE_DOZE	(1<<5)
 #define	GRACKLE_NAP	(1<<4)
@@ -2020,19 +1865,12 @@ static int powerbook_sleep_grackle(void)
 	unsigned long save_l2cr;
 	unsigned short pmcr1;
 	struct adb_request req;
-	int ret;
 	struct pci_dev *grackle;
 
 	grackle = pci_get_bus_and_slot(0, 0);
 	if (!grackle)
 		return -ENODEV;
 
-	ret = pmac_suspend_devices();
-	if (ret) {
-		printk(KERN_ERR "Sleep rejected by devices\n");
-		return ret;
-	}
-	
 	/* Turn off various things. Darwin does some retry tests here... */
 	pmu_request(&req, NULL, 2, PMU_POWER_CTRL0, PMU_POW0_OFF|PMU_POW0_HARD_DRIVE);
 	pmu_wait_complete(&req);
@@ -2095,8 +1933,6 @@ static int powerbook_sleep_grackle(void)
 			PMU_POW_ON|PMU_POW_BACKLIGHT|PMU_POW_CHARGER|PMU_POW_IRLED|PMU_POW_MEDIABAY);
 	pmu_wait_complete(&req);
 
-	pmac_wakeup_devices();
-
 	return 0;
 }
 
@@ -2106,7 +1942,6 @@ powerbook_sleep_Core99(void)
 	unsigned long save_l2cr;
 	unsigned long save_l3cr;
 	struct adb_request req;
-	int ret;
 	
 	if (pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) < 0) {
 		printk(KERN_ERR "Sleep mode not supported on this machine\n");
@@ -2116,12 +1951,6 @@ powerbook_sleep_Core99(void)
 	if (num_online_cpus() > 1 || cpu_is_offline(0))
 		return -EAGAIN;
 
-	ret = pmac_suspend_devices();
-	if (ret) {
-		printk(KERN_ERR "Sleep rejected by devices\n");
-		return ret;
-	}
-
 	/* Stop environment and ADB interrupts */
 	pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, 0);
 	pmu_wait_complete(&req);
@@ -2192,41 +2021,24 @@ powerbook_sleep_Core99(void)
 	/* Restore LPJ, cpufreq will adjust the cpu frequency */
 	loops_per_jiffy /= 2;
 
-	pmac_wakeup_devices();
-
 	return 0;
 }
 
 #define PB3400_MEM_CTRL		0xf8000000
 #define PB3400_MEM_CTRL_SLEEP	0x70
 
+static void __iomem *pb3400_mem_ctrl;
+
 static int
 powerbook_sleep_3400(void)
 {
-	int ret, i, x;
+	int i, x;
 	unsigned int hid0;
 	unsigned long p;
 	struct adb_request sleep_req;
-	void __iomem *mem_ctrl;
 	unsigned int __iomem *mem_ctrl_sleep;
 
-	/* first map in the memory controller registers */
-	mem_ctrl = ioremap(PB3400_MEM_CTRL, 0x100);
-	if (mem_ctrl == NULL) {
-		printk("powerbook_sleep_3400: ioremap failed\n");
-		return -ENOMEM;
-	}
-	mem_ctrl_sleep = mem_ctrl + PB3400_MEM_CTRL_SLEEP;
-
-	/* Allocate room for PCI save */
-	pbook_alloc_pci_save();
-
-	ret = pmac_suspend_devices();
-	if (ret) {
-		pbook_free_pci_save();
-		printk(KERN_ERR "Sleep rejected by devices\n");
-		return ret;
-	}
+	mem_ctrl_sleep = pb3400_mem_ctrl + PB3400_MEM_CTRL_SLEEP;
 
 	/* Save the state of PCI config space for some slots */
 	pbook_pci_save();
@@ -2271,14 +2083,10 @@ powerbook_sleep_3400(void)
 	while (asleep)
 		mb();
 
-	pmac_wakeup_devices();
-	pbook_free_pci_save();
-	iounmap(mem_ctrl);
-
 	return 0;
 }
 
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
 
 /*
  * Support for /dev/pmu device
@@ -2451,6 +2259,157 @@ pmu_release(struct inode *inode, struct 
 	return 0;
 }
 
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
+static int powerbook_prepare_sleep(void)
+{
+	if (pmu_kind == PMU_OHARE_BASED) {
+		/* first map in the memory controller registers */
+		pb3400_mem_ctrl = ioremap(PB3400_MEM_CTRL, 0x100);
+		if (!pb3400_mem_ctrl) {
+			printk(KERN_ERR "powerbook_sleep_3400: "
+			       "ioremap failed\n");
+			return -ENOMEM;
+		}
+
+		/* Allocate room for PCI save */
+		pbook_alloc_pci_save();
+	}
+
+	return 0;
+}
+
+/*
+ * overrides the weak arch_suspend_disable_irqs in kernel/power/main.c
+ *
+ * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
+ *	hooks that patch adds!
+ */
+void arch_suspend_disable_irqs(void)
+{
+#ifdef CONFIG_PMAC_BACKLIGHT
+	/* Tell backlight code not to muck around with the chip anymore */
+	pmu_backlight_set_sleep(1);
+#endif
+
+	/* Call platform functions marked "on sleep" */
+	pmac_pfunc_i2c_suspend();
+	pmac_pfunc_base_suspend();
+
+	/* Stop preemption */
+	preempt_disable();
+
+	/* Make sure the decrementer won't interrupt us */
+	asm volatile("mtdec %0" : : "r" (0x7fffffff));
+	/* Make sure any pending DEC interrupt occurring while we did
+	 * the above didn't re-enable the DEC */
+	mb();
+	asm volatile("mtdec %0" : : "r" (0x7fffffff));
+
+	local_irq_disable();
+}
+
+static int powerbook_sleep(suspend_state_t state)
+{
+	int error = 0;
+
+	/* Wait for completion of async requests */
+	while (!batt_req.complete)
+		pmu_poll();
+
+	/* Giveup the lazy FPU & vec so we don't have to back them
+	 * up from the low level code
+	 */
+	enable_kernel_fp();
+
+#ifdef CONFIG_ALTIVEC
+	if (cpu_has_feature(CPU_FTR_ALTIVEC))
+		enable_kernel_altivec();
+#endif /* CONFIG_ALTIVEC */
+
+	switch (pmu_kind) {
+	case PMU_OHARE_BASED:
+		error = powerbook_sleep_3400();
+		break;
+	case PMU_HEATHROW_BASED:
+	case PMU_PADDINGTON_BASED:
+		error = powerbook_sleep_grackle();
+		break;
+	case PMU_KEYLARGO_BASED:
+		error = powerbook_sleep_Core99();
+		break;
+	default:
+		return -ENOSYS;
+	}
+
+	if (error)
+		return error;
+
+	mdelay(100);
+
+#ifdef CONFIG_PMAC_BACKLIGHT
+	/* Tell backlight code it can use the chip again */
+	pmu_backlight_set_sleep(0);
+#endif
+
+	return 0;
+}
+
+/*
+ * overrides the weak arch_suspend_enable_irqs in kernel/power/main.c
+ *
+ * XXX: Once Scott Wood's patch is merged, this needs to use the ppc_md
+ *	hooks that patch adds!
+ */
+void arch_suspend_enable_irqs(void)
+{
+	/* Force a poll of ADB interrupts */
+	adb_int_pending = 1;
+	via_pmu_interrupt(0, NULL);
+
+	/* Restart jiffies & scheduling */
+	wakeup_decrementer();
+
+	/* Re-enable local CPU interrupts */
+	local_irq_enable();
+	mdelay(10);
+	preempt_enable();
+
+	/* Call platform functions marked "on wake" */
+	pmac_pfunc_base_resume();
+	pmac_pfunc_i2c_resume();
+}
+
+static void powerbook_finish_sleep(void)
+{
+	if (pmu_kind == PMU_OHARE_BASED) {
+		pbook_free_pci_save();
+		iounmap(pb3400_mem_ctrl);
+	}
+}
+
+static int pmu_sleep_valid(suspend_state_t state)
+{
+	return state == PM_SUSPEND_MEM
+		&& (pmac_call_feature(PMAC_FTR_SLEEP_STATE, NULL, 0, -1) >= 0);
+}
+
+static struct platform_suspend_ops pmu_pm_ops = {
+	.prepare = powerbook_prepare_sleep,
+	.enter = powerbook_sleep,
+	.finish = powerbook_finish_sleep,
+	.valid = pmu_sleep_valid,
+};
+
+static int register_pmu_pm_ops(void)
+{
+	suspend_set_ops(&pmu_pm_ops);
+
+	return 0;
+}
+
+device_initcall(register_pmu_pm_ops);
+#endif
+
 static int
 pmu_ioctl(struct inode * inode, struct file *filp,
 		     u_int cmd, u_long arg)
@@ -2459,35 +2418,30 @@ pmu_ioctl(struct inode * inode, struct f
 	int error = -EINVAL;
 
 	switch (cmd) {
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_DEPRECATED_PMU_SLEEP_IOCTL)
 	case PMU_IOC_SLEEP:
 		if (!capable(CAP_SYS_ADMIN))
 			return -EACCES;
-		if (sleep_in_progress)
-			return -EBUSY;
-		sleep_in_progress = 1;
-		switch (pmu_kind) {
-		case PMU_OHARE_BASED:
-			error = powerbook_sleep_3400();
-			break;
-		case PMU_HEATHROW_BASED:
-		case PMU_PADDINGTON_BASED:
-			error = powerbook_sleep_grackle();
-			break;
-		case PMU_KEYLARGO_BASED:
-			error = powerbook_sleep_Core99();
-			break;
-		default:
-			error = -ENOSYS;
-		}
-		sleep_in_progress = 0;
+		printk(KERN_INFO
+		       "via-pmu: the PMU_IOC_SLEEP ioctl is deprecated.\n");
+		printk(KERN_INFO "via-pmu: use \"echo mem >"
+		       " /sys/power/state\"  instead!\n");
+		printk(KERN_INFO
+		       "via-pmu: this ioctl will be removed soon.\n");
+		error = pm_suspend(PM_SUSPEND_MEM);
 		break;
 	case PMU_IOC_CAN_SLEEP:
+		printk(KERN_INFO
+		       "via-pmu: the PMU_IOC_CAN_SLEEP ioctl is deprecated.\n");
+		printk(KERN_INFO
+		       "via-pmu: use \"grep mem /sys/power/state\" instead!\n");
+		printk(KERN_INFO
+		       "via-pmu: this ioctl will be removed soon.\n");
 		if (pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) < 0)
 			return put_user(0, argp);
 		else
 			return put_user(1, argp);
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+#endif /* CONFIG_DEPRECATED_PMU_SLEEP_IOCTL */
 
 #ifdef CONFIG_PMAC_BACKLIGHT_LEGACY
 	/* Compatibility ioctl's for backlight */
@@ -2495,9 +2449,6 @@ pmu_ioctl(struct inode * inode, struct f
 	{
 		int brightness;
 
-		if (sleep_in_progress)
-			return -EBUSY;
-
 		brightness = pmac_backlight_get_legacy_brightness();
 		if (brightness < 0)
 			return brightness;
@@ -2509,9 +2460,6 @@ pmu_ioctl(struct inode * inode, struct f
 	{
 		int brightness;
 
-		if (sleep_in_progress)
-			return -EBUSY;
-
 		error = get_user(brightness, argp);
 		if (error)
 			return error;
@@ -2638,15 +2586,43 @@ pmu_polled_request(struct adb_request *r
 	local_irq_restore(flags);
 	return 0;
 }
-#endif /* DEBUG_SLEEP */
 
+/* N.B. This doesn't work on the 3400 */
+void pmu_blink(int n)
+{
+	struct adb_request req;
 
-/* FIXME: This is a temporary set of callbacks to enable us
- * to do suspend-to-disk.
- */
+	memset(&req, 0, sizeof(req));
 
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+	for (; n > 0; --n) {
+		req.nbytes = 4;
+		req.done = NULL;
+		req.data[0] = 0xee;
+		req.data[1] = 4;
+		req.data[2] = 0;
+		req.data[3] = 1;
+		req.reply[0] = ADB_RET_OK;
+		req.reply_len = 1;
+		req.reply_expected = 0;
+		pmu_polled_request(&req);
+		mdelay(50);
+		req.nbytes = 4;
+		req.done = NULL;
+		req.data[0] = 0xee;
+		req.data[1] = 4;
+		req.data[2] = 0;
+		req.data[3] = 0;
+		req.reply[0] = ADB_RET_OK;
+		req.reply_len = 1;
+		req.reply_expected = 0;
+		pmu_polled_request(&req);
+		mdelay(50);
+	}
+	mdelay(50);
+}
+#endif /* DEBUG_SLEEP */
 
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 int pmu_sys_suspended;
 
 static int pmu_sys_suspend(struct sys_device *sysdev, pm_message_t state)
@@ -2680,7 +2656,7 @@ static int pmu_sys_resume(struct sys_dev
 	return 0;
 }
 
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
 
 static ssize_t show_kind(struct sys_device *sysdev, char *buf)
 {
@@ -2736,10 +2712,10 @@ static struct sys_device device_pmu = {
 };
 
 static struct sysdev_driver driver_pmu = {
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 	.suspend	= &pmu_sys_suspend,
 	.resume		= &pmu_sys_resume,
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
 	.add		= &pmu_sys_add,
 };
 
@@ -2775,10 +2751,10 @@ EXPORT_SYMBOL(pmu_wait_complete);
 EXPORT_SYMBOL(pmu_suspend);
 EXPORT_SYMBOL(pmu_resume);
 EXPORT_SYMBOL(pmu_unlock);
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
 EXPORT_SYMBOL(pmu_enable_irled);
 EXPORT_SYMBOL(pmu_battery_count);
 EXPORT_SYMBOL(pmu_batteries);
 EXPORT_SYMBOL(pmu_power_flags);
-#endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
+#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
 
--- everything.orig/Documentation/feature-removal-schedule.txt	2007-11-13 20:16:51.276261773 +0100
+++ everything/Documentation/feature-removal-schedule.txt	2007-11-13 20:17:08.966262261 +0100
@@ -350,3 +350,13 @@ Why:	The PMU information can be obtained
 Who:	Johannes Berg <johannes@sipsolutions.net>
 
 ---------------------------
+
+What:	/dev/pmu suspend/can-suspend ioctls
+When:	January 2010
+Files:	drivers/macintosh/via-pmu.c
+Why:	powermac supports proper generic pm_ops now and can suspend with
+	"echo mem > /sys/power/state" instead of the ioctl, checking if
+	it can suspend can be done by reading /sys/power/state.
+Who:	Johannes Berg <johannes@sipsolutions.net>
+
+---------------------------
--- everything.orig/drivers/macintosh/Kconfig	2007-11-13 20:16:51.226265462 +0100
+++ everything/drivers/macintosh/Kconfig	2007-11-13 20:17:08.966262261 +0100
@@ -98,6 +98,18 @@ config DEPRECATED_PMU_INFO_IOCTLS
 
 	  If in doubt, say Y even if you will not use the ioctl.
 
+config DEPRECATED_PMU_SLEEP_IOCTL
+	bool "Support deprecated PMU sleep ioctl"
+	depends on ADB_PMU && SUSPEND && PPC32
+	default y
+	help
+	  The PMU code used to support suspending the machine via an ioctl
+	  before Linux had a generic suspend framework. Now the PMU supports
+	  suspending via the generic framework, this option adds the old
+	  PMU specific ioctl to the kernel.
+
+	  If in doubt, say Y even if you will not use the ioctl.
+
 config ADB_PMU_LED
 	bool "Support for the Power/iBook front LED"
 	depends on ADB_PMU

^ permalink raw reply

* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: Lorenz Kolb @ 2007-11-14 13:10 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <13743302.post@talk.nabble.com>




alex_snippet wrote:
> 
> Hi all!
> 
> I'm porting Linux for custom board based on Virtex4 FX, vanilla kernel
> 2.6.22.5 , Xilinx EDK 9.1 BSP, 
> ELDK41 - cross-compiler 
> target nfs-root pointed to ELDK41/ppc_4xx
> 
> Kernel command line:
> Linux/PPC load: root=/dev/nfs rw console=ttyS0,9600
> nfsroot=192.168.0.1:/target
> ip=on
> 
> All work successfully was done, i tested all at 100Mb's connection speed,
> but yesterday my customer said that with 1Gbit connection it did't work :(
> end of log following:
> 
>     3.341532] eth0: XTemac: Options: 0xb8f2
> [   11.855386] eth0: XTemac: We renegotiated the speed to: 1000
> [   11.923237] eth0: XTemac: speed set to 1000Mb/s
> [   13.000064] Sending DHCP requests ......, OK
> [   65.484075] IP-Config: Got DHCP answer from 0.0.0.0, my address is
> 192.168.0.
> 192
> [   65.573684] IP-Config: Complete:
> [   65.610416]       device=eth0, addr=192.168.0.192, mask=255.255.255.0,
> gw=192
> .168.0.1,
> [   65.705572]      host=192.168.0.192, domain=, nis-domain=(none),
> [   65.777872]      bootserver=0.0.0.0, rootserver=192.168.0.1, rootpath=
> [   65.861982] Looking up port of RPC 100003/2 on 192.168.0.1
> [   65.929093] Looking up port of RPC 100005/1 on 192.168.0.1
> [   66.024134] VFS: Mounted root (nfs filesystem).
> [   66.079160] Freeing unused kernel memory: 104k init
> [   71.640314] nfs: server 192.168.0.1 not responding, still trying
> [   76.040311] nfs: server 192.168.0.1 not responding, still trying
> 
> Load process was friezed at this point. When connection speed is 100Mb/s
> everything is ok.
> 
> Please advise me what to do, i tried to increase ppc core frequency from
> 100 to 300 MHz - the same problem. 
> When i'm using virtual machine instead of real hardware it's working on
> 1000Gb/s :) but isn't on real hardware.
> 

We have it working for our ML403. But we are not using the builtin-support
from the kernel.
We are using an initrd/initramfs for mounting the NFS (as this is much
easier for debugging (you can get a shell)).


alex_snippet wrote:
> 
> I'm using Fedora 7 as a host.
> 

We had problems with ubuntu as a host. Debian (Kernel 2.6.18) works fine for
us.


alex_snippet wrote:
> 
> May be there are some nfs-demon settings?
> 

we use

tcp,no_lock

here.

Regards,

Lorenz Kolb
ESIC-Solutions
-- 
View this message in context: http://www.nabble.com/Virtex-TEMAC-1000Mb-s-trouble%2C-but-100b-s-is-working-tf4803823.html#a13746324
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* [PATCH v2] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-14 13:41 UTC (permalink / raw)
  To: linuxppc-dev, netdev, jgarzik

The patch updates the booting-without-of.txt-file.
There is a description for the case
if mdio data and clock pins are on different processor ports.
It extends the "[PATCH v3] using mii-bitbang on different processor ports".

Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
Signed-off-by: Scott Wood <scottwood@freescale.com>
--

diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 497d8d8..084d31b 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1936,11 +1936,15 @@ platforms are moved over to use the flattened-device-tree model.
 
    Currently defined compatibles:
    fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
-   fsl,cpm2-mdio-bitbang (reg is port C registers)
+   fsl,cpm2-mdio-bitbang
 
    Properties for fsl,cpm2-mdio-bitbang:
-   fsl,mdio-pin : pin of port C controlling mdio data
-   fsl,mdc-pin : pin of port C controlling mdio clock
+   The first reg resource is the I/O port register block on which MDIO
+   resides.  The second reg resource is the I/O port register block on
+   which MDC resides.  If there is only one reg resource, it is used for
+   both MDIO and MDC.
+   fsl,mdio-pin : pin of chosen port for controlling mdio data
+   fsl,mdc-pin : pin of chosen port for controlling mdio clock
 
    Example:

^ permalink raw reply related

* [PATCH 2/2] PowerPC: make 4xx uic use generic level irq handler
From: Valentine Barshak @ 2007-11-14 14:00 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <473AEA91.8090109@ru.mvista.com>

This patch makes PowerPC 4xx UIC use generic level irq handler instead
of a custom handle_uic_irq() function. We ack only edge irqs in mask_ack
callback, since acking a level irq on UIC has no effect if the interrupt
is still asserted by the device, even if the interrupt is already masked.
So, to really de-assert the interrupt we need to de-assert the external
source first *and* ack it on UIC then. The handle_level_irq() function
masks and ack's the interrupt with mask_ack callback prior to calling
the actual ISR and unmasks it at the end. So, to use it with UIC interrupts
we need to ack level irqs in the unmask callback instead, after the ISR
has de-asserted the external interrupt source. Even if we ack the interrupt
that we didn't handle (unmask/ack it at the end of the handler, while
next irq is already pending) it will not de-assert the irq, untill we
de-assert its exteral source.

Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
 arch/powerpc/sysdev/uic.c |   81 ++++++++++------------------------------------
 1 files changed, 19 insertions(+), 62 deletions(-)

--- linux-2.6.orig/arch/powerpc/sysdev/uic.c	2007-11-14 15:57:37.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/uic.c	2007-11-14 15:59:18.000000000 +0300
@@ -60,14 +60,19 @@ struct uic {
 
 static void uic_unmask_irq(unsigned int virq)
 {
+	struct irq_desc *desc = get_irq_desc(virq);
 	struct uic *uic = get_irq_chip_data(virq);
 	unsigned int src = uic_irq_to_hw(virq);
 	unsigned long flags;
-	u32 er;
+	u32 er, sr;
 
+	sr = 1 << (31-src);
 	spin_lock_irqsave(&uic->lock, flags);
+	/* ack level-triggered interrupts here */
+	if (desc->status & IRQ_LEVEL)
+		mtdcr(uic->dcrbase + UIC_SR, sr);
 	er = mfdcr(uic->dcrbase + UIC_ER);
-	er |= 1 << (31 - src);
+	er |= sr;
 	mtdcr(uic->dcrbase + UIC_ER, er);
 	spin_unlock_irqrestore(&uic->lock, flags);
 }
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
 
 static void uic_mask_ack_irq(unsigned int virq)
 {
+	struct irq_desc *desc = get_irq_desc(virq);
 	struct uic *uic = get_irq_chip_data(virq);
 	unsigned int src = uic_irq_to_hw(virq);
 	unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
 	er = mfdcr(uic->dcrbase + UIC_ER);
 	er &= ~sr;
 	mtdcr(uic->dcrbase + UIC_ER, er);
-	mtdcr(uic->dcrbase + UIC_SR, sr);
+ 	/* On the UIC, acking (i.e. clearing the SR bit)
+	 * a level irq will have no effect if the interrupt
+	 * is still asserted by the device, even if
+	 * the interrupt is already masked. Therefore
+	 * we only ack the egde interrupts here, while
+	 * level interrupts are ack'ed after the actual
+	 * isr call in the uic_unmask_irq()
+	 */
+	if (!(desc->status & IRQ_LEVEL))
+		mtdcr(uic->dcrbase + UIC_SR, sr);
 	spin_unlock_irqrestore(&uic->lock, flags);
 }
 
@@ -173,64 +188,6 @@ static struct irq_chip uic_irq_chip = {
 	.set_type	= uic_set_irq_type,
 };
 
-/**
- *	handle_uic_irq - irq flow handler for UIC
- *	@irq:	the interrupt number
- *	@desc:	the interrupt description structure for this irq
- *
- * This is modified version of the generic handle_level_irq() suitable
- * for the UIC.  On the UIC, acking (i.e. clearing the SR bit) a level
- * irq will have no effect if the interrupt is still asserted by the
- * device, even if the interrupt is already masked.  Therefore, unlike
- * the standard handle_level_irq(), we must ack the interrupt *after*
- * invoking the ISR (which should have de-asserted the interrupt in
- * the external source).  For edge interrupts we ack at the beginning
- * instead of the end, to keep the window in which we can miss an
- * interrupt as small as possible.
- */
-void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
-{
-	unsigned int cpu = smp_processor_id();
-	struct irqaction *action;
-	irqreturn_t action_ret;
-
-	spin_lock(&desc->lock);
-	if (desc->status & IRQ_LEVEL)
-		desc->chip->mask(irq);
-	else
-		desc->chip->mask_ack(irq);
-
-	if (unlikely(desc->status & IRQ_INPROGRESS))
-		goto out_unlock;
-	desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
-	kstat_cpu(cpu).irqs[irq]++;
-
-	/*
-	 * If its disabled or no action available
-	 * keep it masked and get out of here
-	 */
-	action = desc->action;
-	if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
-		desc->status |= IRQ_PENDING;
-		goto out_unlock;
-	}
-
-	desc->status |= IRQ_INPROGRESS;
-	desc->status &= ~IRQ_PENDING;
-	spin_unlock(&desc->lock);
-
-	action_ret = handle_IRQ_event(irq, action);
-
-	spin_lock(&desc->lock);
-	desc->status &= ~IRQ_INPROGRESS;
-	if (desc->status & IRQ_LEVEL)
-		desc->chip->ack(irq);
-	if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
-		desc->chip->unmask(irq);
-out_unlock:
-	spin_unlock(&desc->lock);
-}
-
 static int uic_host_map(struct irq_host *h, unsigned int virq,
 			irq_hw_number_t hw)
 {
@@ -239,7 +196,7 @@ static int uic_host_map(struct irq_host 
 	set_irq_chip_data(virq, uic);
 	/* Despite the name, handle_level_irq() works for both level
 	 * and edge irqs on UIC.  FIXME: check this is correct */
-	set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
+	set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
 
 	/* Set default irq type */
 	set_irq_type(virq, IRQ_TYPE_NONE);

^ permalink raw reply

* DMA interrupt is not generating in MPC8641D
From: sivaji @ 2007-11-14 14:32 UTC (permalink / raw)
  To: linuxppc-dev


Hai,

We have designed a MPC8641D based AMC card. As part of our customer
requirement for a PCIe messaging driver for communicating between the
MPC8641D AMC card as the PCIe target and the MPC8548E AMC card as the Host.

We are using the DMA for transferring data between the boards thru' PCIe.
The DMA Interrupt on the target end is not getting registered and hence we
face the issue (ie) No interrupt is generated after DMA transfer completion.

As per datasheet(Rev. 1, 05/2007) page no:445 interrupt number for
DMAchannel 1 is 4. We are using linux kernel version :2.6.23-rc3. According
to file (include/asm-powerpc/irq.h) line no:636 the interrupt number for DMA
in linux is 20(decimal). When using this interrupt number 20 we are not able
to registerd the DMA interrupts.

Note:
1. Linux is configured in SMP mode.
2. Value of Device status register(0xf80E000C)  : 0x0aa28747 


Thanks and Regards
Sivaji

-- 
View this message in context: http://www.nabble.com/DMA-interrupt-is-not-generating-in-MPC8641D-tf4805310.html#a13747460
Sent from the linuxppc-dev mailing list archive at Nabble.com.

^ permalink raw reply

* about uImage-DENX-v2.6.14 config
From: zhangwei zhang @ 2007-11-14 15:06 UTC (permalink / raw)
  To: info, linuxppc-embedded, linuxppc-dev

Hello, I have a problem when using linux-2.6.14(download from
ftp.denx.de) for RTAI on ppc440EP. I use the ELDK4.1 and when boot the
uImage I compiled , I always have the problem as following:

## Booting image at 00500000 ...
   Image Name:   Linux-2.6.14
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    1155686 Bytes =  1.1 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK

then it stopped . I am afraid that maybe the problem comes from the
config. I have ever use the uImage-DENX-v2.6.14 you offered in
ftp.denx.de/pub/linux/amcc/image/yosemite/ and it works. So can you
send me a config file for 2.6.14 to me? Thank you.

Best wishes
kyla

^ permalink raw reply

* Re: 2.6.24-rc1 freezes on powerbook at first boot stage
From: Johannes Berg @ 2007-11-14 15:26 UTC (permalink / raw)
  To: Elimar Riesebieter
  Cc: linux-wireless, linuxppc-dev, Nathan Lynch,
	Linux Kernel Mailing List, linux-usb-devel
In-Reply-To: <20071113220235.GB9008@frodo.home.lxtec.de>

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]


[FWIW, my powerbook worked with -rc1]

> 2.6.24-rc2 works so lala :)

> b43 doesn't authenticate via wpa (bluetooth isn't loaded):
> WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported
> WEXT auth param 5 value 0x1 - Internet Systems Consortium DHCP Client V3.1.0

Those error messages are unrelated. My b43 works fine, even with a
multi-MAC patch.

> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> sysctl table check failed: /kernel .1 Writable sysctl directory
> Call Trace:
> [c1061e60] [c0008b28] show_stack+0x4c/0x1ac (unreliable)
> [c1061ea0] [c0047354] set_fail+0x50/0x68
> [c1061ec0] [c0047784] sysctl_check_table+0x418/0x714
> [c1061f30] [c00335b8] register_sysctl_table+0x64/0xb4
> [c1061f50] [c033fd5c] register_powersave_nap_sysctl+0x18/0x2c
> [c1061f60] [c03391e4] kernel_init+0xc0/0x2a0
> [c1061ff0] [c0011a58] kernel_thread+0x44/0x60

This has been fixed.

> There is a lot to do, but it seems to be a big, big code change in
> that version. This impressed me by looking at the git changes and
> the size of patches. And the rc's don't seem to be frozend versions.
> A lot of new code comes in....
> Let me know whether a complete dmesg is needed.

What is the problem? Why is this on wireless? It'd help if you'd make
one message per problem and post it to the correct mailing lists.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply

* Re: I2C on mpc8248 / device tree
From: Alan Bennett @ 2007-11-14 15:31 UTC (permalink / raw)
  To: Jon Smirl; +Cc: linuxppc-dev
In-Reply-To: <9e4733910711131556r23a38780q39baf15d85c0bd85@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Does this patch support the cpm2 as well?

I get conflicting thoughts looking over the latest postings.

-Alan


On 11/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> I am working on a patch for i2c and device tree. I attached the current
> version.
>
> DTC entry looks like this.
>
>                 i2c@3d40 {
>                         compatible =
> "mpc5200b-i2c","mpc5200-i2c","fsl-i2c";
>                         reg = <3d40 40>;
>                         interrupts = <2 10 0>;
>                         interrupt-parent = <&mpc5200_pic>;
>                         fsl5200-clocking;
>
>                         rtc@51f {
>                                 compatible = "epson,rtc8564";
>                                 reg = <51>;
>                         };
>                 };
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
>

[-- Attachment #2: Type: text/html, Size: 2581 bytes --]

^ permalink raw reply

* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: alex_snippet @ 2007-11-14 15:44 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <13746324.post@talk.nabble.com>


Hi All

Thanks a lot

Trouble solved by adding tcp,no_lock !!!

Regards, Alex
-- 
View this message in context: http://www.nabble.com/Virtex-TEMAC-1000Mb-s-trouble%2C-but-100b-s-is-working-tf4803823.html#a13749163
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

^ permalink raw reply

* Re: Xilinx EMAC Lite driver
From: Wolfgang Reissnegger @ 2007-11-14 16:06 UTC (permalink / raw)
  To: Petr Z(ejdl; +Cc: linuxppc-embedded
In-Reply-To: <473AEADC.9030603@fel.cvut.cz>

Hi Petr,

you can clone the Xilinx Linux git tree at:
 
   git://git.xilinx.com/linux-2.6-xlnx.git

The lin26-xlnx branch in the repository is based on 2.6.23 and contains support for the EMACLITE.

Hope this helps,
     Wolfgang

Petr Z(ejdl wrote:
> Hi All,
> 
> I'm running vanilla kernel 2.6.23.1 on Memec board (ppc405, ML300
> compatible) with ethernet Xilinx EMAC Lite. What I need is the driver
> for EMAC Lite. I was looking around without any luck. Do You know any
> solution? Or should I write a new one?
> 
> Thanks,
> Petr
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply

* Re: I2C on mpc8248 / device tree
From: Kumar Gala @ 2007-11-14 16:20 UTC (permalink / raw)
  To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711140731n20ccd8bdme2de6302848f5a4f@mail.gmail.com>

The patch is orthogonal to your issue.

There is NOT a driver in the kernel tree for the i2c on CPM2 based  
parts like the 8248 (from what I can tell).

- k

On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:

> Does this patch support the cpm2 as well?
>
> I get conflicting thoughts looking over the latest postings.
>
> -Alan
>
>
> On 11/13/07, Jon Smirl < jonsmirl@gmail.com> wrote:I am working on  
> a patch for i2c and device tree. I attached the current version.
>
> DTC entry looks like this.
>
>                 i2c@3d40 {
>                         compatible = "mpc5200b-i2c","mpc5200- 
> i2c","fsl-i2c";
>                         reg = <3d40 40>;
>                         interrupts = <2 10 0>;
>                         interrupt-parent = <&mpc5200_pic>;
>                         fsl5200-clocking;
>
>                         rtc@51f {
>                                 compatible = "epson,rtc8564";
>                                 reg = <51>;
>                         };
>                 };
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: g.schardt @ 2007-11-14 16:36 UTC (permalink / raw)
  To: alex_snippet; +Cc: linuxppc-embedded

can you tell me, how to add this parameters to the kernel boot parameter ? or do you mount after booting ?

G



----- Original Message -----
From: alex_snippet <alex.snippet@gmail.com>
Date: Wednesday, November 14, 2007 4:44 pm
Subject: Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working

> 
> Hi All
> 
> Thanks a lot
> 
> Trouble solved by adding tcp,no_lock !!!
> 
> Regards, Alex
> -- 
> View this message in context: http://www.nabble.com/Virtex-TEMAC-
> 1000Mb-s-trouble%2C-but-100b-s-is-working-tf4803823.html#a13749163
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 



-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------

^ permalink raw reply

* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: g.schardt @ 2007-11-14 17:01 UTC (permalink / raw)
  To: jozsef imrek; +Cc: linuxppc-embedded

argl, i read the nfsroot.txt but imho i am a little bit blind :)

thanks
G

----- Original Message -----
From: jozsef imrek <imrek@atomki.hu>
Date: Wednesday, November 14, 2007 6:00 pm
Subject: Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working

> On Wed, 14 Nov 2007 g.schardt@fz-juelich.de wrote:
> 
> >>
> >> Trouble solved by adding tcp,no_lock !!!
> >>
> >
> > can you tell me, how to add this parameters to the kernel boot 
> parameter ? or do you mount after booting ?
> >
> 
> if you are using a bootloader see Documentation/nfsroot.txt in the 
> linuxsource tree (a quick example: 
> nfsroot=192.168.0.1:/nfsroot,tcp,no_lock).
> if you are using dhcp, then you have to tell your dhcp server to 
> serv 
> these paramters (for the isc dhcpd: option root-path 
> "/nfsroot,tcp,no_lock").
> -- 
> mazsi
> 
> ----------------------------------------------------------------
> strawberry fields forever!                       imrek@atomki.hu
> ----------------------------------------------------------------
> 
>



-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------

^ permalink raw reply

* Re: DMA interrupt is not generating in MPC8641D
From: Timur Tabi @ 2007-11-14 17:12 UTC (permalink / raw)
  To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <13747460.post@talk.nabble.com>

sivaji wrote:
> Hai,
> 
> We have designed a MPC8641D based AMC card. As part of our customer
> requirement for a PCIe messaging driver for communicating between the
> MPC8641D AMC card as the PCIe target and the MPC8548E AMC card as the Host.
> 
> We are using the DMA for transferring data between the boards thru' PCIe.
> The DMA Interrupt on the target end is not getting registered and hence we
> face the issue (ie) No interrupt is generated after DMA transfer completion.
> 
> As per datasheet(Rev. 1, 05/2007) page no:445 interrupt number for
> DMAchannel 1 is 4. We are using linux kernel version :2.6.23-rc3. According
> to file (include/asm-powerpc/irq.h) line no:636 the interrupt number for DMA
> in linux is 20(decimal). When using this interrupt number 20 we are not able
> to registerd the DMA interrupts.

Since you're using 2.6.23, the IRQ for all devices is specified in the device 
tree, not some header file.  However, the device tree for the 8641 does not 
specify any DMA nodes, so you need to add that.  Here are the nodes for the 8610 
that I'm going to add:

                 dma@21300 {
                         #address-cells = <1>;
                         #size-cells = <1>;
                         compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
                         device-id = <0>;
                         reg = <21300 4>; /* DMA general status register */
                         ranges = <0 21100 200>;

                         dma-channel@0 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <0>;
				reg = <0 80>;
				interrupt-parent = <&mpic>;
				interrupts = <14 2>;
                         };
                         dma-channel@1 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <1>;
				reg = <80 80>;
				interrupt-parent = <&mpic>;
				interrupts = <15 2>;
                         };
                         dma-channel@2 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <2>;
				reg = <100 80>;
				interrupt-parent = <&mpic>;
				interrupts = <16 2>;
                         };
                         dma-channel@3 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <3>;
				reg = <180 80>;
				interrupt-parent = <&mpic>;
				interrupts = <17 2>;
                         };
                 };

                 dma@c300 {
                         #address-cells = <1>;
                         #size-cells = <1>;
                         compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma";
                         device-id = <1>;
                         reg = <c300 4>; /* DMA general status register */
                         ranges = <0 c100 200>;

                         dma-channel@0 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <0>;
				reg = <0 80>;
				interrupt-parent = <&mpic>;
				interrupts = <3c 2>;
                         };
                         dma-channel@1 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <1>;
				reg = <80 80>;
				interrupt-parent = <&mpic>;
				interrupts = <3d 2>;
                         };
                         dma-channel@2 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <2>;
				reg = <100 80>;
				interrupt-parent = <&mpic>;
				interrupts = <3e 2>;
                         };
                         dma-channel@3 {
				compatible = "fsl,mpc8610-dma-channel",
					"fsl,mpc8540-dma-channel";
				device-id = <3>;
				reg = <180 80>;
				interrupt-parent = <&mpic>;
				interrupts = <3f 2>;
                         };
                 };

	};

Please note that there is no support in the kernel for generic PowerPC DMA 
transfers, so in addition to adding these nodes, you would also need to write 
all the code to do the DMA transfers.

-- 
Timur Tabi
Linux kernel developer at Freescale

^ permalink raw reply

* Re: Virtex TEMAC 1000Mb/s trouble, but 100b/s is working
From: jozsef imrek @ 2007-11-14 17:00 UTC (permalink / raw)
  To: g.schardt; +Cc: linuxppc-embedded
In-Reply-To: <32948332c393.32c393329483@fz-juelich.de>

On Wed, 14 Nov 2007 g.schardt@fz-juelich.de wrote:

>>
>> Trouble solved by adding tcp,no_lock !!!
>>
>
> can you tell me, how to add this parameters to the kernel boot parameter ? or do you mount after booting ?
>

if you are using a bootloader see Documentation/nfsroot.txt in the linux
source tree (a quick example: nfsroot=192.168.0.1:/nfsroot,tcp,no_lock).

if you are using dhcp, then you have to tell your dhcp server to serv 
these paramters (for the isc dhcpd: option root-path "/nfsroot,tcp,no_lock").

-- 
mazsi

----------------------------------------------------------------
strawberry fields forever!                       imrek@atomki.hu
----------------------------------------------------------------

^ permalink raw reply

* Re: I2C on mpc8248 / device tree
From: Alan Bennett @ 2007-11-14 17:49 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <9AADA2CE-A7F0-4C88-BFCF-08D6C8DC09E0@kernel.crashing.org>

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

ERk.
  So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed?  Kernel = 2.6.23+.

  Do I need to start from scratch?

  Start by using Jon's patch  (or are the 5200 i2c and the cpm2 i2c
completely incompatible?)

  What about other cpm2/i2c threads - Did they ever complete?
     1) On Wednesday, November 23, 2005 8:01 AM Kumar Gala wrote: >* Can we
rename the driver from mpc8260 -> cpm2. The driver should work* >* on any
device that has a "CPM2" which includes a number of MPC82xx* >* and MPC85xx
processors <http://osdir.com/ml/ports.ppc.devel/2005-11/msg00153.html#>. So
calling it and its config options, etc* >* MPC8260 is going to be confusing
to users.* [PATCH] I2C: Add I2C Bus support for MPC with CPM2.





On 11/14/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> The patch is orthogonal to your issue.
>
> There is NOT a driver in the kernel tree for the i2c on CPM2 based
> parts like the 8248 (from what I can tell).
>
> - k
>
> On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:
>
> > Does this patch support the cpm2 as well?
> >
> > I get conflicting thoughts looking over the latest postings.
> >
> > -Alan
> >
> >
> > On 11/13/07, Jon Smirl < jonsmirl@gmail.com> wrote:I am working on
> > a patch for i2c and device tree. I attached the current version.
> >
> > DTC entry looks like this.
> >
> >                 i2c@3d40 {
> >                         compatible = "mpc5200b-i2c","mpc5200-
> > i2c","fsl-i2c";
> >                         reg = <3d40 40>;
> >                         interrupts = <2 10 0>;
> >                         interrupt-parent = <&mpc5200_pic>;
> >                         fsl5200-clocking;
> >
> >                         rtc@51f {
> >                                 compatible = "epson,rtc8564";
> >                                 reg = <51>;
> >                         };
> >                 };
> >
> >
> >
> > --
> > Jon Smirl
> > jonsmirl@gmail.com
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4974 bytes --]

^ permalink raw reply

* Re: I2C on mpc8248 / device tree
From: Scott Wood @ 2007-11-14 17:56 UTC (permalink / raw)
  To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0711140949q4cf92442gcb4c1ecf7592b040@mail.gmail.com>

On Wed, Nov 14, 2007 at 10:49:13AM -0700, Alan Bennett wrote:
> ERk.
>   So if I needed to read values from four i2c devices (raw access would be
> fine) and I need to get this working in a few days, how would you suggest I
> proceed?  Kernel = 2.6.23+.
> 
>   Do I need to start from scratch?
> 
>   Start by using Jon's patch  (or are the 5200 i2c and the cpm2 i2c
> completely incompatible?)

Start with the cpm i2c driver that Jochen Friedrich posted to
linuxppc-embedded.

-Scott

^ permalink raw reply

* Re: Do not depend on MAX_ORDER when grouping pages by mobility
From: Mel Gorman @ 2007-11-14 18:10 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20071113114401.73d81ce2.sfr@canb.auug.org.au>

On (13/11/07 11:44), Stephen Rothwell didst pronounce:
> On Mon, 12 Nov 2007 15:54:53 +0000 mel@skynet.ie (Mel Gorman) wrote:
> >
> > Ordinarily, the size of a pageblock is determined from the hugepage size.
> > On PPC64, the hugepage size is determined at runtime based on the ability
> > of the machine. If the machine does not support hugepages, HPAGE_SHIFT is
> > 0. This results in pageblock_order being set to -PAGE_SHIFT and a crash
> > results shortly afterwards.
> > 
> > This patch checks that HPAGE_SHIFT is a sensible value before using the
> > hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible
> > value of pageblock_order.
> > 
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> 
> Looks good. Legacy iSeries boots fine with this and David Gibson has run
> his libhugetlbfs test suite on a Power5+ machine also running the same
> kernel (ppc64_defconfig).
> 
> I would be good if we could get this in for 2.6.24 (since, as far as
> legacy iSeries is concerned, this is a regression from 2.6.23).  I am not
> sure what other testing needs to be done.
> 

libhugetlbfs test suite and boot test on iSeries is sufficient in this
case. However, the version I sent would break on IA-64 due to the lack of
a definition for HPAGE_SHIFT when CONFIG_HUGETLB_PAGE is not set. Can you
confirm this patch still fixes the problem please? If it does, I'll send
it to Andrew as a fix for 2.6.24. Whether iSeries is legacy or not, this is
breakage and should be fixed.

Thanks

====

Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that
do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
being set to -PAGE_SHIFT and a crash results shortly afterwards.

This patch adds a function to select a sensible value for pageblock order by
default when HUGETLB_PAGE_SIZE_VARIABLE is set. It checks that HPAGE_SHIFT
is a sensible value before using the hugepage size; if it is not MAX_ORDER-1
is used.

This is a fix for 2.6.24.

Credit goes to Stephen Rothwell for identifying the bug and testing on
iSeries. Additional credit goes to Andy Whitcroft for spotting a problem
with respects to IA-64 before releasing. Additional credit goes to David
Gibson for testing with the libhugetlbfs test suite.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>

--- 
 arch/powerpc/Kconfig |    5 +++++
 mm/page_alloc.c      |   14 ++++++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig
--- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig	2007-11-14 11:38:05.000000000 +0000
+++ linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig	2007-11-14 11:39:12.000000000 +0000
@@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
 	default "9" if PPC_64K_PAGES
 	default "13"
 
+config HUGETLB_PAGE_SIZE_VARIABLE
+	bool
+	depends on HUGETLB_PAGE
+	default y
+
 config MATH_EMULATION
 	bool "Math emulation"
 	depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c
--- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c	2007-11-14 11:38:08.000000000 +0000
+++ linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c	2007-11-14 13:45:19.000000000 +0000
@@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
 #endif /* CONFIG_SPARSEMEM */
 
 #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
+
+/* Return a sensible default order for the pageblock size. */
+static inline int __init pageblock_default_order(void)
+{
+	if (HPAGE_SHIFT > PAGE_SHIFT)
+		return HUGETLB_PAGE_ORDER;
+
+	return MAX_ORDER-1;
+}
+
 /* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
 static inline void __init set_pageblock_order(unsigned int order)
 {
@@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
 }
 #else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
 
-/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
+#define pageblock_default_order(x) (0)
 #define set_pageblock_order(x)	do {} while (0)
 
 #endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
@@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
 		if (!size)
 			continue;
 
-		set_pageblock_order(HUGETLB_PAGE_ORDER);
+		set_pageblock_order(pageblock_default_order());
 		setup_usemap(pgdat, zone, size);
 		ret = init_currently_empty_zone(zone, zone_start_pfn,
 						size, MEMMAP_EARLY);

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

^ permalink raw reply

* [PATCH] powerpc: prpmc2800 - Enable L2 cache
From: Mark A. Greer @ 2007-11-14 19:04 UTC (permalink / raw)
  To: linuxppc-dev

From: Mark A. Greer <mgreer@mvista.com>

Turn on the L2 cache on the prpmc2800 platform.

Signed-off-by: Mark A. Greer <mgreer@mvista.com

---
 arch/powerpc/platforms/embedded6xx/prpmc2800.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..653a5eb 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -144,6 +144,7 @@ static int __init prpmc2800_probe(void)
 		strncpy(prpmc2800_platform_name, m,
 			min((int)len, PLATFORM_NAME_MAX - 1));
 
+	_set_L2CR(_get_L2CR() | L2CR_L2E);
 	return 1;
 }
 

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox