* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01 0:36 UTC (permalink / raw)
To: linuxppc-embedded
At 05:51 PM 2/29/2008, you wrote:
>On Fri, 29 Feb 2008 17:31:10 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > At 04:35 PM 2/29/2008, Josh Boyer wrote:
> > >On Fri, 29 Feb 2008 16:34:09 -0500
> > >Steve Heflin <sheflin@newagemicro.com> wrote:
> > >
> > > > I attempted to enable the kernel debugger on my Sequoia board, and I
> > > > get build errors:
> > > > /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:254: undefined
> > > > reference to `set_debug_traps'
> > > > /linux-2.6.25-rc3/arch/powerpc/kernel/setup_32.c:259: undefined
> > > > reference to `breakpoint'
> > > >
> > > > Josh: I assume you have used the kernel debugger with your 44x
> > > > boards, how did you build it?
> > >
> > >Why would you assume that? I've never used kgdb on arch/powerpc
> > >kernels, nor have I ever tried to build it.
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
>
>Nope. I did the poor man's method of manually poking characters out of
>the serial port.
>
> > worked right out of the gate and you never needed a
> debugger? You're my hero!
>
>I largely stood on the shoulders of those that came before me. Porting
>has become trivial lately, mostly due to the collective work lots of
>people have put in.
>
>That all being said, I'm not opposed to having kgdb work on 4xx. I
>just have never personally looked at it yet. Patches welcome :).
>
>josh
poor man's debugging works fine if a serial port is available, but my
Sequoia platform doesn't get that far! I use u-boot to download and
boot my image, and I don't get any serial output after the boot completes:
=> bootm 0x500000
## Booting image at 00500000 ...
Image Name: Kernel and Ramdisk
Created: 2008-03-01 0:09:57 UTC
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 2430248 Bytes = 2.3 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 1471523 Bytes = 1.4 MB
Image 1: 958712 Bytes = 936.2 kB
Verifying Checksum ... OK
Uncompressing Multi-File Image ... OK
Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
------
console port is now dead.
------
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Wolfgang Denk @ 2008-03-01 0:16 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080229223046.1B332DDE0A@ozlabs.org>
In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
>
> I assumed that because I've always needed a debugger when
> implementing kernel level components. Since you've implemented kernel
> level support for several 44x processors, I just assumed that you
> needed kdbg at some point. So you're saying that your additions
> worked right out of the gate and you never needed a debugger? You're my hero!
Many people working on this stuff use a BDI2000 / BDI3000. Makes life
much easier...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have the simplest tastes. I am always satisfied with the best.
-- Oscar Wilde
^ permalink raw reply
* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: Badari Pulavarty @ 2008-03-01 1:12 UTC (permalink / raw)
To: michael; +Cc: Nathan Lynch, anton, paulus, linuxppc-dev
In-Reply-To: <1204307816.10146.11.camel@dyn9047017100.beaverton.ibm.com>
On Fri, 2008-02-29 at 09:56 -0800, Badari Pulavarty wrote:
> Hi,
>
> I am wondering if you could give me your opinion on how to proceed
> (before I code too much).
>
> eHEA driver writers wants to know what the memory layout is - where the
> holes are and where the reserved memory is. They can get this from
> parsing through the device-tree every time, but it would be too
> expensive. And also, they would like to get information for contiguous
> ranges (instead of 16MB chunks).
>
> Since we already have this information at boot time in lmb.memory,
> lmb.reserve - would it be okay to update those for hotplug mem
> add/remove ? Of course, all the routines which handles updates
> (lmb_add() etc..) are available only at boot (__init). I could
> change that. Is it acceptable ?
>
> Other way to handle the issue is to come up with arch-neutral
> way of representing the memory layout. x86-64 and ia64 shows
> this information in /proc/iomem (even there is in chunks not
> combined).
>
> Ideas ? Would it be acceptable if I update lmb.memory for add/remove
> memory ? Am I missing something ?
Here is what I cooked up and it seems to work fine.
It may be easier to review the code (against my earlier patches).
Thanks,
Badari
ppc kernel maintains information about logical memory blocks in
lmb.memory structure at the boot time. Its not updated for
hotplug memory add/remove. hotplug memory notifier for memory
add/remove now updates lmb.memory.
This information is useful for eHEA driver to find out the memory
layout and holes.
TODO: locking ?
---
arch/powerpc/mm/lmb.c | 61 +++++++++++++++++++++---
arch/powerpc/platforms/pseries/hotplug-memory.c | 42 ++++++++++++++++
include/asm-powerpc/lmb.h | 3 -
3 files changed, 98 insertions(+), 8 deletions(-)
Index: linux-2.6.25-rc2/arch/powerpc/mm/lmb.c
===================================================================
--- linux-2.6.25-rc2.orig/arch/powerpc/mm/lmb.c 2008-02-15 12:57:20.000000000 -0800
+++ linux-2.6.25-rc2/arch/powerpc/mm/lmb.c 2008-02-29 16:55:49.000000000 -0800
@@ -60,13 +60,13 @@ void lmb_dump_all(void)
#endif /* DEBUG */
}
-static unsigned long __init lmb_addrs_overlap(unsigned long base1,
+static unsigned long lmb_addrs_overlap(unsigned long base1,
unsigned long size1, unsigned long base2, unsigned long size2)
{
return ((base1 < (base2+size2)) && (base2 < (base1+size1)));
}
-static long __init lmb_addrs_adjacent(unsigned long base1, unsigned long size1,
+static long lmb_addrs_adjacent(unsigned long base1, unsigned long size1,
unsigned long base2, unsigned long size2)
{
if (base2 == base1 + size1)
@@ -77,7 +77,7 @@ static long __init lmb_addrs_adjacent(un
return 0;
}
-static long __init lmb_regions_adjacent(struct lmb_region *rgn,
+static long lmb_regions_adjacent(struct lmb_region *rgn,
unsigned long r1, unsigned long r2)
{
unsigned long base1 = rgn->region[r1].base;
@@ -88,7 +88,7 @@ static long __init lmb_regions_adjacent(
return lmb_addrs_adjacent(base1, size1, base2, size2);
}
-static void __init lmb_remove_region(struct lmb_region *rgn, unsigned long r)
+static void lmb_remove_region(struct lmb_region *rgn, unsigned long r)
{
unsigned long i;
@@ -100,7 +100,7 @@ static void __init lmb_remove_region(str
}
/* Assumption: base addr of region 1 < base addr of region 2 */
-static void __init lmb_coalesce_regions(struct lmb_region *rgn,
+static void lmb_coalesce_regions(struct lmb_region *rgn,
unsigned long r1, unsigned long r2)
{
rgn->region[r1].size += rgn->region[r2].size;
@@ -135,7 +135,7 @@ void __init lmb_analyze(void)
}
/* This routine called with relocation disabled. */
-static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
+static long lmb_add_region(struct lmb_region *rgn, unsigned long base,
unsigned long size)
{
unsigned long coalesced = 0;
@@ -191,7 +191,7 @@ static long __init lmb_add_region(struct
}
/* This routine may be called with relocation disabled. */
-long __init lmb_add(unsigned long base, unsigned long size)
+long lmb_add(unsigned long base, unsigned long size)
{
struct lmb_region *_rgn = &(lmb.memory);
@@ -203,6 +203,53 @@ long __init lmb_add(unsigned long base,
}
+long lmb_remove(unsigned long base, unsigned long size)
+{
+ struct lmb_region *rgn = &(lmb.memory);
+ unsigned long end = base + size;
+ unsigned long rgnbegin, rgnend;
+ int i;
+
+ /* Find the region where (base, size) belongs to */
+ for (i=0; i < rgn->cnt; i++) {
+ rgnbegin = rgn->region[i].base;
+ rgnend = rgnbegin + rgn->region[i].size;
+
+ if ((rgnbegin <= base) && (end <= rgnend))
+ break;
+ }
+
+ /* Didn't find the region */
+ if (i == rgn->cnt)
+ return -1;
+
+ /* Check to see if we are removing entire region */
+ if ((rgnbegin == base) && (rgnend == end)) {
+ lmb_remove_region(rgn, i);
+ return 0;
+ }
+
+ /* Check to see if region is matching at the front */
+ if (rgnbegin == base) {
+ rgn->region[i].base = end;
+ rgn->region[i].size -= size;
+ return 0;
+ }
+
+ /* Check to see if the region is matching at the end */
+ if (rgnend == end) {
+ rgn->region[i].size -= size;
+ return 0;
+ }
+
+ /*
+ * We need to split the entry - adjust the current one to the
+ * beginging of the hole and add the region after hole.
+ */
+ rgn->region[i].size = base - rgn->region[i].base;
+ return lmb_add_region(rgn, end, rgnend - end);
+}
+
long __init lmb_reserve(unsigned long base, unsigned long size)
{
struct lmb_region *_rgn = &(lmb.reserved);
Index: linux-2.6.25-rc2/include/asm-powerpc/lmb.h
===================================================================
--- linux-2.6.25-rc2.orig/include/asm-powerpc/lmb.h 2008-02-15 12:57:20.000000000 -0800
+++ linux-2.6.25-rc2/include/asm-powerpc/lmb.h 2008-02-29 13:42:03.000000000 -0800
@@ -41,7 +41,8 @@ extern struct lmb lmb;
extern void __init lmb_init(void);
extern void __init lmb_analyze(void);
-extern long __init lmb_add(unsigned long base, unsigned long size);
+extern long lmb_add(unsigned long base, unsigned long size);
+extern long lmb_remove(unsigned long base, unsigned long size);
extern long __init lmb_reserve(unsigned long base, unsigned long size);
extern unsigned long __init lmb_alloc(unsigned long size, unsigned long align);
extern unsigned long __init lmb_alloc_base(unsigned long size,
Index: linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c
===================================================================
--- linux-2.6.25-rc2.orig/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-29 09:25:14.000000000 -0800
+++ linux-2.6.25-rc2/arch/powerpc/platforms/pseries/hotplug-memory.c 2008-02-29 16:58:33.000000000 -0800
@@ -12,6 +12,7 @@
#include <asm/prom.h>
#include <asm/firmware.h>
#include <asm/machdep.h>
+#include <asm/lmb.h>
#include <asm/pSeries_reconfig.h>
static int pseries_remove_memory(struct device_node *np)
@@ -58,6 +59,11 @@ static int pseries_remove_memory(struct
return ret;
/*
+ * Update memory regions for memory remove
+ */
+ lmb_remove(start_pfn << PAGE_SHIFT, regs[3]);
+
+ /*
* Remove htab bloted mappings for this section of memory
*/
start = (unsigned long)__va(start_pfn << PAGE_SHIFT);
@@ -65,6 +71,40 @@ static int pseries_remove_memory(struct
return ret;
}
+static int pseries_add_memory(struct device_node *np)
+{
+ const char *type;
+ const unsigned int *my_index;
+ const unsigned int *regs;
+ u64 start_pfn;
+ int ret = -EINVAL;
+
+ /*
+ * Check to see if we are actually adding memory
+ */
+ type = of_get_property(np, "device_type", NULL);
+ if (type == NULL || strcmp(type, "memory") != 0)
+ return 0;
+
+ /*
+ * Find the memory index and size of the removing section
+ */
+ my_index = of_get_property(np, "ibm,my-drc-index", NULL);
+ if (!my_index)
+ return ret;
+
+ regs = of_get_property(np, "reg", NULL);
+ if (!regs)
+ return ret;
+
+ start_pfn = section_nr_to_pfn(*my_index & 0xffff);
+
+ /*
+ * Update memory region to represent the memory add
+ */
+ return lmb_add(start_pfn << PAGE_SHIFT, regs[3]);
+}
+
static int pseries_memory_notifier(struct notifier_block *nb,
unsigned long action, void *node)
{
@@ -72,6 +112,8 @@ static int pseries_memory_notifier(struc
switch (action) {
case PSERIES_RECONFIG_ADD:
+ if (pseries_add_memory(node))
+ err = NOTIFY_BAD;
break;
case PSERIES_RECONFIG_REMOVE:
if (pseries_remove_memory(node))
^ permalink raw reply
* [PATCH 0/3] firewire: PPC PMac updates
From: Stefan Richter @ 2008-03-01 1:42 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
Next up:
1/3 firewire: fw-ohci: PPC PMac platform code
2/3 firewire: fw-ohci: Apple UniNorth 1st generation support
3/3 firewire: fw-ohci: shut up false compiler warning on PPC32
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01 1:42 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>
Copied from ohci1394.c. This code is necessary to prevent machine check
exceptions when reloading or resuming the driver.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
drivers/firewire/fw-ohci.c | 50 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -33,6 +33,10 @@
#include <asm/page.h>
#include <asm/system.h>
+#ifdef CONFIG_PPC_PMAC
+#include <asm/pmac_feature.h>
+#endif
+
#include "fw-ohci.h"
#include "fw-transaction.h"
@@ -2057,6 +2061,18 @@ pci_probe(struct pci_dev *dev, const str
int err;
size_t size;
+#ifdef CONFIG_PPC_PMAC
+ /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(dev);
+
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+ }
+ }
+#endif /* CONFIG_PPC_PMAC */
+
ohci = kzalloc(sizeof(*ohci), GFP_KERNEL);
if (ohci == NULL) {
fw_error("Could not malloc fw_ohci data.\n");
@@ -2189,6 +2205,20 @@ static void pci_remove(struct pci_dev *d
pci_iounmap(dev, ohci->registers);
pci_release_region(dev, 0);
pci_disable_device(dev);
+
+#ifdef CONFIG_PPC_PMAC
+ /* On UniNorth, power down the cable and turn off the chip clock
+ * to save power on laptops */
+ if (machine_is(powermac)) {
+ struct device_node* ofn = pci_device_to_OF_node(dev);
+
+ if (ofn) {
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
+ }
+ }
+#endif /* CONFIG_PPC_PMAC */
+
kfree(&ohci->card);
fw_notify("Removed fw-ohci device.\n");
@@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
if (err)
fw_error("pci_set_power_state failed with %d\n", err);
+/* PowerMac suspend code comes last */
+#ifdef CONFIG_PPC_PMAC
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(pdev);
+
+ if (ofn)
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
return 0;
}
@@ -2219,6 +2259,16 @@ static int pci_resume(struct pci_dev *pd
struct fw_ohci *ohci = pci_get_drvdata(pdev);
int err;
+/* PowerMac resume code comes first */
+#ifdef CONFIG_PPC_PMAC
+ if (machine_is(powermac)) {
+ struct device_node *ofn = pci_device_to_OF_node(pdev);
+
+ if (ofn)
+ pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
+ }
+#endif /* CONFIG_PPC_PMAC */
+
pci_set_power_state(pdev, PCI_D0);
pci_restore_state(pdev);
err = pci_enable_device(pdev);
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: David Miller @ 2008-03-01 1:44 UTC (permalink / raw)
To: pbadari; +Cc: paulus, anton, ntl, linuxppc-dev
In-Reply-To: <1204333964.10146.18.camel@dyn9047017100.beaverton.ibm.com>
From: Badari Pulavarty <pbadari@us.ibm.com>
Date: Fri, 29 Feb 2008 17:12:44 -0800
> Here is what I cooked up and it seems to work fine.
> It may be easier to review the code (against my earlier patches).
BTW, the lmb code now lives under lib/ (sparc64 will be using it too)
and has several bug fixes applied to it in Paulus's current upstream
tree.
^ permalink raw reply
* [PATCH 2/3] firewire: fw-ohci: Apple UniNorth 1st generation support
From: Stefan Richter @ 2008-03-01 1:47 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>
Mostly copied from ohci1394.c. Necessary for some older Macs, e.g.
PowerBook G3 Pismo and early PowerBook G4 Titanium.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Since my TiBook has a broken FireWire PHY I was only able to test
the byte order of self ID packets but not of the headers of any
other packets. The code in handle_ar_packet() is only guesswork
from ohci1394.c's respective code. Also, I wonder what's up with
isochronous packets...
drivers/firewire/fw-ohci.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)
Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -179,6 +179,7 @@ struct fw_ohci {
int generation;
int request_generation;
u32 bus_seconds;
+ bool old_uninorth;
/*
* Spinlock for accessing fw_ohci data. Never call out of
@@ -315,15 +316,22 @@ static int ar_context_add_page(struct ar
return 0;
}
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
+#define cond_le32_to_cpu(v) \
+ (ohci->old_uninorth ? (__force __u32)(v) : le32_to_cpu(v))
+#else
+#define cond_le32_to_cpu(v) le32_to_cpu(v)
+#endif
+
static __le32 *handle_ar_packet(struct ar_context *ctx, __le32 *buffer)
{
struct fw_ohci *ohci = ctx->ohci;
struct fw_packet p;
u32 status, length, tcode;
- p.header[0] = le32_to_cpu(buffer[0]);
- p.header[1] = le32_to_cpu(buffer[1]);
- p.header[2] = le32_to_cpu(buffer[2]);
+ p.header[0] = cond_le32_to_cpu(buffer[0]);
+ p.header[1] = cond_le32_to_cpu(buffer[1]);
+ p.header[2] = cond_le32_to_cpu(buffer[2]);
tcode = (p.header[0] >> 4) & 0x0f;
switch (tcode) {
@@ -335,7 +343,7 @@ static __le32 *handle_ar_packet(struct a
break;
case TCODE_READ_BLOCK_REQUEST :
- p.header[3] = le32_to_cpu(buffer[3]);
+ p.header[3] = cond_le32_to_cpu(buffer[3]);
p.header_length = 16;
p.payload_length = 0;
break;
@@ -344,7 +352,7 @@ static __le32 *handle_ar_packet(struct a
case TCODE_READ_BLOCK_RESPONSE:
case TCODE_LOCK_REQUEST:
case TCODE_LOCK_RESPONSE:
- p.header[3] = le32_to_cpu(buffer[3]);
+ p.header[3] = cond_le32_to_cpu(buffer[3]);
p.header_length = 16;
p.payload_length = p.header[3] >> 16;
break;
@@ -361,7 +369,7 @@ static __le32 *handle_ar_packet(struct a
/* FIXME: What to do about evt_* errors? */
length = (p.header_length + p.payload_length + 3) / 4;
- status = le32_to_cpu(buffer[length]);
+ status = cond_le32_to_cpu(buffer[length]);
p.ack = ((status >> 16) & 0x1f) - 16;
p.speed = (status >> 21) & 0x7;
@@ -1026,13 +1034,14 @@ static void bus_reset_tasklet(unsigned l
*/
self_id_count = (reg_read(ohci, OHCI1394_SelfIDCount) >> 3) & 0x3ff;
- generation = (le32_to_cpu(ohci->self_id_cpu[0]) >> 16) & 0xff;
+ generation = (cond_le32_to_cpu(ohci->self_id_cpu[0]) >> 16) & 0xff;
rmb();
for (i = 1, j = 0; j < self_id_count; i += 2, j++) {
if (ohci->self_id_cpu[i] != ~ohci->self_id_cpu[i + 1])
fw_error("inconsistent self IDs\n");
- ohci->self_id_buffer[j] = le32_to_cpu(ohci->self_id_cpu[i]);
+ ohci->self_id_buffer[j] =
+ cond_le32_to_cpu(ohci->self_id_cpu[i]);
}
rmb();
@@ -2091,6 +2100,10 @@ pci_probe(struct pci_dev *dev, const str
pci_write_config_dword(dev, OHCI1394_PCI_HCI_Control, 0);
pci_set_drvdata(dev, ohci);
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
+ ohci->old_uninorth = dev->vendor == PCI_VENDOR_ID_APPLE &&
+ dev->device == PCI_DEVICE_ID_APPLE_UNI_N_FW;
+#endif
spin_lock_init(&ohci->lock);
tasklet_init(&ohci->bus_reset_tasklet,
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01 1:48 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20080301001632.BA47B2476B@gemini.denx.de>
At 07:16 PM 2/29/2008, Wolfgang Denk wrote:
>In message <20080229223046.1B332DDE0A@ozlabs.org> you wrote:
> >
> > I assumed that because I've always needed a debugger when
> > implementing kernel level components. Since you've implemented kernel
> > level support for several 44x processors, I just assumed that you
> > needed kdbg at some point. So you're saying that your additions
> > worked right out of the gate and you never needed a
> debugger? You're my hero!
>
>Many people working on this stuff use a BDI2000 / BDI3000. Makes life
>much easier...
Wolfgang, you hit the nail on the head. Trying to debug a target
without a JTAG debugger is a pain.
^ permalink raw reply
* [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stefan Richter @ 2008-03-01 1:50 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.ac97915a5b51e35b@s5r6.in-berlin.de>
Shut up two "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Wasn't there a macro somewhere for this?
Also, could this be better done in PPC32's dma_alloc_coherent()?
At least this kind of workaround here doesn't add anything to the
compiled result.
drivers/firewire/fw-ohci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
===================================================================
--- linux-2.6.25-rc3.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.25-rc3/drivers/firewire/fw-ohci.c
@@ -544,7 +544,7 @@ static int
context_add_buffer(struct context *ctx)
{
struct descriptor_buffer *desc;
- dma_addr_t bus_addr;
+ dma_addr_t bus_addr = bus_addr;
int offset;
/*
@@ -1334,7 +1334,7 @@ ohci_set_config_rom(struct fw_card *card
unsigned long flags;
int retval = -EBUSY;
__be32 *next_config_rom;
- dma_addr_t next_config_rom_bus;
+ dma_addr_t next_config_rom_bus = next_config_rom_bus;
ohci = fw_ohci(card);
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01 2:04 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <tkrat.7e8e04e66a38dcd6@s5r6.in-berlin.de>
I wrote:
> + struct device_node* ofn = pci_device_to_OF_node(dev);
-ECOPYANDWASTE: struct device_node *ofn
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Josh Boyer @ 2008-03-01 2:30 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <200803010023.m210NHwr011345@e2.ny.us.ibm.com>
On Fri, 29 Feb 2008 19:23:40 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
Putting the list back on CC because I'm sure you won't be the only
person to have this issue.
> poor man's debugging works fine if a serial port is available, but my
> Sequoia platform doesn't get that far! I use u-boot to download and
> boot my image, and I don't get any serial output after the boot completes:
By "poking characters out the serial port" I meant I literally coded up
assembly functions to setup MMU translations and poke hex values at hard
coded addresses. That's why it's "poor man's". If you had a working
serial port out of the box, that would be a luxury ;).
> => bootm 0x500000
> ## Booting image at 00500000 ...
> Image Name: Kernel and Ramdisk
> Created: 2008-03-01 0:09:57 UTC
> Image Type: PowerPC Linux Multi-File Image (gzip compressed)
> Data Size: 2430248 Bytes = 2.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Contents:
> Image 0: 1471523 Bytes = 1.4 MB
> Image 1: 958712 Bytes = 936.2 kB
> Verifying Checksum ... OK
> Uncompressing Multi-File Image ... OK
> Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> ------
> console port is now dead.
> ------
What image type are you using? If this is an older U-Boot, you'll need
to use the cuImage.sequoia file that is produced when you compile your
kernel with 'make zImage'. Sequoia (and I'm assuming you mean the
AMCC Sequoia Eval Board, not some custom hardware that's based on it)
has been working fine for a long time.
It seems you have some kind of other uImage, so try using the one
that's built with the kernel and go from there.
josh
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Stephen Rothwell @ 2008-03-01 2:51 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1204307236.10146.1.camel@dyn9047017100.beaverton.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Fri, 29 Feb 2008 09:47:16 -0800 Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> Here is the latest for review. (just to make sure I didn't miss
> anything).
Sorry I didn't review the previous ones ... just a small thing.
> + type = of_get_property(np, "device_type", NULL);
To use the of_ accessors, you need to include linux/of.h (currently
asm/prom.h include linux/of.h, but that may not always be true). In
fact, I think you don't even need asm/prom.h.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Steve Heflin @ 2008-03-01 2:55 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20080229203015.0ada459e@zod.rchland.ibm.com>
At 09:30 PM 2/29/2008, Josh Boyer wrote:
>On Fri, 29 Feb 2008 19:23:40 -0500
>Steve Heflin <sheflin@newagemicro.com> wrote:
>
>Putting the list back on CC because I'm sure you won't be the only
>person to have this issue.
>
> > poor man's debugging works fine if a serial port is available, but my
> > Sequoia platform doesn't get that far! I use u-boot to download and
> > boot my image, and I don't get any serial output after the boot completes:
>
>By "poking characters out the serial port" I meant I literally coded up
>assembly functions to setup MMU translations and poke hex values at hard
>coded addresses. That's why it's "poor man's". If you had a working
>serial port out of the box, that would be a luxury ;).
>
> > => bootm 0x500000
> > ## Booting image at 00500000 ...
> > Image Name: Kernel and Ramdisk
> > Created: 2008-03-01 0:09:57 UTC
> > Image Type: PowerPC Linux Multi-File Image (gzip compressed)
> > Data Size: 2430248 Bytes = 2.3 MB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Contents:
> > Image 0: 1471523 Bytes = 1.4 MB
> > Image 1: 958712 Bytes = 936.2 kB
> > Verifying Checksum ... OK
> > Uncompressing Multi-File Image ... OK
> > Loading Ramdisk to 07e42000, end 07f2c0f8 ... OK
> > ------
> > console port is now dead.
> > ------
>
>What image type are you using? If this is an older U-Boot, you'll need
>to use the cuImage.sequoia file that is produced when you compile your
>kernel with 'make zImage'. Sequoia (and I'm assuming you mean the
>AMCC Sequoia Eval Board, not some custom hardware that's based on it)
>has been working fine for a long time.
>
>It seems you have some kind of other uImage, so try using the one
>that's built with the kernel and go from there.
>
>josh
thank you so much for your helpful reply. No, I don't have a serial
port that works "out of the box", and your hint of setting up the MMU
translations and poking characters at hard coded addresses, is a big help.
My hardware is NOT a Sequoia eval, it is a custom board derived from
the Sequoia platform back at 2.6.14. In a previous message when you
said that ECC should be handled by the NAND driver, I figured out
that our AMCC-440EPx board was not a standard Sequoia. Ours has DDR
ECC and the setup code writes to several registers to enable it. I
still offer this code to you.
I've used the zImage, the uImage, and the vmlinux image, all with the
same results. My last attempt was a uImage, so I'll switch to the
zImage and try again.
thanks so much for your help,
Steve
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Benjamin Herrenschmidt @ 2008-03-01 2:59 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <tkrat.7e8e04e66a38dcd6@s5r6.in-berlin.de>
> +#ifdef CONFIG_PPC_PMAC
> + /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
> + if (machine_is(powermac)) {
> + struct device_node *ofn = pci_device_to_OF_node(dev);
> +
> + if (ofn) {
> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
> + }
> + }
> +#endif /* CONFIG_PPC_PMAC */
I -think- that the hunk above can be removed if you just call
pci_enable_device(). I have a hook in the arch pcibios_enable_device()
that detects the internal firewire and does the calls. Can you verify it
works ?
> +#ifdef CONFIG_PPC_PMAC
> + /* On UniNorth, power down the cable and turn off the chip clock
> + * to save power on laptops */
> + if (machine_is(powermac)) {
> + struct device_node* ofn = pci_device_to_OF_node(dev);
> +
> + if (ofn) {
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 0);
> + }
> + }
> +#endif /* CONFIG_PPC_PMAC */
Unfortunately, I don't have the pending hook here for disable so you
need to keep that one for now.
> kfree(&ohci->card);
>
> fw_notify("Removed fw-ohci device.\n");
> @@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
> if (err)
> fw_error("pci_set_power_state failed with %d\n", err);
>
> +/* PowerMac suspend code comes last */
> +#ifdef CONFIG_PPC_PMAC
> + if (machine_is(powermac)) {
> + struct device_node *ofn = pci_device_to_OF_node(pdev);
> +
> + if (ofn)
> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
> + }
> +#endif /* CONFIG_PPC_PMAC */
I wonder why we don't do the cable power thingy here...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/3] ppc64-specific memory notifier support
From: Badari Pulavarty @ 2008-03-01 3:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <20080301135123.262bfdb0.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Fri, 29 Feb 2008 09:47:16 -0800 Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
>> Here is the latest for review. (just to make sure I didn't miss
>> anything).
>>
>
> Sorry I didn't review the previous ones ... just a small thing.
>
>
>> + type = of_get_property(np, "device_type", NULL);
>>
>
> To use the of_ accessors, you need to include linux/of.h (currently
> asm/prom.h include linux/of.h, but that may not always be true). In
> fact, I think you don't even need asm/prom.h.
>
>
Yes. linux/of.h is enough. Thank you for pointing it out.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Benjamin Herrenschmidt @ 2008-03-01 3:04 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, paulus, LKML
In-Reply-To: <1204301097.14759.6.camel@localhost.localdomain>
On Fri, 2008-02-29 at 11:04 -0500, Steven Rostedt wrote:
> strncmp is defined in assembly for bootup, but it is not defined in the
> normal running kernel. This patch takes the strncmp code from the bootup
> and copies it to the kernel proper.
>
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> ---
Do we have any indication that it performs better than the C one ?
Ben.
> arch/powerpc/kernel/ppc_ksyms.c | 1 +
> arch/powerpc/lib/string.S | 12 ++++++++++++
> include/asm-powerpc/string.h | 2 ++
> 3 files changed, 15 insertions(+)
>
> Index: linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c
> ===================================================================
> --- linux-sched-devel.git.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-02-27 14:01:38.000000000 -0800
> +++ linux-sched-devel.git/arch/powerpc/kernel/ppc_ksyms.c 2008-02-29 07:24:22.000000000 -0800
> @@ -78,6 +78,7 @@ EXPORT_SYMBOL(strncpy);
> EXPORT_SYMBOL(strcat);
> EXPORT_SYMBOL(strlen);
> EXPORT_SYMBOL(strcmp);
> +EXPORT_SYMBOL(strncmp);
>
> EXPORT_SYMBOL(csum_partial);
> EXPORT_SYMBOL(csum_partial_copy_generic);
> Index: linux-sched-devel.git/arch/powerpc/lib/string.S
> ===================================================================
> --- linux-sched-devel.git.orig/arch/powerpc/lib/string.S 2008-02-27 14:01:38.000000000 -0800
> +++ linux-sched-devel.git/arch/powerpc/lib/string.S 2008-02-29 07:24:22.000000000 -0800
> @@ -75,6 +75,18 @@ _GLOBAL(strcmp)
> beq 1b
> blr
>
> +_GLOBAL(strncmp)
> + mtctr r5
> + addi r5,r3,-1
> + addi r4,r4,-1
> +1: lbzu r3,1(r5)
> + cmpwi 1,r3,0
> + lbzu r0,1(r4)
> + subf. r3,r0,r3
> + beqlr 1
> + bdnzt eq,1b
> + blr
> +
> _GLOBAL(strlen)
> addi r4,r3,-1
> 1: lbzu r0,1(r4)
> Index: linux-sched-devel.git/include/asm-powerpc/string.h
> ===================================================================
> --- linux-sched-devel.git.orig/include/asm-powerpc/string.h 2008-02-27 14:01:58.000000000 -0800
> +++ linux-sched-devel.git/include/asm-powerpc/string.h 2008-02-29 07:24:22.000000000 -0800
> @@ -7,6 +7,7 @@
> #define __HAVE_ARCH_STRNCPY
> #define __HAVE_ARCH_STRLEN
> #define __HAVE_ARCH_STRCMP
> +#define __HAVE_ARCH_STRNCMP
> #define __HAVE_ARCH_STRCAT
> #define __HAVE_ARCH_MEMSET
> #define __HAVE_ARCH_MEMCPY
> @@ -18,6 +19,7 @@ extern char * strcpy(char *,const char *
> extern char * strncpy(char *,const char *, __kernel_size_t);
> extern __kernel_size_t strlen(const char *);
> extern int strcmp(const char *,const char *);
> +extern int strncmp(const char *,const char *,__kernel_size_t);
> extern char * strcat(char *, const char *);
> extern void * memset(void *,int,__kernel_size_t);
> extern void * memcpy(void *,const void *,__kernel_size_t);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] updating lmb.memory information for hot mem add/remove
From: Badari Pulavarty @ 2008-03-01 3:06 UTC (permalink / raw)
To: David Miller; +Cc: paulus, anton, ntl, linuxppc-dev
In-Reply-To: <20080229.174434.216640668.davem@davemloft.net>
David Miller wrote:
> From: Badari Pulavarty <pbadari@us.ibm.com>
> Date: Fri, 29 Feb 2008 17:12:44 -0800
>
>
>> Here is what I cooked up and it seems to work fine.
>> It may be easier to review the code (against my earlier patches).
>>
>
> BTW, the lmb code now lives under lib/ (sparc64 will be using it too)
> and has several bug fixes applied to it in Paulus's current upstream
> tree.
>
Yes. I noticed that earlier. But it was easy for me to test against
mainline/-mm.
I can easily update it against Paul's tree, if every one is okay with
the changes
I am proposing.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stephen Rothwell @ 2008-03-01 3:17 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <tkrat.ee238048a5a50184@s5r6.in-berlin.de>
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
On Sat, 1 Mar 2008 02:50:44 +0100 (CET) Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>
> Shut up two "may be used uninitialised in this function" warnings due to
> PPC32's implementation of dma_alloc_coherent().
>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
>
> Wasn't there a macro somewhere for this?
Yes, uninitialized_var() in linux/compiler*.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Steven Rostedt @ 2008-03-01 3:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, LKML
In-Reply-To: <1204340690.15052.457.camel@pasglop>
On Sat, 1 Mar 2008, Benjamin Herrenschmidt wrote:
>
> Do we have any indication that it performs better than the C one ?
See below.
>
> Ben.
>
> >
> > +_GLOBAL(strncmp)
> > + mtctr r5
> > + addi r5,r3,-1
> > + addi r4,r4,-1
> > +1: lbzu r3,1(r5)
> > + cmpwi 1,r3,0
> > + lbzu r0,1(r4)
> > + subf. r3,r0,r3
> > + beqlr 1
> > + bdnzt eq,1b
> > + blr
> > +
And here's the objdump of the C version:
0000000000000080 <.strncmp>:
80: fb e1 ff f0 std r31,-16(r1)
84: f8 21 ff c1 stdu r1,-64(r1)
88: 7c 69 1b 78 mr r9,r3
8c: 7c a0 2b 79 mr. r0,r5
90: 38 60 00 00 li r3,0
94: 7c 09 03 a6 mtctr r0
98: 7c 3f 0b 78 mr r31,r1
9c: 41 82 00 68 beq- 104 <.strncmp+0x84>
a0: 89 69 00 00 lbz r11,0(r9)
a4: 88 04 00 00 lbz r0,0(r4)
a8: 7c 00 58 50 subf r0,r0,r11
ac: 78 00 06 20 clrldi r0,r0,56
b0: 2f a0 00 00 cmpdi cr7,r0,0
b4: 7c 00 07 74 extsb r0,r0
b8: 7c 03 03 78 mr r3,r0
bc: 40 9e 00 48 bne- cr7,104 <.strncmp+0x84>
c0: 2f ab 00 00 cmpdi cr7,r11,0
c4: 41 9e 00 40 beq- cr7,104 <.strncmp+0x84>
c8: 38 84 00 01 addi r4,r4,1
cc: 38 69 00 01 addi r3,r9,1
d0: 42 40 00 30 bdz- 100 <.strncmp+0x80>
d4: 88 03 00 00 lbz r0,0(r3)
d8: 89 24 00 00 lbz r9,0(r4)
dc: 38 63 00 01 addi r3,r3,1
e0: 38 84 00 01 addi r4,r4,1
e4: 2f 20 00 00 cmpdi cr6,r0,0
e8: 7c 09 00 50 subf r0,r9,r0
ec: 78 00 06 20 clrldi r0,r0,56
f0: 2f a0 00 00 cmpdi cr7,r0,0
f4: 7c 00 07 74 extsb r0,r0
f8: 40 9e 00 08 bne- cr7,100 <.strncmp+0x80>
fc: 40 9a ff d4 bne+ cr6,d0 <.strncmp+0x50>
100: 7c 03 03 78 mr r3,r0
104: e8 21 00 00 ld r1,0(r1)
108: eb e1 ff f0 ld r31,-16(r1)
10c: 4e 80 00 20 blr
I'll let you decide ;-)
Even if it was logically faster (which I still doubt) it's a hell of a lot
of cache lines to waste.
-- Steve
^ permalink raw reply
* Re: Sequoia build with KDBG
From: Olof Johansson @ 2008-03-01 5:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: Steve Heflin, linuxppc-embedded
In-Reply-To: <20080229203015.0ada459e@zod.rchland.ibm.com>
On Fri, Feb 29, 2008 at 08:30:15PM -0600, Josh Boyer wrote:
> > poor man's debugging works fine if a serial port is available, but my
> > Sequoia platform doesn't get that far! I use u-boot to download and
> > boot my image, and I don't get any serial output after the boot completes:
>
> By "poking characters out the serial port" I meant I literally coded up
> assembly functions to setup MMU translations and poke hex values at hard
> coded addresses. That's why it's "poor man's". If you had a working
> serial port out of the box, that would be a luxury ;).
Does 4xx have support for udbg and xmon? That would be a good first step
in getting an in-kernel debugger facility going.
-Olof
^ permalink raw reply
* Re: [PATCH 0/2] firewire: endinaness warnings (was Re: sparse - make __CHECK_ENDIAN__ default enabled?)
From: Jarod Wilson @ 2008-03-01 5:23 UTC (permalink / raw)
To: Stefan Richter
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <tkrat.e2bfb30f2c0ae70a@s5r6.in-berlin.de>
On Saturday 23 February 2008 06:23:30 am Stefan Richter wrote:
> On 20 Feb, Harvey Harrison wrote on LKML:
> > On Wed, 2008-02-20 at 23:03 +0100, Sam Ravnborg wrote:
> >> Hi Harvey.
> >>
> >> Can I ask you to look into the worst offenders so we
> >> can make -D__CHECK_ENDIAN__ enabled per default
> >> in the kernel.
> >> Or maybe we should do it anyway?
> >
> > Well, I've got the worst of fs and drivers/ata done so far, still
> > weeping over the 5500 warnings in drivers. (X86_32 allyesconfig).
> > People ignore the existing warnings anyway, why not toss a few more
> > on the pile?
> >
> > I'll look them over tonight and see how bad it would be.
>
> I looked into drivers/firewire and drivers/ieee1394. As expected, there
> are quite a lot endianess related warnings in the latter because this is
> code from way before sparse was regularly used.
>
> There are also a few warnings in the former, even though sparse checks
> were run before submission of the whole drivers/firewire stack. I will
> follow up with two patches:
> 1/2 firewire: endianess fix
> 2/2 firewire: endianess annotations
> Whether the "fix" is really a fix remains to be seen; I don't have a big
> endian Linux box myself.
Doesn't hurt anything on my end, spb2 devices work, they survive bus resets
and so on. The funky uninorth controller definitely doesn't work, but it
didn't before the patch either, and the fix is being chased in another patch
series.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
--
Jarod Wilson
jwilson@redhat.com
^ permalink raw reply
* Re: [PATCH 0/4] Add Emerson KSI8560 board support
From: Paul Mackerras @ 2008-03-01 7:51 UTC (permalink / raw)
To: Alexandr Smirnov; +Cc: linuxppc-dev
In-Reply-To: <20080229171114.GA14325@ru.mvista.com>
Alexandr Smirnov writes:
> I've fixed the code according to your comments.
None of the patches you sent have any patch description or commentary,
and that's not good enough. Yes, it all might be completely clear and
obvious in your head as to what the KSI8560 is and why you have made
the various design decisions you have, but it isn't necessarily
obvious to other people, and you yourself probably won't remember in
two years' time. So write a paragraph or two for each patch telling
us those sort of things.
I concede that patches that just add a defconfig or a dts often don't
need much of a description, although even then there may be choices
made where you could usefully give us a rationale in the patch
description.
Paul.
^ permalink raw reply
* Re: [PATCH 1/3] firewire: fw-ohci: PPC PMac platform code
From: Stefan Richter @ 2008-03-01 8:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <1204340392.15052.455.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> +#ifdef CONFIG_PPC_PMAC
>> + /* Necessary on some machines if fw-ohci was loaded/ unloaded before */
>> + if (machine_is(powermac)) {
>> + struct device_node *ofn = pci_device_to_OF_node(dev);
>> +
>> + if (ofn) {
>> + pmac_call_feature(PMAC_FTR_1394_CABLE_POWER, ofn, 0, 1);
>> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 1);
>> + }
>> + }
>> +#endif /* CONFIG_PPC_PMAC */
>
> I -think- that the hunk above can be removed if you just call
> pci_enable_device(). I have a hook in the arch pcibios_enable_device()
> that detects the internal firewire and does the calls. Can you verify it
> works ?
The first test I did was
# modprobe ohci1394 # this has the same four feature call blocks
# modprobe -r ohci1394
# modprobe firewire-ohci
<boom>
Tried the same now again (actually modprobe -r firewire-ohci (patched);
modprobe firewire-ohci (unpatched)):
Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
PowerMac
Modules linked in: firewire_ohci(+) firewire_core crc_itu_t af_packet
apm_emu apm_emulation usbhid sungem sungem_phy yenta_socket
rsrc_nonstatic ohci_hcd pcmcia_core usbcore ide_cd_mod cdrom evdev [last
unloaded: crc_itu_t]
NIP: e18ee3dc LR: e18ee32c CTR: c0065178
REGS: d7c01c40 TRAP: 0200 Not tainted (2.6.25-rc3)
MSR: 00049030 <EE,ME,IR,DR> CR: 84004428 XER: 00000000
TASK = dedae6d0[5376] 'modprobe' THREAD: d7c00000
GPR00: e18e61c0 d7c01cf0 dedae6d0 defcf000 00000000 00000385 c06c09f8
00001000
GPR08: ffffec0f 00000000 e18e6000 dfafd000 24004428 1001e354 00000000
00000000
GPR16: 0000007a 0000007a 00000000 e18e9bf4 00000124 00000000 e18e6000
c0050280
GPR24: 00000019 e18e9cc4 c0290630 dfb61420 df85b800 dfafdcf8 00000000
dfafdcf8
NIP [e18ee3dc] ar_context_add_page+0xd0/0xf4 [firewire_ohci]
LR [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci]
Call Trace:
[d7c01cf0] [e18ee32c] ar_context_add_page+0x20/0xf4 [firewire_ohci]
(unreliable)
[d7c01d00] [e18ee440] ar_context_init+0x40/0x70 [firewire_ohci]
[d7c01d50] [e18f0004] pci_probe+0x118/0x70c [firewire_ohci]
[d7c01d70] [c010e0ac] pci_device_probe+0x80/0xa0
[d7c01d90] [c0146230] driver_probe_device+0xb8/0x1cc
[d7c01db0] [c0146528] __driver_attach+0xd4/0x104
[d7c01dd0] [c0144d78] bus_for_each_dev+0x58/0x94
[d7c01e00] [c0145f60] driver_attach+0x24/0x34
[d7c01e10] [c0145d48] bus_add_driver+0xb0/0x250
[d7c01e30] [c0146a18] driver_register+0x48/0x130
[d7c01e50] [c010dcb0] __pci_register_driver+0x48/0x94
[d7c01e70] [e101e028] fw_ohci_init+0x28/0x48 [firewire_ohci]
[d7c01e80] [c00516e8] sys_init_module+0xd4/0x1754
[d7c01f40] [c0013d98] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff7325c
LR = 0x10003b50
Instruction dump:
90690010 817f0000 907f0008 814b04b4 813f0010 7c0a4a14 7c0004ac 7ce0052c
817f0000 812b04b4 7c0004ac 7d204c2c <0c090000> 4c00012c 38000000 7c030378
---[ end trace a3cf91a5f7d45355 ]---
BTW, ohci1394 had traditionally only 3 of the blocks; I added the block
by commit 48cfae44b4d6c7ca843d611a93ed2f94b59bcb38 in November 2006.
This fixed http://bugzilla.kernel.org/show_bug.cgi?id=7431 .
[...]
>> @@ -2211,6 +2241,16 @@ static int pci_suspend(struct pci_dev *p
>> if (err)
>> fw_error("pci_set_power_state failed with %d\n", err);
>>
>> +/* PowerMac suspend code comes last */
>> +#ifdef CONFIG_PPC_PMAC
>> + if (machine_is(powermac)) {
>> + struct device_node *ofn = pci_device_to_OF_node(pdev);
>> +
>> + if (ofn)
>> + pmac_call_feature(PMAC_FTR_1394_ENABLE, ofn, 0, 0);
>> + }
>> +#endif /* CONFIG_PPC_PMAC */
>
> I wonder why we don't do the cable power thingy here...
I don't know.
I tested with a bus powered device now. Actually, suspend to RAM
switches off cable power nevertheless, but resume does not switch it on
anymore...
Of course the same is true with ohci1394. Why did nobody ever complain?
I suppose the last two users of FireWire + Linux + UniNorth rev01 don't
use cable power or don't suspend and resume.
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH 3/3] firewire: fw-ohci: shut up false compiler warning on PPC32
From: Stefan Richter @ 2008-03-01 8:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux1394-devel, linux-kernel
In-Reply-To: <20080301141741.172013ba.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Sat, 1 Mar 2008 02:50:44 +0100 (CET) Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
>> Wasn't there a macro somewhere for this?
>
> Yes, uninitialized_var() in linux/compiler*.h
Right. I actually did look into compiler.h and compiler-gcc.h but
somehow didn't make it down into -gcc?.h. Thanks,
--
Stefan Richter
-=====-==--- --== ----=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [dtc] breaking out libfdt from dtc so other progs can use it
From: Fathi Boudra @ 2008-03-01 9:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, David Gibson
In-Reply-To: <Pine.LNX.4.64.0802290930020.25557@vixen.sonytel.be>
> I think people are confusing source and binary packages.
>
> E.g. on Debian, the openssl source package is used to build 3 binary
> packages: openssl, libssl0.9.8, and libssl-dev. Hence to install
> applications that use libssl, you don't have to install all 3, just
> libssl0.9.8.
That make sense.
Just ask downstream (distros) to ship libfdt binaries packages.
cheers,
Fathi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox