* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-14 21:10 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <4AD63301.6090307@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 14/10/2009 22:22:25:
>
> Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 14/10/2009 21:23:02:
> >> Joakim Tjernlund wrote:
> >>> BTW, you could add a test and printk in do_page_fault on address 0x000000f0.
> >>> if that ever hits there is a problem with dcbX fixup.
> >> It doesn't get any 0xf0 faults.
> >>
> >> FWIW, I'm not seeing the segfault any more, but I still get the lockup.
> >
> > Have you reverted
> > 8xx: start using dcbX instructions in various copy routines ?
> >
> > After that you could stick a
> > b DataAccess
> >
> > directly in the DTLB error handler to skip and dcbX fixups.
>
> With that, I don't see the hard lockup, but things get stuck during
You needed both to loose the hard lockup? I would think
it should be enough to revert the "various copy routines" stuff?
I figure that these routines aren't working in 8xx for other reasons
since they haven't been used on 8xx since at least early 2.4.
> bootup with everything idle. I see this even if I revert everything but
> the "invalidate non present TLBs" patch, and I was seeing similar things
> sometimes with the other tlbil_va hacks.
OK, something else is up.
>
> I think there's something else going on in the 2.6 8xx code that needs
> to be fixed before we can tell what the impact of these patches is.
> I'll look into it.
Great because I am really out of ideas. Perhaps back down to 2.6.30 and test
from there?
^ permalink raw reply
* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Scott Wood @ 2009-10-14 21:14 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OF459A0F65.D3201748-ONC125764F.00738958-C125764F.00744CF0@transmode.se>
Joakim Tjernlund wrote:
>> With that, I don't see the hard lockup, but things get stuck during
>
> You needed both to loose the hard lockup? I would think
> it should be enough to revert the "various copy routines" stuff?
No, but when I just reverted the patch and didn't change the TLB error handler,
I got some other weirdness (assertion failure in some userspace program). It
may have been coincidental, though.
>> I think there's something else going on in the 2.6 8xx code that needs
>> to be fixed before we can tell what the impact of these patches is.
>> I'll look into it.
>
> Great because I am really out of ideas. Perhaps back down to 2.6.30 and test
> from there?
I think the last working version was a little older than that -- and it's quite
possible that there was underlying badness even earlier that just recently got
exposed. I think I want to just debug it and find out what's really going on.
-Scott
^ permalink raw reply
* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Benjamin Herrenschmidt @ 2009-10-14 21:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <4AD63F48.8030301@freescale.com>
On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
>
> I think the last working version was a little older than that -- and it's quite
> possible that there was underlying badness even earlier that just recently got
> exposed. I think I want to just debug it and find out what's really going on.
That would be good :-)
I've been itching to do that but without HW it's not trivial :-)
Cheers,
Ben.
^ permalink raw reply
* Re: i2c-powermac fails
From: Benjamin Herrenschmidt @ 2009-10-14 21:26 UTC (permalink / raw)
To: Jean Delvare; +Cc: Paul Mackerras, Tim Shepard, linuxppc-dev
In-Reply-To: <20091014230252.0d0cba8d@hyperion.delvare>
On Wed, 2009-10-14 at 23:02 +0200, Jean Delvare wrote:
> Hi all,
>
> On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> > I2C bus being setup too fast sounds more likely. It might be worth
> > adding an arbitrary delay after initialization, just to see if it
> > helps. Not sure where though, as I'm not familiar with the Powermac
> > initialization steps. Maybe right before i2c_add_adapter() in
> > i2c_powermac_probe?
>
> Tim, can you please give a try to this patch? Obviously your machine
> will take 5 additional seconds to boot, and this isn't meant as a real
> fix, but if it helps, this will be an interesting hint for further
> debugging attempts.
Oh, I was actually thinking about the frequency of the I2C clock :-)
Cheers,
Ben.
> --- kernel32.orig/drivers/macintosh/therm_adt746x.c
> +++ kernel32/drivers/macintosh/therm_adt746x.c
> @@ -380,6 +380,7 @@ static int probe_thermostat(struct i2c_c
> if (thermostat)
> return 0;
>
> + msleep(5000);
> th = kzalloc(sizeof(struct thermostat), GFP_KERNEL);
> if (!th)
> return -ENOMEM;
>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Prevent unsigned wrap in htab_dt_scan_page_sizes()
From: Paul Mackerras @ 2009-10-14 21:29 UTC (permalink / raw)
To: Roel Kluin; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <4AD5C01E.8000600@gmail.com>
Roel Kluin writes:
> Check to prevent unsigned wrap of size before subtraction.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Is this maybe better or are we certain that size can't wrap?
Patch looks good, though while you're at it, you could add a space
after the "while".
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: Support for S29JL064 in MPC8272ADS?
From: Roberto Guerra @ 2009-10-14 21:34 UTC (permalink / raw)
To: linuxppc-dev, Scott Wood
In-Reply-To: <20091009181617.GA14304@loki.buserror.net>
On Fri, Oct 9, 2009 at 2:16 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Fri, Oct 09, 2009 at 01:59:58PM -0400, Roberto Guerra wrote:
>> No. I did not. My FDT was simplified from the stock MPC8272ADS:
>> =3D> fdt list
>> / {
>> =A0 =A0 =A0 =A0 model =3D "pq2fads";
>> =A0 =A0 =A0 =A0 compatible =3D "fsl,pq2fads";
>> =A0 =A0 =A0 =A0 #address-cells =3D <0x00000001>;
>> =A0 =A0 =A0 =A0 #size-cells =3D <0x00000001>;
>> =A0 =A0 =A0 =A0 cpus {
>> =A0 =A0 =A0 =A0 };
>> =A0 =A0 =A0 =A0 memory {
>> =A0 =A0 =A0 =A0 };
>> =A0 =A0 =A0 =A0 soc@f0000000 {
>> =A0 =A0 =A0 =A0 };
>> =A0 =A0 =A0 =A0 chosen {
>> =A0 =A0 =A0 =A0 };
>> };
>
> You need more than that. =A0What happened to all the content of those nod=
es?
>
>> I am searching how I could add the mtd branch between the "soc" and
>> the "chosen".
>
> Look at the localbus node on the mpc8272ads dts.
>
> Look at (and use) a recent upstream kernel, if you're not already.
>
> -Scott
>
I've been learning how to modify the dts from
http://www.mjmwired.net/kernel/Documentation/powerpc/dts-bindings/mtd-physm=
ap.txt#49
The original mpc8272ads.dts represents four 8-bit JEDEC Sharp flash
chips in 1 SIMM module:
[snip] localbus@f0010100 {
compatible =3D "fsl,mpc8280-localbus",
"fsl,pq2-localbus";
#address-cells =3D <2>;
#size-cells =3D <1>;
reg =3D <f0010100 60>;
ranges =3D <0 0 fe000000 00800000
1 0 f4500000 00008000
8 0 f8200000 00008000>;
flash@0,0 {
compatible =3D "jedec-flash";
reg =3D <0 0 800000>;
bank-width =3D <4>;
device-width =3D <1>;
};
[snip]
My board (based on the PQ2FADS, using the MPC8272ADS BSP) uses one
16-bit Spansion (AMD) CFI chip at addresses FF800000 through FFFFFFFF.
It probably needs to be represented this way (I've only made changes
to the "flash" section.
[snip]
flash@0,0 {
compatible =3D "amd, s29jl064h", "cfi-flash";
reg =3D <0 0 800000>;
bank-width =3D <2>;
device-width =3D <2>;
};
[snip]
However, I don't know what would be the correct addresses to type
after "localbus", "flash" and "reg". Is this enough information to
define my dts?
Thanks,
Roberto
^ permalink raw reply
* Re: Support for S29JL064 in MPC8272ADS?
From: Scott Wood @ 2009-10-14 21:40 UTC (permalink / raw)
To: Roberto Guerra; +Cc: linuxppc-dev
In-Reply-To: <7c4144600910141434y26972dbbnb776c4ef89d15a17@mail.gmail.com>
Roberto Guerra wrote:
> I've been learning how to modify the dts from
> http://www.mjmwired.net/kernel/Documentation/powerpc/dts-bindings/mtd-physmap.txt#49
> The original mpc8272ads.dts represents four 8-bit JEDEC Sharp flash
> chips in 1 SIMM module:
> [snip] localbus@f0010100 {
> compatible = "fsl,mpc8280-localbus",
> "fsl,pq2-localbus";
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <f0010100 60>;
>
> ranges = <0 0 fe000000 00800000
> 1 0 f4500000 00008000
> 8 0 f8200000 00008000>;
>
> flash@0,0 {
> compatible = "jedec-flash";
> reg = <0 0 800000>;
> bank-width = <4>;
> device-width = <1>;
> };
> [snip]
> My board (based on the PQ2FADS, using the MPC8272ADS BSP)
Don't base anything on the BSPs, unless there's something in them that you
really need that isn't upstream. There is pq2fads support in current upstream
kernels.
> uses one
> 16-bit Spansion (AMD) CFI chip at addresses FF800000 through FFFFFFFF.
> It probably needs to be represented this way (I've only made changes
> to the "flash" section.
> [snip]
> flash@0,0 {
> compatible = "amd, s29jl064h", "cfi-flash";
> reg = <0 0 800000>;
> bank-width = <2>;
> device-width = <2>;
> };
> [snip]
> However, I don't know what would be the correct addresses to type
> after "localbus", "flash" and "reg". Is this enough information to
> define my dts?
The flash node looks good, other than that there shouldn't be a space after "amd,".
In the localbus node, change fe000000 to ff800000. Remove or change the other
ranges entries if they don't describe your board's chipselects.
If your IMMR is somewhere other than 0xf0000000, update the f0010100 to match.
-Scott
^ permalink raw reply
* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-14 21:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1255555029.2347.55.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/10/2009 23:17:09:
>
> On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> >
> > I think the last working version was a little older than that -- and it's quite
> > possible that there was underlying badness even earlier that just recently got
> > exposed. I think I want to just debug it and find out what's really going on.
>
> That would be good :-)
>
> I've been itching to do that but without HW it's not trivial :-)
Meanwhile, how about the tlb asm you promised me? :)
It will be a challenge I think since you only have 2 GPRs
I guess it would be possible to stash yet another reg since it
will fit in the cache line already used by the TLB handlers.
Jocke
^ permalink raw reply
* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Benjamin Herrenschmidt @ 2009-10-14 21:52 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFDAF14BF7.E3D4EBC9-ONC125764F.0076DF84-C125764F.00772817@transmode.se>
On Wed, 2009-10-14 at 23:41 +0200, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/10/2009 23:17:09:
> >
> > On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> > >
> > > I think the last working version was a little older than that -- and it's quite
> > > possible that there was underlying badness even earlier that just recently got
> > > exposed. I think I want to just debug it and find out what's really going on.
> >
> > That would be good :-)
> >
> > I've been itching to do that but without HW it's not trivial :-)
>
> Meanwhile, how about the tlb asm you promised me? :)
> It will be a challenge I think since you only have 2 GPRs
> I guess it would be possible to stash yet another reg since it
> will fit in the cache line already used by the TLB handlers.
Let's just get it working first :-)
Ben.
^ permalink raw reply
* [PATCH] hvc_console: returning 0 from put_chars is not an error
From: Timur Tabi @ 2009-10-14 21:53 UTC (permalink / raw)
To: linuxppc-dev, scottwood, borntraeger, brueckner
hvc_console_print() calls the HVC client driver's put_chars() callback
to write some characters to the console. If the callback returns 0, that
indicates that no characters were written (perhaps the output buffer is
full), but hvc_console_print() treats that as an error and discards the
rest of the buffer.
So change hvc_console_print() to just loop and call put_chars() again if it
returns a 0 return code.
This change makes hvc_console_print() behave more like hvc_push(), which does
check for a 0 return code and re-schedules itself.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch might cause a hang in drivers that return 0 in case of error,
instead of a negative number, but those drivers are broken anyway. This
patch might fix drivers that return 0 to indicate that they're busy, such as
arch/powerpc/platforms/pseries/hvconsole.c. It will break drivers that
return 0 if their output buffer is full, but where those buffers cannot be
emptied while the kernel is in a loop.
drivers/char/hvc_console.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index 25ce15b..0c94907 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -161,7 +161,7 @@ static void hvc_console_print(struct console *co, const char *b,
}
} else {
r = cons_ops[index]->put_chars(vtermnos[index], c, i);
- if (r <= 0) {
+ if (r < 0) {
/* throw away chars on error */
i = 0;
} else if (r > 0) {
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] net: Fix OF platform drivers coldplug/hotplug when compiled as modules
From: David Miller @ 2009-10-14 21:54 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, netdev
In-Reply-To: <20091008121512.GA2390@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Thu, 8 Oct 2009 16:15:12 +0400
> Some OF platform drivers are missing module device tables, so they won't
> load automatically on boot. This patch fixes the issue by adding proper
> MODULE_DEVICE_TABLE() macros to the drivers.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2] net/fec_mpc52xx: Fix kernel panic on FEC error
From: David Miller @ 2009-10-14 22:10 UTC (permalink / raw)
To: grant.likely; +Cc: bones, netdev, linuxppc-dev
In-Reply-To: <20091014174224.29221.18830.stgit@angua>
From: Grant Likely <grant.likely@secretlab.ca>
Date: Wed, 14 Oct 2009 11:43:43 -0600
> From: John Bonesio <bones@secretlab.ca>
>
> The MDIO bus cannot be accessed at interrupt context, but on an FEC
> error, the fec_mpc52xx driver reset function also tries to reset the
> PHY. Since the error is detected at IRQ context, and the PHY functions
> try to sleep, the kernel ends up panicking.
>
> Resetting the PHY on an FEC error isn't even necessary. This patch
> solves the problem by removing the PHY reset entirely.
>
> Signed-off-by: John Bonesio <bones@secretlab.ca>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-14 22:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1255557130.2347.58.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/10/2009 23:52:10:
>
> On Wed, 2009-10-14 at 23:41 +0200, Joakim Tjernlund wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 14/10/2009 23:17:09:
> > >
> > > On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> > > >
> > > > I think the last working version was a little older than that -- and it's quite
> > > > possible that there was underlying badness even earlier that just recently got
> > > > exposed. I think I want to just debug it and find out what's really going on.
> > >
> > > That would be good :-)
> > >
> > > I've been itching to do that but without HW it's not trivial :-)
> >
> > Meanwhile, how about the tlb asm you promised me? :)
> > It will be a challenge I think since you only have 2 GPRs
> > I guess it would be possible to stash yet another reg since it
> > will fit in the cache line already used by the TLB handlers.
>
> Let's just get it working first :-)
Chicken :):)
^ permalink raw reply
* Re: linux-next: tree build failure
From: Hollis Blanchard @ 2009-10-14 22:57 UTC (permalink / raw)
To: Jan Beulich
Cc: sfr, Rusty Russell, linux-kernel, kvm-ppc, linux-next, akpm,
linuxppc-dev
In-Reply-To: <1255115648.2546.71.camel@slab.beaverton.ibm.com>
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
>
> original: built but didn't work
> Jan's: doesn't build
> Rusty's: builds and works
>
> Where do you want to go from here?
Jan, what are your thoughts? Your BUILD_BUG_ON patch has broken the
build, and we still need to fix it.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Make NR_IRQS a CONFIG option
From: Michael Ellerman @ 2009-10-14 23:47 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40910141159l402304e9y22a6b2d7d8d79759@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]
On Wed, 2009-10-14 at 12:59 -0600, Grant Likely wrote:
> On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
> > The irq_desc array consumes quite a lot of space, and for systems
> > that don't need or can't have 512 irqs it's just wasted space.
> >
> > The first 16 are reserved for ISA, so the minimum of 32 is really
> > 16 - and no one has asked for more than 512 so leave that as the
> > maximum.
>
> Does it really make sense to have this as a user twiddlable value?
> Especially when many users just don't have the background to know what
> an appropriate value is here and will get it wrong? I believe your
> sparse IRQ patch has a bigger impact anyway on systems where memory is
> tight.
We have users? But yes I think it's reasonable, there's a million other
options people can fiddle with and break their kernel, I don't see that
this is much different.
The sparse IRQ patch has a bigger difference on the size of the irq_desc
array, but there are still other things that are statically sized based
on NR_IRQs. So if you're building an machine-specific kernel and you
know you're only going to have N interrupts, then this will give you a
bigger saving.
But I'm not super fussed, if other people think it's too dangerous we
can drop it.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] powerpc: Enable sparse irq_descs on powerpc
From: Michael Ellerman @ 2009-10-14 23:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40910141144y1776c476uc8e26e06eb57e6ac@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
On Wed, 2009-10-14 at 12:44 -0600, Grant Likely wrote:
> On Tue, Oct 13, 2009 at 11:45 PM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
> > Defining CONFIG_SPARSE_IRQ enables generic code that gets rid of the
> > static irq_desc array, and replaces it with an array of pointers to
> > irq_descs.
> >
> > It also allows node local allocation of irq_descs, however we
> > currently don't have the information available to do that, so we just
> > allocate them on all on node 0.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> Why not make sparse IRQs manditory for all platforms? Is there a
> performance concern with doing so? From a maintenance perspective,
> I'd rather see IRQ descs manged in one way only to keep the code
> simple.
I agree on the maintenance angle. My thinking was we'd run with it
optional but default y for a release or two, and if no one complains we
can make it mandatory.
It does make some code paths bigger, and looking up an irq_desc is going
to take slightly more cycles. I don't think it's a big issue, but I
thought we should try it for a while before making it mandatory. The
code has only been tested on x86 and sh as far as I know.
cheers
ps. thanks for the review
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 6/6] powerpc: Enable sparse irq_descs on powerpc
From: Grant Likely @ 2009-10-15 0:33 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1255564276.9651.14.camel@concordia>
On Wed, Oct 14, 2009 at 5:51 PM, Michael Ellerman
<michael@ellerman.id.au> wrote:
> On Wed, 2009-10-14 at 12:44 -0600, Grant Likely wrote:
>> Why not make sparse IRQs manditory for all platforms? =A0Is there a
>> performance concern with doing so? =A0From a maintenance perspective,
>> I'd rather see IRQ descs manged in one way only to keep the code
>> simple.
>
> I agree on the maintenance angle. My thinking was we'd run with it
> optional but default y for a release or two, and if no one complains we
> can make it mandatory.
>
> It does make some code paths bigger, and looking up an irq_desc is going
> to take slightly more cycles. I don't think it's a big issue, but I
> thought we should try it for a while before making it mandatory. The
> code has only been tested on x86 and sh as far as I know.
No guts, no glory. I say throw it into linux-next to give it some
time before the next merge window. I don't think you'll get any
better results by having it optional for a few releases (in fact, I
suspect that people who do have problems will just end up turning it
off and waiting for someone else to report/fix the problems). If this
is the direction IRQ handling is going, then just make the change and
force any bugs to be dealt with before the next release.
> ps. thanks for the review
You're welcome.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* I think I have 8xx working...
From: Rex Feany @ 2009-10-15 0:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
The biggest problem for me turned out to be the MMU context IDs being
clamped to 32 when the 8xx only has 16. With this, things are a bit more
stable :)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index c2f93dc..15e00c5 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -404,7 +404,8 @@ void __init mmu_context_init(void)
}
#ifdef DEBUG_CLAMP_LAST_CONTEXT
- last_context = DEBUG_CLAMP_LAST_CONTEXT;
+ if (last_context > DEBUG_CLAMP_LAST_CONTEXT)
+ last_context = DEBUG_CLAMP_LAST_CONTEXT;
#endif
/*
* Allocate the maps used by context management
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index e7dae82..26fb6b9 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -40,7 +40,7 @@
#include <asm/uaccess.h>
#include <asm/tlbflush.h>
#include <asm/siginfo.h>
-
+#include <mm/mmu_decl.h>
#ifdef CONFIG_KPROBES
static inline int notify_page_fault(struct pt_regs *regs)
@@ -246,6 +246,12 @@ good_area:
goto bad_area;
#endif /* CONFIG_6xx */
#if defined(CONFIG_8xx)
+ /* 8xx sometimes need to load a invalid/non-present TLBs.
+ * These must be invalidated separately as linux mm don't.
+ */
+ if (error_code & 0x40000000) /* no translation? */
+ _tlbil_va(address, 0, 0, 0);
+
/* The MPC8xx seems to always set 0x80000000, which is
* "undefined". Of those that can be set, this is the only
* one which seems bad.
^ permalink raw reply related
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Stephen Rothwell @ 2009-10-15 1:00 UTC (permalink / raw)
To: Grant Likely
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091007041007.16890.62194.stgit@angua>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
Hi Grant,
On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> Well, I've got to start somewhere...
>
> So here goes. I've begun the work to merge and clean up the OF device
> tree handling code and this is my first set of patches. Not fully
> tested yet, but I'm getting them out to the lists so that I can start
> responding to comments and collecting acks. This first batch isn't
> anything exciting, just a merge of common code
This all looks OK to me. One thing: I started in this as well some time
ago and in my attempt I was hoping to avoid the ARCH ifdefs in linux/of.h
by creating asm/of.h and moving the differing bits in there ...
I'll send out the two patches I did just to show what I mean (these are
from before microblaze was using the OF stuff).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: I think I have 8xx working...
From: Benjamin Herrenschmidt @ 2009-10-15 1:00 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091015004127.GA15570@laura.chatsunix.int.mrv.com>
On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> The biggest problem for me turned out to be the MMU context IDs being
> clamped to 32 when the 8xx only has 16. With this, things are a bit more
> stable :)
Ugh ? The clamp went upstream ? That sucks... let me fix that asap
Cheers,
Ben.
> diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
> index c2f93dc..15e00c5 100644
> --- a/arch/powerpc/mm/mmu_context_nohash.c
> +++ b/arch/powerpc/mm/mmu_context_nohash.c
> @@ -404,7 +404,8 @@ void __init mmu_context_init(void)
> }
>
> #ifdef DEBUG_CLAMP_LAST_CONTEXT
> - last_context = DEBUG_CLAMP_LAST_CONTEXT;
> + if (last_context > DEBUG_CLAMP_LAST_CONTEXT)
> + last_context = DEBUG_CLAMP_LAST_CONTEXT;
> #endif
> /*
> * Allocate the maps used by context management
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index e7dae82..26fb6b9 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -40,7 +40,7 @@
> #include <asm/uaccess.h>
> #include <asm/tlbflush.h>
> #include <asm/siginfo.h>
> -
> +#include <mm/mmu_decl.h>
>
> #ifdef CONFIG_KPROBES
> static inline int notify_page_fault(struct pt_regs *regs)
> @@ -246,6 +246,12 @@ good_area:
> goto bad_area;
> #endif /* CONFIG_6xx */
> #if defined(CONFIG_8xx)
> + /* 8xx sometimes need to load a invalid/non-present TLBs.
> + * These must be invalidated separately as linux mm don't.
> + */
> + if (error_code & 0x40000000) /* no translation? */
> + _tlbil_va(address, 0, 0, 0);
> +
> /* The MPC8xx seems to always set 0x80000000, which is
> * "undefined". Of those that can be set, this is the only
> * one which seems bad.
^ permalink raw reply
* [PATCH 1/2] of: create asm/of.h
From: Stephen Rothwell @ 2009-10-15 1:01 UTC (permalink / raw)
To: Grant Likely
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091015120007.3780c59b.sfr@canb.auug.org.au>
This creates asm/of.h for powerpc and sparc and includes it
from linux/of.h, it also moves the first trivial stuff there from
asm/prom.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/of.h | 23 +++++++++++++++++++++++
arch/powerpc/include/asm/prom.h | 7 -------
arch/sparc/include/asm/of.h | 24 ++++++++++++++++++++++++
arch/sparc/include/asm/prom.h | 7 -------
include/linux/of.h | 1 +
5 files changed, 48 insertions(+), 14 deletions(-)
create mode 100644 arch/powerpc/include/asm/of.h
create mode 100644 arch/sparc/include/asm/of.h
diff --git a/arch/powerpc/include/asm/of.h b/arch/powerpc/include/asm/of.h
new file mode 100644
index 0000000..1c1089a
--- /dev/null
+++ b/arch/powerpc/include/asm/of.h
@@ -0,0 +1,23 @@
+#ifndef _POWERPC_OF_H
+#define _POWERPC_OF_H
+/*
+ * Definitions for accessing the in memory device tree.
+ *
+ * Extracted from prom.h
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 1
+#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
+#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
+#define of_prop_cmp(s1, s2) strcmp((s1), (s2))
+#define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
+
+#endif /* _POWERPC_OF_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 6ff0418..07aef9f 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -21,13 +21,6 @@
#include <asm/irq.h>
#include <asm/atomic.h>
-#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 1
-#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
-#define of_compat_cmp(s1, s2, l) strcasecmp((s1), (s2))
-#define of_prop_cmp(s1, s2) strcmp((s1), (s2))
-#define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
-
/* Definitions used by the flattened device tree */
#define OF_DT_HEADER 0xd00dfeed /* marker */
#define OF_DT_BEGIN_NODE 0x1 /* Start of node, full name */
diff --git a/arch/sparc/include/asm/of.h b/arch/sparc/include/asm/of.h
new file mode 100644
index 0000000..57ab8f9
--- /dev/null
+++ b/arch/sparc/include/asm/of.h
@@ -0,0 +1,24 @@
+#ifndef _SPARC_OF_H
+#define _SPARC_OF_H
+/*
+ * Definitions for accessing the in memory device tree.
+ *
+ * Extracted from prom.h
+ * Copyright (C) 1996-2005 Paul Mackerras.
+ * Updates for PPC64 by Peter Bergner & David Engebretsen, IBM Corp.
+ * Updates for SPARC by David S. Miller
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 2
+#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
+
+#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
+#define of_prop_cmp(s1, s2) strcasecmp((s1), (s2))
+#define of_node_cmp(s1, s2) strcmp((s1), (s2))
+
+#endif /* _SPARC_OF_H */
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index 82a190d..4b6ec43 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -21,13 +21,6 @@
#include <linux/mutex.h>
#include <asm/atomic.h>
-#define OF_ROOT_NODE_ADDR_CELLS_DEFAULT 2
-#define OF_ROOT_NODE_SIZE_CELLS_DEFAULT 1
-
-#define of_compat_cmp(s1, s2, l) strncmp((s1), (s2), (l))
-#define of_prop_cmp(s1, s2) strcasecmp((s1), (s2))
-#define of_node_cmp(s1, s2) strcmp((s1), (s2))
-
typedef u32 phandle;
typedef u32 ihandle;
diff --git a/include/linux/of.h b/include/linux/of.h
index 7be2d10..3bfdaec 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -19,6 +19,7 @@
#include <linux/bitops.h>
#include <linux/mod_devicetable.h>
+#include <asm/of.h>
#include <asm/prom.h>
/* flag descriptions */
--
1.6.4.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 2/2] of: move struct property to asm/of.h
From: Stephen Rothwell @ 2009-10-15 1:02 UTC (permalink / raw)
To: Grant Likely
Cc: monstr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev, davem
In-Reply-To: <20091015120144.73ef384c.sfr@canb.auug.org.au>
Also find all users of struct property and make sure that they include
linux/of.h.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/of.h | 7 +++++++
arch/powerpc/include/asm/prom.h | 7 +------
arch/powerpc/kernel/machine_kexec_64.c | 1 +
arch/powerpc/kernel/prom.c | 1 +
arch/powerpc/kernel/prom_parse.c | 2 ++
arch/powerpc/platforms/maple/pci.c | 1 +
arch/powerpc/platforms/powermac/pci.c | 1 +
arch/powerpc/platforms/powermac/pfunc_core.c | 1 +
arch/powerpc/platforms/pseries/reconfig.c | 1 +
arch/powerpc/sysdev/qe_lib/qe.c | 2 ++
arch/sparc/include/asm/of.h | 9 +++++++++
arch/sparc/include/asm/prom.h | 9 +--------
arch/sparc/kernel/pci_psycho.c | 1 +
arch/sparc/kernel/pci_schizo.c | 1 +
arch/sparc/kernel/pci_sun4v.c | 1 +
arch/sparc/kernel/prom_32.c | 1 +
arch/sparc/kernel/prom_64.c | 1 +
drivers/macintosh/smu.c | 1 +
drivers/sbus/char/openprom.c | 2 ++
fs/openpromfs/inode.c | 1 +
fs/proc/proc_devtree.c | 2 ++
21 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/of.h b/arch/powerpc/include/asm/of.h
index 1c1089a..383f48d 100644
--- a/arch/powerpc/include/asm/of.h
+++ b/arch/powerpc/include/asm/of.h
@@ -20,4 +20,11 @@
#define of_prop_cmp(s1, s2) strcmp((s1), (s2))
#define of_node_cmp(s1, s2) strcasecmp((s1), (s2))
+struct property {
+ char *name;
+ int length;
+ void *value;
+ struct property *next;
+};
+
#endif /* _POWERPC_OF_H */
diff --git a/arch/powerpc/include/asm/prom.h b/arch/powerpc/include/asm/prom.h
index 07aef9f..97b24c9 100644
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@ -68,12 +68,7 @@ struct boot_param_header
typedef u32 phandle;
typedef u32 ihandle;
-struct property {
- char *name;
- int length;
- void *value;
- struct property *next;
-};
+struct property;
struct device_node {
const char *name;
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 040bd1d..8ff5e00 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,7 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/of.h>
#include <asm/page.h>
#include <asm/current.h>
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index d4405b9..c7c2655 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include <linux/debugfs.h>
#include <linux/irq.h>
#include <linux/lmb.h>
+#include <linux/of.h>
#include <asm/prom.h>
#include <asm/rtas.h>
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index 8362620..07698d4 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -6,6 +6,8 @@
#include <linux/module.h>
#include <linux/ioport.h>
#include <linux/etherdevice.h>
+#include <linux/of.h>
+
#include <asm/prom.h>
#include <asm/pci-bridge.h>
diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
index 04296ff..599c192 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/bootmem.h>
#include <linux/irq.h>
+#include <linux/of.h>
#include <asm/sections.h>
#include <asm/io.h>
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index e81403b..ac0ab8d 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/bootmem.h>
#include <linux/irq.h>
+#include <linux/of.h>
#include <asm/sections.h>
#include <asm/io.h>
diff --git a/arch/powerpc/platforms/powermac/pfunc_core.c b/arch/powerpc/platforms/powermac/pfunc_core.c
index 96d5ce5..2eb9cde 100644
--- a/arch/powerpc/platforms/powermac/pfunc_core.c
+++ b/arch/powerpc/platforms/powermac/pfunc_core.c
@@ -11,6 +11,7 @@
#include <linux/spinlock.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/of.h>
#include <asm/prom.h>
#include <asm/pmac_pfunc.h>
diff --git a/arch/powerpc/platforms/pseries/reconfig.c b/arch/powerpc/platforms/pseries/reconfig.c
index 2e2bbe1..5d089d7 100644
--- a/arch/powerpc/platforms/pseries/reconfig.c
+++ b/arch/powerpc/platforms/pseries/reconfig.c
@@ -15,6 +15,7 @@
#include <linux/kref.h>
#include <linux/notifier.h>
#include <linux/proc_fs.h>
+#include <linux/of.h>
#include <asm/prom.h>
#include <asm/machdep.h>
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 464271b..8e690ca 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -27,6 +27,8 @@
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/crc32.h>
+#include <linux/of.h>
+
#include <asm/irq.h>
#include <asm/page.h>
#include <asm/pgtable.h>
diff --git a/arch/sparc/include/asm/of.h b/arch/sparc/include/asm/of.h
index 57ab8f9..7aeb0c2 100644
--- a/arch/sparc/include/asm/of.h
+++ b/arch/sparc/include/asm/of.h
@@ -21,4 +21,13 @@
#define of_prop_cmp(s1, s2) strcasecmp((s1), (s2))
#define of_node_cmp(s1, s2) strcmp((s1), (s2))
+struct property {
+ char *name;
+ int length;
+ void *value;
+ struct property *next;
+ unsigned long _flags;
+ unsigned int unique_id;
+};
+
#endif /* _SPARC_OF_H */
diff --git a/arch/sparc/include/asm/prom.h b/arch/sparc/include/asm/prom.h
index 4b6ec43..03266c2 100644
--- a/arch/sparc/include/asm/prom.h
+++ b/arch/sparc/include/asm/prom.h
@@ -24,14 +24,7 @@
typedef u32 phandle;
typedef u32 ihandle;
-struct property {
- char *name;
- int length;
- void *value;
- struct property *next;
- unsigned long _flags;
- unsigned int unique_id;
-};
+struct property;
struct of_irq_controller;
struct device_node {
diff --git a/arch/sparc/kernel/pci_psycho.c b/arch/sparc/kernel/pci_psycho.c
index 142b9d6..d9c8cde 100644
--- a/arch/sparc/kernel/pci_psycho.c
+++ b/arch/sparc/kernel/pci_psycho.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <linux/of_device.h>
#include <asm/iommu.h>
diff --git a/arch/sparc/kernel/pci_schizo.c b/arch/sparc/kernel/pci_schizo.c
index 2b5cdde..c923817 100644
--- a/arch/sparc/kernel/pci_schizo.c
+++ b/arch/sparc/kernel/pci_schizo.c
@@ -9,6 +9,7 @@
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/interrupt.h>
+#include <linux/of.h>
#include <linux/of_device.h>
#include <asm/iommu.h>
diff --git a/arch/sparc/kernel/pci_sun4v.c b/arch/sparc/kernel/pci_sun4v.c
index 23c33ff..322dfe0 100644
--- a/arch/sparc/kernel/pci_sun4v.c
+++ b/arch/sparc/kernel/pci_sun4v.c
@@ -13,6 +13,7 @@
#include <linux/irq.h>
#include <linux/msi.h>
#include <linux/log2.h>
+#include <linux/of.h>
#include <linux/of_device.h>
#include <asm/iommu.h>
diff --git a/arch/sparc/kernel/prom_32.c b/arch/sparc/kernel/prom_32.c
index 0a37e8c..61eafe0 100644
--- a/arch/sparc/kernel/prom_32.c
+++ b/arch/sparc/kernel/prom_32.c
@@ -21,6 +21,7 @@
#include <linux/mm.h>
#include <linux/bootmem.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <asm/prom.h>
#include <asm/oplib.h>
diff --git a/arch/sparc/kernel/prom_64.c b/arch/sparc/kernel/prom_64.c
index fb06ac2..f05ebdc 100644
--- a/arch/sparc/kernel/prom_64.c
+++ b/arch/sparc/kernel/prom_64.c
@@ -21,6 +21,7 @@
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/lmb.h>
+#include <linux/of.h>
#include <linux/of_device.h>
#include <asm/prom.h>
diff --git a/drivers/macintosh/smu.c b/drivers/macintosh/smu.c
index 96faa79..743e44a 100644
--- a/drivers/macintosh/smu.c
+++ b/drivers/macintosh/smu.c
@@ -36,6 +36,7 @@
#include <linux/sysdev.h>
#include <linux/poll.h>
#include <linux/mutex.h>
+#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
diff --git a/drivers/sbus/char/openprom.c b/drivers/sbus/char/openprom.c
index 75ac19b..c67a9ab 100644
--- a/drivers/sbus/char/openprom.c
+++ b/drivers/sbus/char/openprom.c
@@ -38,6 +38,8 @@
#include <linux/miscdevice.h>
#include <linux/init.h>
#include <linux/fs.h>
+#include <linux/of.h>
+
#include <asm/oplib.h>
#include <asm/prom.h>
#include <asm/system.h>
diff --git a/fs/openpromfs/inode.c b/fs/openpromfs/inode.c
index ffcd04f..b308cdf 100644
--- a/fs/openpromfs/inode.c
+++ b/fs/openpromfs/inode.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/seq_file.h>
#include <linux/magic.h>
+#include <linux/of.h>
#include <asm/openprom.h>
#include <asm/oplib.h>
diff --git a/fs/proc/proc_devtree.c b/fs/proc/proc_devtree.c
index 7ba79a5..42121fc 100644
--- a/fs/proc/proc_devtree.c
+++ b/fs/proc/proc_devtree.c
@@ -9,6 +9,8 @@
#include <linux/proc_fs.h>
#include <linux/stat.h>
#include <linux/string.h>
+#include <linux/of.h>
+
#include <asm/prom.h>
#include <asm/uaccess.h>
#include "internal.h"
--
1.6.4.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: I think I have 8xx working...
From: Benjamin Herrenschmidt @ 2009-10-15 1:06 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091015004127.GA15570@laura.chatsunix.int.mrv.com>
On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> The biggest problem for me turned out to be the MMU context IDs being
> clamped to 32 when the 8xx only has 16. With this, things are a bit more
> stable :)
This is with Joakim patches or without ?
Ben.
> diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
> index c2f93dc..15e00c5 100644
> --- a/arch/powerpc/mm/mmu_context_nohash.c
> +++ b/arch/powerpc/mm/mmu_context_nohash.c
> @@ -404,7 +404,8 @@ void __init mmu_context_init(void)
> }
>
> #ifdef DEBUG_CLAMP_LAST_CONTEXT
> - last_context = DEBUG_CLAMP_LAST_CONTEXT;
> + if (last_context > DEBUG_CLAMP_LAST_CONTEXT)
> + last_context = DEBUG_CLAMP_LAST_CONTEXT;
> #endif
> /*
> * Allocate the maps used by context management
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index e7dae82..26fb6b9 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -40,7 +40,7 @@
> #include <asm/uaccess.h>
> #include <asm/tlbflush.h>
> #include <asm/siginfo.h>
> -
> +#include <mm/mmu_decl.h>
>
> #ifdef CONFIG_KPROBES
> static inline int notify_page_fault(struct pt_regs *regs)
> @@ -246,6 +246,12 @@ good_area:
> goto bad_area;
> #endif /* CONFIG_6xx */
> #if defined(CONFIG_8xx)
> + /* 8xx sometimes need to load a invalid/non-present TLBs.
> + * These must be invalidated separately as linux mm don't.
> + */
> + if (error_code & 0x40000000) /* no translation? */
> + _tlbil_va(address, 0, 0, 0);
> +
> /* The MPC8xx seems to always set 0x80000000, which is
> * "undefined". Of those that can be set, this is the only
> * one which seems bad.
^ permalink raw reply
* Re: I think I have 8xx working...
From: Rex Feany @ 2009-10-15 1:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <1255568772.2347.60.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
> On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > The biggest problem for me turned out to be the MMU context IDs being
> > clamped to 32 when the 8xx only has 16. With this, things are a bit more
> > stable :)
>
> This is with Joakim patches or without ?
with just one: adding tlbil_va() to do_page_fault().
take care!
/rex.
^ permalink raw reply
* Re: I think I have 8xx working...
From: Benjamin Herrenschmidt @ 2009-10-15 1:12 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev@ozlabs.org
In-Reply-To: <20091015010855.GA32710@compile2.chatsunix.int.mrv.com>
On Wed, 2009-10-14 at 18:08 -0700, Rex Feany wrote:
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > > The biggest problem for me turned out to be the MMU context IDs being
> > > clamped to 32 when the 8xx only has 16. With this, things are a bit more
> > > stable :)
> >
> > This is with Joakim patches or without ?
>
> with just one: adding tlbil_va() to do_page_fault().
Ah cool, at least that keeps my sanity, I didn't get how it could work
at all without that bit :-)
Scott, Joakim: It will be interesting to figure out exactly what is the
condition where that is necessary. It definitely should make the one
in set_pte_filter() or ptep_set_access_flags_filter() unnecessary.
Joakim, you mentioned increased amount of TLB errors or misses when
doing that too often, that sounds a bit weird and worth investigating
Finally we could implement preload from update_mmu_cache() but that's a
different matter alltogether.
Cheers,
Ben.
^ 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