* Re: [PATCH 2/6] 8xx: get rid of _PAGE_HWWRITE dependency in MMU.
From: Benjamin Herrenschmidt @ 2009-10-08 20:21 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <OFB3DEEF6E.1F3F6AC5-ONC1257649.00246C73-C1257649.002523BD@transmode.se>
On Thu, 2009-10-08 at 08:45 +0200, Joakim Tjernlund wrote:
> > Generic code should sort it out in handle_mm_fault() (or earlier if it
> > can't find a VMA at all).
>
> How can it? You need to know more that just read and write.
It does. It's going to look for the VMA, which will tell it what is
allowed or not. You'll notice 4xx/BookE doesn't use DSISR (except the
ESR bit we pass to separate loads from stores).
If the region has no access, the kernel will know it (no VMA for
example) and will trigger a SEGV.
Really, the DSISR stuff is not as necessary as you think it is :-) You
should be able to jump to C code straight from both TLB error
interrupts.
> >
> > But that's a slow path anyways.
>
> How so? You take a TLB Error for the first write to
> every page.
Compared to the TLB miss that is :-) But my main point is that a TLB
error caused by a lack of DIRTY or ACCESSED will be rare.
Ben.
^ permalink raw reply
* Re: [PATCH 3/6] 8xx: invalidate non present TLBs
From: Benjamin Herrenschmidt @ 2009-10-08 20:18 UTC (permalink / raw)
To: Dan Malek; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <7A3C6D4C-E92B-434D-AF68-7AEEDE6DAD45@embeddedalley.com>
On Thu, 2009-10-08 at 13:11 -0700, Dan Malek wrote:
>
> There are many comments written about 8xx as various
> behavior was discovered. Worse, some of these details
> would be different among the different processor versions.
> You need to be careful and test as many different part
> versions as possible to ensure you have everything
> covered..... then someone will find a part that doesn't
> quite work, "fix" it, and break others :-)
>
> In this particular case, the PEM does state dcbst is treated
> as a load, but from experience we know 8xx doesn't work
> that way. Of course, since dcbst is a store operation,
> you could argue that 8xx got it correct :-)
Hehe. Well, it's architecturally incorrect, as dcbst is not really a
store operation in the sense that it doesn't modify the target cache
line, and as such doesn't (mustn't) be covered by write access
protection, shouldn't set DIRTY, etc...
So I would argue that 8xx got it wrong either way :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 3/6] 8xx: invalidate non present TLBs
From: Dan Malek @ 2009-10-08 20:11 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OF44C1983F.1C42E290-ONC1257649.0069CAF3-C1257649.006A78D1@transmode.se>
On Oct 8, 2009, at 12:22 PM, Joakim Tjernlund wrote:
> hare are comments in the kernel that dcbst wrongly
> generates TLB Errors with store set on 8xx. Is this really so?
> Should dcbst always trap as a load?
There are many comments written about 8xx as various
behavior was discovered. Worse, some of these details
would be different among the different processor versions.
You need to be careful and test as many different part
versions as possible to ensure you have everything
covered..... then someone will find a part that doesn't
quite work, "fix" it, and break others :-)
In this particular case, the PEM does state dcbst is treated
as a load, but from experience we know 8xx doesn't work
that way. Of course, since dcbst is a store operation,
you could argue that 8xx got it correct :-)
Have fun!
-- Dan
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: Fix decrementer setup on 1GHz boards
From: Benjamin Herrenschmidt @ 2009-10-08 20:12 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Anton Blanchard, Detlev Zundel
In-Reply-To: <1255013362-27135-1-git-send-email-sr@denx.de>
On Thu, 2009-10-08 at 16:49 +0200, Stefan Roese wrote:
> We noticed that recent kernels didn't boot on our 1GHz Canyonlands 460EX
> boards anymore. As it seems, patch 8d165db1 [powerpc: Improve
> decrementer accuracy] introduced this problem. The routine div_sc()
> overflows with shift = 32 resulting in this incorrect setup:
>
> time_init: decrementer frequency = 1000.000012 MHz
> time_init: processor frequency = 1000.000012 MHz
> clocksource: timebase mult[400000] shift[22] registered
> clockevent: decrementer mult[33] shift[32] cpu[0]
>
> This patch now introduces a local div_dc64() version of this function
> so that this overflow doesn't happen anymore.
Ugh ? We never expected that the decrementer would be ticking that fast.
This is too fast actually. Somebody at AMCC must be told to stick a
divider in front of the timebase when reaching such frequencies.
Ben.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Anton Blanchard <anton@samba.org>
> Cc: Detlev Zundel <dzu@denx.de>
> ---
> Ben, Anton, how should we handle this? Is this patch acceptable? Or how
> should this be solved?
>
> arch/powerpc/kernel/time.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 92dc844..3ad729f 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -882,12 +882,21 @@ static void decrementer_set_mode(enum clock_event_mode mode,
> decrementer_set_next_event(DECREMENTER_MAX, dev);
> }
>
> +static inline uint64_t div_sc64(unsigned long ticks, unsigned long nsec,
> + int shift)
> +{
> + uint64_t tmp = ((uint64_t)ticks) << shift;
> +
> + do_div(tmp, nsec);
> + return tmp;
> +}
> +
> static void __init setup_clockevent_multiplier(unsigned long hz)
> {
> u64 mult, shift = 32;
>
> while (1) {
> - mult = div_sc(hz, NSEC_PER_SEC, shift);
> + mult = div_sc64(hz, NSEC_PER_SEC, shift);
> if (mult && (mult >> 32UL) == 0UL)
> break;
>
^ permalink raw reply
* Re: [PATCH 3/6] 8xx: invalidate non present TLBs
From: Joakim Tjernlund @ 2009-10-08 19:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1254950285.2409.10.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 07/10/2009 23:18:05:
>
> On Wed, 2009-10-07 at 22:46 +0200, Joakim Tjernlund wrote:
> > 8xx sometimes need to load a invalid/non-present TLBs in
> > it DTLB asm handler.
> > These must be invalidated separaly as linux mm don't.
>
> not sure about the dsisr test here, what is the point ?
Without this patch I get about twice as many DTLB errors( on 2.4)
I have also noted that all my dcbst DTLB has the store bit set:
trap:300 address:10030b8c, dar:10030b8c,err:42000000 dcbst
Thare are comments in the kernel that dcbst wrongly
generates TLB Errors with store set on 8xx. Is this really so?
Should dcbst always trap as a load?
Jocke
>
> Cheers,
> Ben.
>
> > ---
> > arch/powerpc/mm/fault.c | 8 +++++++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> > index 7699394..72941c7 100644
> > --- a/arch/powerpc/mm/fault.c
> > +++ b/arch/powerpc/mm/fault.c
> > @@ -39,7 +39,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)
> > @@ -243,6 +243,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);
> > +
> > /* 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: Crash in the kernel panic linux mpc 832x
From: Scott Wood @ 2009-10-08 18:48 UTC (permalink / raw)
To: nanda; +Cc: linuxppc-dev
In-Reply-To: <20090916150233.33919.qmail@f5mail-237-241.rediffmail.com>
On Wed, Sep 16, 2009 at 03:02:33PM -0000, nanda wrote:
> Hi,
> Iam getting the below crash on new board tested on MPC832x using
> linux-2.6.24, please let me what could be the problem on the same.
> Does it infer any information on the exception?
Please try running the latest kernel.
> # Oops: Exception in kernel mode, sig: 4 [#1]
> PREEMPT MPC832x RDB
> Modules linked in:
I think you left off some relevant ines before this -- was there anything
like "kernel BUG in line ..."? Do you have verbose BUG reporting
enabled?
-Scott
^ permalink raw reply
* [PATCH][v2] powerpc/4xx: Add 16K FIFO size DTS entries on supported platforms
From: Dave Mitchell @ 2009-10-08 16:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Dave Mitchell
Adding tx/rx-fifo-size-gige to EMAC fields for evaluation kit DTS
files where appropriate.
Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
Acked-by: Victor Gallardo <vgallardo@appliedmicro.com>
Acked-by: Loc Ho <lho@appliedmicro.com>
---
v1->v2: local date/time was out-of-sync and thus mail was as well
arch/powerpc/boot/dts/canyonlands.dts | 2 ++
arch/powerpc/boot/dts/eiger.dts | 6 ++++++
arch/powerpc/boot/dts/glacier.dts | 6 ++++++
arch/powerpc/boot/dts/haleakala.dts | 2 ++
arch/powerpc/boot/dts/kilauea.dts | 4 ++++
arch/powerpc/boot/dts/makalu.dts | 4 ++++
arch/powerpc/boot/dts/redwood.dts | 1 +
7 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index c920170..cd56bb5 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -352,6 +352,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -381,6 +382,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
diff --git a/arch/powerpc/boot/dts/eiger.dts b/arch/powerpc/boot/dts/eiger.dts
index c4a934f..48bcf71 100644
--- a/arch/powerpc/boot/dts/eiger.dts
+++ b/arch/powerpc/boot/dts/eiger.dts
@@ -316,6 +316,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -345,6 +346,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -375,6 +377,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>; /* emac2&3 only */
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII1>;
@@ -403,6 +407,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>; /* emac2&3 only */
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII1>;
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
index f3787a2..f6f6189 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -292,6 +292,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -321,6 +322,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -351,6 +353,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>; /* emac2&3 only */
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII1>;
@@ -379,6 +383,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>; /* emac2&3 only */
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII1>;
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index 5b2a494..2b25669 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -226,6 +226,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index c465614..083e68e 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -272,6 +272,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
@@ -300,6 +302,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index ffc246e..63d48b6 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -227,6 +227,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x0000003f>; /* Start at 6 */
rgmii-device = <&RGMII0>;
@@ -255,6 +257,8 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
+ tx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
diff --git a/arch/powerpc/boot/dts/redwood.dts b/arch/powerpc/boot/dts/redwood.dts
index ad402c4..d2af32e 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -226,6 +226,7 @@
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
+ rx-fifo-size-gige = <16384>;
phy-mode = "rgmii";
phy-map = <0x00000000>;
rgmii-device = <&RGMII0>;
--
1.6.3.2
^ permalink raw reply related
* [PATCH][v2] ibm_newemac: Added 16K Tx FIFO size support for EMAC4
From: Dave Mitchell @ 2009-10-08 16:32 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev, Dave Mitchell
Some of the EMAC V4 implementations support 16K Tx FIFOs. This
patch adds support for this functionality and fixes typos in the
Tx FIFO size error messages.
Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
Acked-by: Victor Gallardo <vgallardo@appliedmicro.com>
Acked-by: Loc Ho <lho@appliedmicro.com>
---
v1->v2: local date/time was out-of-sync and thus mail was as well
drivers/net/ibm_newemac/core.c | 7 +++++--
drivers/net/ibm_newemac/emac.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 89c82c5..c6591cb 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -443,7 +443,7 @@ static u32 __emac_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_s
ret |= EMAC_MR1_TFS_2K;
break;
default:
- printk(KERN_WARNING "%s: Unknown Rx FIFO size %d\n",
+ printk(KERN_WARNING "%s: Unknown Tx FIFO size %d\n",
dev->ndev->name, tx_size);
}
@@ -470,6 +470,9 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
DBG2(dev, "__emac4_calc_base_mr1" NL);
switch(tx_size) {
+ case 16384:
+ ret |= EMAC4_MR1_TFS_16K;
+ break;
case 4096:
ret |= EMAC4_MR1_TFS_4K;
break;
@@ -477,7 +480,7 @@ static u32 __emac4_calc_base_mr1(struct emac_instance *dev, int tx_size, int rx_
ret |= EMAC4_MR1_TFS_2K;
break;
default:
- printk(KERN_WARNING "%s: Unknown Rx FIFO size %d\n",
+ printk(KERN_WARNING "%s: Unknown Tx FIFO size %d\n",
dev->ndev->name, tx_size);
}
diff --git a/drivers/net/ibm_newemac/emac.h b/drivers/net/ibm_newemac/emac.h
index 0afc2cf..d34adf9 100644
--- a/drivers/net/ibm_newemac/emac.h
+++ b/drivers/net/ibm_newemac/emac.h
@@ -153,6 +153,7 @@ struct emac_regs {
#define EMAC4_MR1_RFS_16K 0x00280000
#define EMAC4_MR1_TFS_2K 0x00020000
#define EMAC4_MR1_TFS_4K 0x00030000
+#define EMAC4_MR1_TFS_16K 0x00050000
#define EMAC4_MR1_TR 0x00008000
#define EMAC4_MR1_MWSW_001 0x00001000
#define EMAC4_MR1_JPSM 0x00000800
--
1.6.3.2
^ permalink raw reply related
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Grant Likely @ 2009-10-08 15:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, devicetree-discuss, linux-embedded, linux-i2c
In-Reply-To: <20091008151007.GA21328@oksana.dev.rtsoft.ru>
On Thu, Oct 8, 2009 at 9:10 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Thu, Oct 08, 2009 at 08:53:46AM -0600, Grant Likely wrote:
> [...]
>> Please don't. =A0It is such a small amount of code,
>
> It's *always* a small amound of code, at a start. Then we get
> floppy disk drivers and the tty layer. ;-)
Holy straw man argument Batman!
But the focus is still on creating pdata. If a translator gets too
big, then sure, split it into a separate file. Until then, there I
see no good reason to do so now.
>
> [...]
>> Driver writers shouldn't have to
>> write anything more than a tiny function to populate pdata from the
>> device tree. =A0Managing that pdata instance needs to be done with
>> common infrastructure (but I don't have a firm idea about how it
>> should look yet). =A0In the mean time I think Wolfram's approach has
>> lower impact.
>
> If I wasn't a PPC/OF guy to some degree, I'd hate PPC/OF people
> for bringing arch-specific details into a generic code... :-P
No, this goes beyond PPC/OF. The real issue is that it is no longer a
safe assumption that pdata will be a static data structure in platform
code. The number of possible data sources is going to get larger, not
smaller. OF is just one. UEFI is another. Translating that data
into pdata will be the problem that comes up over and over again.
However, translation code is still driver specific, so it belongs with
the driver that it translates code for.
So, in my opinion, translation code must:
1. be *tiny* -- should be trivial to add to a driver without impacting
common code
2. live with the driver that it translates data for; ideally in the
same .c file for drivers that are small.
> No matter how small the OF code is, I believe we shouldn't put it
> into the generic code. Take a look at mmc_spi case again, it can be
> easily extended to any arch, because there is no arch-specific stuff,
> but a "get/put" pattern for platform data.
I'm not disagreeing with you that the arch specific stuff should be
logically separated from the generic code. But I don't agree that it
belongs in a separate file. And I also think that the mmc_spi
implementation uses too much code. There must be a better way.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Anton Vorontsov @ 2009-10-08 15:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c
In-Reply-To: <fa686aa40910080753v6f597b0h4ce835db9f7a653@mail.gmail.com>
On Thu, Oct 08, 2009 at 08:53:46AM -0600, Grant Likely wrote:
[...]
> Please don't. It is such a small amount of code,
It's *always* a small amound of code, at a start. Then we get
floppy disk drivers and the tty layer. ;-)
[...]
> Driver writers shouldn't have to
> write anything more than a tiny function to populate pdata from the
> device tree. Managing that pdata instance needs to be done with
> common infrastructure (but I don't have a firm idea about how it
> should look yet). In the mean time I think Wolfram's approach has
> lower impact.
If I wasn't a PPC/OF guy to some degree, I'd hate PPC/OF people
for bringing arch-specific details into a generic code... :-P
No matter how small the OF code is, I believe we shouldn't put it
into the generic code. Take a look at mmc_spi case again, it can be
easily extended to any arch, because there is no arch-specific stuff,
but a "get/put" pattern for platform data.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Grant Likely @ 2009-10-08 14:53 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c
In-Reply-To: <20091008143301.GA6084@oksana.dev.rtsoft.ru>
On Thu, Oct 8, 2009 at 8:33 AM, Anton Vorontsov
<avorontsov@ru.mvista.com> wrote:
> On Thu, Oct 08, 2009 at 04:04:32PM +0200, Wolfram Sang wrote:
>> As Anton introduced archdata support, I wondered if this is a suitable w=
ay to
>> handle the platform_data/devicetree_property-dualism (at least for some
>> drivers).
>
> Yes, we handle OF in a similar way for mmc_spi driver. Though,
>
> [...]
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -22,6 +22,9 @@
> [...]
>> +#ifdef CONFIG_OF_I2C
>> +#include <linux/of.h>
>> +#endif
> [..]
>> +#ifdef CONFIG_OF_I2C
>> +static void at24_get_ofdata(struct i2c_client *client, struct at24_plat=
form_data *chip)
>> +{
>> + =A0 =A0 const u32 *val;
>> + =A0 =A0 struct device_node *node =3D dev_archdata_get_node(&client->de=
v.archdata);
>> +
>> + =A0 =A0 if (node) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 if (of_get_property(node, "read-only", NULL))
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chip->flags |=3D AT24_FLAG_REA=
DONLY;
>> + =A0 =A0 =A0 =A0 =A0 =A0 val =3D of_get_property(node, "pagesize", NULL=
);
>> + =A0 =A0 =A0 =A0 =A0 =A0 if (val)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chip->page_size =3D *val;
>> + =A0 =A0 }
>> +}
>> +#else
>> +static void at24_get_ofdata(struct i2c_client *client, struct at24_plat=
form_data *chip)
>> +{ }
>> +#endif
>
> #ifdefs are ugly in .c files. I'd suggest to move the OF code
> into a separate file. As an example, see
Please don't. It is such a small amount of code, and I far prefer to
see drivers self contained in a single .c file. #ifdefs are fine IMHO
when it is a top level block, and not inside a function block. In the
example you give, I do like the move toward focusing on the pdata
structure; but the patch ads a *lot* of code for something very
simple. And then we'll need to do the same think for every driver
which will ever be described in the device tree. It's the right
direction, but still not right. Driver writers shouldn't have to
write anything more than a tiny function to populate pdata from the
device tree. Managing that pdata instance needs to be done with
common infrastructure (but I don't have a firm idea about how it
should look yet). In the mean time I think Wolfram's approach has
lower impact.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] Ftrace : fix function_graph tracer OOPS
From: Sachin Sant @ 2009-10-08 14:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, rostedt
In-Reply-To: <1254906621.2409.1.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 282 bytes --]
Enabling function graph causes oops due to usage of LOAD_REG_IMMEDIATE().
As explained by Ben the usage of LOAD_REG_IMMEDIATE generates relocs that are
not supported when CONFIG_RELOCATABLE is set.
Switch to LOAD_REG_ADDR().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
[-- Attachment #2: fix_ftrace_function_graph.patch --]
[-- Type: text/x-patch, Size: 845 bytes --]
Enabling function graph causes oops due to usage of LOAD_REG_IMMEDIATE().
As explained by Ben the usage of LOAD_REG_IMMEDIATE generates relocs that are
not supported when CONFIG_RELOCATABLE is set.
Switch to LOAD_REG_ADDR().
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp old/arch/powerpc/kernel/entry_64.S new/arch/powerpc/kernel/entry_64.S
--- old/arch/powerpc/kernel/entry_64.S 2009-10-08 18:37:44.000000000 +0530
+++ new/arch/powerpc/kernel/entry_64.S 2009-10-08 18:34:33.000000000 +0530
@@ -1038,8 +1038,8 @@ _GLOBAL(mod_return_to_handler)
* We are in a module using the module's TOC.
* Switch to our TOC to run inside the core kernel.
*/
- LOAD_REG_IMMEDIATE(r4,ftrace_return_to_handler)
- ld r2, 8(r4)
+ ld r2, PACATOC(r13)
+ LOAD_REG_ADDR(r4,ftrace_return_to_handler)
bl .ftrace_return_to_handler
nop
^ permalink raw reply
* [PATCH/RFC] powerpc: Fix decrementer setup on 1GHz boards
From: Stefan Roese @ 2009-10-08 14:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anton Blanchard, Detlev Zundel
We noticed that recent kernels didn't boot on our 1GHz Canyonlands 460EX
boards anymore. As it seems, patch 8d165db1 [powerpc: Improve
decrementer accuracy] introduced this problem. The routine div_sc()
overflows with shift = 32 resulting in this incorrect setup:
time_init: decrementer frequency = 1000.000012 MHz
time_init: processor frequency = 1000.000012 MHz
clocksource: timebase mult[400000] shift[22] registered
clockevent: decrementer mult[33] shift[32] cpu[0]
This patch now introduces a local div_dc64() version of this function
so that this overflow doesn't happen anymore.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Detlev Zundel <dzu@denx.de>
---
Ben, Anton, how should we handle this? Is this patch acceptable? Or how
should this be solved?
arch/powerpc/kernel/time.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 92dc844..3ad729f 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -882,12 +882,21 @@ static void decrementer_set_mode(enum clock_event_mode mode,
decrementer_set_next_event(DECREMENTER_MAX, dev);
}
+static inline uint64_t div_sc64(unsigned long ticks, unsigned long nsec,
+ int shift)
+{
+ uint64_t tmp = ((uint64_t)ticks) << shift;
+
+ do_div(tmp, nsec);
+ return tmp;
+}
+
static void __init setup_clockevent_multiplier(unsigned long hz)
{
u64 mult, shift = 32;
while (1) {
- mult = div_sc(hz, NSEC_PER_SEC, shift);
+ mult = div_sc64(hz, NSEC_PER_SEC, shift);
if (mult && (mult >> 32UL) == 0UL)
break;
--
1.6.4.4
^ permalink raw reply related
* Re: SMU-base PowerMac and server_mode
From: Romain Goyet @ 2009-10-08 14:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20091007163341.GA7657@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
Ahem, that's pretty bad :'( How comes noone uses that ?
- Romain
On Wed, Oct 7, 2009 at 6:33 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Oct 07, 2009 at 01:25:13PM +0200, Romain Goyet wrote:
> > On Tue, Oct 6, 2009 at 6:07 PM, Olof Johansson <olof@lixom.net> wrote:
>
> > > Yeah, I had one but I have since lost it. I suspect it was on the
> > > drive of my second quad that I wiped before I sold it, thinking there
> > > was nothing of value on it. :(
> >
> > Ha, that's too bad. Do you know if it might be online somewhere ? Maybe
> an
> > idea of the right keywords to google ?
>
> I searched for it, couldn't find any trace of it anywhere. I know I
> based my little tool on some small smu example that came from Ben or
> possibly Segher. I can't even find that any more. It's been a couple of
> years since I last touched it. :(
>
>
> -Olof
>
[-- Attachment #2: Type: text/html, Size: 1821 bytes --]
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Grant Likely @ 2009-10-08 14:37 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c
In-Reply-To: <1255010672-21656-1-git-send-email-w.sang@pengutronix.de>
On Thu, Oct 8, 2009 at 8:04 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> As Anton introduced archdata support, I wondered if this is a suitable way to
> handle the platform_data/devicetree_property-dualism (at least for some
> drivers).
I think in general, this is the right direction; but I'm not convinced
that the right pattern or form has been found yet. What I don't like
on this particular patch is that it still hooks of-specific stuff into
an arbitrary point in the probe routine.
I'd like to see some pattern for retrieving or populating a
platform_data structure when one isn't already provided, and
regardless of the data source.
So, I guess I'm saying that I agree with the approach, but I think a
better pattern would be to factor out all of the platform_data
fetching code into a separate function and keep probe() focused on
initializing the device based on a pdata structure returned by it. It
will take a bit of experimentation to come up with the best form for
the pdata fetching function, but it will be better contained if it is
all at a single place.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Anton Vorontsov @ 2009-10-08 14:33 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, devicetree-discuss, linux-i2c
In-Reply-To: <1255010672-21656-1-git-send-email-w.sang@pengutronix.de>
On Thu, Oct 08, 2009 at 04:04:32PM +0200, Wolfram Sang wrote:
> As Anton introduced archdata support, I wondered if this is a suitable way to
> handle the platform_data/devicetree_property-dualism (at least for some
> drivers).
Yes, we handle OF in a similar way for mmc_spi driver. Though,
[...]
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -22,6 +22,9 @@
[...]
> +#ifdef CONFIG_OF_I2C
> +#include <linux/of.h>
> +#endif
[..]
> +#ifdef CONFIG_OF_I2C
> +static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip)
> +{
> + const u32 *val;
> + struct device_node *node = dev_archdata_get_node(&client->dev.archdata);
> +
> + if (node) {
> + if (of_get_property(node, "read-only", NULL))
> + chip->flags |= AT24_FLAG_READONLY;
> + val = of_get_property(node, "pagesize", NULL);
> + if (val)
> + chip->page_size = *val;
> + }
> +}
> +#else
> +static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip)
> +{ }
> +#endif
#ifdefs are ugly in .c files. I'd suggest to move the OF code
into a separate file. As an example, see
commit 9c43df57910bbba540a6cb5c9132302a9ea5f41a
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Tue Dec 30 18:15:28 2008 +0300
mmc_spi: Add support for OpenFirmware bindings
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [RFC] misc/at24: add experimental OF support for the generic eeprom driver
From: Wolfram Sang @ 2009-10-08 14:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss, linux-i2c
As Anton introduced archdata support, I wondered if this is a suitable way to
handle the platform_data/devicetree_property-dualism (at least for some
drivers).
If considered suitable, I would document the bindings properly. I really think
that pagesize deserves its own property as it is specific to the hardware and I
have seen devices with equal name and still having different pagesizes. Not too
sure about 'read-only' though, I just copied it from flash-partitions :)
Tested on a phyCORE-MPC5200-IO and build-tested on x86.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/misc/eeprom/at24.c | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index db39f4a..4e543e6 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -22,6 +22,9 @@
#include <linux/jiffies.h>
#include <linux/i2c.h>
#include <linux/i2c/at24.h>
+#ifdef CONFIG_OF_I2C
+#include <linux/of.h>
+#endif
/*
* I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
@@ -414,6 +417,25 @@ static ssize_t at24_macc_write(struct memory_accessor *macc, const char *buf,
return at24_write(at24, buf, offset, count);
}
+#ifdef CONFIG_OF_I2C
+static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip)
+{
+ const u32 *val;
+ struct device_node *node = dev_archdata_get_node(&client->dev.archdata);
+
+ if (node) {
+ if (of_get_property(node, "read-only", NULL))
+ chip->flags |= AT24_FLAG_READONLY;
+ val = of_get_property(node, "pagesize", NULL);
+ if (val)
+ chip->page_size = *val;
+ }
+}
+#else
+static void at24_get_ofdata(struct i2c_client *client, struct at24_platform_data *chip)
+{ }
+#endif
+
/*-------------------------------------------------------------------------*/
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -444,6 +466,9 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
*/
chip.page_size = 1;
+ /* update chipdata if OF is present */
+ at24_get_ofdata(client, &chip);
+
chip.setup = NULL;
chip.context = NULL;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/6] 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-4-git-send-email-Joakim.Tjernlund@transmode.se>
dcbz, dcbf, dcbi, dcbst and icbi do not set DAR when they
cause a DTLB Error. Dectect this by tagging DAR with 0x00f0
at every exception exit that modifies DAR.
Test for DAR=0x00f0 in DataTLBError and bail
to handle_page_fault().
---
arch/powerpc/kernel/head_8xx.S | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1639d16..9707dc4 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -206,6 +206,8 @@ MachineCheck:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -222,6 +224,8 @@ DataAccess:
stw r10,_DSISR(r11)
mr r5,r10
mfspr r4,SPRN_DAR
+ li r10,0x00f0
+ mtspr SPRN_DAR,r10 /* Tag DAR, to be used in DTLB Error */
EXC_XFER_EE_LITE(0x300, handle_page_fault)
/* Instruction access exception.
@@ -244,6 +248,8 @@ Alignment:
EXCEPTION_PROLOG
mfspr r4,SPRN_DAR
stw r4,_DAR(r11)
+ li r5,0x00f0
+ mtspr SPRN_DAR,r5 /* Tag DAR, to be used in DTLB Error */
mfspr r5,SPRN_DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
@@ -441,6 +447,7 @@ DataStoreTLBMiss:
* of the MMU.
*/
2: li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
@@ -481,6 +488,10 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
+ mfspr r10, SPRN_DAR
+ cmpwi cr0, r10, 0x00f0
+ beq- 2f /* must be a buggy dcbX, icbi insn. */
+
mfspr r11, SPRN_DSISR
andis. r11, r11, 0x4800 /* !translation or protection */
bne 2f /* branch if either is set */
@@ -504,7 +515,8 @@ DataTLBError:
* are initialized in mapin_ram(). This will avoid the problem,
* assuming we only use the dcbi instruction on kernel addresses.
*/
- mfspr r10, SPRN_DAR
+
+ /* DAR is in r10 already */
rlwinm r11, r10, 0, 0, 19
ori r11, r11, MD_EVALID
mfspr r10, SPRN_M_CASID
@@ -546,6 +558,7 @@ DataTLBError:
* of the MMU.
*/
li r11, 0x00f0
+ mtspr SPRN_DAR,r11 /* Tag DAR */
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x3d80, r3)
mtspr SPRN_MD_RPN, r10 /* Update TLB entry */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 6/6] 8xx: start using dcbX instructions in various copy routines
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-6-git-send-email-Joakim.Tjernlund@transmode.se>
Now that 8xx can fixup dcbX instructions, start using them
where possible like every other PowerPc arch do.
---
arch/powerpc/kernel/misc_32.S | 18 ------------------
arch/powerpc/lib/copy_32.S | 24 ------------------------
2 files changed, 0 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 15f28e0..b92095e 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -495,15 +495,7 @@ _GLOBAL(clear_pages)
li r0,PAGE_SIZE/L1_CACHE_BYTES
slw r0,r0,r4
mtctr r0
-#ifdef CONFIG_8xx
- li r4, 0
-1: stw r4, 0(r3)
- stw r4, 4(r3)
- stw r4, 8(r3)
- stw r4, 12(r3)
-#else
1: dcbz 0,r3
-#endif
addi r3,r3,L1_CACHE_BYTES
bdnz 1b
blr
@@ -528,15 +520,6 @@ _GLOBAL(copy_page)
addi r3,r3,-4
addi r4,r4,-4
-#ifdef CONFIG_8xx
- /* don't use prefetch on 8xx */
- li r0,4096/L1_CACHE_BYTES
- mtctr r0
-1: COPY_16_BYTES
- bdnz 1b
- blr
-
-#else /* not 8xx, we can prefetch */
li r5,4
#if MAX_COPY_PREFETCH > 1
@@ -577,7 +560,6 @@ _GLOBAL(copy_page)
li r0,MAX_COPY_PREFETCH
li r11,4
b 2b
-#endif /* CONFIG_8xx */
/*
* void atomic_clear_mask(atomic_t mask, atomic_t *addr)
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index c657de5..74a7f41 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -98,20 +98,7 @@ _GLOBAL(cacheable_memzero)
bdnz 4b
3: mtctr r9
li r7,4
-#if !defined(CONFIG_8xx)
10: dcbz r7,r6
-#else
-10: stw r4, 4(r6)
- stw r4, 8(r6)
- stw r4, 12(r6)
- stw r4, 16(r6)
-#if CACHE_LINE_SIZE >= 32
- stw r4, 20(r6)
- stw r4, 24(r6)
- stw r4, 28(r6)
- stw r4, 32(r6)
-#endif /* CACHE_LINE_SIZE */
-#endif
addi r6,r6,CACHELINE_BYTES
bdnz 10b
clrlwi r5,r8,32-LG_CACHELINE_BYTES
@@ -200,9 +187,7 @@ _GLOBAL(cacheable_memcpy)
mtctr r0
beq 63f
53:
-#if !defined(CONFIG_8xx)
dcbz r11,r6
-#endif
COPY_16_BYTES
#if L1_CACHE_BYTES >= 32
COPY_16_BYTES
@@ -356,14 +341,6 @@ _GLOBAL(__copy_tofrom_user)
li r11,4
beq 63f
-#ifdef CONFIG_8xx
- /* Don't use prefetch on 8xx */
- mtctr r0
- li r0,0
-53: COPY_16_BYTES_WITHEX(0)
- bdnz 53b
-
-#else /* not CONFIG_8xx */
/* Here we decide how far ahead to prefetch the source */
li r3,4
cmpwi r0,1
@@ -416,7 +393,6 @@ _GLOBAL(__copy_tofrom_user)
li r3,4
li r7,0
bne 114b
-#endif /* CONFIG_8xx */
63: srwi. r0,r5,2
mtctr r0
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/6] 8xx: Update TLB asm so it behaves as linux mm expects.
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-2-git-send-email-Joakim.Tjernlund@transmode.se>
Update the TLB asm to make proper use of _PAGE_DIRY and _PAGE_ACCESSED.
Get rid of _PAGE_HWWRITE too.
Pros:
- I/D TLB Miss never needs to write to the linux pte.
- _PAGE_ACCESSED is only set on TLB Error fixing accounting
- _PAGE_DIRTY is mapped to 0x100, the changed bit, and is set directly
when a page has been made dirty.
- Proper RO/RW mapping of user space.
- Free up 2 SW TLB bits in the linux pte(add back _PAGE_WRITETHRU ?)
- Less instructions in I/D TLB Miss.
- Prepared for HWEXEC support.
- Prepared kernel RO/user NA support.
Cons:
- None ?
---
arch/powerpc/include/asm/pte-8xx.h | 13 ++---
arch/powerpc/kernel/head_8xx.S | 93 ++++++++++++++++++------------------
2 files changed, 52 insertions(+), 54 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index 8c6e312..f23cd15 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -32,22 +32,21 @@
#define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
+#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These five software bits must be masked out when the entry is loaded
- * into the TLB.
+/* These 3 software bits must be masked out when the entry is loaded
+ * into the TLB, 2 SW bits left.
*/
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
-#define _PAGE_DIRTY 0x0020 /* software: page changed */
-#define _PAGE_RW 0x0040 /* software: user write access allowed */
-#define _PAGE_ACCESSED 0x0080 /* software: page referenced */
+#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
* are always zero.
*/
-#define _PAGE_HWWRITE 0x0100 /* h/w write enable: never set in Linux PTE */
-#define _PAGE_USER 0x0800 /* One of the PP bits, the other is USER&~RW */
+#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
+#define _PAGE_USER 0x0800 /* msb PP bits */
#define _PMD_PRESENT 0x0001
#define _PMD_BAD 0x0ff0
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 118bb05..1639d16 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -333,26 +333,21 @@ InstructionTLBMiss:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
-4:
-#else
- ori r10, r10, _PAGE_ACCESSED
- stw r10, 0(r11)
-#endif
+ /* r10=(r10&~_PAGE_PRESENT)|((r10&_PAGE_ACCESSED)>>5) */
+ rlwimi. r10, r10, 27, 31, 31
+ beq- cr0, 2f /* Can be removed, costs a ITLB Err */
+#if 0 /* Dont' bother with PP lsb, bit 21 for now */
+ /* r10 = (r10 & ~0x0400) | ((r10 & _PAGE_EXEC) << 7) */
+ rlwimi r10, r10, 7, 21, 21 /* Set _PAGE_EXEC << 7 */
+#endif
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
*/
-2: li r11, 0x00f0
+ li r11, 0x00f0
rlwimi r10, r11, 0, 24, 28 /* Set 24-27, clear 28 */
DO_8xx_CPU6(0x2d80, r3)
mtspr SPRN_MI_RPN, r10 /* Update TLB entry */
@@ -365,6 +360,22 @@ InstructionTLBMiss:
lwz r3, 8(r0)
#endif
rfi
+2:
+ mfspr r11, SRR1
+ /* clear all error bits as TLB Miss
+ * sets a few unconditionally
+ */
+ rlwinm r11, r11, 0, 0xffff
+ mtspr SRR1, r11
+
+ mfspr r10, SPRN_M_TW /* Restore registers */
+ lwz r11, 0(r0)
+ mtcr r11
+ lwz r11, 4(r0)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0)
+#endif
+ b InstructionAccess
. = 0x1200
DataStoreTLBMiss:
@@ -409,21 +420,22 @@ DataStoreTLBMiss:
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
-#ifdef CONFIG_SWAP
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
- /* and update pte in table */
-#else
- ori r10, r10, _PAGE_ACCESSED
+ /* Need to know if load/store -> force a TLB Error
+ * by copying ACCESSED to PRESENT.
+ */
+ /* r10=(r10&~_PAGE_PRESENT)|((r10&_PAGE_ACCESSED)>>5) */
+ rlwimi r10, r10, 27, 31, 31
+
+#if 0 /* Not yet */
+ /* Honour kernel RO, User NA */
+ andi. r11, r10, _PAGE_USER | _PAGE_RW
+ bne- cr0, 5f
+ ori r10,r10, 0x200 /* Extended encoding, bit 22 */
#endif
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
+5: xori r10, r10, _PAGE_RW /* invert RW bit */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
@@ -469,11 +481,12 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
- /* First, make sure this was a store operation.
- */
- mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x4800 /* no translation, no permission. */
+ mfspr r11, SPRN_DSISR
+ andis. r11, r11, 0x4800 /* !translation or protection */
bne 2f /* branch if either is set */
+ /* Only Change bit left now, do it here as it is faster
+ * than trapping to the C fault handler.
+ */
/* The EA of a data TLB miss is automatically stored in the MD_EPN
* register. The EA of a data TLB error is automatically stored in
@@ -522,26 +535,12 @@ DataTLBError:
mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
lwz r10, 0(r11) /* Get the pte */
- andi. r11, r10, _PAGE_RW /* Is it writeable? */
- beq 2f /* Bail out if not */
-
- /* Update 'changed', among others.
- */
-#ifdef CONFIG_SWAP
- ori r10, r10, _PAGE_DIRTY|_PAGE_HWWRITE
- /* do not set the _PAGE_ACCESSED bit of a non-present page */
- andi. r11, r10, _PAGE_PRESENT
- beq 4f
- ori r10, r10, _PAGE_ACCESSED
-4:
-#else
- ori r10, r10, _PAGE_DIRTY|_PAGE_ACCESSED|_PAGE_HWWRITE
-#endif
- mfspr r11, SPRN_MD_TWC /* Get pte address again */
+ ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
+ xori r10, r10, _PAGE_RW /* RW bit is inverted */
/* The Linux PTE won't go exactly into the MMU TLB.
- * Software indicator bits 21, 22 and 28 must be clear.
+ * Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
* set. All other Linux PTE bits control the behavior
* of the MMU.
--
1.6.4.4
^ permalink raw reply related
* [PATCH 5/6] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-5-git-send-email-Joakim.Tjernlund@transmode.se>
This is an assembler version to fixup DAR not being set
by dcbX, icbi instructions. There are two versions, one
uses selfmodifing code, the other uses a
jump table but is much bigger(default).
---
arch/powerpc/kernel/head_8xx.S | 146 +++++++++++++++++++++++++++++++++++++++-
1 files changed, 145 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 9707dc4..6541855 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -490,7 +490,8 @@ DataTLBError:
mfspr r10, SPRN_DAR
cmpwi cr0, r10, 0x00f0
- beq- 2f /* must be a buggy dcbX, icbi insn. */
+ beq- FixDAR /* must be a buggy dcbX, icbi insn. */
+DARFix: /* Return from dcbx instruction bug workaround, r10 holds value of DAR */
mfspr r11, SPRN_DSISR
andis. r11, r11, 0x4800 /* !translation or protection */
@@ -600,6 +601,149 @@ DataTLBError:
. = 0x2000
+/* This is the procedure to calculate the data EA for buggy dcbx,dcbi instructions
+ * by decoding the registers used by the dcbx instruction and adding them.
+ * DAR is set to the calculated address and r10 also holds the EA on exit.
+ */
+#define NO_SELF_MODIFYING_CODE /* define if you don't want to use self modifying code */
+ nop /* A few nops to make the modified_instr: space below cache line aligned */
+ nop
+139: /* fetch instruction from userspace memory */
+ DO_8xx_CPU6(0x3780, r3)
+ mtspr SPRN_MD_EPN, r10
+ mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
+ lwz r11, 0(r11) /* Get the level 1 entry */
+ tophys (r11, r11)
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r11, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r11, 0(r11) /* Get the pte */
+ /* concat physical page address(r11) and page offset(r10) */
+ rlwimi r11, r10, 0, 20, 31
+ b 140f
+FixDAR: /* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10, SPRN_SRR0
+ andis. r11, r10, 0x8000
+ tophys (r11, r10)
+ beq- 139b /* Branch if user space address */
+140: lwz r11,0(r11)
+#ifdef CONFIG_8xx_CPU6
+ lwz r3, 8(r0) /* restore r3 from memory */
+#endif
+#ifndef NO_SELF_MODIFYING_CODE
+ andis. r10,r11,0x1f /* test if reg RA is r0 */
+ li r10,modified_instr@l
+ dcbtst r0,r10 /* touch for store */
+ rlwinm r11,r11,0,0,20 /* Zero lower 10 bits */
+ oris r11,r11,640 /* Transform instr. to a "add r10,RA,RB" */
+ ori r11,r11,532
+ stw r11,0(r10) /* store add/and instruction */
+ dcbf 0,r10 /* flush new instr. to memory. */
+ icbi 0,r10 /* invalidate instr. cache line */
+ lwz r11, 4(r0) /* restore r11 from memory */
+ mfspr r10, SPRN_M_TW /* restore r10 from M_TW */
+ isync /* Wait until new instr is loaded from memory */
+modified_instr:
+ .space 4 /* this is where the add/and instr. is stored */
+ bne+ 143f
+ subf r10,r0,r10 /* r10=r10-r0, only if reg RA is r0 */
+143: mtdar r10 /* store faulting EA in DAR */
+ b DARFix /* Go back to normal TLB handling */
+#else
+ mfctr r10
+ mtdar r10 /* save ctr reg in DAR */
+ rlwinm r10, r11, 24, 24, 28 /* offset into jump table for reg RB */
+ addi r10, r10, 150f@l /* add start of table */
+ mtctr r10 /* load ctr with jump address */
+ xor r10, r10, r10 /* sum starts at zero */
+ bctr /* jump into table */
+150:
+ add r10, r10, r0
+ b 151f
+ add r10, r10, r1
+ b 151f
+ add r10, r10, r2
+ b 151f
+ add r10, r10, r3
+ b 151f
+ add r10, r10, r4
+ b 151f
+ add r10, r10, r5
+ b 151f
+ add r10, r10, r6
+ b 151f
+ add r10, r10, r7
+ b 151f
+ add r10, r10, r8
+ b 151f
+ add r10, r10, r9
+ b 151f
+ add r10, r10, r10
+ b 151f
+ add r10, r10, r11
+ b 151f
+ add r10, r10, r12
+ b 151f
+ add r10, r10, r13
+ b 151f
+ add r10, r10, r14
+ b 151f
+ add r10, r10, r15
+ b 151f
+ add r10, r10, r16
+ b 151f
+ add r10, r10, r17
+ b 151f
+ add r10, r10, r18
+ b 151f
+ add r10, r10, r19
+ b 151f
+ mtctr r11 /* r10 needs special handling */
+ b 154f
+ mtctr r11 /* r11 needs special handling */
+ b 153f
+ add r10, r10, r22
+ b 151f
+ add r10, r10, r23
+ b 151f
+ add r10, r10, r24
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r25
+ b 151f
+ add r10, r10, r27
+ b 151f
+ add r10, r10, r28
+ b 151f
+ add r10, r10, r29
+ b 151f
+ add r10, r10, r30
+ b 151f
+ add r10, r10, r31
+151:
+ rlwinm. r11,r11,19,24,28 /* offset into jump table for reg RA */
+ beq 152f /* if reg RA is zero, don't add it */
+ addi r11, r11, 150b@l /* add start of table */
+ mtctr r11 /* load ctr with jump address */
+ rlwinm r11,r11,0,16,10 /* make sure we don't execute this more than once */
+ bctr /* jump into table */
+152:
+ mfdar r11
+ mtctr r11 /* restore ctr reg from DAR */
+ mtdar r10 /* save fault EA to DAR */
+ b DARFix /* Go back to normal TLB handling */
+
+ /* special handling for r10,r11 since these are modified already */
+153: lwz r11, 4(r0) /* load r11 from memory */
+ b 155f
+154: mfspr r11, SPRN_M_TW /* load r10 from M_TW */
+155: add r10, r10, r11 /* add it */
+ mfctr r11 /* restore r11 */
+ b 151b
+#endif
+
.globl giveup_fpu
giveup_fpu:
blr
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/6] 8xx: invalidate non present TLBs
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-3-git-send-email-Joakim.Tjernlund@transmode.se>
8xx sometimes need to load a invalid/non-present TLBs in
it DTLB asm handler.
These must be invalidated separaly as linux mm don't.
---
arch/powerpc/mm/fault.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 7699394..72941c7 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -39,7 +39,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)
@@ -243,6 +243,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);
+
/* The MPC8xx seems to always set 0x80000000, which is
* "undefined". Of those that can be set, this is the only
* one which seems bad.
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/6] 8xx: DTLB Error must check for more errors.
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
In-Reply-To: <1255008298-19949-1-git-send-email-Joakim.Tjernlund@transmode.se>
DataTLBError currently does:
if ((err & 0x02000000) == 0)
DSI();
This won't handle a store with no valid translation.
Change this to
if ((err & 0x48000000) != 0)
DSI();
that is, branch to DSI if either !permission or
!translation.
---
arch/powerpc/kernel/head_8xx.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 52ff8c5..118bb05 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -472,8 +472,8 @@ DataTLBError:
/* First, make sure this was a store operation.
*/
mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x0200 /* If set, indicates store op */
- beq 2f
+ andis. r11, r10, 0x4800 /* no translation, no permission. */
+ bne 2f /* branch if either is set */
/* The EA of a data TLB miss is automatically stored in the MD_EPN
* register. The EA of a data TLB error is automatically stored in
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/6] 8xx MMU fixes
From: Joakim Tjernlund @ 2009-10-08 13:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev@ozlabs.org, Rex Feany,
Scott Wood
So here we go again. This time I am
fairly confindent I got most things correct :)
Also manged to use even less instructions in the
TLB Miss handlers.
Scott and Rex, forget previous versions and
try this one out.
Once this works we can discuss further enchantments.
Joakim Tjernlund (6):
8xx: DTLB Error must check for more errors.
8xx: Update TLB asm so it behaves as linux mm expects.
8xx: invalidate non present TLBs
8xx: Tag DAR with 0x00f0 to catch buggy instructions.
8xx: Fixup DAR from buggy dcbX instructions.
8xx: start using dcbX instructions in various copy routines
arch/powerpc/include/asm/pte-8xx.h | 13 +-
arch/powerpc/kernel/head_8xx.S | 252 +++++++++++++++++++++++++++++-------
arch/powerpc/kernel/misc_32.S | 18 ---
arch/powerpc/lib/copy_32.S | 24 ----
arch/powerpc/mm/fault.c | 8 +-
5 files changed, 217 insertions(+), 98 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 00/12] Merge common OpenFirmware device tree code
From: Kjetil Oftedal @ 2009-10-08 13:24 UTC (permalink / raw)
To: David Miller
Cc: sammy, sfr, julian.calaby, devicetree-discuss, sparclinux, crn,
microblaze-uclinux, wmb, linuxppc-dev
In-Reply-To: <20091007.213915.37481688.davem@davemloft.net>
On Wed, 7 Oct 2009, David Miller wrote:
> From: Chris Newport <crn@netunix.com>
> Date: Thu, 8 Oct 2009 02:29:25 +0100 (BST)
>
>> Sun4d has never had SMP support and
>
> Wrong.
>
>> this is apparantly problematic due to Cray interlectual property
>> causing a lack of bus documentation.
>
> XBUS documentation is not available, but we fully know how to
> program the SBUS interrupt controller and whatnot. It's all
> there in the sun4d interrupt and SMP support and it did work
> just fine at one point.
>
> Amusingly the SBUS interrupt stuff on sun4d is a very close
> sibling to the IMAP/ICLR scheme used on sun4u.
>
The Sun4d SMP support exists, but is broken in 2.6.
And the UP support is buggy. At least on my test-setup, the
kernel is unable to load userland from scsi-drives.
Dropping the sun4 32-bit SPARC is a bit counterproductive when
considering the resent effort to unify sparc64 and sparc
arch-branches ?
^ 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