LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: mpc5200, sysctl table check failed
From: Jon Smirl @ 2007-11-07 20:39 UTC (permalink / raw)
  To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <fa686aa40711071233x7f892d20g41449cd1e8a34dd4@mail.gmail.com>

On 11/7/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/7/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I'm porting mpc5200 support for the Phytec pcm030 onto current git
> > head. When booting I get this:
> >
> > sysctl table check failed: /kernel .1 Writable sysctl directory
> > Call Trace:
> > [c0817ee0] [c0008034] show_stack+0x50/0x184 (unreliable)
> > [c0817f00] [c003cfc8] set_fail+0x50/0x68
> > [c0817f20] [c003d630] sysctl_check_table+0x650/0x6a0
> > [c0817f50] [c002a9b8] register_sysctl_table+0x64/0xb4
> > [c0817f70] [c02dee70] register_powersave_nap_sysctl+0x18/0x2c
> > [c0817f80] [c02d81d0] kernel_init+0xb4/0x270
> > [c0817ff0] [c0011be0] kernel_thread+0x44/0x60
> >
> > What's going on? I get all the way through boot and user space doesn't
> > start, this is probably why.
>
> I see the same thing on the latest git (or at least latest as of last
> night); except for me I have no problem with userspace starting.  This
> is on a Xilinx Virtex 405.

Olof's patch fixes it.
http://patchwork.ozlabs.org/linuxppc/patch?id=14612

Phytec pcm030.c depended on mpc52xx_setup_cpu which got removed. I
fixed it up by copying the old version into pcm030.c. There must be
more to the fix.

/*
 * Phytec mpc5200b tiny (pcm030) board support
 *
 * Written by: Sascha Hauer <s.hauer@pengutronix.de>
 *
 * Copyright (C) 2006 Pengutronix
 *
 * Description:
 * This program is free software; you can redistribute  it and/or modify it
 * under  the terms of  the GNU General  Public License as published by the
 * Free Software Foundation;  either version 2 of the  License, or (at your
 * option) any later version.
 */

#include <linux/stddef.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/reboot.h>
#include <linux/pci.h>
#include <linux/kdev_t.h>
#include <linux/major.h>
#include <linux/console.h>
#include <linux/delay.h>
#include <linux/seq_file.h>
#include <linux/root_dev.h>
#include <linux/initrd.h>

#include <asm/system.h>
#include <asm/atomic.h>
#include <asm/time.h>
#include <asm/io.h>
#include <asm/machdep.h>
#include <asm/ipic.h>
#include <asm/mpc52xx.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/udbg.h>
#include <sysdev/fsl_soc.h>
#include <asm/qe.h>
#include <asm/qe_ic.h>
#include <asm/of_platform.h>
#include <linux/mtd/physmap.h>
#include <linux/platform_device.h>
#include <linux/fsl_devices.h>

#include <asm/mpc52xx.h>

static struct __iomem mpc52xx_gpt *gpt = NULL;

static void __init
mpc52xx_setup_cpu(void)
{
	struct mpc52xx_cdm  __iomem *cdm;
	struct mpc52xx_xlb  __iomem *xlb;

	/* needed for mpc52xx_restart */
	gpt = mpc52xx_find_and_map("mpc52xx-gpt");

	/* Map zones */
	cdm = mpc52xx_find_and_map("mpc5200-cdm");
	xlb = mpc52xx_find_and_map("mpc5200-xlb");

	if (!cdm || !xlb) {
		printk(KERN_ERR __FILE__ ": "
			"Error while mapping CDM/XLB during mpc52xx_setup_cpu. "
			"Expect some abnormal behavior\n");
		goto unmap_regs;
	}

	/* Use internal 48 Mhz */
	out_8(&cdm->ext_48mhz_en, 0x00);
	out_8(&cdm->fd_enable, 0x01);
	if (in_be32(&cdm->rstcfg) & 0x40)	/* Assumes 33Mhz clock */
		out_be16(&cdm->fd_counters, 0x0001);
	else
		out_be16(&cdm->fd_counters, 0x5555);

	/* Configure the XLB Arbiter priorities */
	out_be32(&xlb->master_pri_enable, 0xff);
	out_be32(&xlb->master_priority, 0x11111111);

	/* Disable XLB pipelining */
	/* (cfr errate 292. We could do this only just before ATA PIO
	    transaction and re-enable it afterwards ...) */
	out_be32(&xlb->config, in_be32(&xlb->config) | MPC52xx_XLB_CFG_PLDIS);

	/* Unmap zones */
unmap_regs:
	if (cdm) iounmap(cdm);
	if (xlb) iounmap(xlb);
}

struct mpc52xx_gpio __iomem *mpc52xx_gpio=NULL;
struct mpc52xx_gpio_wkup __iomem *mpc52xx_wkpio=NULL;
EXPORT_SYMBOL(mpc52xx_gpio);
EXPORT_SYMBOL(mpc52xx_wkpio);

/*
 * Map the GPIO relevant register fix and global.
 * They will be used in the Pengutronix' GOIO framework
 * This is very PCM030 specific stuff!
 */
static void __init pcm030_gpio_setup(void)
{
	mpc52xx_gpio = mpc52xx_find_and_map("mpc52xx-gpio");
	if (mpc52xx_gpio == NULL) {
		printk(KERN_ERR "%s: Error while mapping GPIO register for port config. "
				"Expect some abnormal behavior\n",__FILE__);
		goto error;
	}

	mpc52xx_wkpio = mpc52xx_find_and_map("mpc52xx-gpio-wkup");
	if (mpc52xx_wkpio == NULL) {
		printk(KERN_ERR "%s: "
				"Error while mapping WAKEUP register for port config. "
				"Expect some abnormal behavior\n",__FILE__);
		goto error;
	}

	return;

error:
	if (mpc52xx_gpio != NULL)
		iounmap(mpc52xx_gpio);
	if (mpc52xx_wkpio != NULL)
		iounmap(mpc52xx_wkpio);
}

static void __init pcm030_setup_arch(void)
{
	struct device_node *np;

	if (ppc_md.progress)
		ppc_md.progress("pcm030_setup_arch()", 0);

	np = of_find_node_by_type(NULL, "cpu");
	if (np) {
		unsigned int *fp =
		    (int *)of_get_property(np, "clock-frequency", NULL);
		if (fp != 0)
			loops_per_jiffy = *fp / HZ;
		else
			loops_per_jiffy = 50000000 / HZ;
		of_node_put(np);
	}

	mpc52xx_setup_cpu();
	pcm030_gpio_setup();
}

static struct physmap_flash_data pcm030_flash_data = {
	.width	= 1,
};

static struct resource pcm030_flash_resource = {
	.start		= 0xff000000,
	.end		= 0xffffffff,
	.flags		= IORESOURCE_MEM,
};

static struct platform_device pcm030_flash = {
	.name		= "physmap-flash",
	.id		= 0,
	.dev		= {
				.platform_data	= &pcm030_flash_data,
			},
	.resource	= &pcm030_flash_resource,
	.num_resources	= 1,
};

#define MBAR_BASE 0xf0000000

static int __init pcm030_register_flash(void)
{
	void __iomem *mbar;
	unsigned int cs0;

	/*
	 * The pcm030 comes with different flash buswidths. Detect
	 * it by looking in the chipselect setup register
	 */
	mbar = ioremap(MBAR_BASE, 0x1000);
	if (!mbar)
		return -EINVAL;

	cs0 = in_be32(mbar + 0x300);

	iounmap(mbar);

	switch ((cs0 >> 8) & 0x3) {
	case 0:
		pcm030_flash_data.width = 1;
		break;
	case 1:
		pcm030_flash_data.width = 2;
		break;
	case 3:
		pcm030_flash_data.width = 4;
		break;
	}

	return platform_device_register(&pcm030_flash);
}

static void __init pcm030_init(void)
{
	pcm030_register_flash();
	mpc52xx_declare_of_platform_devices();
}

void pcm030_show_cpuinfo(struct seq_file *m)
{
	seq_printf(m, "vendor\t\t:	Phytec\n");
	seq_printf(m, "machine\t\t:	Phycore mpc5200b tiny (pcm030)\n");
}

/*
 * Called very early, MMU is off, device-tree isn't unflattened
 */
static int __init pcm030_probe(void)
{
	unsigned long node = of_get_flat_dt_root();

	if (!of_flat_dt_is_compatible(node, "fsl,pcm030"))
		return 0;

	return 1;
}

define_machine(pcm030) {
	.name 		= "pcm030",
	.probe 		= pcm030_probe,
	.setup_arch 	= pcm030_setup_arch,
	.restart	= mpc52xx_restart,
	.init           = pcm030_init,
	.init_IRQ 	= mpc52xx_init_irq,
	.get_irq 	= mpc52xx_get_irq,
	.show_cpuinfo	= pcm030_show_cpuinfo,
	.calibrate_decr	= generic_calibrate_decr,
};


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* Re: mpc5200, sysctl table check failed
From: Grant Likely @ 2007-11-07 20:33 UTC (permalink / raw)
  To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711071224v7bf643bahba0fd23eb2d16ee1@mail.gmail.com>

On 11/7/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> I'm porting mpc5200 support for the Phytec pcm030 onto current git
> head. When booting I get this:
>
> sysctl table check failed: /kernel .1 Writable sysctl directory
> Call Trace:
> [c0817ee0] [c0008034] show_stack+0x50/0x184 (unreliable)
> [c0817f00] [c003cfc8] set_fail+0x50/0x68
> [c0817f20] [c003d630] sysctl_check_table+0x650/0x6a0
> [c0817f50] [c002a9b8] register_sysctl_table+0x64/0xb4
> [c0817f70] [c02dee70] register_powersave_nap_sysctl+0x18/0x2c
> [c0817f80] [c02d81d0] kernel_init+0xb4/0x270
> [c0817ff0] [c0011be0] kernel_thread+0x44/0x60
>
> What's going on? I get all the way through boot and user space doesn't
> start, this is probably why.

I see the same thing on the latest git (or at least latest as of last
night); except for me I have no problem with userspace starting.  This
is on a Xilinx Virtex 405.

Cheers,
g.

>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* mpc5200, sysctl table check failed
From: Jon Smirl @ 2007-11-07 20:24 UTC (permalink / raw)
  To: PowerPC dev list

I'm porting mpc5200 support for the Phytec pcm030 onto current git
head. When booting I get this:

sysctl table check failed: /kernel .1 Writable sysctl directory
Call Trace:
[c0817ee0] [c0008034] show_stack+0x50/0x184 (unreliable)
[c0817f00] [c003cfc8] set_fail+0x50/0x68
[c0817f20] [c003d630] sysctl_check_table+0x650/0x6a0
[c0817f50] [c002a9b8] register_sysctl_table+0x64/0xb4
[c0817f70] [c02dee70] register_powersave_nap_sysctl+0x18/0x2c
[c0817f80] [c02d81d0] kernel_init+0xb4/0x270
[c0817ff0] [c0011be0] kernel_thread+0x44/0x60

What's going on? I get all the way through boot and user space doesn't
start, this is probably why.


-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* [PATCH] powerpc/eeh: make sure warning message is printed.
From: Linas Vepstas @ 2007-11-07 20:03 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: ppc-dev


Fix old buglet; a warning message should have been printed 
when a hardware reset takes too long. 

Signed-off-by: Linas Vepstas <linas@austin.ibm.com>

----
 arch/powerpc/platforms/pseries/eeh.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh.c	2007-11-05 16:22:44.000000000 -0600
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c	2007-11-05 16:24:17.000000000 -0600
@@ -325,7 +325,7 @@ eeh_wait_for_slot_status(struct pci_dn *
 
 		if (rets[2] == 0) return -1; /* permanently unavailable */
 
-		if (max_wait_msecs <= 0) return -1;
+		if (max_wait_msecs <= 0) break;
 
 		mwait = rets[2];
 		if (mwait <= 0) {

^ permalink raw reply

* [PATCH] hugetlb: follow_hugetlb_page for write access
From: Adam Litke @ 2007-11-07 19:51 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev, Hoang-Nam Nguyen, Ken Chen, linux-kernel


When calling get_user_pages(), a write flag is passed in by the caller to
indicate if write access is required on the faulted-in pages.  Currently,
follow_hugetlb_page() ignores this flag and always faults pages for
read-only access.  This can cause data corruption because a device driver
that calls get_user_pages() with write set will not expect COW faults to
occur on the returned pages.

This patch passes the write flag down to follow_hugetlb_page() and makes
sure hugetlb_fault() is called with the right write_access parameter.

Signed-off-by: Adam Litke <agl@us.ibm.com>
---

 include/linux/hugetlb.h |    2 +-
 mm/hugetlb.c            |    5 +++--
 mm/memory.c             |    2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 3a19b03..31fa0a0 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -19,7 +19,7 @@ static inline int is_vm_hugetlb_page(struct vm_area_struct *vma)
 int hugetlb_sysctl_handler(struct ctl_table *, int, struct file *, void __user *, size_t *, loff_t *);
 int hugetlb_treat_movable_handler(struct ctl_table *, int, struct file *, void __user *, size_t *, loff_t *);
 int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *, struct vm_area_struct *);
-int follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *, struct page **, struct vm_area_struct **, unsigned long *, int *, int);
+int follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *, struct page **, struct vm_area_struct **, unsigned long *, int *, int, int);
 void unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned long);
 void __unmap_hugepage_range(struct vm_area_struct *, unsigned long, unsigned long);
 int hugetlb_prefault(struct address_space *, struct vm_area_struct *);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index eab8c42..b645985 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -621,7 +621,8 @@ int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
 
 int follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
 			struct page **pages, struct vm_area_struct **vmas,
-			unsigned long *position, int *length, int i)
+			unsigned long *position, int *length, int i,
+			int write)
 {
 	unsigned long pfn_offset;
 	unsigned long vaddr = *position;
@@ -643,7 +644,7 @@ int follow_hugetlb_page(struct mm_struct *mm, struct vm_area_struct *vma,
 			int ret;
 
 			spin_unlock(&mm->page_table_lock);
-			ret = hugetlb_fault(mm, vma, vaddr, 0);
+			ret = hugetlb_fault(mm, vma, vaddr, write);
 			spin_lock(&mm->page_table_lock);
 			if (!(ret & VM_FAULT_ERROR))
 				continue;
diff --git a/mm/memory.c b/mm/memory.c
index f82b359..1bcd444 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1039,7 +1039,7 @@ int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
 
 		if (is_vm_hugetlb_page(vma)) {
 			i = follow_hugetlb_page(mm, vma, pages, vmas,
-						&start, &len, i);
+						&start, &len, i, write);
 			continue;
 		}
 

^ permalink raw reply related

* Re: [PATCH 2/2] IB/ehca: Fix static rate calculation
From: Roland Dreier @ 2007-11-07 19:45 UTC (permalink / raw)
  To: Joachim Fenkes
  Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
	Stefan Roscher
In-Reply-To: <200711021441.50158.fenkes@de.ibm.com>

thanks, applied both patches.

^ permalink raw reply

* Re: [RFC/PATCH] Fix rtas_ibm_suspend_me bugs
From: Nathan Lynch @ 2007-11-07 19:19 UTC (permalink / raw)
  To: linuxppc-dev
In-Reply-To: <20071106044309.GK9695@localdomain>

Nathan Lynch wrote:
> (very rfc for now, no sign-off, needs more testing)
> 
> There are a couple of bugs in the rtas_ibm_suspend_me() and
> rtas_percpu_suspend_me() functions:
> 
> 1.  rtas_ibm_suspend_me() uses on_each_cpu() to invoke
> rtas_percpu_suspend_me() via IPI:
> 
> if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
> ...
> 
> 'data' is on the stack, and rtas_ibm_suspend_me() takes no measures to
> ensure that all instances of rtas_percpu_suspend_me() are finished
> accessing 'data' before returning.  This can result in the IPI'd cpus
> accessing random stack data and getting stuck in H_JOIN.

Another possible issue is that H_JOIN requires MSR.EE to be off, but
lazy interrupt disabling could conceivably allow that constraint to be
violated if we end up doing H_JOIN on the cpu which calls on_each_cpu().
At least I think so...

^ permalink raw reply

* Re: [RFC] Modifying i2c-core to support alias driver names compatible with device trees
From: Jon Smirl @ 2007-11-07 18:02 UTC (permalink / raw)
  To: Jean Delvare, Grant Likely, Tjernlund, i2c, linuxppc-dev
In-Reply-To: <9e4733910711061239g22b06863rbec37fcef138c869@mail.gmail.com>

On 11/6/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> This code modifies the i2c-core to support lists of alias names in the
> chip drivers.

Any comments on this code?

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply

* [PATCH] Register AC97 Controller Reference with the platform bus
From: Grant Likely @ 2007-11-07 16:14 UTC (permalink / raw)
  To: linuxppc-dev, JOFT, jwboyer

From: Joachim Foerster <mls.JOFT@gmx.de>

Add AC97 platform bus registration for Xilinx Virtex platforms.

Signed-off-by: Joachim Foerster <JOFT@gmx.de>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---

Josh, can you please pick up this patch into your .24 queue.  I know it's
arch/ppc, but it is harmless and it is required to get the AC97 device
driver working on Virtex boards.  It's pretty much a bug fix in that regard.

Cheers,
g.

 arch/ppc/syslib/virtex_devices.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index 96188f8..95ee313 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -169,6 +169,29 @@
 	}, \
 }
 
+#define XPAR_AC97_CONTROLLER_REFERENCE(num) { \
+	.name = "ml403_ac97cr", \
+	.id = num, \
+	.num_resources = 3, \
+	.resource = (struct resource[]) { \
+		{ \
+			.start = XPAR_OPB_AC97_CONTROLLER_REF_##num##_BASEADDR, \
+			.end = XPAR_OPB_AC97_CONTROLLER_REF_##num##_HIGHADDR, \
+			.flags = IORESOURCE_MEM, \
+		}, \
+		{ \
+			.start = XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_PLAYBACK_INTERRUPT_INTR, \
+			.end = XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_PLAYBACK_INTERRUPT_INTR, \
+			.flags = IORESOURCE_IRQ, \
+		}, \
+		{ \
+			.start = XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_RECORD_INTERRUPT_INTR, \
+			.end = XPAR_OPB_INTC_0_OPB_AC97_CONTROLLER_REF_##num##_RECORD_INTERRUPT_INTR, \
+			.flags = IORESOURCE_IRQ, \
+		}, \
+	}, \
+}
+
 /* UART 8250 driver platform data table */
 struct plat_serial8250_port virtex_serial_platform_data[] = {
 #if defined(XPAR_UARTNS550_0_BASEADDR)
@@ -303,6 +326,14 @@ struct platform_device virtex_platform_devices[] = {
 #if defined(XPAR_TFT_3_BASEADDR)
 	XPAR_TFT(3),
 #endif
+
+	/* AC97 Controller Reference instances */
+#if defined(XPAR_OPB_AC97_CONTROLLER_REF_0_BASEADDR)
+	XPAR_AC97_CONTROLLER_REFERENCE(0),
+#endif
+#if defined(XPAR_OPB_AC97_CONTROLLER_REF_1_BASEADDR)
+	XPAR_AC97_CONTROLLER_REFERENCE(1),
+#endif
 };
 
 /* Early serial support functions */

^ permalink raw reply related

* Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig
From: Paul Mundt @ 2007-11-07 15:13 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Bryan Wu, linux-mips, Ralf Baechle, Rafael J. Wysocki,
	linuxppc-dev, linux-pm, Guennadi Liakhovetski, Russell King
In-Reply-To: <20071107135849.207149000@sipsolutions.net>

On Wed, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote:
> This cleans up the suspend Kconfig and removes the need to
> declare centrally which architectures support suspend. All
> architectures that currently support suspend are modified
> accordingly.
> 
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: linuxppc-dev@ozlabs.org
> Cc: linux-pm@lists.linux-foundation.org
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Bryan Wu <bryan.wu@analog.com>
> Cc: Russell King <rmk@arm.linux.org.uk>
> ---
> Architecture maintainers should evaluate whether their
> ARCH_SUSPEND_POSSIBLE symbol should be set only under
> stricter circumstances like I've done for powerpc.
> 
The SH bits look fine.

Acked-by: Paul Mundt <lethal@linux-sh.org>

^ permalink raw reply

* [PATCH] [POWERPC] pasemi: Move cpus to hold loop before restart
From: Olof Johansson @ 2007-11-07 15:41 UTC (permalink / raw)
  To: linuxppc-dev

[POWERPC] pasemi: Move cpus to hold loop before restart

Use smp_send_stop() to move all cpus besides the one executing reboot
into a hold loop, to keep them from being in powersavings mode at the
time of reboot.

Signed-off-by: Olof Johansson <olof@lixom.net>

diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index bd85853..14dace7 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -60,6 +60,9 @@ static int num_mce_regs;
 
 static void pas_restart(char *cmd)
 {
+	/* Need to put others cpu in hold loop so they're not sleeping */
+	smp_send_stop();
+	udelay(10000);
 	printk("Restarting...\n");
 	while (1)
 		out_le32(reset_reg, 0x6000000);

^ permalink raw reply related

* [PATCH] [POWERPC] pasemi: Don't enter powersaving states from elevated astates
From: Olof Johansson @ 2007-11-07 15:39 UTC (permalink / raw)
  To: linuxppc-dev

[POWERPC] pasemi: Don't enter powersaving states from elevated astates

When the PWRficient cpus are entered into powersavings states, the
astate is automatically dropped down to 0. While we still restore it
when we come out of idle, it can still cause some weird effects with
respect to performance (especially since it takes a while to ramp up to
higher astates).

So, to avoid this, don't enter power savings when the cpufreq driver
(or user) has set higher astates than 0.

The restore is still required, since there's a chance the astate has
been raised from the other cpu while the idling one was asleep.

Signed-off-by: Olof Johansson <olof@lixom.net>

diff --git a/arch/powerpc/platforms/pasemi/cpufreq.c b/arch/powerpc/platforms/pasemi/cpufreq.c
index 8caa166..c2e0340 100644
--- a/arch/powerpc/platforms/pasemi/cpufreq.c
+++ b/arch/powerpc/platforms/pasemi/cpufreq.c
@@ -124,6 +124,11 @@ static void set_astate(int cpu, unsigned int astate)
 	local_irq_restore(flags);
 }
 
+int check_astate(void)
+{
+	return get_cur_astate(hard_smp_processor_id());
+}
+
 void restore_astate(int cpu)
 {
 	set_astate(cpu, current_astate);
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index 516acab..c96127b 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -16,8 +16,14 @@ extern void idle_doze(void);
 
 /* Restore astate to last set */
 #ifdef CONFIG_PPC_PASEMI_CPUFREQ
+extern int check_astate(void);
 extern void restore_astate(int cpu);
 #else
+static inline int check_astate(void)
+{
+	/* Always return >0 so we never power save */
+	return 1;
+}
 static inline void restore_astate(int cpu)
 {
 }
diff --git a/arch/powerpc/platforms/pasemi/powersave.S b/arch/powerpc/platforms/pasemi/powersave.S
index 6d0fba6..56f45ad 100644
--- a/arch/powerpc/platforms/pasemi/powersave.S
+++ b/arch/powerpc/platforms/pasemi/powersave.S
@@ -62,7 +62,16 @@ sleep_common:
 	mflr	r0
 	std	r0, 16(r1)
 	stdu	r1,-64(r1)
+#ifdef CONFIG_PPC_PASEMI_CPUFREQ
+	std	r3, 48(r1)
 
+	/* Only do power savings when in astate 0 */
+	bl	.check_astate
+	cmpwi	r3,0
+	bne	1f
+
+	ld	r3, 48(r1)
+#endif
 	LOAD_REG_IMMEDIATE(r6,MSR_DR|MSR_IR|MSR_ME|MSR_EE)
 	mfmsr	r4
 	andc	r5,r4,r6
@@ -73,7 +82,7 @@ sleep_common:
 
 	mtmsrd	r4,0
 
-	addi	r1,r1,64
+1:	addi	r1,r1,64
 	ld	r0,16(r1)
 	mtlr	r0
 	blr

^ permalink raw reply related

* [PATCH (2.6.25) 2/2] suspend: clean up Kconfig
From: Johannes Berg @ 2007-11-07 13:58 UTC (permalink / raw)
  To: linux-pm
  Cc: Bryan Wu, linux-mips, Ralf Baechle, Rafael J. Wysocki,
	linuxppc-dev, Paul Mundt, Guennadi Liakhovetski, Russell King
In-Reply-To: <20071107135758.100171000@sipsolutions.net>

This cleans up the suspend Kconfig and removes the need to
declare centrally which architectures support suspend. All
architectures that currently support suspend are modified
accordingly.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: linuxppc-dev@ozlabs.org
Cc: linux-pm@lists.linux-foundation.org
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Scott Wood <scottwood@freescale.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Bryan Wu <bryan.wu@analog.com>
Cc: Russell King <rmk@arm.linux.org.uk>
---
Architecture maintainers should evaluate whether their
ARCH_SUSPEND_POSSIBLE symbol should be set only under
stricter circumstances like I've done for powerpc.

Always setting it is not usually a problem, however, since the
infrastructure is only available for use after suspend_set_ops().

 arch/arm/Kconfig      |    3 +++
 arch/blackfin/Kconfig |    4 ++++
 arch/frv/Kconfig      |    5 +++++
 arch/i386/Kconfig     |    4 ++++
 arch/mips/Kconfig     |    4 ++++
 arch/powerpc/Kconfig  |    4 ++++
 arch/sh/Kconfig       |    4 ++++
 arch/x86_64/Kconfig   |    3 +++
 kernel/power/Kconfig  |   21 +++------------------
 9 files changed, 34 insertions(+), 18 deletions(-)

--- everything.orig/arch/i386/Kconfig	2007-11-07 14:45:28.591544215 +0100
+++ everything/arch/i386/Kconfig	2007-11-07 14:45:28.631515461 +0100
@@ -1323,3 +1323,7 @@ config KTIME_SCALAR
 config ARCH_HIBERNATION_POSSIBLE
 	def_bool y
 	depends on !SMP || !X86_VOYAGER
+
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on !X86_VOYAGER
--- everything.orig/arch/x86_64/Kconfig	2007-11-07 14:45:28.591544215 +0100
+++ everything/arch/x86_64/Kconfig	2007-11-07 14:45:28.631515461 +0100
@@ -716,6 +716,9 @@ menu "Power management options"
 
 source kernel/power/Kconfig
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+
 config ARCH_HIBERNATION_POSSIBLE
 	def_bool y
 
--- everything.orig/kernel/power/Kconfig	2007-11-07 14:45:28.591544215 +0100
+++ everything/kernel/power/Kconfig	2007-11-07 14:45:28.641531465 +0100
@@ -64,7 +64,7 @@ config PM_TRACE
 config PM_SLEEP_SMP
 	bool
 	depends on SMP
-	depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
+	depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
 	depends on PM_SLEEP
 	select HOTPLUG_CPU
 	default y
@@ -74,29 +74,14 @@ config PM_SLEEP
 	depends on SUSPEND || HIBERNATION
 	default y
 
-config SUSPEND_UP_POSSIBLE
-	bool
-	depends on (X86 && !X86_VOYAGER) || PPC || ARM || BLACKFIN || MIPS \
-		   || SUPERH || FRV
-	depends on !SMP
-	default y
-
-config SUSPEND_SMP_POSSIBLE
-	bool
-	depends on (X86 && !X86_VOYAGER) \
-		   || (PPC && (PPC_PSERIES || PPC_PMAC)) || ARM
-	depends on SMP
-	default y
-
 config SUSPEND
 	bool "Suspend to RAM and standby"
-	depends on PM
-	depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE
+	depends on PM && ARCH_SUSPEND_POSSIBLE
 	default y
 	---help---
 	  Allow the system to enter sleep states in which main memory is
 	  powered and thus its contents are preserved, such as the
-	  suspend-to-RAM state (i.e. the ACPI S3 state).
+	  suspend-to-RAM state (e.g. the ACPI S3 state).
 
 config HIBERNATION
 	bool "Hibernation (aka 'suspend to disk')"
--- everything.orig/arch/blackfin/Kconfig	2007-11-07 14:44:55.551521971 +0100
+++ everything/arch/blackfin/Kconfig	2007-11-07 14:45:28.641531465 +0100
@@ -993,6 +993,10 @@ endmenu
 menu "Power management options"
 source "kernel/power/Kconfig"
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on !SMP
+
 choice
 	prompt "Select PM Wakeup Event Source"
 	default PM_WAKEUP_GPIO_BY_SIC_IWR
--- everything.orig/arch/arm/Kconfig	2007-11-07 14:44:55.651522948 +0100
+++ everything/arch/arm/Kconfig	2007-11-07 14:45:28.641531465 +0100
@@ -977,6 +977,9 @@ menu "Power management options"
 
 source "kernel/power/Kconfig"
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+
 endmenu
 
 source "net/Kconfig"
--- everything.orig/arch/mips/Kconfig	2007-11-07 14:44:55.701522460 +0100
+++ everything/arch/mips/Kconfig	2007-11-07 14:45:28.641531465 +0100
@@ -1999,6 +1999,10 @@ endmenu
 
 menu "Power management options"
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on !SMP
+
 source "kernel/power/Kconfig"
 
 endmenu
--- everything.orig/arch/sh/Kconfig	2007-11-07 14:44:55.801520344 +0100
+++ everything/arch/sh/Kconfig	2007-11-07 14:45:28.651528536 +0100
@@ -748,6 +748,10 @@ endmenu
 menu "Power management options (EXPERIMENTAL)"
 depends on EXPERIMENTAL && SYS_SUPPORTS_PM
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on !SMP
+
 source kernel/power/Kconfig
 
 endmenu
--- everything.orig/arch/frv/Kconfig	2007-11-07 14:44:55.861520941 +0100
+++ everything/arch/frv/Kconfig	2007-11-07 14:45:28.651528536 +0100
@@ -357,6 +357,11 @@ source "drivers/pcmcia/Kconfig"
 #	  should probably wait a while.
 
 menu "Power management options"
+
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on !SMP
+
 source kernel/power/Kconfig
 endmenu
 
--- everything.orig/arch/powerpc/Kconfig	2007-11-07 14:45:28.591544215 +0100
+++ everything/arch/powerpc/Kconfig	2007-11-07 14:45:28.651528536 +0100
@@ -155,6 +155,10 @@ config ARCH_HIBERNATION_POSSIBLE
 	depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32)
 	default y
 
+config ARCH_SUSPEND_POSSIBLE
+	def_bool y
+	depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200
+
 config PPC_DCR_NATIVE
 	bool
 	default n

-- 

^ permalink raw reply

* [PATCH (2.6.25) 1/2] hibernation: clean up Kconfig
From: Johannes Berg @ 2007-11-07 13:57 UTC (permalink / raw)
  To: linux-pm; +Cc: Rafael J. Wysocki, linuxppc-dev
In-Reply-To: <20071107135758.100171000@sipsolutions.net>

This cleans up the hibernation Kconfig and removes the need to
declare centrally which architectures support hibernation. All
architectures that currently support hibernation are modified
accordingly.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: linuxppc-dev@ozlabs.org
Cc: linux-pm@lists.linux-foundation.org

---
 arch/i386/Kconfig    |    4 ++++
 arch/powerpc/Kconfig |   14 ++++++++++++--
 arch/x86_64/Kconfig  |    3 +++
 kernel/power/Kconfig |   18 +++---------------
 4 files changed, 22 insertions(+), 17 deletions(-)

--- everything.orig/arch/powerpc/Kconfig	2007-11-07 13:52:14.641523382 +0100
+++ everything/arch/powerpc/Kconfig	2007-11-07 14:29:17.251530543 +0100
@@ -140,9 +140,19 @@ config DEFAULT_UIMAGE
 	  Used to allow a board to specify it wants a uImage built by default
 	default n
 
-config PPC64_SWSUSP
+config HIBERNATE_32
 	bool
-	depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))
+	depends on (PPC_PMAC && !SMP) || BROKEN
+	default y
+
+config HIBERNATE_64
+	bool
+	depends on BROKEN || (PPC_PMAC64 && EXPERIMENTAL)
+	default y
+
+config ARCH_HIBERNATION_POSSIBLE
+	bool
+	depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32)
 	default y
 
 config PPC_DCR_NATIVE
--- everything.orig/kernel/power/Kconfig	2007-11-07 13:52:14.731524087 +0100
+++ everything/kernel/power/Kconfig	2007-11-07 14:29:17.351531628 +0100
@@ -63,7 +63,8 @@ config PM_TRACE
 
 config PM_SLEEP_SMP
 	bool
-	depends on SUSPEND_SMP_POSSIBLE || HIBERNATION_SMP_POSSIBLE
+	depends on SMP
+	depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
 	depends on PM_SLEEP
 	select HOTPLUG_CPU
 	default y
@@ -97,22 +98,9 @@ config SUSPEND
 	  powered and thus its contents are preserved, such as the
 	  suspend-to-RAM state (i.e. the ACPI S3 state).
 
-config HIBERNATION_UP_POSSIBLE
-	bool
-	depends on X86 || PPC64_SWSUSP || PPC32
-	depends on !SMP
-	default y
-
-config HIBERNATION_SMP_POSSIBLE
-	bool
-	depends on (X86 && !X86_VOYAGER) || PPC64_SWSUSP
-	depends on SMP
-	default y
-
 config HIBERNATION
 	bool "Hibernation (aka 'suspend to disk')"
-	depends on PM && SWAP
-	depends on HIBERNATION_UP_POSSIBLE || HIBERNATION_SMP_POSSIBLE
+	depends on PM && SWAP && ARCH_HIBERNATION_POSSIBLE
 	---help---
 	  Enable the suspend to disk (STD) functionality, which is usually
 	  called "hibernation" in user interfaces.  STD checkpoints the
--- everything.orig/arch/i386/Kconfig	2007-11-07 13:54:07.811521157 +0100
+++ everything/arch/i386/Kconfig	2007-11-07 14:29:16.631526474 +0100
@@ -1319,3 +1319,7 @@ config X86_TRAMPOLINE
 config KTIME_SCALAR
 	bool
 	default y
+
+config ARCH_HIBERNATION_POSSIBLE
+	def_bool y
+	depends on !SMP || !X86_VOYAGER
--- everything.orig/arch/x86_64/Kconfig	2007-11-07 13:57:35.091520777 +0100
+++ everything/arch/x86_64/Kconfig	2007-11-07 14:29:16.721529458 +0100
@@ -716,6 +716,9 @@ menu "Power management options"
 
 source kernel/power/Kconfig
 
+config ARCH_HIBERNATION_POSSIBLE
+	def_bool y
+
 config ARCH_HIBERNATION_HEADER
 	bool
 	depends on HIBERNATION

-- 

^ permalink raw reply

* [PATCH] powerpc swsusp: make altivec code depend on CONFIG_ALTIVEC
From: Johannes Berg @ 2007-11-07 12:59 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, sam, David Miller,
	Balbir Singh
In-Reply-To: <1194428323.4055.3.camel@johannes.berg>

This makes the altivec code in swsusp_32.S depend on CONFIG_ALTIVEC to
avoid build failures for systems that don't have altivec. I'm not sure
whether the code will actually work for other systems, but it was merged
for just ppc32 rather than powermac a very long time ago.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---

--- everything.orig/arch/powerpc/kernel/swsusp_32.S	2007-11-07 13:27:12.441517359 +0100
+++ everything/arch/powerpc/kernel/swsusp_32.S	2007-11-07 13:27:25.251519911 +0100
@@ -133,10 +133,12 @@ _GLOBAL(swsusp_arch_suspend)
 /* Resume code */
 _GLOBAL(swsusp_arch_resume)
 
+#ifdef CONFIG_ALTIVEC
 	/* Stop pending alitvec streams and memory accesses */
 BEGIN_FTR_SECTION
 	DSSALL
 END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
+#endif
  	sync
 
 	/* Disable MSR:DR to make sure we don't take a TLB or

^ permalink raw reply

* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Johannes Berg @ 2007-11-07 12:49 UTC (permalink / raw)
  To: Andy Whitcroft
  Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, sam, David Miller,
	Balbir Singh
In-Reply-To: <1194428323.4055.3.camel@johannes.berg>

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


On Wed, 2007-11-07 at 10:38 +0100, Johannes Berg wrote:
> 
> > So that sounds like a Kconfig problem then?  That HIBERATION requires
> > ALITIVEC and yet does not depend on it or set it.
> 
> Yes. I'm guessing that it broke with Rafael's hibernation/suspend
> Kconfig changes but will take a look. I think it used to depend on
> powermac.

Hmm, no, it didn't. I don't feel confident enough that nobody cares
about this code to make these Kconfig changes for 2.6.24.

johannes

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

^ permalink raw reply

* Re: [PATCH 4/3] Make swsusp_32.S usable for suspend-to-RAM.
From: Johannes Berg @ 2007-11-07 12:25 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070905220846.GA11400@ld0162-tx32.am.freescale.net>

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


> +config PPC32_SUSPEND

> +config PPC32_SWSUSP

> -obj32-$(CONFIG_HIBERNATION) += swsusp_32.o
> +obj32-$(CONFIG_PPC32_SUSPEND)	+= swsusp_32.o

I think that's overkill, couldn't it just use CONFIG_PM_SLEEP here? I'm
not sure that was available at the time you posted this patchset though,
so that may well be the reason you didn't use it.

For reference, kernel/power/Kconfig has:

config PM_SLEEP
        bool   
        depends on SUSPEND || HIBERNATION
        default y


johannes

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

^ permalink raw reply

* [PATCH] autoload snd-powermac via modalias
From: Olaf Hering @ 2007-11-07 14:43 UTC (permalink / raw)
  To: linuxppc-dev


Autoload snd-powermac on systems without i2s bus by creating a fake
modalias entry. udev/modprobe will use the 'modalias' file from
/sys/devices/pci*/*/*/*:mac-io/*:davbus/ to find a matching module.
Newer systems use snd-aoa, which provides the required modalias already.

Some systems with i2s bus, but without a 'layout-id' property, will not work
with this patch because an fake i2s alias will conflict with snd-aoa.


Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 sound/ppc/powermac.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/sound/ppc/powermac.c
+++ b/sound/ppc/powermac.c
@@ -174,6 +174,16 @@ static struct platform_driver snd_pmac_d
 	},
 };
 
+/* for NewWorld AGP (Pismo, CRT iMac) */
+MODULE_ALIAS("of:NdavbusTsoundbusCdavbus");
+/* for OldWorld beige G3 */
+/* for NewWorld PCI (G3 and early G4) */
+MODULE_ALIAS("of:NdavbusTdavbus");
+/* for OldWorld ohare based */
+MODULE_ALIAS("of:NdavbusTsoundbus");
+/* for OldWorld bandit based */
+MODULE_ALIAS("of:NawacsTsound");
+
 static int __init alsa_card_pmac_init(void)
 {
 	int err;

^ permalink raw reply

* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: Jon Loeliger @ 2007-11-07 14:14 UTC (permalink / raw)
  To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071106231120.GG31367@localhost.localdomain>

So, like, the other day David Gibson mumbled:
> On Tue, Nov 06, 2007 at 04:19:19PM -0600, Jon Loeliger wrote:
> > From: Jon Loeliger <jdl@freescale.com>
> > 
> > Fixes BYTESTRING lexing.
> > Allows -O dts output to be emitted in a given (1) format version.
> 
> Ok... I'd actually be more inclined to remove the option and just have
> -Odts *always* use the newer version.

You didn't read the code. :-)  That's what it does!
There is no option, it is just parameterized in the code.
It _always_ forward re-writes as the latest version.

> Having dtc be able to convert dts versions forward is easy and
> useful.

Oh, I see.  Thank you.

> > This patch is directly on top of your prior two patches.
> > Lemme know what you think.
> 
> On top of my two dts-v1 patches that is, I assume?

Right.

> Ow... that's rather embarrassing, that I didn't even notice I'd
> totally broken bytestrings.  Really must add some bytestrings to
> test_tree1.dts so this actually gets checked by the testsuite.

I ran my "old versus new DTC" comparison script and found it. :-)

> Not really related changes, but whatever..

Uh, yeah.  Leftoverish.  Sorry.


> > +/*
> > + * bits is unused, but it should be 32 or 64 as needed.
> > + *
> > + * FIXME: However, with bits == 64, ((1ULL << bits) - 1)
> > + * overflows before you can actually do the range test.
> > + */
> >  unsigned long long eval_literal(const char *s, int base, int bits)
> >  {
> >  	unsigned long long val;
> > @@ -317,9 +323,10 @@ unsigned long long eval_literal(const char *s, int base, int bits)
> >  	val = strtoull(s, &e, base);
> >  	if (*e)
> >  		yyerror("bad characters in literal");
> > -	else if ((errno == ERANGE) || (val > ((1ULL << bits)-1)))
> > +	else if (errno == ERANGE)
> >  		yyerror("literal out of range");
> >  	else if (errno != 0)
> >  		yyerror("bad literal");
> > +
> 
> Ok.. I don't understand why you've pulled out the range checking
> against bits here.

Because it wasn't working, as explained in the comment I added.
Specifically, (1<<bits), with bits==64 overflowed and yielded
the value 0.

Here's the problem:

---------------- snip to get foo.c ----------------
#include "stdio.h"

int bits = 64;
unsigned long long val = 0xabcd1234;

main()
{
    int i;

    for (i = 1; i <= 64; i++) {
        unsigned long long r =  (1ULL << i) - 1;
        printf("range at %d is 0x%016llx\n", i, r);
    }

    printf("val   is 0x%016llx\n", val);

    if (val > ((1ULL << bits) - 1)) {
        printf("val out of dynamic range\n");
    } else {
        printf("val is ok with dynamic range
    }

    if (val > ((1ULL << 64) - 1)) {
        printf("val out of static range\n");
    } else {
        printf("val is ok with static range\n");
    }
}
---------------- snip to get foo.c ----------------

Yielding output:

    [ snip ]

    range at 60 is 0x0fffffffffffffff
    range at 61 is 0x1fffffffffffffff
    range at 62 is 0x3fffffffffffffff
    range at 63 is 0x7fffffffffffffff
    range at 64 is 0x0000000000000000
    val   is 0x00000000abcd1234
    val out of dynamic range
    val is ok with static range

This is:

    jdl.com 1069 % gcc -v
    Using built-in specs.
    Target: i486-linux-gnu
    Configured with: ../src/configure -v
    --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
    --enable-shared --with-system-zlib --libexecdir=/usr/lib
    --without-included-gettext --enable-threads=posix --enable-nls
    --with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
    --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
    --enable-mpfr --with-tune=i686 --enable-checking=release
    i486-linux-gnu
    Thread model: posix
    gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)

Which seems at least reasonable, though perhaps wrong. :-)

> > -static void write_propval_bytes(FILE *f, struct data val)
> > +static void write_propval_bytes(FILE *f, struct data val, int dts_version)
> >  {
> >  	void *propend = val.val + val.len;
> >  	char *bp = val.val;
> >  
> >  	fprintf(f, " = [");
> >  	for (;;) {
> > -		fprintf(f, "%02hhx", *bp++);
> > +		if (dts_version == 0) {
> > +			fprintf(f, "%02hhx", *bp++);
> > +		} else {
> > +			fprintf(f, "0x%02hhx", *bp++);
> > +		}
> 
> Uh.. not quite right.  My patch (intentionally) leaves bytestrings as
> pure hex, without 0x.

Ugh.  That seems inconsistent and wrong to me.

> We can argue about whether that's a good idea,
> if you like,

And in the blue corner, touting consistent hex forms, ...

> but in any case input and output should match.

Oops.  That they should.

> To avoid this sort of problem, I suggest before we apply the dts-v1
> transition, we apply the patch I'm working on (I'll try to get it out
> today), which adds a bunch of extra testcases checking that using dtc
> to go dtb->dts->dtb preserves everything.

Yeah, I've been doing that too...  Sounds good.

Thanks,
jdl

^ permalink raw reply

* Re: [PATCH] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
From: Sergej Stepanov @ 2007-11-07 13:40 UTC (permalink / raw)
  To: Scott Wood; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20071106184649.GA5283@loki.buserror.net>

Am Dienstag, den 06.11.2007, 12:46 -0600 schrieb Scott Wood:
> >  
> > +   The "reg"-property may have also depending on board design
> > +   the following form:
> > +	reg = <10d40 14 10d60 14>;
> > +   In that case the pin for mdio data controlling is on the port C,
> > +   and the pin for mdio clock controlling is on the port D.
> 
> It'd be better to explicitly say that the first resource is mdio, and the
> second resource is mdc, rather than require the reader to know/look up which
> corresponds to 10d40 and which to 10d60.
> 
> -Scott

Ok. What would you say about something like that:
--
If both mdio and mdc controlling pins are on the same processor port,
one resource should be used.
Otherwise, two resources are used: the 1-st - mdio, the 2-nd - mdc.
--
Please, correct me, if it sounds bad.

Thanks and regards
Sergej. 

^ permalink raw reply

* Bootloader & Flash
From: schardt @ 2007-11-07 12:00 UTC (permalink / raw)
  To: Linuxppc-embedded

Hi,

i use the AVnet Xilinx4 FX12 Minimodule and until now, i use system-ace
to configure the fpga and boot the linux kernel.
But now, i want to boot from the on board flash memory and have no idea
where to start.

I think i have to:
- save the fpga configuration in the fpga-prom
- use/program some kind of bootloader store in fpga block ram to jump to
the flash-adress where the executable linux kernel resist
- use the mtd-device driver to mount  root fs on the same flash some
address later

Is this the right way ?


Regards
Georg






-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich

Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. 
Vorsitzender)
-----------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------

^ permalink raw reply

* Re: [RFC/PATCH 0/2] powerpc: 64 bits irqtrace / lockdep support
From: Johannes Berg @ 2007-11-07 10:22 UTC (permalink / raw)
  To: Tim Pepper; +Cc: External List
In-Reply-To: <eada2a070711061136l18ac7651h85bf3da19a79b669@mail.gmail.com>

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


On Tue, 2007-11-06 at 11:36 -0800, Tim Pepper wrote:
> On 10/14/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > This is 2 patches, one from Christoph Hellwig that adds the backtrace support,
> > and one from Johannes Berg modified by me that adds the irq tracing support.
> >
> > This successfully boots a POWER5 pSeries machine. I'm going to run some more
> > tests in the upcoming few days, so this is not an official submission (and it's
> > too late for .24 merge window anyway) but it's looking good so far.
> 
> FYI: Boots and survives watching /proc/lock_stat during a kernel build
> for me (on a 970 based blade).

Hmm. I should give it another try and see why it breaks for me. Could be
CONFIG_HIBERNATION related maybe.

johannes

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

^ permalink raw reply

* [PATCH (resend, for 2.6.24)] windfarm: fix windfarm thread freezer interaction
From: Johannes Berg @ 2007-11-07 10:18 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: Rafael J. Wysocki, linuxppc-dev list

When I fixed the windfarm freezer interaction first in commit
1ed2ddf380e19dafeec2150ca709ef7f4a67cd21, an earlier patch than the one
I came up with after comments was committed. This has come back to haunt
us now because commit d5d8c5976d6adeddb8208c240460411e2198b393 changed
the freezer to no long send signals. Fix it by removing the windfarm
thread's signal logic and restoring the original try_to_freeze().

We could simply revert 1ed2ddf380e19dafeec2150ca709ef7f4a67cd21 now
but I feel that the assertion that no signal is delivered to the
windfarm thread needs not be there.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
---
This fixes a regression: with 2.6.24 hibernation can no longer work
because the windfarm thread never freezes.

 drivers/macintosh/windfarm_core.c |   10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

--- linux-2.6-git.orig/drivers/macintosh/windfarm_core.c	2007-10-23 14:23:02.406437623 +0200
+++ linux-2.6-git/drivers/macintosh/windfarm_core.c	2007-10-23 14:25:28.745447695 +0200
@@ -94,7 +94,9 @@ static int wf_thread_func(void *data)
 	DBG("wf: thread started\n");
 
 	set_freezable();
-	while(!kthread_should_stop()) {
+	while (!kthread_should_stop()) {
+		try_to_freeze();
+
 		if (time_after_eq(jiffies, next)) {
 			wf_notify(WF_EVENT_TICK, NULL);
 			if (wf_overtemp) {
@@ -116,12 +118,6 @@ static int wf_thread_func(void *data)
 		delay = next - jiffies;
 		if (delay <= HZ)
 			schedule_timeout_interruptible(delay);
-
-		/* there should be no non-suspend signal, but oh well */
-		if (signal_pending(current) && !try_to_freeze()) {
-			printk(KERN_WARNING "windfarm: thread got sigl !\n");
-			break;
-		}
 	}
 
 	DBG("wf: thread stopped\n");

^ permalink raw reply

* Re: 2.6.24-rc1-git15 Kernel build fails on powerpc - Unrecognized opcode: `dssall'
From: Johannes Berg @ 2007-11-07  9:38 UTC (permalink / raw)
  To: Andy Whitcroft
  Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, sam, David Miller,
	Balbir Singh
In-Reply-To: <20071106154439.GK5080@shadowen.org>

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



> So that sounds like a Kconfig problem then?  That HIBERATION requires
> ALITIVEC and yet does not depend on it or set it.

Yes. I'm guessing that it broke with Rafael's hibernation/suspend
Kconfig changes but will take a look. I think it used to depend on
powermac.

johannes

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

^ permalink raw reply

* Re: [ofa-general] Re: problem in follow_hugetlb_page on ppc64 architecture with get_user_pages
From: Christoph Raisch @ 2007-11-07  8:35 UTC (permalink / raw)
  To: David Gibson
  Cc: Roland Dreier, linux-kernel, linux-ppc, general-bounces,
	Hoang-Nam Nguyen, general, Hoang-Nam Nguyen
In-Reply-To: <20071106223119.GC31367@localhost.localdomain>


general-bounces@lists.openfabrics.org wrote on 06.11.2007 23:31:19:


> We should cut this down to the bare necessary and fold it into the
> libhugetlbfs testsuite.

Well, this testcase is already pretty close to the bare minimum
what's needed to run IB/RDMA queues.
You can compare this to for example ibv_rc_pingpong in libibverbs...

Maybe it's possible to test this with anything else than IB?

> --
Gruss / Regards
Christoph R

^ permalink raw reply


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