* Re: [PATCH] fixes for the SLB shadow buffer
From: Michael Neuling @ 2007-08-03 1:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: will_schmidt, linuxppc-dev
In-Reply-To: <30559.1186046895@neuling.org>
We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Integrated more comments from people.
arch/powerpc/kernel/entry_64.S | 3 +++
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/slb.c | 28 ++++++++++++++++++----------
include/asm-powerpc/mmu-hash64.h | 1 +
4 files changed, 23 insertions(+), 11 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -389,8 +389,11 @@ BEGIN_FTR_SECTION
ld r9,PACA_SLBSHADOWPTR(r13)
li r12,0
std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
+ eieio
std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
+ eieio
std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
+ eieio
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_utils_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
@@ -759,7 +759,7 @@ int hash_page(unsigned long ea, unsigned
mmu_psize_defs[mmu_vmalloc_psize].sllp) {
get_paca()->vmalloc_sllp =
mmu_psize_defs[mmu_vmalloc_psize].sllp;
- slb_flush_and_rebolt();
+ slb_vmalloc_update();
}
#endif /* CONFIG_PPC_64K_PAGES */
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -53,7 +53,8 @@ static inline unsigned long mk_vsid_data
return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
}
-static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
+static inline void slb_shadow_update(unsigned long ea,
+ unsigned long flags,
unsigned long entry)
{
/*
@@ -61,11 +62,11 @@ static inline void slb_shadow_update(uns
* updating it.
*/
get_slb_shadow()->save_area[entry].esid = 0;
- barrier();
- get_slb_shadow()->save_area[entry].vsid = vsid;
- barrier();
- get_slb_shadow()->save_area[entry].esid = esid;
-
+ smp_wmb();
+ get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
+ smp_wmb();
+ get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
+ smp_wmb();
}
static inline void create_shadowed_slbe(unsigned long ea, unsigned long flags,
@@ -76,8 +77,7 @@ static inline void create_shadowed_slbe(
* we don't get a stale entry here if we get preempted by PHYP
* between these two statements.
*/
- slb_shadow_update(mk_esid_data(ea, entry), mk_vsid_data(ea, flags),
- entry);
+ slb_shadow_update(ea, flags, entry);
asm volatile("slbmte %0,%1" :
: "r" (mk_vsid_data(ea, flags)),
@@ -104,8 +104,7 @@ void slb_flush_and_rebolt(void)
ksp_esid_data &= ~SLB_ESID_V;
/* Only third entry (stack) may change here so only resave that */
- slb_shadow_update(ksp_esid_data,
- mk_vsid_data(ksp_esid_data, lflags), 2);
+ slb_shadow_update(get_paca()->kstack, lflags, 2);
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
@@ -123,6 +122,15 @@ void slb_flush_and_rebolt(void)
: "memory");
}
+void slb_vmalloc_update(void)
+{
+ unsigned long vflags;
+
+ vflags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_vmalloc_psize].sllp;
+ slb_shadow_update(VMALLOC_START, vflags, 1);
+ slb_flush_and_rebolt();
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -262,6 +262,7 @@ extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
extern void stab_initialize(unsigned long stab);
+extern void slb_vmalloc_update(void);
#endif /* __ASSEMBLY__ */
/*
^ permalink raw reply
* Re: [PATCH] fixes for the SLB shadow buffer
From: Benjamin Herrenschmidt @ 2007-08-03 2:50 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Paul Mackerras, will_schmidt
In-Reply-To: <1158.1186106139@neuling.org>
On Fri, 2007-08-03 at 11:55 +1000, Michael Neuling wrote:
> We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
> never updated with slb shadow buffer. This fixes it. Thanks to paulus
> for finding this.
>
> Also added some write barriers to ensure the shadow buffer is always
> valid.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Integrated more comments from people.
>
> arch/powerpc/kernel/entry_64.S | 3 +++
> arch/powerpc/mm/hash_utils_64.c | 2 +-
> arch/powerpc/mm/slb.c | 28 ++++++++++++++++++----------
> include/asm-powerpc/mmu-hash64.h | 1 +
> 4 files changed, 23 insertions(+), 11 deletions(-)
>
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
> @@ -389,8 +389,11 @@ BEGIN_FTR_SECTION
> ld r9,PACA_SLBSHADOWPTR(r13)
> li r12,0
> std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
> + eieio
> std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
> + eieio
> std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
> + eieio
>
> slbie r6
> slbie r6 /* Workaround POWER5 < DD2.1 issue */
> Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_utils_64.c
> +++ linux-2.6-ozlabs/arch/powerpc/mm/hash_utils_64.c
> @@ -759,7 +759,7 @@ int hash_page(unsigned long ea, unsigned
> mmu_psize_defs[mmu_vmalloc_psize].sllp) {
> get_paca()->vmalloc_sllp =
> mmu_psize_defs[mmu_vmalloc_psize].sllp;
> - slb_flush_and_rebolt();
> + slb_vmalloc_update();
> }
> #endif /* CONFIG_PPC_64K_PAGES */
>
> Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
> +++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> @@ -53,7 +53,8 @@ static inline unsigned long mk_vsid_data
> return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
> }
>
> -static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
> +static inline void slb_shadow_update(unsigned long ea,
> + unsigned long flags,
> unsigned long entry)
> {
> /*
> @@ -61,11 +62,11 @@ static inline void slb_shadow_update(uns
> * updating it.
> */
> get_slb_shadow()->save_area[entry].esid = 0;
> - barrier();
> - get_slb_shadow()->save_area[entry].vsid = vsid;
> - barrier();
> - get_slb_shadow()->save_area[entry].esid = esid;
> -
> + smp_wmb();
> + get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
> + smp_wmb();
> + get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
> + smp_wmb();
> }
>
> static inline void create_shadowed_slbe(unsigned long ea, unsigned long flags,
> @@ -76,8 +77,7 @@ static inline void create_shadowed_slbe(
> * we don't get a stale entry here if we get preempted by PHYP
> * between these two statements.
> */
> - slb_shadow_update(mk_esid_data(ea, entry), mk_vsid_data(ea, flags),
> - entry);
> + slb_shadow_update(ea, flags, entry);
>
> asm volatile("slbmte %0,%1" :
> : "r" (mk_vsid_data(ea, flags)),
> @@ -104,8 +104,7 @@ void slb_flush_and_rebolt(void)
> ksp_esid_data &= ~SLB_ESID_V;
>
> /* Only third entry (stack) may change here so only resave that */
> - slb_shadow_update(ksp_esid_data,
> - mk_vsid_data(ksp_esid_data, lflags), 2);
> + slb_shadow_update(get_paca()->kstack, lflags, 2);
>
> /* We need to do this all in asm, so we're sure we don't touch
> * the stack between the slbia and rebolting it. */
> @@ -123,6 +122,15 @@ void slb_flush_and_rebolt(void)
> : "memory");
> }
>
> +void slb_vmalloc_update(void)
> +{
> + unsigned long vflags;
> +
> + vflags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_vmalloc_psize].sllp;
> + slb_shadow_update(VMALLOC_START, vflags, 1);
> + slb_flush_and_rebolt();
> +}
> +
> /* Flush all user entries from the segment table of the current processor. */
> void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> {
> Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
> +++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
> @@ -262,6 +262,7 @@ extern void slb_initialize(void);
> extern void slb_flush_and_rebolt(void);
> extern void stab_initialize(unsigned long stab);
>
> +extern void slb_vmalloc_update(void);
> #endif /* __ASSEMBLY__ */
>
> /*
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: David Gibson @ 2007-08-03 2:53 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186087283.22717.80.camel@farscape.rchland.ibm.com>
On Thu, Aug 02, 2007 at 03:41:23PM -0500, Will Schmidt wrote:
> Hi Paul,
> just a few questions.
[snip]
> > +#define VSID_MULTIPLIER_256M ASM_CONST(200730139) /* 28-bit prime */
>
> > +#define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
>
> Anything special in how this 24-bit prime value was selected? (same
> question could be for the 28-bit prime, though I see that value was
> updated at least once a few years back)
I can't speak to the 24-bit value specifically, but I can speak to the
28-bit one: I did the rewrite of the SLB miss handler to use that
multiplicative hash, and changed the prime value when a bug report
showed problems in the original choice.
Afaict, the value of the prime doesn't matter all that much - in fact
it doesn't strictly even need to be prime, just co-prime to (2^36-1).
Originally, I picked the largest 28-bit prime, on the basis that a
large multiplier should give better scattering/folding.
That turned out to cause problems on some iSeries machines (which
couldn't do 16M pages) - we were filling up hash buckets with the
linear mapping. I figured out that that was because a very large
28-bit number was in the relevant modulus, sort of equivalent to a
small negative number. For a big linear mapping, the hash bucket
selected strided gradually backwards through the table - there were
also differences in the high bits of the hash, but they were lost
because of the limited size of the hash table.
So, I changed the multiplier to the median 28-bit prime, in the hopes
that that would give better hash scattering across as many bits of the
VSID as possible. I don't have much in the way of theoretical
justification for that, but it fixed the iSeries problem and I've
never heard of any regressions, so apparently it's not too bad.
--
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
^ permalink raw reply
* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-03 3:13 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <46B1F6D4.3070707@ru.mvista.com>
On Thu, Aug 02, 2007 at 07:23:00PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>Also mine. I've been home sick the last couple of days, but by way of
> >>a sharper prod, see my draft work below. It patches both
> >>booting-without-of.txt with a revised binding, and implements it in
> >>the physmap_of driver (which needs renaming, but that's another
> >>story). It also revises the ebony device tree as an example.
>
> >>This is certainly not complete - it defines none of the extra
> >>properties that JEDEC chips need (although the mtd drivers'
> >>defaults/probing seem to cope for ebony). And there are various other
> >>ommisions. Still, it's a starting point - something precise for you
> >>to flame Segher :-p.
>
> Let me flame you a bit for starters ;-)
Well, ok then.
> > Duh, forgot to attach the actual patch. Here it is:
>
> > Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> > ===================================================================
> > --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> > +++ working-2.6/Documentation/powerpc/booting-without-of.txt 2007-07-30 17:07:14.000000000 +1000
> > @@ -1757,45 +1757,23 @@ platforms are moved over to use the flat
> > };
> > };
> >
> > - j) Flash chip nodes
> > + j) CFI or JEDEC memory-mapped NOR flash
> >
> > Flash chips (Memory Technology Devices) are often used for solid state
> > file systems on embedded devices.
> >
> > - Required properties:
> > + - compatible : should contain the specific model of flash chip(s) used
> > + followed by either "cfi-flash" or "jedec-flash"
>
> This "compatible" prop (and the node in whole) doesn't say a
> thing about how the flash is mapped into the CPU address space. I
> strongly disagree that this node provides enough info to select a
> driver. :-/
To be honest, I'm not sure that describing the mapping is really the
job of the compatible property. That the flash is mapped into the
address space is kind of implicit in the way the reg interacts with
the parents' ranges property.
Can you describe some of the options for *not* direct mapped flash
chips - I can't reasonably come up with a way of describing the
distinction when I've never seen NOR flash other than direct mapped.
> > + - reg : Address range of the flash chip
> > + - bank-width : Width (in bytes) of the flash bank. Equal to the device width
> > + times the number of interleaved chips.
> > + - device-width : (optional) Width of a single flash chip. If omitted,
> > + assumed to be equal to 'bank-width'.
>
> Why then not just introduce the "interleave" prop and obsolete the
> "bank-width"?
Because they're equivalent information, and bank-width is what the
code ends up actually caring about. I don't see any reason to prefer
giving the interleave.
> > - Example:
> > -
> > - flash@ff000000 {
> > - device_type = "rom";
> > - compatible = "direct-mapped";
> > - probe-type = "CFI";
> > - reg = <ff000000 01000000>;
> > - bank-width = <4>;
> > - partitions = <00000000 00f80000
> > - 00f80000 00080001>;
> > - partition-names = "fs\0firmware";
> > - };
>
> Why delete the example? :-/
Because it's the old style, and I haven't gotten around to writing a
new example for the new style.
> > + Flash partitions
> > + - reg :
> > + - read-only : (optional)
>
> All that would look nice but partition is even less of a device than the
> original "rom" node was... well, who cares now? :-)
>
> > Index: working-2.6/drivers/mtd/maps/physmap_of.c
> > ===================================================================
> > --- working-2.6.orig/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:11.000000000 +1000
> > +++ working-2.6/drivers/mtd/maps/physmap_of.c 2007-07-30 17:07:14.000000000 +1000
> [...]
> > @@ -30,17 +33,72 @@ struct physmap_flash_info {
> > struct map_info map;
> > struct resource *res;
> > #ifdef CONFIG_MTD_PARTITIONS
> > - int nr_parts;
> > struct mtd_partition *parts;
> > #endif
> > };
> >
> > -static const char *rom_probe_types[] = { "cfi_probe", "jedec_probe", "map_rom", NULL };
> > #ifdef CONFIG_MTD_PARTITIONS
> > -static const char *part_probe_types[] = { "cmdlinepart", "RedBoot", NULL };
> > -#endif
> > +static int __devinit handle_of_flash_partitions(struct physmap_flash_info *info,
> > + struct of_device *dev)
> > +{
> > + static const char *part_probe_types[]
> > + = { "cmdlinepart", "RedBoot", NULL };
> > + struct device_node *dp = dev->node, *pp;
> > + int nr_parts, i, err;
> > +
> > + /* First look for RedBoot table or partitions on the command
> > + * line, these take precedence over device tree information */
> > + nr_parts = parse_mtd_partitions(info->mtd, part_probe_types,
> > + &info->parts, 0);
> > + if (nr_parts > 0) {
> > + add_mtd_partitions(info->mtd, info->parts, err);
> > + return 0;
> > + }
> > +
> > + /* First count the subnodes */
> > + nr_parts = 0;
> > + for (pp = dp->child; pp; pp = pp->sibling)
> > + nr_parts++;
> > +
> > + info->parts = kzalloc(nr_parts * sizeof(struct mtd_partition), GFP_KERNEL);
> > + if (!info->parts) {
> > + printk(KERN_ERR "Can't allocate the flash partition data!\n");
> > + return -ENOMEM;
> > + }
> > +
> > + for (pp = dp->child, i = 0 ; pp; pp = pp->sibling, i++) {
> > + const u32 *reg;
> > + const char *name;
> > + const void *ro;
>
> We hardly need the above 2 variables.
They're all used...
> > + int len;
> > +
> > + reg = of_get_property(pp, "reg", &len);
> > + if (! reg || (len != 2*sizeof(u32))) {
>
> Kill the space after !, please.
Done.
> > + dev_err(&dev->dev, "Invalid 'reg' on %s\n",
> > + dp->full_name);
> > + err = -EINVAL;
> > + goto fail;
> > + }
> > + info->parts[i].offset = reg[0];
> > + info->parts[i].size = reg[1];
> > +
> > + name = of_get_property(pp, "name", &len);
> > + info->parts[i].name = name;
> > +
> > + ro = of_get_property(pp, "read-only", &len);
> > + if (ro)
> > + info->parts[i].mask_flags = MTD_WRITEABLE;
> > + }
> > +
> > + add_mtd_partitions(info->mtd, info->parts, nr_parts);
> > + return 0;
> > +
> > + fail:
> > + kfree(info->parts);
> > + info->parts = NULL;
> > + return err;
> > +}
>
> Oh, I see that the new partition representation have really simplified
> parsing -- this function is hardly shorter than the old one... :-P
They new format isn't supposed to be simpler to parse: it's supposed
to be more flexible if we ever need to add more per-partition
information than just the offset / size / read-only.
> > -#ifdef CONFIG_MTD_PARTITIONS
> > static int parse_flash_partitions(struct device_node *node,
> > struct mtd_partition **parts)
> > {
> > @@ -79,7 +137,14 @@ static int parse_flash_partitions(struct
> > err:
> > return retval;
>
> Could get rid of that useless label and goto's in this function, while at
> it...
Yes, haven't really touched this function yet - it needs to be cleaned
up and re-integrated as the fallback method to parse device trees with
the old-style partition description.
> > }
> > -#endif
> > +#else /* MTD_PARTITIONS */
> > +static int __devinit handle_of_flash_partitions(struct physmap_flash_info *info,
> > + struct device_node *dev)
> > +{
> > + add_mtd_device(info->mtd);
> > + return 0;
> > +}
> > +#endif /* MTD_PARTITIONS */
> >
> > static int of_physmap_remove(struct of_device *dev)
> > {
> > @@ -115,13 +180,45 @@ static int of_physmap_remove(struct of_d
> > return 0;
> > }
> >
> > +/* Helper function to handle probing of the obsolete "direct-mapped"
> > + * compatible binding, which has an extra "probe-type" property
> > + * describing the type of flash probe necessary. */
>
> Too early to obsolete it, I'm afraid... :-)
Hrm.. obsolete != deprecate. The names designed to discourage use of
it for anything new, not to indicate that it's about to go away.
> > +static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
> > + struct map_info *map)
> > +{
> > + struct device_node *dp = dev->node;
> > + const char *of_probe;
> > + struct mtd_info *mtd;
> > + static const char *rom_probe_types[]
> > + = { "cfi_probe", "jedec_probe", "map_rom"};
> > + int i;
> > +
> > + of_probe = of_get_property(dp, "probe-type", NULL);
> > + if (!of_probe) {
> > + for (i = 0; i < ARRAY_SIZE(rom_probe_types); i++) {
> > + mtd = do_map_probe(rom_probe_types[i], map);
> > + if (mtd)
> > + return mtd;
> > + }
> > + return NULL;
> > + } else if (strcmp(of_probe, "CFI") == 0) {
> > + return do_map_probe("cfi_probe", map);
> > + } else if (strcmp(of_probe, "JEDEC") == 0) {
> > + return do_map_probe("jedec_probe", map);
> > + } else {
> > + if (strcmp(of_probe, "ROM") != 0)
> > + dev_dbg(&dev->dev, "obsolete_probe: don't know probe type "
> > + "'%s', mapping as rom\n", of_probe);
> > + return do_map_probe("mtd_rom", map);
> > + }
> > +}
> > +
> > static int __devinit of_physmap_probe(struct of_device *dev, const struct of_device_id *match)
> > {
> > struct device_node *dp = dev->node;
> > struct resource res;
> > struct physmap_flash_info *info;
> > - const char **probe_type;
> > - const char *of_probe;
> > + const char *probe_type = (const char *)match->data;
> > const u32 *width;
> > int err;
> [...]
> > @@ -221,6 +297,14 @@ err_out:
> >
> > static struct of_device_id of_physmap_match[] = {
> > {
> > + .compatible = "cfi-flash",
> > + .data = (void *)"cfi_probe",
> > + },
> > + {
> > + .compatible = "jedec-flash",
> > + .data = (void *)"jedec_probe",
> > + },
> > + {
>
> This would also trigger on non-linearly mapped CFI or JEDEC
> flashes which is not a good idea -- however, as we're using the MTD
> probing code anyway, it will just fail, so it's not luckily is not a
> fatal design flaw.
Well, if there's nothing else to distinguish them. Which there isn't
yet, but will need to be: see above about incomplete - helpful
suggestions about how to describe the mapping would be more useful
than merely pointing out the lack.
> > .type = "rom",
> > .compatible = "direct-mapped"
> > },
> > Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
> > ===================================================================
> > --- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
> > +++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-07-30 17:07:14.000000000 +1000
> [...]
> > @@ -158,14 +161,20 @@
> > };
> >
> > large-flash@2,0 {
>
> Hmm... what does @2,0 mean? :-O
EBC chip select 2, offset 0.
> > - device_type = "rom";
> > - compatible = "direct-mapped";
> > - probe-type = "JEDEC";
> > + compatible = "jedec-flash";
> > bank-width = <1>;
> > - partitions = <0 380000
> > - 380000 80000>;
> > - partition-names = "fs", "firmware";
> > +// partitions = <0 380000
> > +// 380000 80000>;
> > +// partition-names = "fs", "firmware";
> > reg = <2 0 400000>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
>
> Heh...
Yeah, that bit's a bit ugly, I'll grant you.
> > + fs@0 {
> > + reg = <0 380000>;
> > + };
> > + firmware@380000 {
> > + reg = <380000 80000>;
>
> I guess the "firmware" should have a "read-only" prop...
Possibly.
> > + };
> > };
>
> So, I don't see what we're really winning with your changes...
"direct-mapped" is simply not a sufficiently specific compatible
property, no two ways about it. This spec still needs more specific
description of some properties, at least for JEDEC flashes.
--
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
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: David Gibson @ 2007-08-03 4:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1186103889.5495.650.camel@localhost.localdomain>
On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> > On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > > PPC44x cascade UIC irq handler fix.
> > >
> > > According to PPC44x UM, if an interrupt is configured as level-sensitive,
> > > and a clear is attempted on the UIC_SR, the UIC_SR field is not
> > > cleared if the incoming interrupt signal is at the asserted polarity.
> > > This causes us to enter a cascade handler twice, since we first ack
> > > parent UIC interrupt and ack child UIC one after that.
> > > The patch checks child UIC msr value and returns IRQ_HANDLED
> > > if there're no pending interrupts. Otherwise we get a kernel panic
> > > with a "Fatal exception in interrupt" (illegal vector).
> > > The patch also fixes status flags.
> > >
> > > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> >
> > Hrm... This doesn't seem like the right fix to me. Instead, I think
> > the cascaded IRQ handler should ack the interrupt on the child first.
> > I'm a little surprised it doesn't at the moment.
>
> Well, we certainly do also need to make the code more solid vs.
> spurrious interrupts.
Actually that's true. The suggested patch is a good improvement for
general robustness, but doesn't actually address the real problem.
> The main thing is, if the cascade is a level interrupt, it should
> probably use a smarter cascade handler that masks it, handle the child
> interrupts, then unmasks it.
We already have that, since I just use setup_irq() to set up a cascade
handler, rather than a custom flow handler.
The problem is that the standard handle_level_irq() flow handler acks
before the ISR is called, whereas because of this UIC behaviour, we
need to ack after the ISR has cleared the interrupt in the source.
This is not specific to cascades, but is a problem for all
level-triggered interrupts (i.e. basically everything).
I think it means we must currently be getting a whole lot of spurious
interrupts - will do some investigation in a moment.
To fix this either we'll need a custom flow handler for UIC, or we can
use the standard one, but clear the UIC_SR bits from the ->unmask()
callback for level interrupts. I'm not entirely sure if the latter
approach is safe - I *think* it is, but I could do with more
convincing.
--
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
^ permalink raw reply
* Re: Open Firmware - dts file
From: David Gibson @ 2007-08-03 5:22 UTC (permalink / raw)
To: Siva Prasad; +Cc: linuxppc-dev
In-Reply-To: <D83235F0F3C86D4D889D8B9A0DA8C6D79AE206@corpexc01.corp.networkrobots.com>
On Thu, Aug 02, 2007 at 12:21:21PM -0700, Siva Prasad wrote:
> Hi,
>
> I am trying to understand ..
>
> 1) How a given dts file is embedded into the zImage (how about vmlinux?)
The arch/powerpc/boot/wrapper script builds the dts into a device tree
blob using dtc (the Device Tree Compiler), it then folds the binary
device tree into a special section in the zImage.
> 2) Where does it get stored for later access during booting?
The zImage, possibly after adjusting the device tree based on
information from the firmware, passes the address of the tree to the
kernel as it invokes it. The kernel adds the device tree address (as
well as any further ranges specified in the device tree blob) to its
internal list of reserved addresses so it won't clobber it with other
allocations.
> 3) How a specific dts file out of the available in /boot/dts directory
> is chosen?
Depending on the Kconfig, different Makefile targets will be
selected. Those targets then invoke the wrapper script with different
options, including different dts files into the zImage.
> I am a newbie to this open firmware thing and looking for the right
> pointer to get started.
Ok.. do understand that on systems with a full open firmware
implementation a dts won't generally be used at all. Instead the
kernel will read the device tree information from open firmware itself
and convert it directly into a device tree blob (which will later be
unpacked into the run-time device tree structure).
--
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
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: David Gibson @ 2007-08-03 6:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Valentine Barshak
In-Reply-To: <20070803045705.GA2392@localhost.localdomain>
On Fri, Aug 03, 2007 at 02:57:05PM +1000, David Gibson wrote:
> On Fri, Aug 03, 2007 at 11:18:09AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 13:48 +1000, David Gibson wrote:
> > > On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
> > > > PPC44x cascade UIC irq handler fix.
> > > >
> > > > According to PPC44x UM, if an interrupt is configured as level-sensitive,
> > > > and a clear is attempted on the UIC_SR, the UIC_SR field is not
> > > > cleared if the incoming interrupt signal is at the asserted polarity.
> > > > This causes us to enter a cascade handler twice, since we first ack
> > > > parent UIC interrupt and ack child UIC one after that.
> > > > The patch checks child UIC msr value and returns IRQ_HANDLED
> > > > if there're no pending interrupts. Otherwise we get a kernel panic
> > > > with a "Fatal exception in interrupt" (illegal vector).
> > > > The patch also fixes status flags.
> > > >
> > > > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > >
> > > Hrm... This doesn't seem like the right fix to me. Instead, I think
> > > the cascaded IRQ handler should ack the interrupt on the child first.
> > > I'm a little surprised it doesn't at the moment.
> >
> > Well, we certainly do also need to make the code more solid vs.
> > spurrious interrupts.
>
> Actually that's true. The suggested patch is a good improvement for
> general robustness, but doesn't actually address the real problem.
>
> > The main thing is, if the cascade is a level interrupt, it should
> > probably use a smarter cascade handler that masks it, handle the child
> > interrupts, then unmasks it.
>
> We already have that, since I just use setup_irq() to set up a cascade
> handler, rather than a custom flow handler.
>
> The problem is that the standard handle_level_irq() flow handler acks
> before the ISR is called, whereas because of this UIC behaviour, we
> need to ack after the ISR has cleared the interrupt in the source.
> This is not specific to cascades, but is a problem for all
> level-triggered interrupts (i.e. basically everything).
>
> I think it means we must currently be getting a whole lot of spurious
> interrupts - will do some investigation in a moment.
>
> To fix this either we'll need a custom flow handler for UIC, or we can
> use the standard one, but clear the UIC_SR bits from the ->unmask()
> callback for level interrupts. I'm not entirely sure if the latter
> approach is safe - I *think* it is, but I could do with more
> convincing.
Ok, here's a patch which fixes up the flow handling on the UIC. It
needs some polish yet, but should be ok to test. Valentine, can you
test this on your setup, *without* your original proposed patch.
Eventually, for robustness, we'll want something like your original
patch as well for robustness, but in the meantime leaving it out
should tell us if my patch is actually having the intended effect.
Index: working-2.6/arch/powerpc/sysdev/uic.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/uic.c 2007-08-03 16:09:48.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/uic.c 2007-08-03 16:09:49.000000000 +1000
@@ -24,6 +24,7 @@
#include <linux/spinlock.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/kernel_stat.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <asm/prom.h>
@@ -159,6 +160,56 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
+/**
+ * handle_uic_irq - Level type irq handler
+ * @irq: the interrupt number
+ * @desc: the interrupt description structure for this irq
+ *
+ * Level type interrupts are active as long as the hardware line has
+ * the active level. This may require to mask the interrupt and unmask
+ * it after the associated handler has acknowledged the device, so the
+ * interrupt line is back to inactive.
+ */
+void fastcall
+handle_uic_irq(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cpu = smp_processor_id();
+ struct irqaction *action;
+ irqreturn_t action_ret;
+
+ spin_lock(&desc->lock);
+ desc->chip->mask(irq);
+
+ if (unlikely(desc->status & IRQ_INPROGRESS))
+ goto out_unlock;
+ desc->status &= ~(IRQ_REPLAY | IRQ_WAITING);
+ kstat_cpu(cpu).irqs[irq]++;
+
+ /*
+ * If its disabled or no action available
+ * keep it masked and get out of here
+ */
+ action = desc->action;
+ if (unlikely(!action || (desc->status & IRQ_DISABLED))) {
+ desc->status |= IRQ_PENDING;
+ goto out_unlock;
+ }
+
+ desc->status |= IRQ_INPROGRESS;
+ desc->status &= ~IRQ_PENDING;
+ spin_unlock(&desc->lock);
+
+ action_ret = handle_IRQ_event(irq, action);
+
+ spin_lock(&desc->lock);
+ desc->status &= ~IRQ_INPROGRESS;
+ desc->chip->ack(irq);
+ if (!(desc->status & IRQ_DISABLED) && desc->chip->unmask)
+ desc->chip->unmask(irq);
+out_unlock:
+ spin_unlock(&desc->lock);
+}
+
static int uic_host_match(struct irq_host *h, struct device_node *node)
{
struct uic *uic = h->host_data;
@@ -173,7 +224,7 @@ static int uic_host_map(struct irq_host
set_irq_chip_data(virq, uic);
/* Despite the name, handle_level_irq() works for both level
* and edge irqs on UIC. FIXME: check this is correct */
- set_irq_chip_and_handler(virq, &uic_irq_chip, handle_level_irq);
+ set_irq_chip_and_handler(virq, &uic_irq_chip, handle_uic_irq);
/* Set default irq type */
set_irq_type(virq, IRQ_TYPE_NONE);
--
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
^ permalink raw reply
* Re: [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPCarchitecture with ULI chip quirk functions.
From: Zang Roy-r61911 @ 2007-08-03 6:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <05E0FF5A-03DB-441E-81E8-54BD4A215D32@kernel.crashing.org>
On Thu, 2007-08-02 at 12:29, Kumar Gala wrote:
> On Aug 1, 2007, at 8:23 PM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2007-08-02 at 09:17 +0800, Zhang Wei-r63237 wrote:
> >> Hi, Ben,
> >>
> >>>
> >>> Are we sure that any powerpc machine that uses that ULI chip will
> >>> need
> >>> the same quirk setting ?
> >>>
> >>
> >> We can ensure current platforms (as far as we know, MPC8544DS and
> >> MPC8641HPCN) using ULI chips in powerpc of kernel need the same
> quirk
> >> setting.
> >> And we hope to make them more generic. And if there are some
> >> different
> >> setting in the future, we can add special codes.
> >
> > All right.
>
> My feeling is this code is pretty specific to how the ULI M1575 is
> used on those boards and should only be built for those boards.
Until now, it is right.
Roy
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-08-03 6:35 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070628100020.GA24215@iram.es>
On Thu, Jun 28, 2007 at 12:00:20PM +0200, Gabriel Paubert wrote:
> On Thu, Jun 28, 2007 at 10:59:35AM +0200, Segher Boessenkool wrote:
> > > Here is an implementation to allow PReP systems to boot under the
> > > arch/powerpc codebase, one of the few remaining platforms supported in
> > > arch/ppc but not so far in arch/powerpc.
> >
> > > Too big for the list, the patch is at:
> > > http://ozlabs.org/~dgibson/home/prep-support
> >
> > Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Anyway, here goes the DTS bits:
> >
> > +/*
> > + * PReP skeleton device tree
> > + *
> > + * Paul Mackerras <paulus@samba.org>
> > + */
> > +
> > +/ {
> > + device_type = "prep";
> > + model = "IBM,PReP";
> >
> > Not specific enough, leave it out or fill it in in the bootwrapper.
>
> Motorola also provided PreP boards (MTX and MVME at least).
>
> >
> > + compatible = "prep";
> >
> > Maybe fill this in, too.
> >
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cpu@0 {
> >
> > Do all (supported) PReP boards have one CPU only?
>
> Not sure, but I don't have any. I believe that there were
> dual processors MTX boards, and dual 604 MVME boards were
> offered (but probably not very popular).
>
> >
> > + device_type = "cpu";
> > + reg = <0>;
> > + clock-frequency = <0>; // filled in by bootwrapper
> > + bus-frequency = <0>; // filled in by bootwrapper
> > + timebase-frequency = <0>; // filled in by bootwrapper
> > + i-cache-line-size = <0>; // filled in by bootwrapper
> > + d-cache-line-size = <0>; // filled in by bootwrapper
> > + d-cache-size = <0>; // filled in by bootwrapper
> > + i-cache-size = <0>; // filled in by bootwrapper
> > + external-control;
> >
> > Really?
>
> Well, is anybody actually using eciwx/ecowx?
Eh, I've removed those properties anyway, the kernel never looks at
them anyway.
> > + graphics;
> > + performance-monitor;
> > +
> > + l2-cache {
> > + device_type = "cache";
> > + i-cache-size = <00100000>;
> > + d-cache-size = <00100000>;
> > + i-cache-sets = <00008000>;
> > + d-cache-sets = <00008000>;
> > + i-cache-line-size = <00000020>;
> > + d-cache-line-size = <00000020>;
> >
> > Drop the leading zeroes, they make my head spin :-)
>
> It's also wrong, my boards have 256kB of L2 cache.
Yeah, I need to fill in the L2 cache information from the residual as
well.
> > + cache-unified;
> > + };
> > + };
> > + };
> > +
> > + memory {
> > + device_type = "memory";
> > + // dummy range here, zImage wrapper will fill in the actual
> > + // amount of memory from the residual data
> > + reg = <00000000 00000000>;
> > + };
> > +
> > + pci@80000000 {
> > + device_type = "pci";
> > + compatible = "prep";
> >
> > Is that specific enough?
>
> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> space is smaller and at a higher address. Actually for
> MVME2400/2600/2700, I wrote a bootloader that reprograms the bridge
> in a CHRP like mode since nobody needs almost 1GB of PCI I/O space
> but having 1.5GB of PCI memory space is very useful.
Hrm... ok. Now I'm a bit confused, because I thought what I'd put in
the device tree for PCI was all based on what was already hardcoded /
assumed in prep_pci.c anyway.
> > + clock-frequency = <01fca055>;
> > + reg = <80000000 7effffff>;
> > + 8259-interrupt-acknowledge = <bffffff0>;
>
> Not always. It is at feff0030 on Raven/Falcon/Hawk boards (given
> by a system address assigned to the 8259 PIC in the residual data).
>
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + ranges=<01000000 00000000 00000000 80000000 00000000 00800000
> > + 01000000 00000000 00800000 81000000 00000000 3e800000
> > + 02000000 00000000 00000000 c0000000 00000000 01000000
> > + 02000000 00000000 01000000 c1000000 00000000 3e000000>;
> > + interrupt-map-mask = <f800 0 0 7>;
> > + interrupt-map = <6000 0 0 1 &MPIC 6 0
> > + 8000 0 0 1 &MPIC 7 0
> > + 9000 0 0 1 &MPIC 2 0
> > + b000 0 0 1 &MPIC 1 0>;
> >
> > I can't believe this "ranges" and interrupt mapping will
> > work on all PReP systems...
>
> Neither do I.
>
> > + isa {
> > + device_type = "isa";
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + #interrupt-cells = <2>;
> > + ranges = <00000001 00000000
> > + 01005800 00000000 00000000 00010000
> > + 00000000 00000000
> > + 02005800 00000000 00000000 01000000>;
> > +
> > + parallel {
> > + device_type = "parallel";
> > + compatible = "ecp", "pnpPNP,400";
> >
> > "pnpPNP,401", "pnpPNP,400"
Adjusted.
> > + reg = <00000001 000003bc 00000008
> > + 00000001 000007bc 00000006>;
> > + interrupts = <00000007 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
> > +
> > + serial@3f8 {
> > + device_type = "serial";
> > + compatible = "pnpPNP,501";
> >
> > "pnpPNP,501", "pnpPNP,500" I'd say. Many/some device
> > tree users will only care it is _some_ 8250 family thing.
Ok.
> > + clock-frequency = <001c2000>;
> > + reg = <00000001 000003f8 00000008>;
> > + interrupts = <00000004 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
> > + serial@2f8 {
> > + device_type = "serial";
> > + compatible = "pnpPNP,501";
> > + clock-frequency = <001c2000>;
> > + reg = <00000001 000002f8 00000008>;
> > + interrupts = <00000003 00000003>;
> > + interrupt-parent = <&PIC8259>;
> > + };
>
> Some of my boards have only one serial port (and also only 1 in the residual data).
Ok, I'll have to think about how to implement that. Probably wants to
wait until we've integrated libfdt for more flexible manipulation of
the device tree.
> > + PIC8259: interrupt-controller {
> > + device_type = "i8259";
> >
> > device_type = "interrupt-controller".
Is that really right? The MPIC binding, at least, has device_type =
"open-pic" rather than "interrupt-controller".
> > + compatible = "prep,iic";
> > + reg = < 00000001 00000020 00000002
> > + 00000001 000000a0 00000002
> > + 00000001 000004d0 00000002>;
> > + interrupts = <00000000 00000003
> > + 00000002 00000003>;
> > + interrupt-parent = <&MPIC>;
> > + };
> > + };
> > +
> > + MPIC: interrupt-controller@d {
> > + device_type = "open-pic";
> >
> > device_type = "interrupt-controller".
Not according to the binding in booting-without-of.txt
> > + compatible = "mpic";
> > + reg = < 00006800 00000000 00000000 00000000 00000000
> > + 02006810 00000000 00000000 00000000 00040000>;
> > + assigned-addresses = <
> > + 82006810 00000000 3afc0000 00000000 00040000>;
> > + };
> > + };
> > +
> > + chosen {
> > + linux,stdout-path = "/pci/isa/serial@3f8";
> > + };
> > +};
> >
> > What is the plan here -- have the bootwrapper build the
> > device tree / fill in the details from the residual data?
>
> I think so. I might have some time to try a more recent kernel
> on MVME2400/2600 boards next week.
>
> Regards,
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
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
^ permalink raw reply
* Re: [PATCH 4/6] PowerPC 440EPx: Sequoia bootwrapper
From: Stefan Roese @ 2007-08-03 6:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802152941.579a55fa@weaponx.rchland.ibm.com>
On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:14:45 +0400
> > +#define SPRN_CCR1 0x378
> > +void ibm440ep_fixup_clocks(unsigned int sysclk, unsigned int ser_clk)
> > +{
> > + u32 cpu, plb, opb, ebc, tb, uart0, m, vco;
> > + u32 reg;
> > + u32 fwdva, fwdvb, fbdv, lfbdv, opbdv0, perdv0, spcid0, prbdv0, tmp;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x000F0000) >> 16;
> > + fwdva = tmp ? tmp : 16;
> > + tmp = (reg & 0x00000700) >> 8;
> > + fwdvb = tmp ? tmp : 8;
> > + tmp = (reg & 0x1F000000) >> 24;
> > + fbdv = tmp ? tmp : 32;
> > + lfbdv = (reg & 0x0000007F);
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_OPBD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + opbdv0 = tmp ? tmp : 4;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PERD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x07000000) >> 24;
> > + perdv0 = tmp ? tmp : 8;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PRIMBD0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x07000000) >> 24;
> > + prbdv0 = tmp ? tmp : 8;
> > +
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_SCPID);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + spcid0 = tmp ? tmp : 4;
> > +
> > + /* Calculate M */
> > + mtdcr(DCRN_CPR0_ADDR, CPR0_PLLC0);
> > + reg = mfdcr(DCRN_CPR0_DATA);
> > + tmp = (reg & 0x03000000) >> 24;
> > + if (tmp == 0) { /* PLL output */
> > + tmp = (reg & 0x20000000) >> 29;
> > + if (!tmp) /* PLLOUTA */
> > + m = fbdv * lfbdv * fwdva;
> > + else
> > + m = fbdv * lfbdv * fwdvb;
> > + }
> > + else if (tmp == 1) /* CPU output */
> > + m = fbdv * fwdva;
> > + else
> > + m = perdv0 * opbdv0 * fwdvb;
> > +
> > + vco = (m * sysclk) + (m >> 1);
> > + cpu = vco / fwdva;
> > + plb = vco / fwdvb / prbdv0;
> > + opb = plb / opbdv0;
> > + ebc = plb / perdv0;
> > +
> > + /* FIXME */
> > + uart0 = ser_clk;
> > +
> > + /* Figure out timebase. Either CPU or default TmrClk */
> > + asm volatile (
> > + "mfspr %0,%1\n"
> > + :
> > + "=&r"(reg) : "i"(SPRN_CCR1));
> > + if (reg & 0x0080)
> > + tb = 25000000; /* TmrClk is 25MHz */
> > + else
> > + tb = cpu;
> > +
> > + dt_fixup_cpu_clocks(cpu, tb, 0);
> > + dt_fixup_clock("/plb", plb);
> > + dt_fixup_clock("/plb/opb", opb);
> > + dt_fixup_clock("/plb/opb/ebc", ebc);
> > + dt_fixup_clock("/plb/opb/serial@ef600300", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600400", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600500", uart0);
> > + dt_fixup_clock("/plb/opb/serial@ef600600", uart0);
> > +}
>
> We don't need to duplicate this function in two different wrappers.
> I'll move it into 4xx.c in my next round of patches, so that bamboo and
> sequoia can just call a common function.
Good idea.
> > +/*
> > + * 440EPx DDR1/2 memory controller code
> > + * TODO: move to generic 44x code
> > + */
> > +
> > +/* DDR0_02 */
> > +#define DDR_START 0x1
> > +#define DDR_START_SHIFT 0
> > +#define DDR_MAX_CS_REG 0x3
> > +#define DDR_MAX_CS_REG_SHIFT 24
> > +#define DDR_MAX_COL_REG 0xf
> > +#define DDR_MAX_COL_REG_SHIFT 16
> > +#define DDR_MAX_ROW_REG 0xf
> > +#define DDR_MAX_ROW_REG_SHIFT 8
> > +/* DDR0_08 */
> > +#define DDR_DDR2_MODE 0x1
> > +#define DDR_DDR2_MODE_SHIFT 0
> > +/* DDR0_10 */
> > +#define DDR_CS_MAP 0x3
> > +#define DDR_CS_MAP_SHIFT 8
> > +/* DDR0_14 */
> > +#define DDR_REDUC 0x1
> > +#define DDR_REDUC_SHIFT 16
> > +/* DDR0_42 */
> > +#define DDR_APIN 0x7
> > +#define DDR_APIN_SHIFT 24
> > +/* DDR0_43 */
> > +#define DDR_COL_SZ 0x7
> > +#define DDR_COL_SZ_SHIFT 8
> > +#define DDR_BANK8 0x1
> > +#define DDR_BANK8_SHIFT 0
> > +
> > +#define DDR_GET_VAL(val, mask, shift) (((val) >> (shift)) & (mask))
> > +
> > +static void ibm440epx_fixup_memsize(void)
>
> And we should move this at the same time. Isn't denali used by another
> CPU as well?
Right now the Denali DDR(2) core is only used by the 440EPx/440GRx. But other
AMCC PPC's using it will follow soon.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: David Gibson @ 2007-08-03 6:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <505C0D97-FF0D-4E7F-B988-88894F629FD2@kernel.crashing.org>
On Wed, Jul 18, 2007 at 05:55:16PM +0200, Segher Boessenkool wrote:
> >>> Too big for the list, the patch is at:
> >>> http://ozlabs.org/~dgibson/home/prep-support
> >>
> >> Too lazy to split the patch into bite-size chunks, you mean ;-)
> >
> > Well... much as I like small patches, I don't really like having a big
> > string of patches, each of which does basically nothing on its own,
> > i.e. split up just for the sake of making smaller, rather than into
> > separate logically separate changes.
>
> Yeah I understand. It's just that I had to dig out the DTS
> part :-)
Diddums :-p.
> >> + external-control;
> >>
> >> Really?
> >
> > No idea, just copied that from earlier work of Paulus'. Don't even
> > know what the property means.
>
> It seems to me a flat device tree could leave out all those
> properties that can be derived from the PVR (except for the
> few that are really useful for bootloaders and such -- cache
> line size, 64-bit-or-not, what kind of MMU). Linux doesn't
> use it anyway. Existing DTSs already leave away most.
I agree, ditched them from my dts.
> >> + pci@80000000 {
> >> + device_type = "pci";
> >> + compatible = "prep";
> >>
> >> Is that specific enough?
> >
> > Well, AFAICT, the prep PCI code doesn't need any more info.
>
> If PReP requires a specific programming model for the PCI
> host bridge, that would be fine. But then compatible =
> "prep-pci-bridge" or such, not just "prep"; everything on
> your board is "prep", it would make matching a bit hard ;-)
Well... I'm rather unclear on how much PReP requires of the PCI
bridge. I thought what I'd coded was based on what appeared to be
hard assumptions in prep_pci.c, but now I'm hearing that this won't
cover all PReP machines, so I'm really not sure.
> >> I can't believe this "ranges" and interrupt mapping will
> >> work on all PReP systems...
> >
> > Probably not, but it should work on a chunk of them. Like I say,
> > there's still a good deal more that needs to be filled in from
> > residual data or wherever.
>
> Sure, I'm just pointing out things that seem problematic, I'm
> not saying your code can't be merged because of that -- esp.
> since it is a new port anyway (for arch/powerpc, that is).
>
> >> What is the plan here -- have the bootwrapper build the
> >> device tree / fill in the details from the residual data?
> >
> > Not sure at this stage if it will be best for the bootwrapper to build
> > a complete tree from residual, or to have a dts skeleton with
> > substantial chunks filled in by bootwrapper from residual.
>
> Conceptually those two options are pretty much the same thing;
> just try them out, see what is nicer for the implementation.
>
> > I was
> > intending to merge libfdt into the kernel for more flexible device
> > tree manipulation before investigating that further.
>
> Into the kernel wrapper, I think you mean?
Yes, of course.
--
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
^ permalink raw reply
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Stefan Roese @ 2007-08-03 6:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802153451.5a92947b@weaponx.rchland.ibm.com>
On Thursday 02 August 2007, Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> > +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
> > 20:44:26.000000000 +0400 @@ -1132,6 +1132,42 @@
> > .dcache_bsize = 32,
> > .platform = "ppc440",
> > },
> > + { /* 440EPX - with Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D0,
> > + .cpu_name = "440EPX - with Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
> > 440EPX has an FPU */ + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440EPX - without Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D4,
> > + .cpu_name = "440EPX - no Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
> > 440EPX has an FPU */ + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440GRX - with Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008D8,
> > + .cpu_name = "440GRX - with Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> > + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
> > + { /* 440GRX - without Security/Kasumi */
> > + .pvr_mask = 0xf0000fff,
> > + .pvr_value = 0x200008DC,
> > + .cpu_name = "440GRX - no Security/Kasumi",
> > + .cpu_features = CPU_FTRS_44X,
> > + .cpu_user_features = COMMON_USER_BOOKE, /* 440GRX has no FPU */
> > + .icache_bsize = 32,
> > + .dcache_bsize = 32,
> > + },
>
> Should the 440GRX PVR additions be done in a separate patch? Or is the
> PVR and cpu features truly the only difference between 440EPx and
> 440GRx?
I think it makes sense to add the 440GRx with this patchset too. The 440GRx is
a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC
Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new
board specific sources should be necessary to support the Rainier, just a
different defconfig file.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Hoang-Nam Nguyen @ 2007-08-03 8:36 UTC (permalink / raw)
To: Roland Dreier
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, raisch, paulus,
general
In-Reply-To: <adawswd3ayo.fsf@cisco.com>
From: Hoang-Nam Nguyen <hnguyen at de.ibm.com>
Date: Fri, 3 Aug 2007 09:44:56 +0200
Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (4k) to user space if kernel page
size is 64k. For reason, why this is required, see also Paul's patch.
In addition to that the kernel page offset of firmware context needs
to be set in cq and qp response block so that user space can assemble
the proper virtual address to use.
An appropriate patch for libehca will follow for ofed-1.3.
Signed-off-by: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_classes.h | 4 +++-
drivers/infiniband/hw/ehca/ehca_cq.c | 2 ++
drivers/infiniband/hw/ehca/ehca_qp.c | 2 ++
drivers/infiniband/hw/ehca/ehca_uverbs.c | 6 +++---
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index b5e9603..206d4eb 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -337,6 +337,8 @@ struct ehca_create_cq_resp {
u32 cq_number;
u32 token;
struct ipzu_queue_resp ipz_queue;
+ u32 fw_handle_ofs;
+ u32 dummy;
};
struct ehca_create_qp_resp {
@@ -347,7 +349,7 @@ struct ehca_create_qp_resp {
u32 qkey;
/* qp_num assigned by ehca: sqp0/1 may have got different numbers */
u32 real_qp_num;
- u32 dummy; /* padding for 8 byte alignment */
+ u32 fw_handle_ofs;
struct ipzu_queue_resp ipz_squeue;
struct ipzu_queue_resp ipz_rqueue;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
index 81aff36..ed5d67f 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -276,6 +276,8 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
resp.ipz_queue.queue_length = ipz_queue->queue_length;
resp.ipz_queue.pagesize = ipz_queue->pagesize;
resp.ipz_queue.toggle_state = ipz_queue->toggle_state;
+ resp.fw_handle_ofs = (u32)
+ (my_cq->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof(resp))) {
ehca_err(device, "Copy to udata failed.");
goto create_cq_exit4;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index b178cba..66f632c 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -745,6 +745,8 @@ static struct ehca_qp *internal_create_qp(
queue2resp(&resp.ipz_squeue, &my_qp->ipz_squeue);
if (HAS_RQ(my_qp))
queue2resp(&resp.ipz_rqueue, &my_qp->ipz_rqueue);
+ resp.fw_handle_ofs = (u32)
+ (my_qp->galpas.user.fw_handle & (PAGE_SIZE - 1));
if (ib_copy_to_udata(udata, &resp, sizeof resp)) {
ehca_err(pd->device, "Copy to udata failed");
diff --git a/drivers/infiniband/hw/ehca/ehca_uverbs.c b/drivers/infiniband/hw/ehca/ehca_uverbs.c
index 4bc687f..be062f1 100644
--- a/drivers/infiniband/hw/ehca/ehca_uverbs.c
+++ b/drivers/infiniband/hw/ehca/ehca_uverbs.c
@@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
u64 vsize, physical;
vsize = vma->vm_end - vma->vm_start;
- if (vsize != EHCA_PAGESIZE) {
+ if (vsize >= EHCA_PAGESIZE) {
ehca_gen_err("invalid vsize=%lx", vma->vm_end - vma->vm_start);
return -EINVAL;
}
@@ -118,8 +118,8 @@ static int ehca_mmap_fw(struct vm_area_struct *vma, struct h_galpas *galpas,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
ehca_gen_dbg("vsize=%lx physical=%lx", vsize, physical);
/* VM_IO | VM_RESERVED are set by remap_pfn_range() */
- ret = remap_pfn_range(vma, vma->vm_start, physical >> PAGE_SHIFT,
- vsize, vma->vm_page_prot);
+ ret = remap_4k_pfn(vma, vma->vm_start, physical >> EHCA_PAGESHIFT,
+ vma->vm_page_prot);
if (unlikely(ret)) {
ehca_gen_err("remap_pfn_range() failed ret=%x", ret);
return -ENOMEM;
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 5/6] PowerPC 440EPx: Sequoia board support
From: Kumar Gala @ 2007-08-03 8:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070802153222.6482ae85@weaponx.rchland.ibm.com>
On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:05:42 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
>>>>> + { /* 440EPX - without Security/Kasumi */
>>>>> + .pvr_mask = 0xf0000fff,
>>>>> + .pvr_value = 0x200008D4,
>>>>> + .cpu_name = "440EPX - no Security/Kasumi",
>>>>> + .cpu_features = CPU_FTRS_44X,
>>>>> + .cpu_user_features = COMMON_USER_BOOKE |
>>>>> PPC_FEATURE_HAS_FPU, /*
>>>>> 440EPX has an FPU */
>>>>> + .icache_bsize = 32,
>>>>> + .dcache_bsize = 32,
>>>>> + },
>>>>
>>>> Since the with/without Security/Kasumi versions have no
>>>> differences in
>>>> their cputable entry other than the PVR, couldn't you just
>>>> remove the
>>>> relevant PVR bit from the mask and use a single entry?
>>>
>>> And get rid of the stupid "has an FPU" comment at the same time
>>> please :-)
>>
>> Actually that comment may be worthwhile if expanded a little. I
>> think
>> the point is that 440EPx *unlike most other 4xx chips* has an
>> FPU. So
>> the point of the comment is not explaining the feature bit, which is
>> obvious, but as a "no, really, it does".
>
> Right. 440EP(x) are the only currently available 44x chips that
> contain an FPU, so I also think the comment can stay.
I agree w/Segher the comment is redundant. Just make a note of the
fact that we really have FPU in the commit message.
- k
^ permalink raw reply
* [PATCH] Expand RPN field to 34 bits when using 64k pages
From: Paul Mackerras @ 2007-08-03 8:44 UTC (permalink / raw)
To: linuxppc-dev
The real page number field in our PTEs when configured for 64kB pages
is currently 32 bits, which turns out to be not quite enough for the
resources that the eHCA driver wants to map. This expands the RPN
field to include 2 adjacent, previously-unused bits.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/include/asm-powerpc/pgtable-64k.h b/include/asm-powerpc/pgtable-64k.h
index 31cbd3d..33ae901 100644
--- a/include/asm-powerpc/pgtable-64k.h
+++ b/include/asm-powerpc/pgtable-64k.h
@@ -49,12 +49,10 @@
/* Shift to put page number into pte.
*
- * That gives us a max RPN of 32 bits, which means a max of 48 bits
- * of addressable physical space.
- * We could get 3 more bits here by setting PTE_RPN_SHIFT to 29 but
- * 32 makes PTEs more readable for debugging for now :)
+ * That gives us a max RPN of 34 bits, which means a max of 50 bits
+ * of addressable physical space, or 46 bits for the special 4k PFNs.
*/
-#define PTE_RPN_SHIFT (32)
+#define PTE_RPN_SHIFT (30)
#define PTE_RPN_MAX (1UL << (64 - PTE_RPN_SHIFT))
#define PTE_RPN_MASK (~((1UL<<PTE_RPN_SHIFT)-1))
^ permalink raw reply related
* [GIT PATCH] ucc_geth fixes for 2.6.22-rc1
From: Li Yang @ 2007-08-03 9:07 UTC (permalink / raw)
To: jeff; +Cc: netdev, linuxppc-embedded
Please pull from 'ucc_geth' branch of
master.kernel.org:/pub/scm/linux/kernel/git/leo/fsl-soc.git ucc_geth
to receive the following fixes:
drivers/net/ucc_geth_ethtool.c | 1 -
drivers/net/ucc_geth_mii.c | 3 ++-
2 files changed, 2 insertions(+), 2 deletions(-)
Domen Puncer (1):
ucc_geth: fix section mismatch
Jan Altenberg (1):
ucc_geth: remove get_perm_addr from ucc_geth_ethtool.c
diff --git a/drivers/net/ucc_geth_ethtool.c
b/drivers/net/ucc_geth_ethtool.c
index a8994c7..64bef7c 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -379,7 +379,6 @@ static const struct ethtool_ops uec_ethtool_ops = {
.get_stats_count = uec_get_stats_count,
.get_strings = uec_get_strings,
.get_ethtool_stats = uec_get_ethtool_stats,
- .get_perm_addr = ethtool_op_get_perm_addr,
};
void uec_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index 5f8c2d3..6c257b8 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -272,7 +272,8 @@ int __init uec_mdio_init(void)
return of_register_platform_driver(&uec_mdio_driver);
}
-void __exit uec_mdio_exit(void)
+/* called from __init ucc_geth_init, therefore can not be __exit */
+void uec_mdio_exit(void)
{
of_unregister_platform_driver(&uec_mdio_driver);
}
^ permalink raw reply related
* [PATCH] Fix special PTE code for secondary hash bucket
From: Paul Mackerras @ 2007-08-03 8:58 UTC (permalink / raw)
To: linuxppc-dev
The code for mapping special 4k pages on kernels using a 64kB base
page size was missing the code for doing the RPN (real page number)
manipulation when inserting the hardware PTE in the secondary hash
bucket. It needs the same code as has already been added to the
code that inserts the HPTE in the primary hash bucket. This adds it.
Spotted by Ben Herrenschmidt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index 4762ff7..35eabfb 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -472,10 +472,12 @@ _GLOBAL(htab_call_hpte_insert1)
/* Now try secondary slot */
/* real page number in r5, PTE RPN value + index */
- rldicl r5,r31,64-PTE_RPN_SHIFT,PTE_RPN_SHIFT
+ andis. r0,r31,_PAGE_4K_PFN@h
+ srdi r5,r31,PTE_RPN_SHIFT
+ bne- 3f
sldi r5,r5,PAGE_SHIFT-HW_PAGE_SHIFT
add r5,r5,r25
- sldi r5,r5,HW_PAGE_SHIFT
+3: sldi r5,r5,HW_PAGE_SHIFT
/* Calculate secondary group hash */
andc r0,r27,r28
^ permalink raw reply related
* Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
From: Russell King @ 2007-08-03 8:36 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, linux-mips, Christoph Hellwig, Domen Puncer
In-Reply-To: <200708021632.13982.david-b@pacbell.net>
On Thu, Aug 02, 2007 at 04:32:13PM -0700, David Brownell wrote:
> On Wednesday 01 August 2007, Christoph Hellwig wrote:
> > On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > > > It doesn't make any assumption on struct clk, it's just a
> > > > wrapper around functions from clk.h.
> > > > Point of this patch was to abstract exported functions, since
> > > > arch/powerpc/ can support multiple platfroms in one binary.
> > >
> > > So... the thread just ended without any consensus, ACK or whatever.
> > >
> > > Choices I see:
> > > - have EXPORT_SYMBOL for clk.h functions in ie. lib/clock.c and have
> > > every implemenation fill some global struct.
> > > - leave this patch as it is, abstraction only for arch/powerpc/.
>
> That seems the best solution for now, I agree.
I've not been avoiding replying further to this thread in spite, it's
just that I've not had any time what so ever to look at this further.
It's very low priority for me at the moment, so it's getting zero time,
and will continue to be in that state for at least the next month and
a bit. Sorry.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: [PATCH] Fix FSL BookE machine check reporting
From: Paul Mackerras @ 2007-08-03 9:18 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <11860870353423-git-send-email-becky.bruce@freescale.com>
Becky Bruce writes:
> Reserved MCSR bits on FSL BookE parts may have spurious values
> when mcheck occurs. Mask these off when printing the MCSR to
> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
> for e500 - this bit doesn't actually have any meaning.
Is this needed for 2.6.23?
Paul.
^ permalink raw reply
* Re: [PATCH] Fix FSL BookE machine check reporting
From: Kumar Gala @ 2007-08-03 9:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18098.62189.596336.471217@cargo.ozlabs.ibm.com>
On Aug 3, 2007, at 4:18 AM, Paul Mackerras wrote:
> Becky Bruce writes:
>
>> Reserved MCSR bits on FSL BookE parts may have spurious values
>> when mcheck occurs. Mask these off when printing the MCSR to
>> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
>> for e500 - this bit doesn't actually have any meaning.
>
> Is this needed for 2.6.23?
It would be nice. I'll queue it up with some other fixes for 2.6.23.
- k
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
From: Kumar Gala @ 2007-08-03 9:29 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <200708021447.22028.david-b@pacbell.net>
On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
> On Thursday 02 August 2007, Anton Vorontsov wrote:
>> Probably someday mpc83xx_spi->sysclk should be renamed to
>> mpc83xx_spi->spiclk to be less confusing.
>
> Why not "today", with this patch? That would fix some of
> the root cause of this bug...
I'm fine with this as well. I just called it sysclk to start with
since when I wrote the driver it was just for the MPC834x.
- k
^ permalink raw reply
* Re: 2.6.23-rc1-mm2
From: Kumar Gala @ 2007-08-03 9:39 UTC (permalink / raw)
To: Mariusz Kozlowski
Cc: linux-usb-devel, gregkh, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton
In-Reply-To: <200708021214.51705.m.kozlowski@tuxland.pl>
On Aug 2, 2007, at 5:14 AM, Mariusz Kozlowski wrote:
>>> Second issue as reported earilier allmodconfig fails to build on
>>> imac g3.
>>
>> Do you really mean g3? If so it's a 32-bit kernel and it
>> shouldn't be
>> building lparmap.s. Or do you mean G5?
>
> Yes it is iMac G3. More or less sth like this:
> http://upload.wikimedia.org/wikipedia/commons/c/c0/IMac_Bondi_Blue.jpg
>
> processor : 0
> cpu : 740/750
> temperature : 47-49 C (uncalibrated)
> clock : 400MHz
> revision : 2.2 (pvr 0008 0202)
> bogomips : 796.67
> machine : PowerMac2,1
> motherboard : PowerMac2,1 MacRISC2 MacRISC Power Macintosh
> detected as : 66 (iMac FireWire)
> pmac flags : 00000005
> L2 cache : 512K unified
> memory : 256MB
> pmac-generation : NewWorld
>
>>> CC arch/powerpc/kernel/lparmap.s
>>> AS arch/powerpc/kernel/head_64.o
>>> lparmap.c: Assembler messages:
>>> lparmap.c:84: Error: file number 1 already allocated
>>> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
>>> make: *** [arch/powerpc/kernel] Blad 2
>>
>> Weird. Could you do make V=1 and send me the output?
>
> Ok. Here it goes. The last screen. If you need all / more feel free
> to mail
> me. Config is attached - please note that this is default
> allmodconfig.
>
>
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (machine_kexec)" -D"KBUILD_MODNAME=KBUILD_STR(machine_kexec)" -c -o
> arch/powerpc/kernel/.tmp_machine_kexec.o arch/powerpc/kernel/
> machine_kexec.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.crash.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (crash)" -D"KBUILD_MODNAME=KBUILD_STR(crash)" -c -o
> arch/powerpc/kernel/.tmp_crash.o arch/powerpc/kernel/crash.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.machine_kexec_64.o.d -
> nostdinc -isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -
> D__KERNEL__ -Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (machine_kexec_64)" -D"KBUILD_MODNAME=KBUILD_STR
> (machine_kexec_64)" -c -o
> arch/powerpc/kernel/.tmp_machine_kexec_64.o
> arch/powerpc/kernel/machine_kexec_64.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.audit.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (audit)" -D"KBUILD_MODNAME=KBUILD_STR(audit)" -c -o
> arch/powerpc/kernel/.tmp_audit.o arch/powerpc/kernel/audit.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.swsusp_64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (swsusp_64)" -D"KBUILD_MODNAME=KBUILD_STR(swsusp_64)" -c -o
> arch/powerpc/kernel/.tmp_swsusp_64.o arch/powerpc/kernel/swsusp_64.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.swsusp_asm64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -D__ASSEMBLY__ -Wa,-maltivec -
> gdwarf2 -c -o
> arch/powerpc/kernel/swsusp_asm64.o arch/powerpc/kernel/swsusp_asm64.S
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.compat_audit.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (compat_audit)" -D"KBUILD_MODNAME=KBUILD_STR(compat_audit)" -c -o
> arch/powerpc/kernel/.tmp_compat_audit.o arch/powerpc/kernel/
> compat_audit.c
> ld -m elf64ppc -r -o arch/powerpc/kernel/built-in.o
> arch/powerpc/kernel/semaphore.o arch/powerpc/kernel/cputable.o
> arch/powerpc/kernel/ptrace.o arch/powerpc/kernel/syscalls.o
> arch/powerpc/kernel/irq.o arch/powerpc/kernel/align.o
> arch/powerpc/kernel/signal_32.o arch/powerpc/kernel/pmc.o
> arch/powerpc/kernel/vdso.o arch/powerpc/kernel/init_task.o
> arch/powerpc/kernel/process.o arch/powerpc/kernel/systbl.o
> arch/powerpc/kernel/idle.o arch/powerpc/kernel/signal.o
> arch/powerpc/kernel/vdso32/built-in.o arch/powerpc/kernel/setup_64.o
> arch/powerpc/kernel/binfmt_elf32.o arch/powerpc/kernel/sys_ppc32.o
> arch/powerpc/kernel/signal_64.o arch/powerpc/kernel/ptrace32.o
> arch/powerpc/kernel/paca.o arch/powerpc/kernel/cpu_setup_ppc970.o
> arch/powerpc/kernel/cpu_setup_pa6t.o arch/powerpc/kernel/firmware.o
> arch/powerpc/kernel/sysfs.o arch/powerpc/kernel/nvram_64.o
> arch/powerpc/kernel/vdso64/built-in.o arch/powerpc/kernel/vecemu.o
> arch/powerpc/kernel/vector.o arch/powerpc/kernel/idle_power4.o
> arch/powerpc/kernel/of_device.o arch/powerpc/kernel/of_platform.o
> arch/powerpc/kernel/prom_parse.o arch/powerpc/kernel/proc_ppc64.o
> arch/powerpc/kernel/rtas.o arch/powerpc/kernel/rtas-rtc.o
> arch/powerpc/kernel/rtas_pci.o arch/powerpc/kernel/rtas-proc.o
> arch/powerpc/kernel/lparcfg.o arch/powerpc/kernel/vio.o
> arch/powerpc/kernel/ibmebus.o arch/powerpc/kernel/smp-tbsync.o
> arch/powerpc/kernel/crash_dump.o arch/powerpc/kernel/swsusp.o
> arch/powerpc/kernel/suspend.o arch/powerpc/kernel/time.o
> arch/powerpc/kernel/prom.o arch/powerpc/kernel/traps.o
> arch/powerpc/kernel/setup-common.o arch/powerpc/kernel/udbg.o
> arch/powerpc/kernel/misc.o arch/powerpc/kernel/io.o
> arch/powerpc/kernel/misc_64.o arch/powerpc/kernel/dma_64.o
> arch/powerpc/kernel/iommu.o arch/powerpc/kernel/prom_init.o
> arch/powerpc/kernel/ppc_ksyms.o arch/powerpc/kernel/btext.o
> arch/powerpc/kernel/smp.o arch/powerpc/kernel/kprobes.o
> arch/powerpc/kernel/legacy_serial.o arch/powerpc/kernel/udbg_16550.o
> arch/powerpc/kernel/kgdb.o arch/powerpc/kernel/kgdb_setjmp64.o
> arch/powerpc/kernel/module_64.o arch/powerpc/kernel/pci_64.o
> arch/powerpc/kernel/pci_dn.o arch/powerpc/kernel/isa-bridge.o
> arch/powerpc/kernel/pci-common.o arch/powerpc/kernel/msi.o
> arch/powerpc/kernel/machine_kexec.o arch/powerpc/kernel/crash.o
> arch/powerpc/kernel/machine_kexec_64.o arch/powerpc/kernel/audit.o
> arch/powerpc/kernel/swsusp_64.o arch/powerpc/kernel/swsusp_asm64.o
> arch/powerpc/kernel/compat_audit.o
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.lparmap.s.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-
> trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-
> function-declaration -Os -msoft-float -pipe -mminimal-toc -
> mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -funit-at-
> a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -g -fno-
> stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -
> mno-minimal-toc -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR
> (lparmap)" -D"KBUILD_MODNAME=KBUILD_STR(lparmap)" -fverbose-asm -S -o
> arch/powerpc/kernel/lparmap.s arch/powerpc/kernel/lparmap.c
>
> gcc -m64 -Wp,-MD,arch/powerpc/kernel/.head_64.o.d -nostdinc -
> isystem /usr/lib/gcc/powerpc-linux-gnu/4.1.2/include -D__KERNEL__ -
> Iinclude -include
> include/linux/autoconf.h -D__ASSEMBLY__ -Wa,-maltivec -gdwarf2 -
> Iarch/powerpc/kernel -c -o
> arch/powerpc/kernel/head_64.o arch/powerpc/kernel/head_64.S
> lparmap.c: Assembler messages:
> lparmap.c:84: Error: file number 1 already allocated
> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
> make: *** [arch/powerpc/kernel] Blad 2
Some how your defconfig is targeting a PPC64 box:
CONFIG_PPC64=y
shouldn't be set if you want to build a kernel for a G3 imac.
- k
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-08-03 10:32 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of bug-fixes for powerpc.
Thanks,
Paul.
arch/powerpc/kernel/entry_64.S | 3 +++
arch/powerpc/kernel/pci_32.c | 5 ++++-
arch/powerpc/kernel/smp.c | 9 +++------
arch/powerpc/mm/hash_low_64.S | 6 ++++--
arch/powerpc/mm/hash_utils_64.c | 2 +-
arch/powerpc/mm/numa.c | 4 ++--
arch/powerpc/mm/slb.c | 28 ++++++++++++++++++----------
arch/powerpc/platforms/cell/spufs/sched.c | 3 ++-
arch/powerpc/platforms/powermac/feature.c | 6 ++++--
arch/powerpc/platforms/ps3/setup.c | 2 +-
include/asm-powerpc/mmu-hash64.h | 1 +
include/asm-powerpc/pgtable-64k.h | 8 +++-----
12 files changed, 46 insertions(+), 31 deletions(-)
Andre Detsch (1):
[POWERPC] spufs: Fix affinity after introduction of node_allowed() calls
Kevin Corry (1):
[POWERPC] Fix num_cpus calculation in smp_call_function_map()
Michael Ellerman (1):
[POWERPC] Fix parse_drconf_memory() for 64-bit start addresses
Michael Neuling (1):
[POWERPC] Fixes for the SLB shadow buffer code
Paul Mackerras (2):
[POWERPC] Expand RPN field to 34 bits when using 64k pages
[POWERPC] Fix special PTE code for secondary hash bucket
Segher Boessenkool (2):
[POWERPC] Fix a compile warning in pci_32.c
[POWERPC] Fix a compile warning in powermac/feature.c
Stephen Rothwell (1):
[POWERPC] ps3: Fix section mismatch in ps3/setup.c
^ permalink raw reply
* Re: [ PATCH ] PowerPC cascade UIC IRQ handler fix.
From: Valentine Barshak @ 2007-08-03 11:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20070802150852.39701576@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Thu, 2 Aug 2007 13:48:48 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
>>> PPC44x cascade UIC irq handler fix.
>>>
>>> According to PPC44x UM, if an interrupt is configured as
>>> level-sensitive, and a clear is attempted on the UIC_SR, the UIC_SR
>>> field is not cleared if the incoming interrupt signal is at the
>>> asserted polarity. This causes us to enter a cascade handler twice,
>>> since we first ack parent UIC interrupt and ack child UIC one after
>>> that. The patch checks child UIC msr value and returns IRQ_HANDLED
>>> if there're no pending interrupts. Otherwise we get a kernel panic
>>> with a "Fatal exception in interrupt" (illegal vector).
>>> The patch also fixes status flags.
>>>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>> Hrm... This doesn't seem like the right fix to me. Instead, I think
>> the cascaded IRQ handler should ack the interrupt on the child first.
>> I'm a little surprised it doesn't at the moment.
>
> Agreed. Anyone going to hack up a patch for that?
>
> josh
Anyways, I don't see why kernel should panic if we get a spurious interrupt.
^ permalink raw reply
* reg : SM722 Linux driver
From: mahendra varman @ 2007-08-03 11:21 UTC (permalink / raw)
To: linuxppc-embedded
Hi Members
Iam in need of SM722 Linux driver source code for Linux 2.6 or for Linux 2.4
Help me to find the source code
Thanks
Mahendra
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox