* 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 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: [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] 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] 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] 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 2/6] PowerPC 440EPx: Sequoia DTS
From: David Gibson @ 2007-08-03 0:49 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070802151833.5e250f2b@weaponx.rchland.ibm.com>
On Thu, Aug 02, 2007 at 03:18:33PM -0500, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:47:51 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> >
> > Duh, forgot to attach the actual patch. Here it is:
>
> So, no signed-off-by. Intentional, as it's for comments only?
Pretty much.
> Also, could you break this out into a separate thread when you do
> submit it please? Will make a few people's lives easier since this has
> nothing to do with 440EPx really :)
Sure.
--
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: Benjamin Herrenschmidt @ 2007-08-03 1:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070802034848.GA837@localhost.localdomain>
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.
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.
Ben.
^ permalink raw reply
* Re: suspend/resume (Xilinx V4)
From: Grant Likely @ 2007-08-03 0:53 UTC (permalink / raw)
To: John Williams; +Cc: linuxppc-embedded
In-Reply-To: <46B26E97.3040706@itee.uq.edu.au>
On 8/2/07, John Williams <jwilliams@itee.uq.edu.au> wrote:
> Hi,
>
> Any comments on the status/feasibility of suspend/resume for LinuxPPC on
> Xilinx devices?
Pretty much non-existant as far as status goes. Feasibility depends
entirely on what power management features the Xilinx silicon
supports. I haven't looked into whether or not the 405 core can be
put into sleep states.
>
> The only suspend-related traffic I see here in the last 12 months is for
> the lite5200b board.
>
> Any guesstimates of level of difficulty for such a task on Xilinx
> PPC405? The core lite5200b patchset didn't look too hairy (just a
> modest bit of ASM :), but there would also be Xilinx device driver hooks
> to consider.
I suspect the driver code will be where most of the effort lies.
> Also, are there kernel revision dependencies here? Project is currently
> on an MVL 2.6.10 tree - but have seen mention of 2.6.17 (?) being
> earliest with PPC suspend/resume capability.
Suspend support for ppc has existed for a long time, but there aren't
many embedded ppc boards which support it (5200 being a notable
example).
Personally, I'm keeping up to date with mainline (2.6.22+) on my Virtex tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Benjamin Herrenschmidt @ 2007-08-03 0:29 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070803002652.GX3925@crusty.rchland.ibm.com>
On Thu, 2007-08-02 at 19:26 -0500, Josh Boyer wrote:
> On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> > >
> > > Someone brought up the fact that the EMAC rewrite is mostly just
> > > changing probing code and the guts are still similar to the current
> > > EMAC driver. I haven't really looked into it yet, but if that's true,
> > > I'd be curious as to why it was done that way.
> >
> > Ask :-) What specifically do you want to know ?
>
> :)
>
> Are the guts mostly the same, and if so why wasn't the existing driver just
> modified to do the device tree probing, perhaps in addition to the arch/ppc
> method?
>
> I can answer the "are they similar" myself with inspection, but I just haven't
> found the time yet. So just some history about the patch would be good in
> general I think.
Guts are the same with subtle differences :-)
The main reason not to modify the existing one was because I wanted to
be conservative and not take any chance at breaking arch/ppc. Also, we
did that in earlier versions internally (have both OCP and device-tree
probing) and it's a terrible mess. Since arch/ppc is doomed, I wanted to
avoid designing something that can do both for no real benefit.
There are other subtle differences, such as the locking of the MDIO
accesses, and locking bits and pieces in general (EMAC wasn't tested in
SMP environments, and while it was tested with preempt, there are a few
subtle differences and issues that went unnoticed).
I also haven't brought back the workarounds for the loss of the Rx clock
with some PHYs at this stage. I need to get my hand on HW that has this
issue to be able to decide what to do I believe. The thing is, global
whacking of clock control registers like the old driver does is a bit
scary, totally per-chip-type, and requires locking vs. other parts of
the system that may want to access the same registers etc...
However, some of the chip folks told me it might be possible instead to
just use loopback mode when there is no link. So I want to investigate
that possibility first, but for that, I need HW that has the symptoms
and so far, I think I don't.
Finally, we still need to add in proper DMA unmapping. The current
driver never unmaps which is a problem on Axon when using the iommu.
Cheers,
Ben.
^ permalink raw reply
* suspend/resume (Xilinx V4)
From: John Williams @ 2007-08-02 23:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Any comments on the status/feasibility of suspend/resume for LinuxPPC on
Xilinx devices?
The only suspend-related traffic I see here in the last 12 months is for
the lite5200b board.
Any guesstimates of level of difficulty for such a task on Xilinx
PPC405? The core lite5200b patchset didn't look too hairy (just a
modest bit of ASM :), but there would also be Xilinx device driver hooks
to consider.
Also, are there kernel revision dependencies here? Project is currently
on an MVL 2.6.10 tree - but have seen mention of 2.6.17 (?) being
earliest with PPC suspend/resume capability.
All info appreciated. Thanks,
John
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Josh Boyer @ 2007-08-03 0:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <1186094296.5495.638.camel@localhost.localdomain>
On Fri, Aug 03, 2007 at 08:38:16AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
> >
> > Someone brought up the fact that the EMAC rewrite is mostly just
> > changing probing code and the guts are still similar to the current
> > EMAC driver. I haven't really looked into it yet, but if that's true,
> > I'd be curious as to why it was done that way.
>
> Ask :-) What specifically do you want to know ?
:)
Are the guts mostly the same, and if so why wasn't the existing driver just
modified to do the device tree probing, perhaps in addition to the arch/ppc
method?
I can answer the "are they similar" myself with inspection, but I just haven't
found the time yet. So just some history about the patch would be good in
general I think.
josh
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Will Schmidt @ 2007-08-02 23:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186094245.5495.637.camel@localhost.localdomain>
On Fri, 2007-08-03 at 08:37 +1000, Benjamin Herrenschmidt wrote:
> > Is there technical reason why the 'local' variable remains at the end of
> > the parm list for these? In other cases 'ssize' simply gets added to
> > the end of the parm list.
>
> Looks nicer to have psize and ssize together :-)
Aah! And here I thought there was some obscure register usage
optimization going on.. :-)
-Will
>
> Ben.
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: FEC driver not working after upgrade
From: Mit Matelske @ 2007-08-02 23:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070802205107.C069F352659@atlas.denx.de>
wd wrote:
>
> In message <11952546.post@talk.nabble.com> you wrote:
>>
>> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and
>> cannot
> ...
>> I am running a 5200B. Thanks for any help.
>
> Do you really have the latest snapshot, i. e. top of tree from the git
> repository?
>
Yes sir. I have the 2007-7-10 snapshot.
Someone posted what I assume to be a similar problem back in March:
http://www.nabble.com/Problems-with-PHY-on-STK5200-tf3326321.html#a9247789
but there was no solution. Thanks for any and all help.
Mit Matelske
--
View this message in context: http://www.nabble.com/FEC-driver-not-working-after-upgrade-tf4202285.html#a11975001
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Generic clk.h wrappers? [Was: Re: [PATCH 1/3] powerpc clk.h interface for platforms]
From: David Brownell @ 2007-08-02 23:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Domen Puncer, Russell King, linux-mips
In-Reply-To: <20070801125753.GB27199@lst.de>
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.
> > - or I can just forget about this, and leave it for the next sucker
> > who will want nicer clock handling in some driver
>
> It seems like arm really wants this optimized to the last cycle
> and no abstraction inbetween so we're probably stuck with the status
> quo. I'm pretty sure this will get too messy sooner and later and
> people will clean the mess up, but due to the political issues I
> don't think it's fair to put that burden on you just for submitting
> the powerpc implementation.
>
> So, please leave the patch as-is.
>
^ permalink raw reply
* Re: [PATCH]: PCI Error Recovery: Symbios SCSI device driver
From: Linas Vepstas @ 2007-08-02 22:53 UTC (permalink / raw)
To: Matthew Wilcox
Cc: James.Bottomley, linux-scsi, willy, linux-kernel, linuxppc-dev,
Paul Mackerras, Andrew Morton, linux-pci
In-Reply-To: <20070705185406.GA3527@parisc-linux.org>
On Thu, Jul 05, 2007 at 12:54:06PM -0600, Matthew Wilcox wrote:
> On Thu, Jul 05, 2007 at 11:28:38AM -0700, Andrew Morton wrote:
> > Well you've sent it a couple of times, and I've sent it in five more times
> > over the past year. Once we were told "awaiting maintainer ack".
> >
> > This situation is fairly stupid. How about we make you the maintainer?
>
> Last time I looked at it, I still wasn't comfortable with it. I'm going
> to look at it again.
Please do. Its burning the proverbial hole in my pocket; I'd really
like to get this off my list of things I worry about.
> I'm fairly sure Linas doesn't want to be the sym2 maintainer. It's
> still an ugly pile of junk that needs cleaning up.
Heh. I have no difficulty living with ugly code: its actually a
great excuse to fix things instead of doing "real work" :-)
Rather, the menagerie of hardware I have access to is constantly
changing; I don't have a symbios card just right now, and it might
take a few days to even find someone who did. Which is an incredibly
unpleasent, unrewarding activity.
--linas
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Benjamin Herrenschmidt @ 2007-08-02 22:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Hollis Blanchard
In-Reply-To: <20070802163951.11c398ee@weaponx.rchland.ibm.com>
On Thu, 2007-08-02 at 16:39 -0500, Josh Boyer wrote:
>
> Someone brought up the fact that the EMAC rewrite is mostly just
> changing probing code and the guts are still similar to the current
> EMAC driver. I haven't really looked into it yet, but if that's true,
> I'd be curious as to why it was done that way.
Ask :-) What specifically do you want to know ?
Ben.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Benjamin Herrenschmidt @ 2007-08-02 22:37 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1186087283.22717.80.camel@farscape.rchland.ibm.com>
> Is there technical reason why the 'local' variable remains at the end of
> the parm list for these? In other cases 'ssize' simply gets added to
> the end of the parm list.
Looks nicer to have psize and ssize together :-)
Ben.
^ permalink raw reply
* Re: [spi-devel-general] [PATCH] [SPI][POWERPC] spi_mpc83xx: in "QE mode" spiclk is sysclk/2
From: David Brownell @ 2007-08-02 21:47 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
In-Reply-To: <20070802142641.GA6309@localhost.localdomain>
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...
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Josh Boyer @ 2007-08-02 21:39 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <f8tgfm$e2g$1@sea.gmane.org>
On Thu, 2 Aug 2007 20:57:26 +0000 (UTC)
Hollis Blanchard <hollisb@us.ibm.com> wrote:
> On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
>
> > For those interested, here's my current 4xx patch series. There are a few
> > cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
> > another round of Bamboo patches. These are all based off of Paul's current
> > tree.
>
> Bamboo is booting for me with your patches. Let's get them in soon...
I plan on submitting a series to Paul tomorrow-ish for 2.6.24. Too
late for 2.6.23.
> > Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
> > that Ben and David have poked at. If it doesn't get merged soon, I'll take
> > a look at getting it working again.
>
> Please!
Someone brought up the fact that the EMAC rewrite is mostly just
changing probing code and the guts are still similar to the current
EMAC driver. I haven't really looked into it yet, but if that's true,
I'd be curious as to why it was done that way.
Either way, I'm hoping we can get something into 2.6.24.
josh
^ permalink raw reply
* Re: [PATCH] ehca: map 4k firmware context of cq, qp to user space
From: Roland Dreier @ 2007-08-02 21:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, linuxppc-dev, raisch, paulus, general,
Hoang-Nam Nguyen
In-Reply-To: <200708021608.16436.arnd@arndb.de>
> remap_4k_pfn is defined in terms of remap_pfn_range if the base page
> size if 4k, so you don't need this #ifdef afaics.
Good point. I'll wait for an updated patch.
^ permalink raw reply
* Re: [patch 00/14] Current 4xx patch series
From: Hollis Blanchard @ 2007-08-02 20:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <41060.0659474314$1184697204@news.gmane.org>
On Tue, 17 Jul 2007 13:15:47 -0500, Josh Boyer wrote:
> For those interested, here's my current 4xx patch series. There are a few
> cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
> another round of Bamboo patches. These are all based off of Paul's current
> tree.
Bamboo is booting for me with your patches. Let's get them in soon...
> Ethernet for 4xx in general is still provided by the out-of-tree emac rewrite
> that Ben and David have poked at. If it doesn't get merged soon, I'll take
> a look at getting it working again.
Please!
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: FEC driver not working after upgrade
From: Wolfgang Denk @ 2007-08-02 20:51 UTC (permalink / raw)
To: Mit Matelske; +Cc: linuxppc-dev
In-Reply-To: <11952546.post@talk.nabble.com>
In message <11952546.post@talk.nabble.com> you wrote:
>
> I upgraded from an old 2.4.25 kernel to the latest Denx snapshot and cannot
...
> I am running a 5200B. Thanks for any help.
Do you really have the latest snapshot, i. e. top of tree from the git
repository?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are very few personal problems that cannot be solved through a
suitable application of high explosives.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Will Schmidt @ 2007-08-02 20:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18095.59959.698141.565343@cargo.ozlabs.ibm.com>
Hi Paul,
just a few questions.
On Wed, 2007-08-01 at 12:04 +1000, Paul Mackerras wrote:
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6). We don't currently use 1TB segments
> for user addresses < 1T, since that would effectively prevent 32-bit
> processes from using huge pages unless we also had a way to revert to
> using 256MB segments.
I think I have a question about "user address < 1T".. once I think on
it a bit more it'll either click, or I'll have a question
articulated. :-)
> -static inline void __tlbiel(unsigned long va, unsigned int psize)
> +static inline void __tlbiel(unsigned long va, int psize, int ssize)
> -static inline void tlbie(unsigned long va, int psize, int local)
> +static inline void tlbie(unsigned long va, int psize, int ssize, int local)
> static long native_hpte_insert(unsigned long hpte_group, unsigned long va,
> unsigned long pa, unsigned long rflags,
> - unsigned long vflags, int psize)
> + unsigned long vflags, int psize, int ssize)
> static long native_hpte_updatepp(unsigned long slot, unsigned long newpp,
> - unsigned long va, int psize, int local)
> + unsigned long va, int psize, int ssize,
> + int local)
Is there technical reason why the 'local' variable remains at the end of
the parm list for these? In other cases 'ssize' simply gets added to
the end of the parm list.
> +static int __init htab_dt_scan_seg_sizes(unsigned long node,
> + const char *uname, int depth,
> + void *data)
> +{
> + char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> + u32 *prop;
> + unsigned long size = 0;
> +
> + /* We are scanning "cpu" nodes only */
> + if (type == NULL || strcmp(type, "cpu") != 0)
> + return 0;
> +
> + prop = (u32 *)of_get_flat_dt_prop(node, "ibm,processor-segment-sizes",
> + &size);
> + if (prop != NULL && size >= 8) {
> + if (prop[0] == 0x1c && prop[1] == 0x28) {
This is 0x1c indicating 2^28 for 256M; and 0x28 indicating 2^40 for 1TB
segments.
Will there ever be a segment size between the two? Or will the
representation every vary from this? i.e. wondering if prop[0] will
always be for 256M and prop[1] for 1TB.
> +#define slb_vsid_shift(ssize) \
> + ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
> @@ -100,12 +106,13 @@ void slb_flush_and_rebolt(void)
> vflags = SLB_VSID_KERNEL | vmalloc_llp;
>
> ksp_esid_data = mk_esid_data(get_paca()->kstack, 2);
> - if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
> + mask = (mmu_kernel_ssize == MMU_SEGSIZE_256M)? ESID_MASK: ESID_MASK_1T;
Is this one worthy of a #define like the slb_vsid_shift() above?
> +#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)
-Will
^ permalink raw reply
* [PATCH] Fix FSL BookE machine check reporting
From: Becky Bruce @ 2007-08-02 20:37 UTC (permalink / raw)
To: linuxppc-dev
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.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
---
arch/powerpc/kernel/traps.c | 4 +---
include/asm-powerpc/reg_booke.h | 12 +++++++++++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2bb1cb9..d8502e3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -299,7 +299,7 @@ static inline int check_io_access(struct pt_regs *regs)
#ifndef CONFIG_FSL_BOOKE
#define get_mc_reason(regs) ((regs)->dsisr)
#else
-#define get_mc_reason(regs) (mfspr(SPRN_MCSR))
+#define get_mc_reason(regs) (mfspr(SPRN_MCSR) & MCSR_MASK)
#endif
#define REASON_FP ESR_FP
#define REASON_ILLEGAL (ESR_PIL | ESR_PUO)
@@ -414,8 +414,6 @@ void machine_check_exception(struct pt_regs *regs)
printk("Data Cache Push Parity Error\n");
if (reason & MCSR_DCPERR)
printk("Data Cache Parity Error\n");
- if (reason & MCSR_GL_CI)
- printk("Guarded Load or Cache-Inhibited stwcx.\n");
if (reason & MCSR_BUS_IAERR)
printk("Bus - Instruction Address Error\n");
if (reason & MCSR_BUS_RAERR)
diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h
index 064405c..8fdc2b4 100644
--- a/include/asm-powerpc/reg_booke.h
+++ b/include/asm-powerpc/reg_booke.h
@@ -223,7 +223,6 @@
#define MCSR_ICPERR 0x40000000UL /* I-Cache Parity Error */
#define MCSR_DCP_PERR 0x20000000UL /* D-Cache Push Parity Error */
#define MCSR_DCPERR 0x10000000UL /* D-Cache Parity Error */
-#define MCSR_GL_CI 0x00010000UL /* Guarded Load or Cache-Inhibited stwcx. */
#define MCSR_BUS_IAERR 0x00000080UL /* Instruction Address Error */
#define MCSR_BUS_RAERR 0x00000040UL /* Read Address Error */
#define MCSR_BUS_WAERR 0x00000020UL /* Write Address Error */
@@ -232,6 +231,12 @@
#define MCSR_BUS_WBERR 0x00000004UL /* Write Data Bus Error */
#define MCSR_BUS_IPERR 0x00000002UL /* Instruction parity Error */
#define MCSR_BUS_RPERR 0x00000001UL /* Read parity Error */
+
+/* e500 parts may set unused bits in MCSR; mask these off */
+#define MCSR_MASK (MCSR_MCP | MCSR_ICPERR | MCSR_DCP_PERR | \
+ MCSR_DCPERR | MCSR_BUS_IAERR | MCSR_BUS_RAERR | \
+ MCSR_BUS_WAERR | MCSR_BUS_IBERR | MCSR_BUS_RBERR | \
+ MCSR_BUS_WBERR | MCSR_BUS_IPERR | MCSR_BUS_RPERR)
#endif
#ifdef CONFIG_E200
#define MCSR_MCP 0x80000000UL /* Machine Check Input Pin */
@@ -243,6 +248,11 @@
#define MCSR_BUS_DRERR 0x00000008UL /* Read Bus Error on data load */
#define MCSR_BUS_WRERR 0x00000004UL /* Write Bus Error on buffered
store or cache line push */
+
+/* e200 parts may set unused bits in MCSR; mask these off */
+#define MCSR_MASK (MCSR_MCP | MCSR_CP_PERR | MCSR_CPERR | \
+ MCSR_EXCP_ERR | MCSR_BUS_IRERR | MCSR_BUS_DRERR | \
+ MCSR_BUS_WRERR)
#endif
/* Bit definitions for the DBSR. */
--
1.5.0.3
^ permalink raw reply related
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