Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
On Sat, 2008-02-02 at 10:47 +0300, Yuri Tikhonov wrote: > Hello, > > Here is the patch which makes Linux-2.6 swap routines operate correctly on > the ppc-8xx-based machines. Best is to just remove writeback completely and let the generic code handle it. Ben. > Signed-off-by: Yuri Tikhonov <[EMAIL PROTECTED]> > -- > diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S > index eb8d26f..321bda2 100644 > --- a/arch/ppc/kernel/head_8xx.S > +++ b/arch/ppc/kernel/head_8xx.S > @@ -329,8 +329,18 @@ InstructionTLBMiss: > mfspr r11, SPRN_MD_TWC/* and get the pte address */ > lwz r10, 0(r11) /* Get the pte */ > > +#ifdef CONFIG_SWAP > + /* do not set the _PAGE_ACCESSED bit of a non-present page */ > + andi. r11, r10, _PAGE_PRESENT > + beq 4f > + ori r10, r10, _PAGE_ACCESSED > + mfspr r11, SPRN_MD_TWC/* get the pte address again */ > + stw r10, 0(r11) > +4: > +#else > ori r10, r10, _PAGE_ACCESSED > stw r10, 0(r11) > +#endif > > /* The Linux PTE won't go exactly into the MMU TLB. >* Software indicator bits 21, 22 and 28 must be clear. > @@ -395,8 +405,17 @@ DataStoreTLBMiss: > DO_8xx_CPU6(0x3b80, r3) > mtspr SPRN_MD_TWC, r11 > > - mfspr r11, SPRN_MD_TWC/* get the pte address again */ > +#ifdef CONFIG_SWAP > + /* do not set the _PAGE_ACCESSED bit of a non-present page */ > + andi. r11, r10, _PAGE_PRESENT > + beq 4f > + ori r10, r10, _PAGE_ACCESSED > +4: > + /* and update pte in table */ > +#else > ori r10, r10, _PAGE_ACCESSED > +#endif > + mfspr r11, SPRN_MD_TWC/* get the pte address again */ > stw r10, 0(r11) > > /* The Linux PTE won't go exactly into the MMU TLB. > @@ -575,7 +594,16 @@ DataTLBError: > > /* Update 'changed', among others. > */ > +#ifdef CONFIG_SWAP > + ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE > + /* do not set the _PAGE_ACCESSED bit of a non-present page */ > + andi. r11, r10, _PAGE_PRESENT > + beq 4f > + ori r10, r10, _PAGE_ACCESSED > +4: > +#else > ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE > +#endif > mfspr r11, SPRN_MD_TWC/* Get pte address again */ > stw r10, 0(r11) /* and update pte in table */ > > diff --git a/include/asm-ppc/pgtable.h b/include/asm-ppc/pgtable.h > index c159315..76717ff 100644 > --- a/include/asm-ppc/pgtable.h > +++ b/include/asm-ppc/pgtable.h > @@ -341,14 +341,6 @@ extern unsigned long ioremap_bot, ioremap_base; > #define _PMD_PAGE_MASK 0x000c > #define _PMD_PAGE_8M 0x000c > > -/* > - * The 8xx TLB miss handler allegedly sets _PAGE_ACCESSED in the PTE > - * for an address even if _PAGE_PRESENT is not set, as a performance > - * optimization. This is a bug if you ever want to use swap unless > - * _PAGE_ACCESSED is 2, which it isn't, or unless you have 8xx-specific > - * definitions for __swp_entry etc. below, which would be gross. > - * -- paulus > - */ > #define _PTE_NONE_MASK _PAGE_ACCESSED > > #else /* CONFIG_6xx */ > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
Hi Scott, You are right. The TLB handlers for 8xx in arch/powerpc branch set the PAGE_ACCESSED flag unconditionally too. And the include/asm-powerpc/pgtable-ppc32.h file still includes the comment that this is the bug. So, probably the corresponding patch for powerpc branch will be usefull. Does anybody use swap with some of the 8xx-based boards supported in powerpc branch ? Regards, Yuri On Monday 04 February 2008 21:24, Scott Wood wrote: > On Sat, Feb 02, 2008 at 12:22:17PM +0100, Jochen Friedrich wrote: > > Hi Yuri, > > > > > Here is the patch which makes Linux-2.6 swap routines operate correctly on > > > the ppc-8xx-based machines. > > > > is there any 8xx board left which isn't ported to ARCH=powerpc? > > More importantly, is this something that is also broken in arch/powerpc? It > looks like it has the same code... > > -Scott > -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] Add OF-tree support to RapidIO controller driver.
On Wed, 30 Jan 2008 18:30:52 +0800 Zhang Wei <[EMAIL PROTECTED]> wrote:
>
> -void fsl_rio_setup(int law_start, int law_size)
> +int fsl_rio_setup(struct of_device *dev)
> {
> + if (!dev->node) {
> + dev_err(&dev->dev, "Device OF-Node is NULL");
> + return -EFAULT;
Probably -EINVAL would be better. Here and all the other -EFAULTs.
> + aw = *(u32 *)of_get_property(dev->node, "#address-cells", NULL);
> + sw = *(u32 *)of_get_property(dev->node, "#size-cells", NULL);
What happens if either of these properties is missing?
> +static struct of_device_id fsl_of_rio_rpn_ids[] = {
This should be "const" please.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpgauT5Azp25.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote: > Hi Paul, > > On PPC, I see a disparity between clock_getres implementations in the > vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel > with CONFIG_HIGH_RES_TIMERS=y. > > clock_getres call for CLOCK_REALTIME returns 1 millisecond. However, > when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use > sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems > to be returning some pre-defined (incorrect) variables. > > Could you please let me know the reason for this? Is it something that > should be fixed in vdso? Can you try the attached patch and see it if works for you? From: Tony Breeds <[EMAIL PROTECTED]> Subject: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso. This ensures that the syscall and the (fast) vdso versions of clock_getres() will return the same resolution. Signed-off-by: Tony Breeds <[EMAIL PROTECTED]> --- arch/powerpc/kernel/asm-offsets.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index ed083fe..e6e4928 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -22,6 +22,7 @@ #include #include #include +#include #ifdef CONFIG_PPC64 #include #include @@ -312,7 +313,7 @@ int main(void) DEFINE(CLOCK_REALTIME, CLOCK_REALTIME); DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC); DEFINE(NSEC_PER_SEC, NSEC_PER_SEC); - DEFINE(CLOCK_REALTIME_RES, TICK_NSEC); + DEFINE(CLOCK_REALTIME_RES, (KTIME_MONOTONIC_RES).tv64); #ifdef CONFIG_BUG DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry)); -- 1.5.4 Yours Tony linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/ Jan 28 - Feb 02 2008 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] of: add alias helper functions.
Hi Grant,
On Mon, 04 Feb 2008 09:16:08 -0700 Grant Likely <[EMAIL PROTECTED]> wrote:
>
> From: Grant Likely <[EMAIL PROTECTED]>
>
> Add helper functions for translating back and forth between alias
> properties and device tree nodes.
Do you have a use for this yet (I assume you do - it would be nice to
have a reason in the changelog)?
Overall looks ok, just a few comments?
Dave (Miller) is this useful for Sparc?
> +struct device_node *of_find_node_by_alias(const char *alias)
> +{
> + struct device_node *np, *alias_np;
> + const char *path;
> +
> + np = NULL;
struct device_node *np = NULL;
struct device_node *alias_np;
> +const char *of_node_alias(struct device_node *np, const char *prefix)
> + /* Loop over the aliases looking for a match */
> + alias = NULL;
> + for (pp = alias_np->properties; pp != 0; pp = pp->next) {
^
Use NULL for pointers (or just test "pp").
> + if (test_np == np)
> + alias = pp->name + prefix_len;
> + of_node_put(test_np);
> + if (alias)
> + break;
This could be:
of_node_put(test_np);
if (test_np == np) {
alias = pp->name + prefix_len;
break;
}
As you can still test for pointer equality after dropping the ref count.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpUvpCvctrVt.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] iSeries: fix section mismatch in iseries_veth
WARNING: vmlinux.o(.text+0x25dca0): Section mismatch in reference from the
function .veth_probe() to the function .init.text:.veth_probe_one()
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/net/iseries_veth.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jeff, can this go in through the powerpc tree?
diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
index 419861c..58d3bb6 100644
--- a/drivers/net/iseries_veth.c
+++ b/drivers/net/iseries_veth.c
@@ -1020,7 +1020,7 @@ static const struct ethtool_ops ops = {
.get_link = veth_get_link,
};
-static struct net_device * __init veth_probe_one(int vlan,
+static struct net_device *veth_probe_one(int vlan,
struct vio_dev *vio_dev)
{
struct net_device *dev;
--
1.5.4
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] iSeries: fix section mismatch in viocd
WARNING: drivers/cdrom/viocd.o(.text+0x504): Section mismatch in reference from
the function .viocd_probe() to the function .init.text:.find_capability()
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/cdrom/viocd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jens, can this go in through the powerpc tree?
diff --git a/drivers/cdrom/viocd.c b/drivers/cdrom/viocd.c
index 8473b9f..cac06bc 100644
--- a/drivers/cdrom/viocd.c
+++ b/drivers/cdrom/viocd.c
@@ -558,7 +558,7 @@ static struct cdrom_device_ops viocd_dops = {
.capability = CDC_CLOSE_TRAY | CDC_OPEN_TRAY | CDC_LOCK |
CDC_SELECT_SPEED | CDC_SELECT_DISC | CDC_MULTI_SESSION | CDC_MCN |
CDC_MEDIA_CHANGED | CDC_PLAY_AUDIO | CDC_RESET | CDC_DRIVE_STATUS |
CDC_GENERIC_PACKET | CDC_CD_R | CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM |
CDC_RAM
};
-static int __init find_capability(const char *type)
+static int find_capability(const char *type)
{
struct capability_entry *entry;
--
1.5.4
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] iSeries: fix section mismatch in viodsasd
WARNING: vmlinux.o(.text+0x3017c): Section mismatch in reference from the
function .vio_create_viodasd() to the function
.devinit.text:.vio_register_device_node()
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/vio.c |2 +-
include/asm-powerpc/vio.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index f0bad70..f988672 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -176,7 +176,7 @@ static void __devinit vio_dev_release(struct device *dev)
* Returns a pointer to the created vio_dev or NULL if node has
* NULL device_type or compatible fields.
*/
-struct vio_dev * __devinit vio_register_device_node(struct device_node
*of_node)
+struct vio_dev *vio_register_device_node(struct device_node *of_node)
{
struct vio_dev *viodev;
const unsigned int *unit_address;
diff --git a/include/asm-powerpc/vio.h b/include/asm-powerpc/vio.h
index 9204c15..56512a9 100644
--- a/include/asm-powerpc/vio.h
+++ b/include/asm-powerpc/vio.h
@@ -66,7 +66,7 @@ extern void __devinit vio_unregister_device(struct vio_dev
*dev);
struct device_node;
-extern struct vio_dev * __devinit vio_register_device_node(
+extern struct vio_dev *vio_register_device_node(
struct device_node *node_vdev);
extern const void *vio_get_attribute(struct vio_dev *vdev, char *which,
int *length);
--
1.5.4
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/10] sbc8560: Add v1 device tree source for Wind River SBC8560 board
On Fri, Feb 01, 2008 at 08:46:32AM -0600, Kumar Gala wrote:
>
> On Feb 1, 2008, at 1:54 AM, David Gibson wrote:
>
> > On Thu, Jan 24, 2008 at 06:41:24PM -0500, Paul Gortmaker wrote:
[snip]
> >> + [EMAIL PROTECTED],0 {
> >
> > I'm not entirely convinced on this two-level representation. I think
> > the FSL people need to get together and define a binding (or set of
> > bindings) for their various chipselect style external bus bridges.
>
> It seems reasonable if you had a FPGA off of the localbus to have a
> two level representation. One for the localbus controller on the FSL
> part and the child to describe the FPGA.
>
> What are you expecting beyond what we have today? I guess I'm asking
> what's missing from the localbus nodes we have?
Sorry, I was probably misleading. All I really meant is that I don't
know enough about these FSL bus bridge arrangements to assess if this
representation is the most sensible one. I'm presuming that this
chipselect bridge unit is a more-or-less standard ASIC appearing on
lots of the FSL chips, so it would be nice to have a standard binding
for them, as we do for the roughly-equivalent EBC bridge on 4xx.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] avoid possible extra of_node_put in axon_msi.c
I got this warning from gcc:
arch/powerpc/platforms/cell/axon_msi.c:118: warning: 'tmp' may be used
uninitialized in this function
Which turns out to be a false positive, but pointed out that it was
possible for the error path in find_msi_translator() to do an extra
of_node_put on a node. This fixes it by localising the ref counting
a bit. As a side effect, the warning goes away.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/axon_msi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c
b/arch/powerpc/platforms/cell/axon_msi.c
index 095988f..7a177ba 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -139,6 +139,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev
*dev)
tmp = dn;
dn = of_find_node_by_phandle(*ph);
+ of_node_put(tmp);
if (!dn) {
dev_dbg(&dev->dev,
"axon_msi: msi-translator doesn't point to a node\n");
@@ -156,7 +157,6 @@ static struct axon_msic *find_msi_translator(struct pci_dev
*dev)
out_error:
of_node_put(dn);
- of_node_put(tmp);
return msic;
}
--
1.5.4
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ppc: fix #ifdef-s in mediabay driver (take 2)
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef in
check_media_bay() by CONFIG_MAC_FLOPPY one.
* Replace incorrect CONFIG_BLK_DEV_IDE #ifdef-s by
CONFIG_BLK_DEV_IDE_PMAC ones.
* check_media_bay() is used only by drivers/block/swim3.c
so make this function available only if CONFIG_MAC_FLOPPY
is defined.
* check_media_bay_by_base() and media_bay_set_ide_infos()
are used only by drivers/ide/ppc/pmac.c so so make these
functions available only if CONFIG_MAC_FLOPPY is defined.
v2:
* Remove ifdefs from function prototypes. (Andrew Morton)
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/macintosh/mediabay.c | 46 ++---
include/asm-powerpc/mediabay.h |8 +++
2 files changed, 25 insertions(+), 29 deletions(-)
Index: b/drivers/macintosh/mediabay.c
===
--- a/drivers/macintosh/mediabay.c
+++ b/drivers/macintosh/mediabay.c
@@ -78,12 +78,14 @@ struct media_bay_info {
int cached_gpio;
int sleeping;
struct semaphorelock;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
void __iomem*cd_base;
- int cd_index;
int cd_irq;
int cd_retry;
#endif
+#if defined(CONFIG_BLK_DEV_IDE_PMAC) || defined(CONFIG_MAC_FLOPPY)
+ int cd_index;
+#endif
};
#define MAX_BAYS 2
@@ -91,7 +93,7 @@ struct media_bay_info {
static struct media_bay_info media_bays[MAX_BAYS];
int media_bay_count = 0;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
/* check the busy bit in the media-bay ide interface
(assumes the media-bay contains an ide device) */
#define MB_IDE_READY(i)((readb(media_bays[i].cd_base + 0x70) & 0x80)
== 0)
@@ -401,7 +403,7 @@ static void poll_media_bay(struct media_
set_mb_power(bay, id != MB_NO);
bay->content_id = id;
if (id == MB_NO) {
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
bay->cd_retry = 0;
#endif
printk(KERN_INFO "media bay %d is
empty\n", bay->index);
@@ -414,9 +416,9 @@ static void poll_media_bay(struct media_
}
}
+#ifdef CONFIG_MAC_FLOPPY
int check_media_bay(struct device_node *which_bay, int what)
{
-#ifdef CONFIG_BLK_DEV_IDE
int i;
for (i=0; istate = mb_resetting;
MBDBG("mediabay%d: waiting reset (kind:%d)\n", i,
bay->content_id);
break;
-
case mb_resetting:
if (bay->content_id != MB_CD) {
MBDBG("mediabay%d: bay is up (kind:%d)\n", i,
bay->content_id);
bay->state = mb_up;
break;
}
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
MBDBG("mediabay%d: waiting IDE reset (kind:%d)\n", i,
bay->content_id);
bay->ops->un_reset_ide(bay);
bay->timer = msecs_to_jiffies(MB_IDE_WAIT);
@@ -536,16 +535,14 @@ static void media_bay_step(int i)
#else
printk(KERN_DEBUG "media-bay %d is ide (not compiled in
kernel)\n", i);
set_mb_power(bay, 0);
-#endif /* CONFIG_BLK_DEV_IDE */
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
break;
-
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
case mb_ide_resetting:
bay->timer = msecs_to_jiffies(MB_IDE_TIMEOUT);
bay->state = mb_ide_waiting;
MBDBG("mediabay%d: waiting IDE ready (kind:%d)\n", i,
bay->content_id);
break;
-
case mb_ide_waiting:
if (bay->cd_base == NULL) {
bay->timer = 0;
@@ -587,11 +584,10 @@ static void media_bay_step(int i)
bay->timer = 0;
}
break;
-#endif /* CONFIG_BLK_DEV_IDE */
-
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
case mb_powering_down:
bay->state = mb_empty;
-#ifdef CONFIG_BLK_DEV_IDE
+#ifdef CONFIG_BLK_DEV_IDE_PMAC
if (bay->cd_index >= 0) {
printk(KERN_DEBUG "Unregistering mb %d ide,
index:%d\n", i,
bay->cd_index);
@@ -607,7 +603,7 @@ static void media_bay_step(int i)
bay->content_id = MB_NO;
}
}
-#endif /* CONFIG_BLK_DEV_IDE */
+#endif /* CONFIG_BLK_DEV_IDE_PMAC */
MBDBG("mediabay%d: end of power down\n", i);
break;
}
@@ -739,7 +735,7 @@ static int media
[PATCH v2] Add oprofile support for e300
The e300 c3 and c4 variants support hardware performance monitor counters which
are identical to those found in the e500.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c |6 ++
arch/powerpc/platforms/Kconfig |1 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 98a1c9e..2a8f5cc 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -959,6 +959,9 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = "ppc/e300",
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.platform = "ppc603",
},
{ /* e300c4 (e300c1, plus one IU) */
@@ -971,6 +974,9 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
.machine_check = machine_check_generic,
+ .num_pmcs = 4,
+ .oprofile_cpu_type = "ppc/e300",
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.platform = "ppc603",
},
{ /* default match, we assume split I/D cache & TB (non-601)... */
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index fdce10c..045b8c8 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -24,6 +24,7 @@ config PPC_83xx
select MPC83xx
select IPIC
select WANT_DEVICE_TREE
+ select FSL_EMB_PERFMON
config PPC_86xx
bool "Freescale 86xx"
--
1.5.0.2.230.gfbe3d-dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Made FSL Book-E PMC support more generic
Some of the more recent e300 cores have the same performance monitor
implementation as the e500. e300 isn't book-e, so the name isn't
really appropriate. In preparation for e300 support, rename a bunch
of fsl_booke things to say fsl_emb (Freescale Embedded Performance Monitors).
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c |4 +-
arch/powerpc/kernel/pmc.c |2 +-
arch/powerpc/oprofile/Makefile |2 +-
arch/powerpc/oprofile/common.c |6 +-
.../{op_model_fsl_booke.c => op_model_fsl_emb.c} | 28
arch/powerpc/platforms/Kconfig.cputype |4 +
include/asm-powerpc/cputable.h |2 +-
include/asm-powerpc/oprofile_impl.h|2 +-
include/asm-powerpc/reg.h |4 +
include/asm-powerpc/reg_booke.h| 62 -
include/asm-powerpc/reg_fsl_emb.h | 72
11 files changed, 102 insertions(+), 86 deletions(-)
rename arch/powerpc/oprofile/{op_model_fsl_booke.c => op_model_fsl_emb.c} (91%)
create mode 100644 include/asm-powerpc/reg_fsl_emb.h
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a4c2771..98a1c9e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1435,7 +1435,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 32,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e500",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.machine_check = machine_check_e500,
.platform = "ppc8540",
},
@@ -1453,7 +1453,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 32,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e500",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.machine_check = machine_check_e500,
.platform = "ppc8548",
},
diff --git a/arch/powerpc/kernel/pmc.c b/arch/powerpc/kernel/pmc.c
index ea04e0a..0516e2d 100644
--- a/arch/powerpc/kernel/pmc.c
+++ b/arch/powerpc/kernel/pmc.c
@@ -26,7 +26,7 @@
static void dummy_perf(struct pt_regs *regs)
{
-#if defined(CONFIG_FSL_BOOKE) && !defined(CONFIG_E200)
+#if defined(CONFIG_FSL_EMB_PERFMON)
mtpmr(PMRN_PMGC0, mfpmr(PMRN_PMGC0) & ~PMGC0_PMIE);
#elif defined(CONFIG_PPC64) || defined(CONFIG_6xx)
if (cur_cpu_spec->pmc_type == PPC_PMC_IBM)
diff --git a/arch/powerpc/oprofile/Makefile b/arch/powerpc/oprofile/Makefile
index c5f64c3..2ef6b0d 100644
--- a/arch/powerpc/oprofile/Makefile
+++ b/arch/powerpc/oprofile/Makefile
@@ -15,5 +15,5 @@ oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \
cell/spu_profiler.o cell/vma_map.o \
cell/spu_task_sync.o
oprofile-$(CONFIG_PPC64) += op_model_rs64.o op_model_power4.o op_model_pa6t.o
-oprofile-$(CONFIG_FSL_BOOKE) += op_model_fsl_booke.o
+oprofile-$(CONFIG_FSL_EMB_PERFMON) += op_model_fsl_emb.o
oprofile-$(CONFIG_6xx) += op_model_7450.o
diff --git a/arch/powerpc/oprofile/common.c b/arch/powerpc/oprofile/common.c
index a28cce1..4908dc9 100644
--- a/arch/powerpc/oprofile/common.c
+++ b/arch/powerpc/oprofile/common.c
@@ -202,9 +202,9 @@ int __init oprofile_arch_init(struct oprofile_operations
*ops)
model = &op_model_7450;
break;
#endif
-#ifdef CONFIG_FSL_BOOKE
- case PPC_OPROFILE_BOOKE:
- model = &op_model_fsl_booke;
+#if defined(CONFIG_FSL_EMB_PERFMON)
+ case PPC_OPROFILE_FSL_EMB:
+ model = &op_model_fsl_emb;
break;
#endif
default:
diff --git a/arch/powerpc/oprofile/op_model_fsl_booke.c
b/arch/powerpc/oprofile/op_model_fsl_emb.c
similarity index 91%
rename from arch/powerpc/oprofile/op_model_fsl_booke.c
rename to arch/powerpc/oprofile/op_model_fsl_emb.c
index 183a28b..91596f6 100644
--- a/arch/powerpc/oprofile/op_model_fsl_booke.c
+++ b/arch/powerpc/oprofile/op_model_fsl_emb.c
@@ -1,7 +1,5 @@
/*
- * arch/powerpc/oprofile/op_model_fsl_booke.c
- *
- * Freescale Book-E oprofile support, based on ppc64 oprofile support
+ * Freescale Embedded oprofile support, based on ppc64 oprofile support
* Copyright (C) 2004 Anton Blanchard <[EMAIL PROTECTED]>, IBM
*
* Copyright (c) 2004 Freescale Semiconductor, Inc
@@ -22,7 +20,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -244,7 +242,7 @@ static void dump_pmcs(void)
mfpmr(PMRN_PMLCA3), mfpmr(PMRN_PMLCB3));
Re: [PATCH 7/8] Split out the ioid fetching/checking logic
On Wed, 2008-01-30 at 01:14 +1100, Michael Ellerman wrote:
> Split out the ioid fetching and checking logic so we can use it elsewhere
> in a subsequent patch.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/iommu.c | 23 +--
> 1 files changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c
> b/arch/powerpc/platforms/cell/iommu.c
> index 7779dbf..3baade1 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -443,25 +443,36 @@ static struct iommu_window *find_window(struct
> cbe_iommu *iommu,
> }
> #endif
>
> +static inline u32 cell_iommu_get_ioid(struct device_node *np)
> +{
> + const u32 *ioid;
> +
> + ioid = of_get_property(np, "ioid", NULL);
> + if (ioid == NULL) {
> + printk(KERN_WARNING "iommu: missing ioid for %s using 0\n",
> +np->full_name);
> + return 0;
> + }
> +
> + return *ioid;
> +}
> +
> static struct iommu_window * __init
> cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
> unsigned long offset, unsigned long size,
> unsigned long pte_offset)
> {
> struct iommu_window *window;
> - const unsigned int *ioid;
> + u32 ioid;
>
> - ioid = of_get_property(np, "ioid", NULL);
> - if (ioid == NULL)
> - printk(KERN_WARNING "iommu: missing ioid for %s using 0\n",
> -np->full_name);
> + ioid = cell_iommu_get_ioid(np);
>
> window = kmalloc_node(sizeof(*window), GFP_KERNEL, iommu->nid);
> BUG_ON(window == NULL);
>
> window->offset = offset;
> window->size = size;
> - window->ioid = ioid ? *ioid : 0;
> + window->ioid = ioid;
> window->iommu = iommu;
> window->pte_offset = pte_offset;
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] Add support to cell_iommu_setup_page_tables() for multiple windows
On Wed, 2008-01-30 at 01:14 +1100, Michael Ellerman wrote:
> Add support to cell_iommu_setup_page_tables() for handling two windows,
> the dynamic window and the fixed window. A fixed window size of 0
> indicates that there is no fixed window at all.
>
> Currently there are no callers who pass a non-zero fixed window, but the
> upcoming fixed IOMMU mapping patch will change that.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/iommu.c | 15 ++-
> 1 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c
> b/arch/powerpc/platforms/cell/iommu.c
> index e9769fc..7779dbf 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -307,14 +307,19 @@ static int cell_iommu_find_ioc(int nid, unsigned long
> *base)
> }
>
> static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
> - unsigned long base, unsigned long size)
> + unsigned long dbase, unsigned long dsize,
> + unsigned long fbase, unsigned long fsize)
> {
> struct page *page;
> int i;
> unsigned long reg, segments, pages_per_segment, ptab_size, stab_size,
> - n_pte_pages;
> + n_pte_pages, base;
>
> - segments = size >> IO_SEGMENT_SHIFT;
> + base = dbase;
> + if (fsize != 0)
> + base = min(fbase, dbase);
> +
> + segments = max(dbase + dsize, fbase + fsize) >> IO_SEGMENT_SHIFT;
> pages_per_segment = 1ull << IO_PAGENO_BITS;
>
> pr_debug("%s: iommu[%d]: segments: %lu, pages per segment: %lu\n",
> @@ -366,7 +371,7 @@ static void cell_iommu_setup_page_tables(struct cbe_iommu
> *iommu,
> }
>
> pr_debug("Setting up IOMMU stab:\n");
> - for (i = 0; i * (1ul << IO_SEGMENT_SHIFT) < size; i++) {
> + for (i = base >> IO_SEGMENT_SHIFT; i < segments; i++) {
> iommu->stab[i] = reg |
> (__pa(iommu->ptab) + n_pte_pages * IOMMU_PAGE_SIZE * i);
> pr_debug("\t[%d] 0x%016lx\n", i, iommu->stab[i]);
> @@ -417,7 +422,7 @@ static void cell_iommu_enable_hardware(struct cbe_iommu
> *iommu)
> static void cell_iommu_setup_hardware(struct cbe_iommu *iommu,
> unsigned long base, unsigned long size)
> {
> - cell_iommu_setup_page_tables(iommu, base, size);
> + cell_iommu_setup_page_tables(iommu, base, size, 0, 0);
> cell_iommu_enable_hardware(iommu);
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] Split out the IOMMU logic from cell_dma_dev_setup()
On Wed, 2008-01-30 at 01:14 +1100, Michael Ellerman wrote:
> Split the IOMMU logic out from cell_dma_dev_setup() into a separate
> function. If we're not using dma_direct_ops or dma_iommu_ops we don't
> know what the hell's going on, so BUG.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/iommu.c | 19 +--
> 1 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c
> b/arch/powerpc/platforms/cell/iommu.c
> index a86e5bb..e9769fc 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -507,17 +507,12 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
>
> static unsigned long cell_dma_direct_offset;
>
> -static void cell_dma_dev_setup(struct device *dev)
> +static void cell_dma_dev_setup_iommu(struct device *dev)
> {
> struct iommu_window *window;
> struct cbe_iommu *iommu;
> struct dev_archdata *archdata = &dev->archdata;
>
> - if (get_pci_dma_ops() == &dma_direct_ops) {
> - archdata->dma_data = (void *)cell_dma_direct_offset;
> - return;
> - }
> -
> /* Current implementation uses the first window available in that
>* node's iommu. We -might- do something smarter later though it may
>* never be necessary
> @@ -534,6 +529,18 @@ static void cell_dma_dev_setup(struct device *dev)
> archdata->dma_data = &window->table;
> }
>
> +static void cell_dma_dev_setup(struct device *dev)
> +{
> + struct dev_archdata *archdata = &dev->archdata;
> +
> + if (get_pci_dma_ops() == &dma_iommu_ops)
> + cell_dma_dev_setup_iommu(dev);
> + else if (get_pci_dma_ops() == &dma_direct_ops)
> + archdata->dma_data = (void *)cell_dma_direct_offset;
> + else
> + BUG();
> +}
> +
> static void cell_pci_dma_dev_setup(struct pci_dev *dev)
> {
> cell_dma_dev_setup(&dev->dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] Split out the logic that allocates struct iommus
On Wed, 2008-01-30 at 01:13 +1100, Michael Ellerman wrote:
> Split out the logic that allocates a struct iommu into a separate
> function. This can fail however the calling code has never cared - so
> just return if we can't allocate an iommu.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/iommu.c | 20
> 1 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/iommu.c
> b/arch/powerpc/platforms/cell/iommu.c
> index 9223559..4f1ca43 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -565,10 +565,9 @@ static int __init cell_iommu_get_window(struct
> device_node *np,
> return 0;
> }
>
> -static void __init cell_iommu_init_one(struct device_node *np, unsigned long
> offset)
> +static struct cbe_iommu * __init cell_iommu_alloc(struct device_node *np)
> {
> struct cbe_iommu *iommu;
> - unsigned long base, size;
> int nid, i;
>
> /* Get node ID */
> @@ -576,7 +575,7 @@ static void __init cell_iommu_init_one(struct device_node
> *np, unsigned long off
> if (nid < 0) {
> printk(KERN_ERR "iommu: failed to get node for %s\n",
> np->full_name);
> - return;
> + return NULL;
> }
> pr_debug("iommu: setting up iommu for node %d (%s)\n",
>nid, np->full_name);
> @@ -592,7 +591,7 @@ static void __init cell_iommu_init_one(struct device_node
> *np, unsigned long off
> if (cbe_nr_iommus >= NR_IOMMUS) {
> printk(KERN_ERR "iommu: too many IOMMUs detected ! (%s)\n",
> np->full_name);
> - return;
> + return NULL;
> }
>
> /* Init base fields */
> @@ -603,6 +602,19 @@ static void __init cell_iommu_init_one(struct
> device_node *np, unsigned long off
> snprintf(iommu->name, sizeof(iommu->name), "iommu%d", i);
> INIT_LIST_HEAD(&iommu->windows);
>
> + return iommu;
> +}
> +
> +static void __init cell_iommu_init_one(struct device_node *np,
> +unsigned long offset)
> +{
> + struct cbe_iommu *iommu;
> + unsigned long base, size;
> +
> + iommu = cell_iommu_alloc(np);
> + if (!iommu)
> + return;
> +
> /* Obtain a window for it */
> cell_iommu_get_window(np, &base, &size);
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] Add set_dma_ops() to match get_dma_ops().
On Fri, 2008-01-25 at 21:45 +1100, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> include/asm-powerpc/dma-mapping.h |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/asm-powerpc/dma-mapping.h
> b/include/asm-powerpc/dma-mapping.h
> index 5eea6db..bbefb69 100644
> --- a/include/asm-powerpc/dma-mapping.h
> +++ b/include/asm-powerpc/dma-mapping.h
> @@ -76,6 +76,11 @@ static inline struct dma_mapping_ops *get_dma_ops(struct
> device *dev)
> return dev->archdata.dma_ops;
> }
>
> +static inline void set_dma_ops(struct device *dev, struct dma_mapping_ops
> *ops)
> +{
> + dev->archdata.dma_ops = ops;
> +}
> +
> static inline int dma_supported(struct device *dev, u64 mask)
> {
> struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] Allocate the hash table under 1G on cell
On Fri, 2008-01-25 at 21:45 +1100, Michael Ellerman wrote:
> In order to support our IOMMU performance trick, we need the hash table to be
> inside the DMA window. This is usually 2G, but let's make sure the hash table
> is under 1G as that will satisfy the IOMMU requirements and also means the
> hash table will be on node 0.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/mm/hash_utils_64.c | 12 +---
> 1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 9326a69..487c5e2 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -471,7 +471,7 @@ void __init htab_initialize(void)
> unsigned long table;
> unsigned long pteg_count;
> unsigned long mode_rw;
> - unsigned long base = 0, size = 0;
> + unsigned long base = 0, size = 0, limit;
> int i;
>
> extern unsigned long tce_alloc_start, tce_alloc_end;
> @@ -505,9 +505,15 @@ void __init htab_initialize(void)
> _SDR1 = 0;
> } else {
> /* Find storage for the HPT. Must be contiguous in
> - * the absolute address space.
> + * the absolute address space. On cell we want it to be
> + * in the first 1 Gig.
>*/
> - table = lmb_alloc(htab_size_bytes, htab_size_bytes);
> + if (machine_is(cell))
> + limit = 0x4000;
> + else
> + limit = 0;
> +
> + table = lmb_alloc_base(htab_size_bytes, htab_size_bytes, limit);
>
> DBG("Hash table allocated at %lx, size: %lx\n", table,
> htab_size_bytes);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] Avoid DMA exception when using axon_msi with IOMMU
On Fri, 2008-01-25 at 16:59 +1100, Michael Ellerman wrote:
> There's a brown-paper-bag bug in axon_msi, we pass the address of our
> FIFO directly to the hardware, without DMA mapping it. This leads to
> DMA exceptions if you enable MSI & the IOMMU.
>
> The fix is to correctly DMA map the fifo, dma_alloc_coherent() does
> what we want - and we need to track the virt & phys addresses.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/axon_msi.c | 21 ++---
> 1 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index ea3dc8c..b9a97c4 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -65,7 +65,8 @@
>
> struct axon_msic {
> struct irq_host *irq_host;
> - __le32 *fifo;
> + __le32 *fifo_virt;
> + dma_addr_t fifo_phys;
> dcr_host_t dcr_host;
> u32 read_offset;
> };
> @@ -91,7 +92,7 @@ static void axon_msi_cascade(unsigned int irq, struct
> irq_desc *desc)
>
> while (msic->read_offset != write_offset) {
> idx = msic->read_offset / sizeof(__le32);
> - msi = le32_to_cpu(msic->fifo[idx]);
> + msi = le32_to_cpu(msic->fifo_virt[idx]);
> msi &= 0x;
>
> pr_debug("axon_msi: woff %x roff %x msi %x\n",
> @@ -306,7 +307,6 @@ static int axon_msi_shutdown(struct of_device *device)
> static int axon_msi_probe(struct of_device *device,
> const struct of_device_id *device_id)
> {
> - struct page *page;
> struct device_node *dn = device->node;
> struct axon_msic *msic;
> unsigned int virq;
> @@ -338,16 +338,14 @@ static int axon_msi_probe(struct of_device *device,
> goto out_free_msic;
> }
>
> - page = alloc_pages_node(of_node_to_nid(dn), GFP_KERNEL,
> - get_order(MSIC_FIFO_SIZE_BYTES));
> - if (!page) {
> + msic->fifo_virt = dma_alloc_coherent(&device->dev, MSIC_FIFO_SIZE_BYTES,
> + &msic->fifo_phys, GFP_KERNEL);
> + if (!msic->fifo_virt) {
> printk(KERN_ERR "axon_msi: couldn't allocate fifo for %s\n",
> dn->full_name);
> goto out_free_msic;
> }
>
> - msic->fifo = page_address(page);
> -
> msic->irq_host = irq_alloc_host(of_node_get(dn), IRQ_HOST_MAP_NOMAP,
> NR_IRQS, &msic_host_ops, 0);
> if (!msic->irq_host) {
> @@ -370,9 +368,9 @@ static int axon_msi_probe(struct of_device *device,
> pr_debug("axon_msi: irq 0x%x setup for axon_msi\n", virq);
>
> /* Enable the MSIC hardware */
> - msic_dcr_write(msic, MSIC_BASE_ADDR_HI_REG, (u64)msic->fifo >> 32);
> + msic_dcr_write(msic, MSIC_BASE_ADDR_HI_REG, msic->fifo_phys >> 32);
> msic_dcr_write(msic, MSIC_BASE_ADDR_LO_REG,
> - (u64)msic->fifo & 0x);
> + msic->fifo_phys & 0x);
> msic_dcr_write(msic, MSIC_CTRL_REG,
> MSIC_CTRL_IRQ_ENABLE | MSIC_CTRL_ENABLE |
> MSIC_CTRL_FIFO_SIZE);
> @@ -390,7 +388,8 @@ static int axon_msi_probe(struct of_device *device,
> out_free_host:
> kfree(msic->irq_host);
> out_free_fifo:
> - __free_pages(virt_to_page(msic->fifo), get_order(MSIC_FIFO_SIZE_BYTES));
> + dma_free_coherent(&device->dev, MSIC_FIFO_SIZE_BYTES, msic->fifo_virt,
> + msic->fifo_phys);
> out_free_msic:
> kfree(msic);
> out:
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Convert axon_msi to an of_platform driver
On Fri, 2008-01-25 at 16:59 +1100, Michael Ellerman wrote:
> Now that we create of_platform devices earlier on cell, we can make the
> axon_msi driver an of_platform driver. This makes the code cleaner in
> several ways, and most importantly means we have a struct device.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/axon_msi.c | 76 ++-
> 1 files changed, 34 insertions(+), 42 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/axon_msi.c
> b/arch/powerpc/platforms/cell/axon_msi.c
> index 095988f..ea3dc8c 100644
> --- a/arch/powerpc/platforms/cell/axon_msi.c
> +++ b/arch/powerpc/platforms/cell/axon_msi.c
> @@ -13,7 +13,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include
> #include
> @@ -67,12 +67,9 @@ struct axon_msic {
> struct irq_host *irq_host;
> __le32 *fifo;
> dcr_host_t dcr_host;
> - struct list_head list;
> u32 read_offset;
> };
>
> -static LIST_HEAD(axon_msic_list);
> -
> static void msic_dcr_write(struct axon_msic *msic, unsigned int dcr_n, u32
> val)
> {
> pr_debug("axon_msi: dcr_write(0x%x, 0x%x)\n", val, dcr_n);
> @@ -292,30 +289,25 @@ static struct irq_host_ops msic_host_ops = {
> .map= msic_host_map,
> };
>
> -static int axon_msi_notify_reboot(struct notifier_block *nb,
> - unsigned long code, void *data)
> +static int axon_msi_shutdown(struct of_device *device)
> {
> - struct axon_msic *msic;
> + struct axon_msic *msic = device->dev.platform_data;
> u32 tmp;
>
> - list_for_each_entry(msic, &axon_msic_list, list) {
> - pr_debug("axon_msi: disabling %s\n",
> - msic->irq_host->of_node->full_name);
> - tmp = dcr_read(msic->dcr_host, MSIC_CTRL_REG);
> - tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE;
> - msic_dcr_write(msic, MSIC_CTRL_REG, tmp);
> - }
> + pr_debug("axon_msi: disabling %s\n",
> + msic->irq_host->of_node->full_name);
> + tmp = dcr_read(msic->dcr_host, MSIC_CTRL_REG);
> + tmp &= ~MSIC_CTRL_ENABLE & ~MSIC_CTRL_IRQ_ENABLE;
> + msic_dcr_write(msic, MSIC_CTRL_REG, tmp);
>
> return 0;
> }
>
> -static struct notifier_block axon_msi_reboot_notifier = {
> - .notifier_call = axon_msi_notify_reboot
> -};
> -
> -static int axon_msi_setup_one(struct device_node *dn)
> +static int axon_msi_probe(struct of_device *device,
> + const struct of_device_id *device_id)
> {
> struct page *page;
> + struct device_node *dn = device->node;
> struct axon_msic *msic;
> unsigned int virq;
> int dcr_base, dcr_len;
> @@ -385,7 +377,11 @@ static int axon_msi_setup_one(struct device_node *dn)
> MSIC_CTRL_IRQ_ENABLE | MSIC_CTRL_ENABLE |
> MSIC_CTRL_FIFO_SIZE);
>
> - list_add(&msic->list, &axon_msic_list);
> + device->dev.platform_data = msic;
> +
> + ppc_md.setup_msi_irqs = axon_msi_setup_msi_irqs;
> + ppc_md.teardown_msi_irqs = axon_msi_teardown_msi_irqs;
> + ppc_md.msi_check_device = axon_msi_check_device;
>
> printk(KERN_DEBUG "axon_msi: setup MSIC on %s\n", dn->full_name);
>
> @@ -402,28 +398,24 @@ out:
> return -1;
> }
>
> -static int axon_msi_init(void)
> -{
> - struct device_node *dn;
> - int found = 0;
> -
> - pr_debug("axon_msi: initialising ...\n");
> -
> - for_each_compatible_node(dn, NULL, "ibm,axon-msic") {
> - if (axon_msi_setup_one(dn) == 0)
> - found++;
> - }
> -
> - if (found) {
> - ppc_md.setup_msi_irqs = axon_msi_setup_msi_irqs;
> - ppc_md.teardown_msi_irqs = axon_msi_teardown_msi_irqs;
> - ppc_md.msi_check_device = axon_msi_check_device;
> -
> - register_reboot_notifier(&axon_msi_reboot_notifier);
> +static const struct of_device_id axon_msi_device_id[] = {
> + {
> + .compatible = "ibm,axon-msic"
> + },
> + {}
> +};
>
> - pr_debug("axon_msi: registered callbacks!\n");
> - }
> +static struct of_platform_driver axon_msi_driver = {
> + .match_table= axon_msi_device_id,
> + .probe = axon_msi_probe,
> + .shutdown = axon_msi_shutdown,
> + .driver = {
> + .name = "axon-msi"
> + },
> +};
>
> - return 0;
> +static int __init axon_msi_init(void)
> +{
> + return of_register_platform_driver(&axon_msi_driver);
> }
> -arch_initcall(axon_msi_init);
> +subsys_initcall(axon_msi_init);
> --
> 1.5.2.rc1.1884.g59b20
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlab
Re: [PATCH 2/4] Create and hook up of_platform_device_shutdown
On Fri, 2008-01-25 at 16:59 +1100, Michael Ellerman wrote:
> Although of_platform_device's can have a shutdown routine, at the moment
> the bus code doesn't actually call it. So add the required glue to
> hook the shutdown routine.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> drivers/of/platform.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
>
> CC various folks who've written/touched of_platform_drivers which already
> have shutdown routines. These routines have never been called so they're
> about to get their first testing.
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index b47bb2d..ca09a63 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -85,6 +85,15 @@ static int of_platform_device_resume(struct device * dev)
> return error;
> }
>
> +static void of_platform_device_shutdown(struct device *dev)
> +{
> + struct of_device *of_dev = to_of_device(dev);
> + struct of_platform_driver *drv = to_of_platform_driver(dev->driver);
> +
> + if (dev->driver && drv->shutdown)
> + drv->shutdown(of_dev);
> +}
> +
> int of_bus_type_init(struct bus_type *bus, const char *name)
> {
> bus->name = name;
> @@ -93,6 +102,7 @@ int of_bus_type_init(struct bus_type *bus, const char
> *name)
> bus->remove = of_platform_device_remove;
> bus->suspend = of_platform_device_suspend;
> bus->resume = of_platform_device_resume;
> + bus->shutdown = of_platform_device_shutdown;
> return bus_register(bus);
> }
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] Search for and publish cell OF platform devices earlier
On Fri, 2008-01-25 at 16:59 +1100, Michael Ellerman wrote:
> Currently cell publishes OF devices at device_initcall() time, which
> means the earliest a driver can bind to a device is also device_initcall()
> time. We have a driver we want to register before other devices, so
> publish the devices at subsys_initcall() time.
>
> This should not cause any behaviour change for existing drivers, as they
> are still bound at device_initcall() time.
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/cell/setup.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/setup.c
> b/arch/powerpc/platforms/cell/setup.c
> index e6534b5..a7f609b 100644
> --- a/arch/powerpc/platforms/cell/setup.c
> +++ b/arch/powerpc/platforms/cell/setup.c
> @@ -98,7 +98,7 @@ static int __init cell_publish_devices(void)
> }
> return 0;
> }
> -machine_device_initcall(cell, cell_publish_devices);
> +machine_subsys_initcall(cell, cell_publish_devices);
>
> static void cell_mpic_cascade(unsigned int irq, struct irq_desc *desc)
> {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add oprofile support for e300
On Feb 4, 2008, at 17:14, Andy Fleming wrote: > The e300 c3 and c4 variants support hardware performance monitor > counters which > are identical to those found in the e500. Please ignore. I will send a new version that includes all the changes I apparently missed a change I had already committed. I will send a new version of both oprofile patches so as to make the first patch easier to read, too. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commit for mm/page_alloc.c breaks boot process on my machine
> > It's a virtual address so it depends on the value of CONFIG_KERNEL_START > as to whether this is a user program address or not. Shouldn't it be PAGE_OFFSET ? I mean, CONFIG_KERNEL_START should work on powerpc, but still... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commit for mm/page_alloc.c breaks boot process on my machine
On Mon, 2008-02-04 at 23:20 +0100, Gerhard Pircher wrote: > Original-Nachricht > > Datum: Mon, 4 Feb 2008 10:42:32 + > > Von: Mel Gorman <[EMAIL PROTECTED]> > > An: Gerhard Pircher <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org > > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine > > > > > > > 2. Any chance of seeing a dmesg log? > > > > > That's a little bit of a problem. The kernel log in memory doesn't > > > > > show any kernel oops, but is also fragmented (small fragments seem > > > > > to have been overwritten with 0x0). > > > > > > > > err, that doesn't sound very healthy. > > > > > > Yeah, I know. But the platform code hasn't changed much when porting it > > > from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this > > > case. :-) > > > > > > > I'm at a bit of a loss to guess what might have changed in powerpc code > > that would explain this. I've added the linuxppc-dev mailing list in > > case they can make a guess. > Yes, I'll try to get some comments on the linuxppc-dev mailing list. > > > I think you are also going to need to start bisecting searching > > specifically for the patch that causes these overwrites. > I think I had a similar problem with kernel v2.6.23, too and therefore > waited for kernel 2.6.24. So the problem may exist since a long time. > > > It's a virtual address so it depends on the value of CONFIG_KERNEL_START > > as to whether this is a user program address or not. > AFAIK start_kernel() is called very early in the boot process, were no > user or kernel thread is active. I also wonder why the kernel crashes when > the mem boot option is used. Let's see what the linuxppc-dev people say. Can you post a fresh bug report? There's lots of details missing from the email you forwarded. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] ehea: add memory remove hotplug support
On Mon, 2008-02-04 at 16:24 +0100, Jan-Bernd Themann wrote:
> On Monday 04 February 2008 15:46, Michael Ellerman wrote:
> > On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> > > Add memory remove hotplug support
>
> > > @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> > > if (ret)
> > > ehea_info("failed registering reboot notifier");
> > >
> > > + ret = register_memory_notifier(&ehea_mem_nb);
> > > + if (ret)
> > > + ehea_info("failed registering memory remove notifier");
> > >
> > > ret = crash_shutdown_register(&ehea_crash_handler);
> > > if (ret)
> > > ehea_info("failed registering crash handler");
> >
> > You don't do anything except print a message if the registration fails.
> > What happens when someone tries to remove memory but the memory notifier
> > wasn't registered properly? Bang?
>
> In case the registration fails and somebody tries to free memory:
> - Driver will not remove the affected memory from the eHEA memory region
> --> Firmware (phyp) can not free that memory (as marked as used)
> --> Therefore the removed memory could not be used in an other partition
>
> It makes sense to allow the driver to work anyway. Having no ethernet
> would not really be a good alternative.
Yeah I agree. I wasn't clear from the patch that no notifier -> no
memory removed. Rather than, no notifier -> memory removed and ehea
isn't told about it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add oprofile support for e300
The e300 c3 and c4 variants support hardware performance monitor counters which
are identical to those found in the e500.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c |4 ++--
arch/powerpc/platforms/Kconfig |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c8af497..2a8f5cc 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -961,7 +961,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_603,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e300",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.platform = "ppc603",
},
{ /* e300c4 (e300c1, plus one IU) */
@@ -976,7 +976,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_generic,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e300",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.platform = "ppc603",
},
{ /* default match, we assume split I/D cache & TB (non-601)... */
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index fdce10c..045b8c8 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -24,6 +24,7 @@ config PPC_83xx
select MPC83xx
select IPIC
select WANT_DEVICE_TREE
+ select FSL_EMB_PERFMON
config PPC_86xx
bool "Freescale 86xx"
--
1.5.0.2.230.gfbe3d-dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Made FSL Book-E PMC support more generic
Some of the more recent e300 cores have the same performance monitor
implementation as the e500. e300 isn't book-e, so the name isn't
really appropriate. In preparation for e300 support, rename a bunch
of fsl_booke things to say fsl_emb (Freescale Embedded Performance Monitors).
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |3 +
arch/powerpc/kernel/cputable.c |4 +-
arch/powerpc/kernel/pmc.c |2 +-
arch/powerpc/oprofile/Makefile |2 +-
arch/powerpc/oprofile/common.c |6 +-
arch/powerpc/oprofile/op_model_fsl_booke.c | 371
arch/powerpc/oprofile/op_model_fsl_emb.c | 369 +++
arch/powerpc/platforms/Kconfig.cputype |1 +
include/asm-powerpc/cputable.h |2 +-
include/asm-powerpc/oprofile_impl.h|2 +-
include/asm-powerpc/reg.h |4 +
include/asm-powerpc/reg_booke.h| 62 -
include/asm-powerpc/reg_fsl_emb.h | 72 ++
13 files changed, 458 insertions(+), 442 deletions(-)
delete mode 100644 arch/powerpc/oprofile/op_model_fsl_booke.c
create mode 100644 arch/powerpc/oprofile/op_model_fsl_emb.c
create mode 100644 include/asm-powerpc/reg_fsl_emb.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 5e10838..079c0e3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -473,6 +473,9 @@ config FSL_PCI
bool
select PPC_INDIRECT_PCI
+config FSL_EMB_PERFMON
+ bool
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 14c3b07..c8af497 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1441,7 +1441,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 32,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e500",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.machine_check = machine_check_e500,
.platform = "ppc8540",
},
@@ -1459,7 +1459,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.dcache_bsize = 32,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e500",
- .oprofile_type = PPC_OPROFILE_BOOKE,
+ .oprofile_type = PPC_OPROFILE_FSL_EMB,
.machine_check = machine_check_e500,
.platform = "ppc8548",
},
diff --git a/arch/powerpc/kernel/pmc.c b/arch/powerpc/kernel/pmc.c
index ea04e0a..0516e2d 100644
--- a/arch/powerpc/kernel/pmc.c
+++ b/arch/powerpc/kernel/pmc.c
@@ -26,7 +26,7 @@
static void dummy_perf(struct pt_regs *regs)
{
-#if defined(CONFIG_FSL_BOOKE) && !defined(CONFIG_E200)
+#if defined(CONFIG_FSL_EMB_PERFMON)
mtpmr(PMRN_PMGC0, mfpmr(PMRN_PMGC0) & ~PMGC0_PMIE);
#elif defined(CONFIG_PPC64) || defined(CONFIG_6xx)
if (cur_cpu_spec->pmc_type == PPC_PMC_IBM)
diff --git a/arch/powerpc/oprofile/Makefile b/arch/powerpc/oprofile/Makefile
index c5f64c3..2ef6b0d 100644
--- a/arch/powerpc/oprofile/Makefile
+++ b/arch/powerpc/oprofile/Makefile
@@ -15,5 +15,5 @@ oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \
cell/spu_profiler.o cell/vma_map.o \
cell/spu_task_sync.o
oprofile-$(CONFIG_PPC64) += op_model_rs64.o op_model_power4.o op_model_pa6t.o
-oprofile-$(CONFIG_FSL_BOOKE) += op_model_fsl_booke.o
+oprofile-$(CONFIG_FSL_EMB_PERFMON) += op_model_fsl_emb.o
oprofile-$(CONFIG_6xx) += op_model_7450.o
diff --git a/arch/powerpc/oprofile/common.c b/arch/powerpc/oprofile/common.c
index a28cce1..4908dc9 100644
--- a/arch/powerpc/oprofile/common.c
+++ b/arch/powerpc/oprofile/common.c
@@ -202,9 +202,9 @@ int __init oprofile_arch_init(struct oprofile_operations
*ops)
model = &op_model_7450;
break;
#endif
-#ifdef CONFIG_FSL_BOOKE
- case PPC_OPROFILE_BOOKE:
- model = &op_model_fsl_booke;
+#if defined(CONFIG_FSL_EMB_PERFMON)
+ case PPC_OPROFILE_FSL_EMB:
+ model = &op_model_fsl_emb;
break;
#endif
default:
diff --git a/arch/powerpc/oprofile/op_model_fsl_booke.c
b/arch/powerpc/oprofile/op_model_fsl_booke.c
deleted file mode 100644
index 183a28b..000
--- a/arch/powerpc/oprofile/op_model_fsl_booke.c
+++ /dev/null
@@ -1,371 +0,0 @@
-/*
- * arch/powerpc/oprofile/op_model_fsl_booke.c
- *
- * Freescale Book-E oprofile support, based on ppc64 oprofile support
- * Copyright (C) 2004 Anton Blanchard <[EMAIL PROTECTED]>, IBM
- *
- * Copyright (c) 2004 Freescale Semicondu
Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
On Mon, 4 Feb 2008 21:29:02 +0100
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This is from ppc32:
>
> CC arch/powerpc/mm/mem.o
> arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
> arch/powerpc/mm/mem.c:256: error: too few arguments to function
> 'reserve_bootmem'
> arch/powerpc/mm/mem.c:261: error: too few arguments to function
> 'reserve_bootmem'
>
> Leftover from introduce-flags-for-reserve_bootmem.patch?
>
Yes, I've had to fix that patch many times.
--- a/arch/powerpc/mm/mem.c~introduce-flags-for-reserve_bootmem-powerpc-fix
+++ a/arch/powerpc/mm/mem.c
@@ -253,12 +253,13 @@ void __init do_init_bootmem(void)
lmb_size_bytes(&lmb.reserved, i) - 1;
if (addr < total_lowmem)
reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(&lmb.reserved, i));
+ lmb_size_bytes(&lmb.reserved, i),
+ BOOTMEM_DEFAULT);
else if (lmb.reserved.region[i].base < total_lowmem) {
unsigned long adjusted_size = total_lowmem -
lmb.reserved.region[i].base;
reserve_bootmem(lmb.reserved.region[i].base,
- adjusted_size);
+ adjusted_size, BOOTMEM_DWEFAULT);
}
}
#else
_
We did this wrong. We should have introduced a new reserve_bootmem_foo()
and migrated over to that in stages. Once all callers are migrated, remove
the old interface.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
On Mon, 4 Feb 2008 12:24:21 -0600 Scott Wood wrote: > On Sat, Feb 02, 2008 at 12:22:17PM +0100, Jochen Friedrich wrote: > > Hi Yuri, > > > > > Here is the patch which makes Linux-2.6 swap routines operate > > > correctly on the ppc-8xx-based machines. > > > > is there any 8xx board left which isn't ported to ARCH=powerpc? > > More importantly, is this something that is also broken in > arch/powerpc? It looks like it has the same code... > yes, it is. Though there is currently no best-at-all solution, this looks worth trying. I'll have a look how the 8xx feels under load and report back. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commit for mm/page_alloc.c breaks boot process on my machine
Original-Nachricht > Datum: Mon, 4 Feb 2008 10:42:32 + > Von: Mel Gorman <[EMAIL PROTECTED]> > An: Gerhard Pircher <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], linuxppc-dev@ozlabs.org > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine > > > > > 2. Any chance of seeing a dmesg log? > > > > That's a little bit of a problem. The kernel log in memory doesn't > > > > show any kernel oops, but is also fragmented (small fragments seem > > > > to have been overwritten with 0x0). > > > > > > err, that doesn't sound very healthy. > > > > Yeah, I know. But the platform code hasn't changed much when porting it > > from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this > > case. :-) > > > > I'm at a bit of a loss to guess what might have changed in powerpc code > that would explain this. I've added the linuxppc-dev mailing list in > case they can make a guess. Yes, I'll try to get some comments on the linuxppc-dev mailing list. > I think you are also going to need to start bisecting searching > specifically for the patch that causes these overwrites. I think I had a similar problem with kernel v2.6.23, too and therefore waited for kernel 2.6.24. So the problem may exist since a long time. > It's a virtual address so it depends on the value of CONFIG_KERNEL_START > as to whether this is a user program address or not. AFAIK start_kernel() is called very early in the boot process, were no user or kernel thread is active. I also wonder why the kernel crashes when the mem boot option is used. Let's see what the linuxppc-dev people say. Thanks for your help! Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile quirk linux-2.6.24 (with workaround)
On Sun, 3 Feb 2008 17:29:05 +0100 Bernhard Reiter <[EMAIL PROTECTED]> wrote: > Dear linux powerpc Maintainers and Users, > > recently I have tried to compile a new kernel on a Debian sarge ppc > system (PowerBook5,6 MacRISC3 Power Macintosh). > > The build system bailed out with >BOOTCC arch/powerpc/boot/4xx.o > cc1: error: bad value (440) for -mcpu= switch > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1 > > I have tracked this a few steps and the attached patch made the compile for me > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13) > cannot produce code for 4xx it seems. > > The "ARCH=ppc64" I have came about also looked wrong, but I do not know > if this part of the patch is really necessary. > It is just a workaround, as I have no insight of what is really going wrong. That patch really won't fly. I'll try go come up with something a bit more robust when I can. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support
On Mon, Feb 04, 2008 at 02:30:04PM -0600, Scott Wood wrote:
> On Sun, Feb 03, 2008 at 08:10:19PM +0300, Anton Vorontsov wrote:
> > GTM stands for General-purpose Timers Module and able to generate
> > timer{1,2,3,4} interrupts.
> >
> > There are several limitations in this support:
> > 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
> >This is straightforward to implement when needed, two timers should
> >be marked as "requested" and configured as appropriate.
> > 2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
> >This is also straightforward to implement when needed, all timers
> >should be marked as "requested" and configured as appropriate.
>
> This isn't QE-specific; the same (as far as I see) timer hardware exists on,
> for example, mpc8313 and mpc8349.
In my endless todo list. I'll try to evolve it to support fsl gtms in
general. Though the problem is that, for example, for QE USB we prefer
QE timers. So, we probably want to pass timers via device tree to
distinguish them.
> > +config QE_GTM
> > + bool
> > + help
> > + QE General-Purpose Timers Module support
>
> No bool text?
No. This is silent config option.
> > +struct gtm_timer {
> > + unsigned int irq;
> > + bool requested;
> > +
> > + u8 __iomem *gtcfr;
> > + u16 __iomem *gtmdr;
> > + u16 __iomem *gtpsr;
> > + u16 __iomem *gtcnr;
> > + u16 __iomem *gtrfr;
> > + u16 __iomem *gtevr;
> > +};
>
> __be16
Will do.
> > +static struct gtm_timer timers[4];
> > +static struct qe_timers __iomem *qet;
> > +static spinlock_t gtm_lock = __SPIN_LOCK_UNLOCKED(gtm_lock);
>
> static DEFINE_SPINLOCK(gtm_lock);
I'm trying to open-code as much as I could (well, not as much, but
just using common sense :-), so I prefer the first variant, if you
don't mind. DEFINE_SPINLOCK() and above are equivalents.
This is not something I'm going to argue about, though. Just ask
one more time and I'll simply change it to DEFINE_SPINLOCK().
> Put these in a struct so multiple timer blocks can be supported (the non-QE
> chips tend to have two blocks).
Yes, this is in my todo list. Btw, QE chips have three gtms, QE + 2 IMMR.
> > +int qe_reset_ref_timer_16(int num, unsigned int hz, u16 ref)
>
> What does this function do? What goes in "hz" and "ref"? Is it periodic or
> one-shot?
"ref" means that it counts to some reference value and fires the
interrupt. Hz is count rate. This particular function implements
"reset reference mode", timer will reset itself when reference
value is reached. We probably want to add frr flag (free run).
Will kernel-doc this function.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] PowerPC: 4xx PCIe indirect DCR spinlock fix.
On Mon, 2008-02-04 at 21:27 +0300, Valentine Barshak wrote:
> Since we have mfdcri() and mtdcri() as macros, we can't use constructions,
> such
> as "mtdcri(base, reg, mfdcri(base, reg) | val)". In this case the mfdcri()
> stuff
> is not evaluated first. It's evaluated inside the mtdcr() macro and we have
> the dcr_ind_lock spinlock acquired twice. To avoid this error, I've added
> set_dcri() and clr_dcri() macros which set/clear the specified bits.
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
No, better is to fix the macros to use functions.
Make mfdcri/mtdcri call into __mfdcri/__mtdcri functions after fixing
up the macro register names, and have those be inlines that take the
lock.
Ben.
> arch/powerpc/sysdev/ppc4xx_pci.c | 13 +
> include/asm-powerpc/dcr-native.h | 22 ++
> 2 files changed, 27 insertions(+), 8 deletions(-)
>
> diff -pruN linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c
> linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c
> --- linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c 2008-02-04
> 20:05:37.0 +0300
> +++ linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c2008-02-04
> 20:16:33.0 +0300
> @@ -645,7 +645,7 @@ static int __init ppc440spe_pciex_core_i
> int time_out = 20;
>
> /* Set PLL clock receiver to LVPECL */
> - mtdcri(SDR0, PESDR0_PLLLCT1, mfdcri(SDR0, PESDR0_PLLLCT1) | 1 << 28);
> + set_dcri(SDR0, PESDR0_PLLLCT1, 1 << 28);
>
> /* Shouldn't we do all the calibration stuff etc... here ? */
> if (ppc440spe_pciex_check_reset(np))
> @@ -659,8 +659,7 @@ static int __init ppc440spe_pciex_core_i
> }
>
> /* De-assert reset of PCIe PLL, wait for lock */
> - mtdcri(SDR0, PESDR0_PLLLCT1,
> -mfdcri(SDR0, PESDR0_PLLLCT1) & ~(1 << 24));
> + clr_dcri(SDR0, PESDR0_PLLLCT1, 1 << 24);
> udelay(3);
>
> while (time_out) {
> @@ -712,9 +711,8 @@ static int ppc440spe_pciex_init_port_hw(
> mtdcri(SDR0, port->sdr_base + PESDRn_440SPE_HSSL7SET1,
> 0x3500);
> }
> - val = mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET);
> - mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
> -(val & ~(1 << 24 | 1 << 16)) | 1 << 12);
> + clr_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 24 | 1 << 16)
> + set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 12);
>
> return 0;
> }
> @@ -1042,8 +1040,7 @@ static int __init ppc4xx_pciex_port_init
> port->link = 0;
> }
>
> - mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
> -mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) | 1 << 20);
> + set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 20);
> msleep(100);
>
> return 0;
> diff -pruN linux-2.6.orig/include/asm-powerpc/dcr-native.h
> linux-2.6/include/asm-powerpc/dcr-native.h
> --- linux-2.6.orig/include/asm-powerpc/dcr-native.h 2008-02-04
> 20:06:34.0 +0300
> +++ linux-2.6/include/asm-powerpc/dcr-native.h2008-02-04
> 20:16:33.0 +0300
> @@ -79,6 +79,28 @@ do {
> \
> spin_unlock_irqrestore(&dcr_ind_lock, flags); \
> } while (0)
>
> +#define set_dcri(base, reg, data)\
> +do { \
> + unsigned long flags;\
> + unsigned int val; \
> + spin_lock_irqsave(&dcr_ind_lock, flags);\
> + mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
> + val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
> + mtdcr(DCRN_ ## base ## _CONFIG_DATA, val | (data)); \
> + spin_unlock_irqrestore(&dcr_ind_lock, flags); \
> +} while (0)
> +
> +#define clr_dcri(base, reg, data)\
> +do { \
> + unsigned long flags;\
> + unsigned int val; \
> + spin_lock_irqsave(&dcr_ind_lock, flags);\
> + mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
> + val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
> + mtdcr(DCRN_ ## base ## _CONFIG_DATA, val & ~(data));\
> + spin_unlock_irqrestore(&dcr_ind_lock, flags); \
> +} while (0)
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DCR_NATIVE_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support
On Sun, Feb 03, 2008 at 08:10:19PM +0300, Anton Vorontsov wrote:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts.
>
> There are several limitations in this support:
> 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
>This is straightforward to implement when needed, two timers should
>be marked as "requested" and configured as appropriate.
> 2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
>This is also straightforward to implement when needed, all timers
>should be marked as "requested" and configured as appropriate.
This isn't QE-specific; the same (as far as I see) timer hardware exists on,
for example, mpc8313 and mpc8349.
> +config QE_GTM
> + bool
> + help
> + QE General-Purpose Timers Module support
No bool text?
> +struct gtm_timer {
> + unsigned int irq;
> + bool requested;
> +
> + u8 __iomem *gtcfr;
> + u16 __iomem *gtmdr;
> + u16 __iomem *gtpsr;
> + u16 __iomem *gtcnr;
> + u16 __iomem *gtrfr;
> + u16 __iomem *gtevr;
> +};
__be16
> +static struct gtm_timer timers[4];
> +static struct qe_timers __iomem *qet;
> +static spinlock_t gtm_lock = __SPIN_LOCK_UNLOCKED(gtm_lock);
static DEFINE_SPINLOCK(gtm_lock);
Put these in a struct so multiple timer blocks can be supported (the non-QE
chips tend to have two blocks).
> +int qe_reset_ref_timer_16(int num, unsigned int hz, u16 ref)
What does this function do? What goes in "hz" and "ref"? Is it periodic or
one-shot?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
Hello, This is from ppc32: CC arch/powerpc/mm/mem.o arch/powerpc/mm/mem.c: In function 'do_init_bootmem': arch/powerpc/mm/mem.c:256: error: too few arguments to function 'reserve_bootmem' arch/powerpc/mm/mem.c:261: error: too few arguments to function 'reserve_bootmem' Leftover from introduce-flags-for-reserve_bootmem.patch? Regards, Mariusz ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix ext4 bitops
On Mon, 4 Feb 2008, Aneesh Kumar K.V wrote:
> On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
> > On Sun, 3 Feb 2008, Heiko Carstens wrote:
> > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
> > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
> > > > > On Fri, 1 Feb 2008 21:02:08 +0100
> > > > > Bastian Blank <[EMAIL PROTECTED]> wrote:
> > > > > > Fix ext4 bitops.
> > > > >
> > > > > This is incomplete. Please tell us what was "fixed".
> > > > >
> > > > > If it was a build error then please quote the compile error output in
> > > > > the
> > > > > changelog, as well as the usual description of what the problem is,
> > > > > and how
> > > > > it was fixed.
> > > >
> > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function
> > > > 'generic_find_next_le_bit'
> > > >
> > > > The s390 specific bitops uses parts of the generic implementation.
> > > > Include the correct header.
> > >
> > > That doesn't work:
> > >
> > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > mballoc.c:(.text+0x95a8a): undefined reference to
> > > `generic_find_next_le_bit'
> > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > mballoc.c:(.text+0x967ea): undefined reference to
> > > `generic_find_next_le_bit'
> > >
> > > This still needs generic_find_next_le_bit which comes
> > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > don't set GENERIC_FIND_NEXT_BIT.
> > > Currently we have the lengthly patch below queued.
> >
> > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > impression the ext4 people don't (compile) test on big endian machines?
>
> I have sent this patches to linux-arch expecting a review from
> different arch people. It is true that the patches are tested only on
> powerpc, x86-64, x86. That's the primary reason of me sending the
> patches to linux-arch.
>
> http://marc.info/?l=linux-arch&m=119503501127737&w=2
Sometimes it's difficult to see what can go wrong due to a single patch that
just adds a #define. Sorry, I missed the lack of prototype for
generic_find_next_le_bit() and that we don't set GENERIC_FIND_NEXT_BIT,
just like s390.
And yes, usually I rely on the -mm autocompiler to catch things like
this, but this time it didn't work out...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH] PowerPC: 4xx PCIe indirect DCR spinlock fix.
Since we have mfdcri() and mtdcri() as macros, we can't use constructions, such
as "mtdcri(base, reg, mfdcri(base, reg) | val)". In this case the mfdcri() stuff
is not evaluated first. It's evaluated inside the mtdcr() macro and we have
the dcr_ind_lock spinlock acquired twice. To avoid this error, I've added
set_dcri() and clr_dcri() macros which set/clear the specified bits.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 13 +
include/asm-powerpc/dcr-native.h | 22 ++
2 files changed, 27 insertions(+), 8 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c
linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c
--- linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c 2008-02-04
20:05:37.0 +0300
+++ linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c 2008-02-04 20:16:33.0
+0300
@@ -645,7 +645,7 @@ static int __init ppc440spe_pciex_core_i
int time_out = 20;
/* Set PLL clock receiver to LVPECL */
- mtdcri(SDR0, PESDR0_PLLLCT1, mfdcri(SDR0, PESDR0_PLLLCT1) | 1 << 28);
+ set_dcri(SDR0, PESDR0_PLLLCT1, 1 << 28);
/* Shouldn't we do all the calibration stuff etc... here ? */
if (ppc440spe_pciex_check_reset(np))
@@ -659,8 +659,7 @@ static int __init ppc440spe_pciex_core_i
}
/* De-assert reset of PCIe PLL, wait for lock */
- mtdcri(SDR0, PESDR0_PLLLCT1,
- mfdcri(SDR0, PESDR0_PLLLCT1) & ~(1 << 24));
+ clr_dcri(SDR0, PESDR0_PLLLCT1, 1 << 24);
udelay(3);
while (time_out) {
@@ -712,9 +711,8 @@ static int ppc440spe_pciex_init_port_hw(
mtdcri(SDR0, port->sdr_base + PESDRn_440SPE_HSSL7SET1,
0x3500);
}
- val = mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET);
- mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
- (val & ~(1 << 24 | 1 << 16)) | 1 << 12);
+ clr_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 24 | 1 << 16)
+ set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 12);
return 0;
}
@@ -1042,8 +1040,7 @@ static int __init ppc4xx_pciex_port_init
port->link = 0;
}
- mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
- mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) | 1 << 20);
+ set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 20);
msleep(100);
return 0;
diff -pruN linux-2.6.orig/include/asm-powerpc/dcr-native.h
linux-2.6/include/asm-powerpc/dcr-native.h
--- linux-2.6.orig/include/asm-powerpc/dcr-native.h 2008-02-04
20:06:34.0 +0300
+++ linux-2.6/include/asm-powerpc/dcr-native.h 2008-02-04 20:16:33.0
+0300
@@ -79,6 +79,28 @@ do { \
spin_unlock_irqrestore(&dcr_ind_lock, flags); \
} while (0)
+#define set_dcri(base, reg, data) \
+do { \
+ unsigned long flags;\
+ unsigned int val; \
+ spin_lock_irqsave(&dcr_ind_lock, flags);\
+ mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
+ val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
+ mtdcr(DCRN_ ## base ## _CONFIG_DATA, val | (data)); \
+ spin_unlock_irqrestore(&dcr_ind_lock, flags); \
+} while (0)
+
+#define clr_dcri(base, reg, data) \
+do { \
+ unsigned long flags;\
+ unsigned int val; \
+ spin_lock_irqsave(&dcr_ind_lock, flags);\
+ mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
+ val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
+ mtdcr(DCRN_ ## base ## _CONFIG_DATA, val & ~(data));\
+ spin_unlock_irqrestore(&dcr_ind_lock, flags); \
+} while (0)
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_NATIVE_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
On Sat, Feb 02, 2008 at 12:22:17PM +0100, Jochen Friedrich wrote: > Hi Yuri, > > > Here is the patch which makes Linux-2.6 swap routines operate correctly on > > the ppc-8xx-based machines. > > is there any 8xx board left which isn't ported to ARCH=powerpc? More importantly, is this something that is also broken in arch/powerpc? It looks like it has the same code... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while dumping user core.
Benjamin Herrenschmidt wrote: > On Thu, 2008-01-31 at 16:10 -0600, Rune Torgersen wrote: >> Scott Wood wrote: >>> Changing update_mmu_cache() to always call flush_dcache_icache_page() >>> fixes it, though a better performing fix would probably be to add an >>> exception table entry for the dcbst. >> I can confirm that this seems to fix it. > > Might be better to avoid the flush when the page isn't readable ? Sure, that'd work. I was trying to avoid a tablewalk to determine that, not noticing the pte argument staring me in the face. :-P -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] ehea: fix phyp checkpatch complaints
Doug Maxey wrote: > On Fri, 01 Feb 2008 13:23:45 CST, Scott Wood wrote: >> On Thu, Jan 31, 2008 at 08:20:50PM -0600, Doug Maxey wrote: >>> /* input param R5 */ >>> -#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11) > ... >>> +#define H_ALL_RES_QP_EQPOEHEA_BMASK_IBM(9, 11) > ... >> This was better the way it was (before, it was readable at any tab setting); >> checkpatch is overeager to complain on tab/space issues (it's a bit hard to >> distinguish indentation from alignment with a regex). > > In emacs, with no special offsets, the lines appear to still line up. Are you using a tab size other than 8? > What did happen was spaces were turned to tabs where applicable. I disagree about the applicability. :-) > What editor shows a bad alignment? Any editor that has been configured to a non-default tab size. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/11] [POWERPC] qe_lib: support for gpio_set_dedicated
Anton Vorontsov wrote:
> +static int qe_gpio_set_dedicated(struct gpio_chip *gc, unsigned int gpio,
> + int func)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
> + struct port_regs __iomem *regs = mm_gc->regs;
> + struct port_regs *sregs = &qe_gc->saved_regs;
> + unsigned long flags;
> + u32 mask1 = 1 << (NUM_OF_PINS - (gpio + 1));
> + u32 mask2 = 0x3 << (NUM_OF_PINS - (gpio % (NUM_OF_PINS / 2) + 1) * 2);
> + bool second_reg = gpio > (NUM_OF_PINS / 2) - 1;
> +
> + spin_lock_irqsave(&qe_gc->lock, flags);
> +
> + if (second_reg)
> + clrsetbits_be32(®s->cpdir2, mask2, sregs->cpdir2 & mask2);
> + else
> + clrsetbits_be32(®s->cpdir1, mask2, sregs->cpdir1 & mask2);
> +
> + if (second_reg)
> + clrsetbits_be32(®s->cppar2, mask2, sregs->cppar2 & mask2);
> + else
> + clrsetbits_be32(®s->cppar1, mask2, sregs->cppar1 & mask2);
You could combine these into one if-statement.
I took a quick look at all of your QE lib patches. They generally look okay,
but I haven't examined them thoroughly enough to formally ACK them.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge
Johan Borkhuis wrote: > Hello, > > I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540 > processor). We are planning to move to 2.6.20 (powerpc), but I have some > problems with the initialization of a PCI-PCI bridge. > Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150, > 3388:0022). When using the 2.6.14 kernel this bridge is initialized > correctly: it is setup as bus-master, memory and IO are configured, and > the memory allocation on the PCI-bus is correct. > When I use 2.6.20 (powerpc) the device is not configured correctly: > bus-master, memory and IO are not set, and the memory space of the > bridge on the PCI bus is set to the minimum value (0xf). > I can correct these settings by modifying the PCI_COMMAND register to > set the bus-master, memory and IO. I change the size of the memory space > in pci_32.c, by forcing the size to the required setting in > pci_relocate_bridge_resource. But to be honest, I don't like this very > much: modifying registers like this should not be needed, so I guess > there is something wrong in my configuration or setup. > > How can I fix this problem in a better way? What could be wrong with my > configuration? There has been a fair amount of PCI setup reworking done somewhat recently. (.22 and .23, IIRC, and even .24). It might be best if you can try 2.6.24. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile quirk linux-2.6.24 (with workaround)
On 2/4/08, Bernhard Reiter <[EMAIL PROTECTED]> wrote: > On Monday 04 February 2008 10:51, Sven Luther wrote: > > You should normally not need to build the 4xx bootloader part. Make sure > > that, i don't know why this happens. Can you look into > > arch/powerpc/boot/Makefile, to see what option enables the 4xx build, > > and make sure it is disabled in the main config ? > > I have tried to do this, but it looks like it is just hardcoded into the > Makefile as you can see from the patch. There is probably more that I do not > understand - thus my report with on the workaround. The policy decision was made early on to build all of the bootwrapper bits regardless of whether they are needed by the configured platform or not. AFAIK the reason for this is to increase the variety of platforms and compilers for with the bootwrapper bits are tested on. Unfortunately, there are bits of 4xx bootwrappers which require processor specific instructions for manipulating the cache and DCR. If we're supporting compilers which don't have 440 support, then we'll need to disable the build of those bits when they aren't needed, but I don't know the best way to go about this. David, thoughts? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Build failure with 2.6.24-mm1
On Mon, Feb 04, 2008 at 02:19:17AM -0800, Andrew Morton wrote: > On Mon, 4 Feb 2008 15:37:43 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > > > * Balbir Singh <[EMAIL PROTECTED]> [2008-02-04 15:35:09]: > > > > I just saw the following build failure on a power machine. > > > > In file included from include/acpi/platform/acenv.h:140, > > from include/acpi/acpi.h:54, > > from include/acpi/acpi_bus.h:31, > > from drivers/pci/pcie/aspm.c:20: > > include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or > > directory > > In file included from include/acpi/platform/aclinux.h:120, > > from include/acpi/platform/acenv.h:140, > > from include/acpi/acpi.h:54, > > from include/acpi/acpi_bus.h:31, > > from drivers/pci/pcie/aspm.c:20: > > include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or > > '__attribute__' before 'UINT64' > > include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or > > '__attribute__' before 'INT64' > > include/acpi/actypes.h:753: error: expected ')' before '*' token > > include/acpi/actypes.h:756: error: expected ')' before '*' token > > In file included from include/acpi/acpi.h:61, > > from include/acpi/acpi_bus.h:31, > > from drivers/pci/pcie/aspm.c:20: > > include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...' > > before 'acpi_osd_handler' > > include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...' > > before 'acpi_osd_handler' > > include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...' > > before 'acpi_osd_exec_callback' > > make[3]: *** [drivers/pci/pcie/aspm.o] Error 1 > > make[2]: *** [drivers/pci/pcie] Error 2 > > make[2]: *** Waiting for unfinished jobs > > CC drivers/ps3/ps3-vuart.o > > CC net/netlink/attr.o > > make[1]: *** [drivers/pci] Error 2 > > make[1]: *** Waiting for unfinished jobs.. > > > > The following config option is responsible for the build failure > > > > config PCIEASPM > > bool "PCI Express ASPM support(Experimental)" > > depends on PCI && EXPERIMENTAL && PCIEPORTBUS > > default y > > help > > This enables PCI Express ASPM (Active State Power Management) and > > Clock Power Management. ASPM supports state L0/L0s/L1. > > > > When in doubt, say N. > > > > Here's a probable fix for the problem. > > > > > > Make the build of drivers/pci/pcie/aspm.c depend on ACPI. > > > > NOTE, the patch has not been tested. The dependency on ACPI might be wrong, > > but setting it to default "y" caused the build on my powerpc box to break. > > > > Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> > > --- > > > > drivers/pci/pcie/Kconfig |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig > > --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 > > 15:30:29.0 +0530 > > +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig2008-02-04 > > 15:33:45.0 +0530 > > @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig" > > # > > config PCIEASPM > > bool "PCI Express ASPM support(Experimental)" > > - depends on PCI && EXPERIMENTAL && PCIEPORTBUS > > + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI > > default y > > help > > This enables PCI Express ASPM (Active State Power Management) and > > Thanks. I think Greg is going to revert PCIEASPM altogether? Greg did, hopefully Linus will pull the changes soon... thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] of: add alias helper functions.
From: Grant Likely <[EMAIL PROTECTED]>
Add helper functions for translating back and forth between alias
properties and device tree nodes.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/of/base.c | 80
include/linux/of.h |2 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b306fef..54a7f2e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -331,3 +331,83 @@ struct device_node *of_find_matching_node(struct
device_node *from,
return np;
}
EXPORT_SYMBOL(of_find_matching_node);
+
+/**
+ * of_find_node_by_alias - Find a node from an alias name
+ * @alias: Alias to decode
+ *
+ * Returns a node pointer with refcount incremented. Use of_node_put
+ * on it when done.
+ */
+struct device_node *of_find_node_by_alias(const char *alias)
+{
+ struct device_node *np, *alias_np;
+ const char *path;
+
+ np = NULL;
+
+ /* First decode the alias into a path */
+ alias_np = of_find_node_by_path("/aliases");
+ if (!alias_np)
+ return NULL;
+
+ path = of_get_property(alias_np, alias, NULL);
+ if (!path)
+ goto exit;
+
+ /* Next find the node pointed to by the alias */
+ np = of_find_node_by_path(path);
+
+ exit:
+ of_node_put(alias_np);
+ return np;
+}
+
+/**
+ * of_node_alias - Return the alias for a node
+ * @np Pointer to device node
+ * @prefix Prefix string; if provided then this function will only
+ * match on properties which have the given prefix.
+ *
+ * returns the alias property name for the given node without the prefix
+ */
+const char *of_node_alias(struct device_node *np, const char *prefix)
+{
+ struct device_node *alias_np, *test_np;
+ struct property *pp;
+ int prefix_len;
+ const char *alias;
+
+ prefix_len = 0;
+ if (prefix)
+ prefix_len = strlen(prefix);
+
+ /* First decode the alias into a path */
+ alias_np = of_find_node_by_path("/aliases");
+ if (!alias_np)
+ return NULL;
+
+ /* Loop over the aliases looking for a match */
+ alias = NULL;
+ for (pp = alias_np->properties; pp != 0; pp = pp->next) {
+ /* Skip properties which don't begin with the prefix */
+ if (prefix && (strncmp(pp->name, prefix, prefix_len) != 0))
+ continue;
+
+ /* Skip properties which aren't a NULL terminated string */
+ if (memchr(pp->value, 0, pp->length) == NULL)
+ continue;
+
+ /* Find out what node the property points to and see if it
+* matches. If so then we've found our alias */
+ test_np = of_find_node_by_path(pp->value);
+ if (test_np == np)
+ alias = pp->name + prefix_len;
+ of_node_put(test_np);
+ if (alias)
+ break;
+ }
+
+ of_node_put(alias_np);
+ return alias;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index b5f33ef..aae1570 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -68,5 +68,7 @@ extern int of_n_addr_cells(struct device_node *np);
extern int of_n_size_cells(struct device_node *np);
extern const struct of_device_id *of_match_node(
const struct of_device_id *matches, const struct device_node *node);
+extern struct device_node *of_find_node_by_alias(const char *alias);
+extern const char *of_node_alias(struct device_node *np, const char *prefix);
#endif /* _LINUX_OF_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] powerpc: free_property() mustn't be __init
On Wed, 30 Jan 2008 22:03:13 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > This patch fixes the following section mismatch: > > <-- snip --> > > ... > WARNING: vmlinux.o(.text+0x55648): Section mismatch in reference from the > function .free_node() to the function .init.text:.free_property() > ... > > <-- snip --> > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpTXdsuJqKdH.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] ehea: add memory remove hotplug support
On Monday 04 February 2008 15:46, Michael Ellerman wrote:
> On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> > Add memory remove hotplug support
> > @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> > if (ret)
> > ehea_info("failed registering reboot notifier");
> >
> > + ret = register_memory_notifier(&ehea_mem_nb);
> > + if (ret)
> > + ehea_info("failed registering memory remove notifier");
> >
> > ret = crash_shutdown_register(&ehea_crash_handler);
> > if (ret)
> > ehea_info("failed registering crash handler");
>
> You don't do anything except print a message if the registration fails.
> What happens when someone tries to remove memory but the memory notifier
> wasn't registered properly? Bang?
In case the registration fails and somebody tries to free memory:
- Driver will not remove the affected memory from the eHEA memory region
--> Firmware (phyp) can not free that memory (as marked as used)
--> Therefore the removed memory could not be used in an other partition
It makes sense to allow the driver to work anyway. Having no ethernet
would not really be a good alternative.
Regards,
Jan-Bernd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock; but it's actually isn't defined. This patch adds a missing dcr_ind_lock. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/dcr.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c --- linux-2.6.orig/arch/powerpc/sysdev/dcr.c2008-01-31 16:58:32.0 +0300 +++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.0 +0300 @@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned h.token = NULL; } EXPORT_SYMBOL_GPL(dcr_unmap); - -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ +#else /* defined(CONFIG_PPC_DCR_NATIVE) */ +DEFINE_SPINLOCK(dcr_ind_lock); +#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
On Mon, 4 Feb 2008 16:46:17 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote: > > > > If you don't care about the returned length (argument three to > > of_get_property), you can just pass NULL (and dispense with "size"). > > Also, what happens if prop is NULL? > > All this was in the old code already, I just didn't fix that. I appreciate that, but it did need fixing. > - - - - > From: Anton Vorontsov <[EMAIL PROTECTED]> > Subject: [POWERPC] qe_lib: fix few fluffy negligences > > One is intoduced by me (of_node_put() absence) and another was > present already (not checking for NULL). > > Found by Stephen Rothwell. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Acked-by: Stephen Rothwell <[EMAIL PROTECTED]> -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpt7fvPzUXX7.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] ehea: add memory remove hotplug support
On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> Add memory remove hotplug support
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
> ---
> Comment: This patch depends on the following patch that
> exports the symbols
> register_memory_notifier()
> unregister_memory_notifier()
>
> http://lkml.org/lkml/2008/2/1/293
>
>
> drivers/net/ehea/ehea_main.c | 25 +
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 21af674..b75afcc 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> if (ret)
> ehea_info("failed registering reboot notifier");
>
> + ret = register_memory_notifier(&ehea_mem_nb);
> + if (ret)
> + ehea_info("failed registering memory remove notifier");
>
> ret = crash_shutdown_register(&ehea_crash_handler);
> if (ret)
> ehea_info("failed registering crash handler");
You don't do anything except print a message if the registration fails.
What happens when someone tries to remove memory but the memory notifier
wasn't registered properly? Bang?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
Oops, sorry, please discard this one. DEFINE_SPINLOCK should be used here. Valentine Barshak wrote: > The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock, > but it's actually isn't defined. This patch adds a missing dcr_ind_lock. > > Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> > --- > arch/powerpc/sysdev/dcr.c |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c > linux-2.6/arch/powerpc/sysdev/dcr.c > --- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.0 > +0300 > +++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.0 > +0300 > @@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned > h.token = NULL; > } > EXPORT_SYMBOL_GPL(dcr_unmap); > - > -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ > +#else/* defined(CONFIG_PPC_DCR_NATIVE) */ > +spinlock_t dcr_ind_lock; > +#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock, but it's actually isn't defined. This patch adds a missing dcr_ind_lock. Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/dcr.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c --- linux-2.6.orig/arch/powerpc/sysdev/dcr.c2008-01-31 16:58:32.0 +0300 +++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.0 +0300 @@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned h.token = NULL; } EXPORT_SYMBOL_GPL(dcr_unmap); - -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ +#else /* defined(CONFIG_PPC_DCR_NATIVE) */ +spinlock_t dcr_ind_lock; +#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote:
> Hi Anton,
>
> I know this is late, but a couple of comments anyway.
>
> On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> > @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> > phys_addr_t get_qe_base(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const void *prop;
> >
> > if (qebase != -1)
> > return qebase;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const void *prop = of_get_property(qe, "reg", &size);
> > - qebase = of_translate_address(qe, prop);
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return qebase;
> > + }
> > +
> > + prop = of_get_property(qe, "reg", &size);
> > + qebase = of_translate_address(qe, prop);
>
> If you don't care about the returned length (argument three to
> of_get_property), you can just pass NULL (and dispense with "size").
> Also, what happens if prop is NULL?
All this was in the old code already, I just didn't fix that.
> > @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> > unsigned int get_brg_clk(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const u32 *prop;
> > +
> > if (brg_clk)
> > return brg_clk;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> > - brg_clk = *prop;
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return brg_clk;
> > + }
> > +
> > + prop = of_get_property(qe, "brg-frequency", &size);
> > + if (!prop || size != sizeof(*prop))
> > + return brg_clk;
>
> You need an of_node_put(qe) before the return ...
This is new. :-) Thanks.
- - - -
From: Anton Vorontsov <[EMAIL PROTECTED]>
Subject: [POWERPC] qe_lib: fix few fluffy negligences
One is intoduced by me (of_node_put() absence) and another was
present already (not checking for NULL).
Found by Stephen Rothwell.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/qe.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 5ef844d..6efbd5e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -66,7 +66,7 @@ phys_addr_t get_qe_base(void)
{
struct device_node *qe;
unsigned int size;
- const void *prop;
+ const u32 *prop;
if (qebase != -1)
return qebase;
@@ -79,7 +79,8 @@ phys_addr_t get_qe_base(void)
}
prop = of_get_property(qe, "reg", &size);
- qebase = of_translate_address(qe, prop);
+ if (prop && size >= sizeof(*prop))
+ qebase = of_translate_address(qe, prop);
of_node_put(qe);
return qebase;
@@ -172,10 +173,9 @@ unsigned int get_brg_clk(void)
}
prop = of_get_property(qe, "brg-frequency", &size);
- if (!prop || size != sizeof(*prop))
- return brg_clk;
+ if (prop && size == sizeof(*prop))
+ brg_clk = *prop;
- brg_clk = *prop;
of_node_put(qe);
return brg_clk;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/9] powerpc: add MPC837x RDB platform support
Hi Kim,
Again, a bit late but a couple of comments.
On Thu, 24 Jan 2008 20:47:11 -0600 Kim Phillips <[EMAIL PROTECTED]> wrote:
>
> +static struct of_device_id mpc837x_ids[] = {
Make this __initdata, please.
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
You need an of_node_put(np) here.
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc8377rdb") ||
> +of_flat_dt_is_compatible(root, "fsl,mpc8378rdb") ||
> +of_flat_dt_is_compatible(root, "fsl,mpc8379rdb");
You need to include asm/prom.h to use the flattened device tree accessors.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpcdoPMI7cOX.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc: fold the mpc8313 platform into the mpc831x platform
Hi Kim, I know this is late, but just a trivial comment. On Thu, 24 Jan 2008 20:45:51 -0600 Kim Phillips <[EMAIL PROTECTED]> wrote: > > --- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c > +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c > @@ -1,7 +1,7 @@ > /* > - * arch/powerpc/platforms/83xx/mpc8313_rdb.c > + * arch/powerpc/platforms/83xx/mpc831x_rdb.c Just remove the file name from the comment. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgp6efnUHqYpt.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patches "using mii-bitbang on different processor ports"
Hello! I am about this two patches. http://www.spinics.net/lists/netdev/msg45778.html http://www.spinics.net/lists/netdev/msg47159.html They was not applied. Could they be picked? Thank you Sergej. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API
On Sun, Feb 03, 2008 at 01:17:43PM -0800, David Brownell wrote:
> On Sunday 03 February 2008, Anton Vorontsov wrote:
> > This patch implements support for the GPIO LIB API. Two calls
> > unimplemented though: irq_to_gpio and gpio_to_irq.
>
> Also gpio_cansleep().
>
>
> > +Example of two SOC GPIO banks defined as gpio-controller nodes:
> > +
> > + qe_pio_a: [EMAIL PROTECTED] {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1400 0x18>;
> > + gpio-controller;
> > + };
> > +
> > + qe_pio_e: [EMAIL PROTECTED] {
> > + #gpio-cells = <2>;
> > + compatible = "fsl,qe-pario-bank";
> > + reg = <0x1460 0x18>;
> > + gpio-controller;
> > + };
>
> Let me suggest another example to provide: an I2C GPIO expander
> such as a pcf8574 or pca9354 (both eight bit expanders). The SOC
> case is probably the easiest to cover.
I2C expander will be easy to support via device tree too, something
like:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 8>;
interrupt-parent = <&ipic>;
dfsrr;
pcf_pio: [EMAIL PROTECTED] {
#gpio-cells = <2>;
compatible = "ti,pcf8574";
reg = <0x27>;
gpio-controller;
};
};
Of course, to support this, pcf857x driver needs OF bindings.
> > +#define ARCH_OF_GPIOS_PER_CHIP 32
>
> Well, ARCH_OF_* is clearly not the now-removed ARCH_GPIOS_PER_CHIP,
> but I still suggest moving away from that concept.
Yes, I noticed that ARCH_GPIOS_PER_CHIP is removed from the
gpiolib. But I solely use it to assign gpio_bases to the chips:
static int of_get_gpiochip_base(struct device_node *np)
{
struct device_node *gc = NULL;
int gpiochip_base = 0;
while ((gc = of_find_all_nodes(gc))) {
if (!of_get_property(gc, "gpio-controller", NULL))
continue;
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
of_node_put(gc);
if (gpiochip_base >= ARCH_OF_GPIOS_END)
return -ENOSPC;
return gpiochip_base;
}
return -ENOENT;
}
This function walks the device tree and assigns gpio_base 0 to
the first encountered gpio-controller, ARCH_OF_GPIOS_PER_CHIP * N
to the Nth controller...
Technically, I can replace
if (gc != np) {
gpiochip_base += ARCH_OF_GPIOS_PER_CHIP;
continue;
}
With
if (gc != np) {
struct gpio_chip *chip = gc->data;
if (chip)
gpiochip_base += chip->ngpio;
continue;
}
Here we're getting next available GPIO base. But then this code can't
handle gpio chip removal. So, we need smart "dynamic GPIO base
allocator" as described asm-generic/gpio.h, gpio_find_base(ngpios)
that will find free gpio base suitable for ngpios to place. Until
that allocator implemented, we use simple allocator with
OF_GPIOS_PER_CHIP...
> > +static inline int gpio_get_value(unsigned int gpio)
> > +{
> > + return __gpio_get_value(gpio);
> > +}
> > +
> > +static inline void gpio_set_value(unsigned int gpio, int value)
> > +{
> > + __gpio_set_value(gpio, value);
> > +}
>
> static inline int gpio_cansleep(unsigned int gpio)
> {
> return __gpio_cansleep(gpio);
> }
Will fix.
> > +static inline int irq_to_gpio(unsigned int irq)
> > +{
> > + return -ENOSYS;
>
> Minor nit: "-EINVAL" would be better here, since the argument
> is constrained to have been returned from gpio_to_irq(), and
> as you wrote that call there can be no such values.
Will change.
Thanks!
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model
Hi Anton,
I know this is late, but a couple of comments anyway.
On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> phys_addr_t get_qe_base(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const void *prop;
>
> if (qebase != -1)
> return qebase;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const void *prop = of_get_property(qe, "reg", &size);
> - qebase = of_translate_address(qe, prop);
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return qebase;
> + }
> +
> + prop = of_get_property(qe, "reg", &size);
> + qebase = of_translate_address(qe, prop);
If you don't care about the returned length (argument three to
of_get_property), you can just pass NULL (and dispense with "size").
Also, what happens if prop is NULL?
> @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> unsigned int get_brg_clk(void)
> {
> struct device_node *qe;
> + unsigned int size;
> + const u32 *prop;
> +
> if (brg_clk)
> return brg_clk;
>
> - qe = of_find_node_by_type(NULL, "qe");
> - if (qe) {
> - unsigned int size;
> - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> - brg_clk = *prop;
> - of_node_put(qe);
> - };
> + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!qe) {
> + qe = of_find_node_by_type(NULL, "qe");
> + if (!qe)
> + return brg_clk;
> + }
> +
> + prop = of_get_property(qe, "brg-frequency", &size);
> + if (!prop || size != sizeof(*prop))
> + return brg_clk;
You need an of_node_put(qe) before the return ...
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpd0ELMyrpcU.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] ehea: add memory remove hotplug support
Add memory remove hotplug support
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
Comment: This patch depends on the following patch that
exports the symbols
register_memory_notifier()
unregister_memory_notifier()
http://lkml.org/lkml/2008/2/1/293
drivers/net/ehea/ehea_main.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 21af674..b75afcc 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3480,6 +3481,24 @@ void ehea_crash_handler(void)
0, H_DEREG_BCMC);
}
+static int ehea_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ switch (action) {
+ case MEM_OFFLINE:
+ ehea_info("memory has been removed");
+ ehea_rereg_mrs(NULL);
+ break;
+ default:
+ break;
+ }
+ return NOTIFY_OK;
+}
+
+static struct notifier_block ehea_mem_nb = {
+ .notifier_call = ehea_mem_notifier,
+};
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
if (ret)
ehea_info("failed registering reboot notifier");
+ ret = register_memory_notifier(&ehea_mem_nb);
+ if (ret)
+ ehea_info("failed registering memory remove notifier");
+
ret = crash_shutdown_register(&ehea_crash_handler);
if (ret)
ehea_info("failed registering crash handler");
@@ -3582,6 +3605,7 @@ int __init ehea_module_init(void)
out3:
ibmebus_unregister_driver(&ehea_driver);
out2:
+ unregister_memory_notifier(&ehea_mem_nb);
unregister_reboot_notifier(&ehea_reboot_nb);
crash_shutdown_unregister(&ehea_crash_handler);
out:
@@ -3599,6 +3623,7 @@ static void __exit ehea_module_exit(void)
ret = crash_shutdown_unregister(&ehea_crash_handler);
if (ret)
ehea_info("failed unregistering crash handler");
+ unregister_memory_notifier(&ehea_mem_nb);
kfree(ehea_fw_handles.arr);
kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
--
1.5.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ehea: kdump support
This patch adds kdump support to the ehea driver. As the firmware doesn't free
resource handles automatically, the driver has to run an as simple as possible
free resource function in case of a crash shutdown. The function iterates over
two arrays freeing all resource handles which are stored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h | 34 +-
drivers/net/ehea/ehea_main.c | 281 ++
2 files changed, 290 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include
#define DRV_NAME "ehea"
-#define DRV_VERSION"EHEA_0083"
+#define DRV_VERSION"EHEA_0087"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -386,6 +386,13 @@ struct ehea_port_res {
#define EHEA_MAX_PORTS 16
+
+#define EHEA_NUM_PORTRES_FW_HANDLES6 /* QP handle, SendCQ handle,
+RecvCQ handle, EQ handle,
+SendMR handle, RecvMR handle */
+#define EHEA_NUM_PORT_FW_HANDLES 1 /* EQ handle */
+#define EHEA_NUM_ADAPTER_FW_HANDLES2 /* MR handle, NEQ handle */
+
struct ehea_adapter {
u64 handle;
struct of_device *ofdev;
@@ -405,6 +412,31 @@ struct ehea_mc_list {
u64 macaddr;
};
+/* kdump support */
+struct ehea_fw_handle_entry {
+ u64 adh; /* Adapter Handle */
+ u64 fwh; /* Firmware Handle */
+};
+
+struct ehea_fw_handle_array {
+ struct ehea_fw_handle_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
+struct ehea_bcmc_reg_entry {
+ u64 adh; /* Adapter Handle */
+ u32 port_id; /* Logical Port Id */
+ u8 reg_type; /* Registration Type */
+ u64 macaddr;
+};
+
+struct ehea_bcmc_reg_array {
+ struct ehea_bcmc_reg_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
#define EHEA_PHY_LINK_UP 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..21af674 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
@@ -98,8 +99,10 @@ static int port_name_cnt;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags;
struct work_struct ehea_rereg_mr_task;
-
struct semaphore dlpar_mem_lock;
+struct ehea_fw_handle_array ehea_fw_handles;
+struct ehea_bcmc_reg_array ehea_bcmc_regs;
+
static int __devinit ehea_probe_adapter(struct of_device *dev,
const struct of_device_id *id);
@@ -132,6 +135,160 @@ void ehea_dump(void *adr, int len, char *msg)
}
}
+static void ehea_update_firmware_handles(void)
+{
+ struct ehea_fw_handle_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ int num_adapters = 0;
+ int num_ports = 0;
+ int num_portres = 0;
+ int i = 0;
+ int num_fw_handles, k, l;
+
+ /* Determine number of handles */
+ list_for_each_entry(adapter, &adapter_list, list) {
+ num_adapters++;
+
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_ports++;
+ num_portres += port->num_def_qps + port->num_add_tx_qps;
+ }
+ }
+
+ num_fw_handles = num_adapters * EHEA_NUM_ADAPTER_FW_HANDLES +
+num_ports * EHEA_NUM_PORT_FW_HANDLES +
+num_portres * EHEA_NUM_PORTRES_FW_HANDLES;
+
+ if (num_fw_handles) {
+ arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ for (l = 0;
+l < port->num_def_qps + port->num_add_tx_qps;
+l++) {
+ struct ehea_port_res *pr = &port->port_res[l];
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->qp->fw_handle;
+
[PATCH 0/2] ehea: kdump & memory remove support
This patch set adds support for kdump and hotplug memory remove to the eHEA driver. The "memory remove" patch depends on the following patch that has been posted a few days ago. That patch exports the symbols - register_memory_notifier() - unregister_memory_notifier() http://lkml.org/lkml/2008/2/1/293 Regards, Jan-Bernd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Commit for mm/page_alloc.c breaks boot process on my machine
On (01/02/08 22:06), Gerhard Pircher didst pronounce: > > Original-Nachricht > > Datum: Fri, 1 Feb 2008 20:25:18 + > > Von: Mel Gorman <[EMAIL PROTECTED]> > > An: Gerhard Pircher <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED] > > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine > > > I meant uninitialised memory but I also wonder could something like this > > happen if you are trying to use memory that doesn't exist. i.e. you are > > trying to access more memory than you really have but you indicate later > > that this is not the case. > > Good question. The memory is in the physical address range from 0x > to 0x6000 (1536MB). > > > > > 2. Any chance of seeing a dmesg log? > > > That's a little bit of a problem. The kernel log in memory doesn't show > > > any kernel oops, but is also fragmented (small fragments seem to have > > > been overwritten with 0x0). > > > > err, that doesn't sound very healthy. > > Yeah, I know. But the platform code hasn't changed much when porting it > from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this > case. :-) > I'm at a bit of a loss to guess what might have changed in powerpc code that would explain this. I've added the linuxppc-dev mailing list in case they can make a guess. I think you are also going to need to start bisecting searching specifically for the patch that causes these overwrites. > > > Well, I can't answer this question. The kernel currently locks up when > > > loading the INIT program. But that is another problem (I still have to > > > bisect it) and doesn't seem to be related to this problem. > > > > INIT would be the first MOVABLE allocation so it would be using memory > > at the end of the physical adddress range. i.e. the crash happens when > > memory towards the end and the only difference between the patch applied > > and reverted is when it happens. > Oh, that sounds interesting! > > > Could you try booting with 16MB less memory using mem=? > I started the kernel with 512MB RAM (mem=496) and 1.5GB (mem=1520). The > kernel oopes in both cases with a "Unable to handle kernel paging request > for data address 0xb000", followed by a "Oops: kernel access of bad > area, sig 11" message. The end of the stack trace shows the start_here() > function. > I'm not a PowerPC expert, but if 0xb000 is a virtual address, then > it would be in the user program address space, right? If it is a physical > address, then it is somewhere in the unallocated PCI address space. > It's a virtual address so it depends on the value of CONFIG_KERNEL_START as to whether this is a user program address or not. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile quirk linux-2.6.24 (with workaround)
On Monday 04 February 2008 10:51, Sven Luther wrote: > On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote: > > Dear linux powerpc Maintainers and Users, > > > > recently I have tried to compile a new kernel on a Debian sarge ppc > > system (PowerBook5,6 MacRISC3 Power Macintosh). > > This is a G4 based system. Yes. > > The build system bailed out with > > BOOTCC arch/powerpc/boot/4xx.o > > cc1: error: bad value (440) for -mcpu= switch > > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1 > > > > I have tracked this a few steps and the attached patch made the compile > > for me as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13) > > cannot produce code for 4xx it seems. > > You should normally not need to build the 4xx bootloader part. Make sure > that, i don't know why this happens. Can you look into > arch/powerpc/boot/Makefile, to see what option enables the 4xx build, > and make sure it is disabled in the main config ? I have tried to do this, but it looks like it is just hardcoded into the Makefile as you can see from the patch. There is probably more that I do not understand - thus my report with on the workaround. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpHgMBWQa3vH.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Build failure with 2.6.24-mm1
On Mon, 4 Feb 2008 15:37:43 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > * Balbir Singh <[EMAIL PROTECTED]> [2008-02-04 15:35:09]: > > I just saw the following build failure on a power machine. > > In file included from include/acpi/platform/acenv.h:140, > from include/acpi/acpi.h:54, > from include/acpi/acpi_bus.h:31, > from drivers/pci/pcie/aspm.c:20: > include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or > directory > In file included from include/acpi/platform/aclinux.h:120, > from include/acpi/platform/acenv.h:140, > from include/acpi/acpi.h:54, > from include/acpi/acpi_bus.h:31, > from drivers/pci/pcie/aspm.c:20: > include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'UINT64' > include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or > '__attribute__' before 'INT64' > include/acpi/actypes.h:753: error: expected ')' before '*' token > include/acpi/actypes.h:756: error: expected ')' before '*' token > In file included from include/acpi/acpi.h:61, > from include/acpi/acpi_bus.h:31, > from drivers/pci/pcie/aspm.c:20: > include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...' > before 'acpi_osd_handler' > include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...' > before 'acpi_osd_handler' > include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...' > before 'acpi_osd_exec_callback' > make[3]: *** [drivers/pci/pcie/aspm.o] Error 1 > make[2]: *** [drivers/pci/pcie] Error 2 > make[2]: *** Waiting for unfinished jobs > CC drivers/ps3/ps3-vuart.o > CC net/netlink/attr.o > make[1]: *** [drivers/pci] Error 2 > make[1]: *** Waiting for unfinished jobs.. > > The following config option is responsible for the build failure > > config PCIEASPM > bool "PCI Express ASPM support(Experimental)" > depends on PCI && EXPERIMENTAL && PCIEPORTBUS > default y > help > This enables PCI Express ASPM (Active State Power Management) and > Clock Power Management. ASPM supports state L0/L0s/L1. > > When in doubt, say N. > > Here's a probable fix for the problem. > > > Make the build of drivers/pci/pcie/aspm.c depend on ACPI. > > NOTE, the patch has not been tested. The dependency on ACPI might be wrong, > but setting it to default "y" caused the build on my powerpc box to break. > > Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> > --- > > drivers/pci/pcie/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig > --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build2008-02-04 > 15:30:29.0 +0530 > +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 > 15:33:45.0 +0530 > @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig" > # > config PCIEASPM > bool "PCI Express ASPM support(Experimental)" > - depends on PCI && EXPERIMENTAL && PCIEPORTBUS > + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI > default y > help > This enables PCI Express ASPM (Active State Power Management) and Thanks. I think Greg is going to revert PCIEASPM altogether? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Build failure with 2.6.24-mm1
* Balbir Singh <[EMAIL PROTECTED]> [2008-02-04 15:35:09]: I just saw the following build failure on a power machine. In file included from include/acpi/platform/acenv.h:140, from include/acpi/acpi.h:54, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory In file included from include/acpi/platform/aclinux.h:120, from include/acpi/platform/acenv.h:140, from include/acpi/acpi.h:54, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'UINT64' include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'INT64' include/acpi/actypes.h:753: error: expected ')' before '*' token include/acpi/actypes.h:756: error: expected ')' before '*' token In file included from include/acpi/acpi.h:61, from include/acpi/acpi_bus.h:31, from drivers/pci/pcie/aspm.c:20: include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...' before 'acpi_osd_handler' include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...' before 'acpi_osd_handler' include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...' before 'acpi_osd_exec_callback' make[3]: *** [drivers/pci/pcie/aspm.o] Error 1 make[2]: *** [drivers/pci/pcie] Error 2 make[2]: *** Waiting for unfinished jobs CC drivers/ps3/ps3-vuart.o CC net/netlink/attr.o make[1]: *** [drivers/pci] Error 2 make[1]: *** Waiting for unfinished jobs.. The following config option is responsible for the build failure config PCIEASPM bool "PCI Express ASPM support(Experimental)" depends on PCI && EXPERIMENTAL && PCIEPORTBUS default y help This enables PCI Express ASPM (Active State Power Management) and Clock Power Management. ASPM supports state L0/L0s/L1. When in doubt, say N. Here's a probable fix for the problem. Make the build of drivers/pci/pcie/aspm.c depend on ACPI. NOTE, the patch has not been tested. The dependency on ACPI might be wrong, but setting it to default "y" caused the build on my powerpc box to break. Signed-off-by: Balbir Singh <[EMAIL PROTECTED]> --- drivers/pci/pcie/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.0 +0530 +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig2008-02-04 15:33:45.0 +0530 @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig" # config PCIEASPM bool "PCI Express ASPM support(Experimental)" - depends on PCI && EXPERIMENTAL && PCIEPORTBUS + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI default y help This enables PCI Express ASPM (Active State Power Management) and _ -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: compile quirk linux-2.6.24 (with workaround)
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote: > Dear linux powerpc Maintainers and Users, > > recently I have tried to compile a new kernel on a Debian sarge ppc > system (PowerBook5,6 MacRISC3 Power Macintosh). This is a G4 based system. > The build system bailed out with >BOOTCC arch/powerpc/boot/4xx.o > cc1: error: bad value (440) for -mcpu= switch > make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1 > > I have tracked this a few steps and the attached patch made the compile for me > as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13) > cannot produce code for 4xx it seems. You should normally not need to build the 4xx bootloader part. Make sure that, i don't know why this happens. Can you look into arch/powerpc/boot/Makefile, to see what option enables the 4xx build, and make sure it is disabled in the main config ? Please bounce this message to debian-powerpc, as debian believes in censorship instead of trying to solve inimity by discussion. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix ext4 bitops
On Mon, Feb 04, 2008 at 10:24:36AM +0100, Heiko Carstens wrote:
> > > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function
> > > > > 'generic_find_next_le_bit'
> > > > >
> > > > > The s390 specific bitops uses parts of the generic implementation.
> > > > > Include the correct header.
> > > >
> > > > That doesn't work:
> > > >
> > > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > > mballoc.c:(.text+0x95a8a): undefined reference to
> > > > `generic_find_next_le_bit'
> > > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > > mballoc.c:(.text+0x967ea): undefined reference to
> > > > `generic_find_next_le_bit'
> > > >
> > > > This still needs generic_find_next_le_bit which comes
> > > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > > don't set GENERIC_FIND_NEXT_BIT.
> > > > Currently we have the lengthly patch below queued.
> > >
> > > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > > impression the ext4 people don't (compile) test on big endian machines?
> > >
> > > Gr{oetje,eeting}s,
> > >
> >
> > I have sent this patches to linux-arch expecting a review from
> > different arch people. It is true that the patches are tested only on
> > powerpc, x86-64, x86. That's the primary reason of me sending the
> > patches to linux-arch.
>
> Is there anything special I need to do so the ext4 code actually uses
> ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
> test if the s390 implementation is ok.
With the latest linus kernel in git you can test it by mounting ext4
mount -t ext4dev
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge
Hello, I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540 processor). We are planning to move to 2.6.20 (powerpc), but I have some problems with the initialization of a PCI-PCI bridge. Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150, 3388:0022). When using the 2.6.14 kernel this bridge is initialized correctly: it is setup as bus-master, memory and IO are configured, and the memory allocation on the PCI-bus is correct. When I use 2.6.20 (powerpc) the device is not configured correctly: bus-master, memory and IO are not set, and the memory space of the bridge on the PCI bus is set to the minimum value (0xf). I can correct these settings by modifying the PCI_COMMAND register to set the bus-master, memory and IO. I change the size of the memory space in pci_32.c, by forcing the size to the required setting in pci_relocate_bridge_resource. But to be honest, I don't like this very much: modifying registers like this should not be needed, so I guess there is something wrong in my configuration or setup. How can I fix this problem in a better way? What could be wrong with my configuration? Below is some output from lspci: bash-3.00# lspci -t -[:00]-+-01.0 +-02.0-[:01]-- +-03.0-[:02-03]--+-00.0 |+-00.1 |+-00.2 |\-04.0-[:03]--+-02.0 | \-03.0 \-04.0 bash-3.00# lspci -vs 02:04.0 02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, medium devsel, latency 0 Bus: primary=02, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00011000-00011fff Memory behind bridge: 87f0-87ff Prefetchable memory behind bridge: 87e0-87e0 Capabilities: [dc] Power Management version 1 Capabilities: [e4] #06 [0094] Capabilities: [e8] Vital Product Data After the modifications to the PCI COMMAND register and memory map: bash-3.00# lspci -vs 02:04.0 02:04.0 PCI bridge: Hint Corp HiNT HB4 PCI-PCI Bridge (PCI6150) (rev 04) (prog-if 00 [Normal decode]) Flags: stepping, medium devsel Bus: primary=02, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00011000-00011fff Memory behind bridge: 8200-87ff Prefetchable memory behind bridge: - Capabilities: [dc] Power Management version 1 Capabilities: [e4] #06 [0094] Capabilities: [e8] Vital Product Data Kind regards, Johan Borkhuis -- Johan Borkhuis Dutch Space BV email:[EMAIL PROTECTED] Newtonweg 1 phone:071-5245788 Leiden fax: 071-5245499 The Netherlands ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix ext4 bitops
> > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function
> > > > 'generic_find_next_le_bit'
> > > >
> > > > The s390 specific bitops uses parts of the generic implementation.
> > > > Include the correct header.
> > >
> > > That doesn't work:
> > >
> > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > mballoc.c:(.text+0x95a8a): undefined reference to
> > > `generic_find_next_le_bit'
> > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > mballoc.c:(.text+0x967ea): undefined reference to
> > > `generic_find_next_le_bit'
> > >
> > > This still needs generic_find_next_le_bit which comes
> > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > don't set GENERIC_FIND_NEXT_BIT.
> > > Currently we have the lengthly patch below queued.
> >
> > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > impression the ext4 people don't (compile) test on big endian machines?
> >
> > Gr{oetje,eeting}s,
> >
>
> I have sent this patches to linux-arch expecting a review from
> different arch people. It is true that the patches are tested only on
> powerpc, x86-64, x86. That's the primary reason of me sending the
> patches to linux-arch.
Is there anything special I need to do so the ext4 code actually uses
ext2_find_next_bit() ? Haven't looked at the ext4 code, but I'd like to
test if the s390 implementation is ok.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
