* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Scott Wood @ 2009-11-03 16:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <OFD5642C2D.808C2FF1-ONC1257663.004A341C-C1257663.004A6C26@transmode.se>
Joakim Tjernlund wrote:
>> and things seem to work. You could probably replace the rlwinm by
>> subtracting PAGE_OFFSET from swapper_pg_dir instead.
>
> Just guessing here, do you mean:
> lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
> ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
> rlwimi r11, r10, 22, 0xffc
> or
> lis r11, swapper_pg_dir@h
> ori r11, r11, swapper_pg_dir@l
> subis r11, r11 PAGE_OFFSET
> rlwimi r11, r10, 22, 0xffc
The former.
-Scott
^ permalink raw reply
* Re: [PATCH 0/8] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-11-03 17:16 UTC (permalink / raw)
To: Scott Wood; +Cc: Rex Feany, linuxppc-dev@ozlabs.org
In-Reply-To: <4AF06172.6060407@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 03/11/2009 17:59:30:
>
> Joakim Tjernlund wrote:
> >> and things seem to work. You could probably replace the rlwinm by
> >> subtracting PAGE_OFFSET from swapper_pg_dir instead.
> >
> > Just guessing here, do you mean:
> > lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
> > ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
> > rlwimi r11, r10, 22, 0xffc
> > or
> > lis r11, swapper_pg_dir@h
> > ori r11, r11, swapper_pg_dir@l
> > subis r11, r11 PAGE_OFFSET
> > rlwimi r11, r10, 22, 0xffc
>
> The former.
OK, I will regenerate the patch series with the
lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
rlwimi r11, r10, 22, 0xffc
fix.
Have you already confirmed that this works too?
Jocke
^ permalink raw reply
* Fwd: [PATCH] arch/powerpc: Improve _memcpy
From: Chris Friesen @ 2009-11-03 19:30 UTC (permalink / raw)
To: Linux kernel, linuxppc-dev list, Dirk Eibach
Forwarding to the ppc mailing list.
Chris
-------- Original Message --------
Subject: [PATCH] arch/powerpc: Improve _memcpy
Date: Tue, 3 Nov 2009 15:20:56 +0100
From: Dirk Eibach <eibach@gdsys.de>
To: linux-kernel@vger.kernel.org
CC: Dirk Eibach <eibach@gdsys.de>
The implementation of _memcpy_fromio and _memcpy_toio seems to be
suboptimal for size 4.
Signed-off-by: Dirk Eibach <eibach@gdsys.de>
---
arch/powerpc/kernel/io.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/io.c b/arch/powerpc/kernel/io.c
index 1882bf4..8dc7547 100644
--- a/arch/powerpc/kernel/io.c
+++ b/arch/powerpc/kernel/io.c
@@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const volatile void
__iomem *src,
dest++;
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
vsrc += 4;
@@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem *dest, const
void *src, unsigned long n)
vdest++;
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
vdest += 4;
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 14/27] Add book3s_64 specific opcode emulation
From: Benjamin Herrenschmidt @ 2009-11-03 21:38 UTC (permalink / raw)
To: Alexander Graf
Cc: Kevin Wolf, Arnd Bergmann, Hollis Blanchard, Marcelo Tosatti,
kvm-ppc, linuxppc-dev, Avi Kivity, kvm, bphilips, Olof Johansson
In-Reply-To: <280C9FF6-1C52-4856-9F60-15DA0659FC31@suse.de>
On Tue, 2009-11-03 at 10:06 +0100, Alexander Graf wrote:
> > DCBZ zeroes out a cache line, not 32 bytes; except on 970, where there
> > are HID bits to make it work on 32 bytes only, and an extra DCBZL insn
> > that always clears a full cache line (128 bytes).
>
> Yes. We only come here when we patched the dcbz opcodes to invalid
> instructions because cache line size of target == 32.
> On 970 with MSR_HV = 0 we actually use the dcbz 32-bytes mode.
>
> Admittedly though, this could be a lot more clever.
Yeah well, we also really need to fix ppc32 Linux to use the device-tree
provided cache line size :-) For 64-bits, that should already be the
case, and thus the emulation trick shouldn't be useful as long as you
properly provide the guest with the right size in the device-tree.
(Though glibc can be nasty, afaik it might load up optimized variants of
some routines with hard wired cache line sizes based on the CPU type)
> >> + switch (sprn) {
> >> + case SPRN_IBAT0U ... SPRN_IBAT3L:
> >> + bat = &vcpu_book3s->ibat[(sprn - SPRN_IBAT0U) / 2];
> >> + break;
> >> + case SPRN_IBAT4U ... SPRN_IBAT7L:
> >> + bat = &vcpu_book3s->ibat[(sprn - SPRN_IBAT4U) / 2];
> >> + break;
> >> + case SPRN_DBAT0U ... SPRN_DBAT3L:
> >> + bat = &vcpu_book3s->dbat[(sprn - SPRN_DBAT0U) / 2];
> >> + break;
> >> + case SPRN_DBAT4U ... SPRN_DBAT7L:
> >> + bat = &vcpu_book3s->dbat[(sprn - SPRN_DBAT4U) / 2];
> >> + break;
> >
> > Do xBAT4..7 have the same SPR numbers on all CPUs? They are CPU-
> > specific
> > SPRs, after all. Some CPUs have only six, some only four, some
> > none, btw.
>
> For now only Linux runs which only uses the first 3(?) IIRC. But yes,
> it's probably worth looking into at one point or the other.
>
> >
> >> + case SPRN_HID0:
> >> + to_book3s(vcpu)->hid[0] = vcpu->arch.gpr[rs];
> >> + break;
> >> + case SPRN_HID1:
> >> + to_book3s(vcpu)->hid[1] = vcpu->arch.gpr[rs];
> >> + break;
> >> + case SPRN_HID2:
> >> + to_book3s(vcpu)->hid[2] = vcpu->arch.gpr[rs];
> >> + break;
> >> + case SPRN_HID4:
> >> + to_book3s(vcpu)->hid[4] = vcpu->arch.gpr[rs];
> >> + break;
> >> + case SPRN_HID5:
> >> + to_book3s(vcpu)->hid[5] = vcpu->arch.gpr[rs];
> >
> > HIDs are different per CPU; and worse, different CPUs have different
> > registers (SPR #s) for the same register name!
>
> Sigh :-(
On the other hand, you can probably just "Swallow" all of these and
Linux won't even notice, except for the case of the sleep state maybe on
6xx/7xx/7xxx. Just a matter of knowing what your are emulating as guest.
Cheers,
Ben.
^ permalink raw reply
* DMA to User-Space
From: Jonathan Haws @ 2009-11-03 23:37 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
All,
I have what may be an unconventional question:
Our application consists of data being captured by an FPGA, processed, and =
transferred to SDRAM. I simply give the FPGA an address of where I want it=
stored in SDRAM and it simply DMAs the data over and interrupts me when fi=
nished. I then take that data and store it to disk.
I have code in user space that handles all of the writing to disk nicely an=
d fast enough for my application (I am capturing data at about 35-40 Mbytes=
/sec).
My question is this: is it possible to give a user-space pointer to the FP=
GA to DMA to? It seems like I would have problems with alignment, address =
manipulation, and a whole slew of other issues.
What would be the best way to accomplish something like that? I want to ha=
ndle all the disk access in user-space, but I do not want to have to copy 4=
0 MB/s from kernel space to user-space either.
I can maintain an allocated, DMA-safe buffer in kernel space if needed. Ca=
n I simply get a user-space pointer to that buffer? What calls are needed =
to translate addresses?
Thanks for the help! I am still a newbie when it comes to kernel programmi=
ng, so I really appreciate the help!
Jonathan
^ permalink raw reply
* Re: Filtering bits in set_pte_at()
From: David Gibson @ 2009-11-04 3:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-mm@kvack.org, Hugh Dickins, linuxppc-dev,
linux-kernel@vger.kernel.org
In-Reply-To: <1257200367.7907.50.camel@pasglop>
On Tue, Nov 03, 2009 at 09:19:27AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2009-11-02 at 13:27 +0000, Hugh Dickins wrote:
> > On Sat, 31 Oct 2009, Benjamin Herrenschmidt wrote:
> >
> > > Hi folks !
> > >
> > > So I have a little problem on powerpc ... :-)
> >
> > Thanks a lot for running this by us.
>
> Heh, I though you may have been bored :-)
>
> > I've not looked to see if there are more such issues in arch/powerpc
> > itself, but those instances you mention are the only ones I managed
> > to find: uses of update_mmu_cache() and that hugetlb_cow() one.
>
> Right, that's all I spotted so far
>
> > The hugetlb_cow() one involves not set_pte_at() but set_huge_pte_at(),
> > so you'd want to change that too? And presumably set_pte_at_notify()?
> > It all seems a lot of tedium, when so very few places are interested
> > in the pte after they've set it.
>
> We need to change set_huge_pte_at() too. Currently, David fixed the
> problem in a local tree by making hugetlb_cow() re-read the PTE .
Well, actually I have another cleanup patch in the queue which makes
set_huge_pte_at() equal to set_pte_at() on powerpc, and I was using
that on the tree where this problem became apparent.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: DMA to User-Space
From: Tonyliu @ 2009-11-04 2:19 UTC (permalink / raw)
To: Jonathan Haws; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BB99A6BA28709744BF22A68E6D7EB51F0330F9DC29@midas.usurf.usu.edu>
Jonathan Haws wrote:
> All,
>
> I have what may be an unconventional question:
>
> Our application consists of data being captured by an FPGA, processed, and transferred to SDRAM. I simply give the FPGA an address of where I want it stored in SDRAM and it simply DMAs the data over and interrupts me when finished. I then take that data and store it to disk.
>
> I have code in user space that handles all of the writing to disk nicely and fast enough for my application (I am capturing data at about 35-40 Mbytes/sec).
>
> My question is this: is it possible to give a user-space pointer to the FPGA to DMA to? It seems like I would have problems with alignment, address manipulation, and a whole slew of other issues.
>
> What would be the best way to accomplish something like that? I want to handle all the disk access in user-space, but I do not want to have to copy 40 MB/s from kernel space to user-space either.
>
You can maintain a DMA buffer in kernel, then mmap to user space. And
maybe you need some handshake between FPGA and the apps to balance input
datas with datas to disk.
> I can maintain an allocated, DMA-safe buffer in kernel space if needed. Can I simply get a user-space pointer to that buffer? What calls are needed to translate addresses?
>
Use remap_pfn_range() in your kernel DMA buffer manipulation driver
.mmap() handler to export DMA buffer address to user space.
Tony
> Thanks for the help! I am still a newbie when it comes to kernel programming, so I really appreciate the help!
>
> Jonathan
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
Tony Liu | Liu Bo
-------------------------------------------------------------
WIND RIVER | China Development Center
Tel: 86-10-8477-8542 ext: 8542 | Fax: 86-10-64790367
(M): 86-136-7117-3612
Address: 15/F, Wangjing TowerB, Chaoyang District, Beijing, P.R.China
^ permalink raw reply
* Re: mpc8548 does not make use of DMA when doing memory copy?
From: Kumar Gala @ 2009-11-04 6:25 UTC (permalink / raw)
To: hank peng; +Cc: linuxppc-dev
In-Reply-To: <389deec70911030638g4a90dae7hd5a164e3d2bd178f@mail.gmail.com>
On Nov 3, 2009, at 8:38 AM, hank peng wrote:
> 2009/11/3 Micha Nelissen <micha@neli.hopto.org>:
>> hank peng wrote:
>>>
>>> I remember normal memory copy can also be done (chosen by user) by
>>> DMA
>>> engine on IOP80331(Intel embedded cpu, xscale arch), so why ppc
>>> platform didn't make use of DMA doing memory copy, I think it can
>>> increase performance, please correct me if I am wrong!
>>
>> AFAIK the DMA engine has only an asynchronous mode (not very smart
>> IMHO).
>> This means you always have the overhead of context switch +
>> interrupt +
>> context switch, so the transfer has to be quite large for this to
>> pay off.
>>
> but if the amount of data I want to copy is big enough? can we benefit
> from using DMA in such case?
Correct, we just don't make normal memcpy do this. There isn't
anything stopping specific call from using the async DMA API to get
memcpy behavior.
- k
^ permalink raw reply
* [PATCH] mmc: fix missing module license declaration in of_mmc_spi.c
From: Grant Likely @ 2009-11-04 6:34 UTC (permalink / raw)
To: Pierre Ossman, Anton Vorontsov, linuxppc-dev, linux-kernel
Driver cannot be used as a module without this patch.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/mmc/host/of_mmc_spi.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index fb2921f..644f67e 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -22,6 +22,8 @@
#include <linux/mmc/core.h>
#include <linux/mmc/host.h>
+MODULE_LICENSE("GPL");
+
enum {
CD_GPIO = 0,
WP_GPIO,
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 14/27] Add book3s_64 specific opcode emulation
From: Arnd Bergmann @ 2009-11-04 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Kevin Wolf, Hollis Blanchard, Marcelo Tosatti, Alexander Graf,
kvm-ppc, linuxppc-dev, Avi Kivity, kvm, bphilips, Olof Johansson
In-Reply-To: <1257284313.7907.80.camel@pasglop>
On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote:
> (Though glibc can be nasty, afaik it might load up optimized variants of
> some routines with hard wired cache line sizes based on the CPU type)
You can also get application with hand-coded cache optimizations
that are even harder, if not impossible, to fix.
Arnd <><
^ permalink raw reply
* Re: [PATCH 14/27] Add book3s_64 specific opcode emulation
From: Benjamin Herrenschmidt @ 2009-11-04 8:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Kevin Wolf, Hollis Blanchard, Marcelo Tosatti, Alexander Graf,
kvm-ppc, linuxppc-dev, Avi Kivity, kvm, bphilips, Olof Johansson
In-Reply-To: <200911040943.46617.arnd@arndb.de>
On Wed, 2009-11-04 at 09:43 +0100, Arnd Bergmann wrote:
> On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote:
> > (Though glibc can be nasty, afaik it might load up optimized
> variants of
> > some routines with hard wired cache line sizes based on the CPU
> type)
>
> You can also get application with hand-coded cache optimizations
> that are even harder, if not impossible, to fix.
Right. But those are already broken across CPU variants anyways.
Cheers,
Ben
^ permalink raw reply
* [PATCH] spi/mpc52xx: replace printk with dev_err
From: Wolfram Sang @ 2009-11-04 9:49 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40910311803m43504167s1ad802aecd2b4344@mail.gmail.com>
To easily identify which device has problems.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
drivers/spi/mpc52xx_psc_spi.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index e268437..6fb6b3b 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -471,7 +471,7 @@ static int __init mpc52xx_psc_spi_of_probe(struct of_device *op,
regaddr_p = of_get_address(op->node, 0, &size64, NULL);
if (!regaddr_p) {
- printk(KERN_ERR "Invalid PSC address\n");
+ dev_err(&op->dev, "Invalid PSC address\n");
return -EINVAL;
}
regaddr64 = of_translate_address(op->node, regaddr_p);
@@ -482,8 +482,7 @@ static int __init mpc52xx_psc_spi_of_probe(struct of_device *op,
psc_nump = of_get_property(op->node, "cell-index", NULL);
if (!psc_nump || *psc_nump > 5) {
- printk(KERN_ERR "mpc52xx_psc_spi: Device node %s has invalid "
- "cell-index property\n", op->node->full_name);
+ dev_err(&op->dev, "Invalid cell-index property\n");
return -EINVAL;
}
id = *psc_nump + 1;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 14/27] Add book3s_64 specific opcode emulation
From: Alexander Graf @ 2009-11-04 11:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Kevin Wolf, Hollis Blanchard, Marcelo Tosatti, kvm-ppc,
linuxppc-dev, Arnd Bergmann, Avi Kivity, kvm, bphilips,
Olof Johansson
In-Reply-To: <1257324441.13611.55.camel@pasglop>
On 04.11.2009, at 09:47, Benjamin Herrenschmidt wrote:
> On Wed, 2009-11-04 at 09:43 +0100, Arnd Bergmann wrote:
>> On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote:
>>> (Though glibc can be nasty, afaik it might load up optimized
>> variants of
>>> some routines with hard wired cache line sizes based on the CPU
>> type)
>>
>> You can also get application with hand-coded cache optimizations
>> that are even harder, if not impossible, to fix.
>
> Right. But those are already broken across CPU variants anyways.
... which might be the reason you're using KVM in the first place.
Alex
^ permalink raw reply
* Re: [powerpc] Next tree Nov 2 : kernel BUG at mm/mmap.c:2135!
From: Sachin Sant @ 2009-11-04 12:38 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Stephen Rothwell, dwg, linux-next
In-Reply-To: <4AEEA279.4040106@in.ibm.com>
Sachin Sant wrote:
> Today's next tree failed to boot on a POWER 6 box with :
>
> ------------[ cut here ]------------
> kernel BUG at mm/mmap.c:2135!
> Oops: Exception in kernel mode, sig: 5 [#2]
> SMP NR_CPUS=1024 NUMA pSeries
Problem exists with today's next as well.
Likely cause for this problem seems to the following commit.
If i revert this patch the machine boots fine.
commit a0668cdc154e54bf0c85182e0535eea237d53146
powerpc/mm: Cleanup management of kmem_caches for pagetables
Thanks
-Sachin
> Modules linked in: ibmvscsic scsi_transport_srp scsi_tgt scsi_mod
> NIP: c00000000014e30c LR: c00000000014e2f8 CTR: c00000000014db88
> REGS: c0000000db703620 TRAP: 0700 Tainted: G D
> (2.6.32-rc5-autotest-next-20091102)
> MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 24022442 XER: 2000000c
> TASK = c0000000db7f6fe0[76] 'init' THREAD: c0000000db700000 CPU: 1
> GPR00: 0000000000000001 c0000000db7038a0 c000000000b19900
> 0000000000000000
> GPR04: c0000000db406a40 000000000000000c c0000000fe10c370
> c000000000bb2800
> GPR08: 000000000000db40 0000000000000000 c0000000dfdc0e00
> 000000000000000c
> GPR12: 0000000044022442 c000000000bb2800 00000000ffffffff
> ffffffffffffffff
> GPR16: 0000000008430000 00000000003c0000 c0000000db703ea0
> c0000000db569108
> GPR20: c0000000db568908 0000000000000000 c0000000db703d60
> 0000000000000000
> GPR24: 0000000000000001 0000000000040100 c0000000fe503580
> c0000000db1ac180
> GPR28: 0000000000000000 c000000000f812d0 c000000000a84f00
> 0000000000000000
> NIP [c00000000014e30c] .exit_mmap+0x190/0x1b8
> LR [c00000000014e2f8] .exit_mmap+0x17c/0x1b8
> Call Trace:
> [c0000000db7038a0] [c00000000014e2f8] .exit_mmap+0x17c/0x1b8 (unreliable)
> [c0000000db703950] [c0000000000916cc] .mmput+0x54/0x164
> [c0000000db7039e0] [c0000000000968d8] .exit_mm+0x17c/0x1a0
> [c0000000db703a90] [c000000000098cb8] .do_exit+0x248/0x784
> [c0000000db703b70] [c0000000000992a8] .do_group_exit+0xb4/0xe8
> [c0000000db703c00] [c0000000000aca2c] .get_signal_to_deliver+0x3ec/0x478
> [c0000000db703cf0] [c0000000000134ac] .do_signal+0x6c/0x31c
> [c0000000db703e30] [c000000000008b7c] do_work+0x24/0x28
> Instruction dump:
> 7c8407b4 387d0018 4800ab11 60000000 939d0008 7fe3fb78 4bfffdbd 7c7f1b79
> 4082fff4 e81b00e8 3120ffff 7c090110 <0b000000> 382100b0 e8010010 eb61ffd8
> ---[ end trace ec052ac77a8e7cb4 ]---
> Fixing recursive fault but reboot is needed!
>
> mm/mmap.c:2135 corresponds to :
>
> BUG_ON(mm->nr_ptes > (FIRST_USER_ADDRESS+PMD_SIZE-1)>>PMD_SHIFT);
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Regarding FPGA based cascaded PIC
From: Thirumalai @ 2009-11-04 12:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1257315924.13611.54.camel@pasglop>
----- Original Message -----
From: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
To: "Thirumalai" <thirumalai.p@datapatterns.co.in>
Cc: <scottwood@freescale.com>
Sent: Wednesday, November 04, 2009 11:55 AM
Subject: Re: Regarding FPGA based cascaded PIC
> On Wed, 2009-11-04 at 10:48 +0530, Thirumalai wrote:
>> Hi Ben,
>> I am a having MPC8640D based board on which i am in the process
>> of
>> writing cascaded interrupt handler for my FPGA based PIC. I need some
>> clarification on writing customized cascaded interrupt handler. As for as
>> my
>> understanding we need to use irq_alloc_host() function for allocating
>> the
>> irq_host for my FPGA pic and we should use irq_of_parse_and_map()
>> function
>> for parsing and assignment of virtual IRQ from my device tree. In my case
>> my
>> FPGA based PIC is giving interrupts to 3 external interrupt of MPC8640D
>> i.e
>> 1,2,3 . So i have written my fpga-pic node as follows on my device tree.
>
> Please post to the mailing list linuxppc-dev@lists.ozlabs.org for such
> questions.
>
>> fpga-pic@dc000000 {
>> compatible = "dp,fpga-pic";
>> reg = <0xdc000000 0x7fff>;
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> interrupts = <1 1 2 1 3 1>;
>> interrupt-parent = <&mpic>;
>> };
>
> 3 cells per interrupt ? that's a lot :-) What do you put in there ?
>
>> mpic: pic@40000 {
>> clock-frequency = <0>;
>> interrupt-controller;
>> #address-cells = <0>;
>> #interrupt-cells = <2>;
>> reg = <0x40000 0x40000>;
>> compatible = "chrp,open-pic";
>> device_type = "open-pic";
>> big-endian;
>> };
>
> So far it looks reasonable...
>
>> The function irq_of_parse_and_map is returning VIRQ as 16,17,18
>> successfully. i hooked my chained interrupt handler for this VIRQ using
>> set_irq_chained_handler function. On my user defined interrupt handler
>> when
>> i am searching the vector need to be returned i am getting 0 as vector.
>> ie
>> using the function irq_linear_revmap.
>>
>> So here my doubt:
>> ============
>> Even irq_alloc_host has returned a irq_host for my pic, Why my custom map
>> funtion is not called during irq_of_parse_and_map function. Instead of my
>> map/xlate function it is calling mpic's map/xlate function?
>
> That's where I don't follow you...
>
> So interrupts 1,2,3 in your example are outputs of the FPGA PIC
> connected to inputs 1,2,3 of the MPIC. Those get mapped to virq 16.17
> and 18. Those are really MPIC interrupts.
>
> At some stage some interrupts -below- your FPGA PIC (whatever devices
> you have on the FPGA) are going to fire. it's -those- interrupts that
> will use map/xlate from the FPGA host when irq_of_parse_and_map() is
> called for them
>
you understood correctly. Here the problem lies.Correct me if i am wrong. So
you are telling that irq_of_parse_and_map() will invoke the map/xlate of my
FPGA pic. Right.
But this is what not happening. Instead of calling my map/xlate functions
the irq_of_parse_and_map() function is invoking mpic's map/xlate function.
Here is the piece of code that we are using.
fpga_pic_irq_host = irq_alloc_host(pic, IRQ_HOST_MAP_LINEAR,
DPVPX0659_FPGA_NUM_IRQS,&fpga_pic_host_ops,
NO_IRQ);
if (fpga_pic_irq_host == NULL) {
printk("FPGA PIC: Unable to allocate host\n");
return;
}
for (i = 0; i < 3; i++) {
fpga_irqs[i] = irq_of_parse_and_map(pic, i);
if (fpga_irqs[i] == NO_IRQ) {
printk("FPGA PIC: can't get irq %d.\n", i);
continue;
}
printk("interrupt from device tree : %d \n",fpga_irqs[i]);
set_irq_chained_handler(dpvpx0659_fpga_irqs[i],dpvpx0659_fpga_pic_cascade);
}
> IE. When -those- fire, the FPGA emits one of the 3 interrupts, and your
> cascade handler gets called. It will then fetch off the FPGA PIC what
> interrupts happened and revmap that.
>
> Cheers,
> Ben.
>
>> Kindly reply me soon.
>> Regards
>> Thirumalai
>>
>>
Thank you
Thirumalai
**************** CAUTION - Disclaimer *****************This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
*********** End of Disclaimer ***********DataPatterns ITS Group**********
^ permalink raw reply
* [PATCH 5/8] 8xx: Add missing Guarded setting in DTLB Error.
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-5-git-send-email-Joakim.Tjernlund@transmode.se>
only DTLB Miss did set this bit, DTLB Error needs too otherwise
the setting is lost when the page becomes dirty.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 1d8e4e3..18e9901 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -552,9 +552,16 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
*/
ori r11, r11, 1 /* Set valid bit in physical L2 page */
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 r10, 0(r11) /* Get the pte */
+ mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
+ mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
+ lwz r10, 0(r10) /* Get the pte */
+ /* Insert the Guarded flag into the TWC from the Linux PTE.
+ * It is bit 27 of both the Linux PTE and the TWC
+ */
+ rlwimi r11, r10, 0, 27, 27
+ DO_8xx_CPU6(0x3b80, r3)
+ mtspr SPRN_MD_TWC, r11
+ mfspr r11, SPRN_MD_TWC /* get the pte address again */
ori r10, r10, _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_HWWRITE
stw r10, 0(r11) /* and update pte in table */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 0/8] 8xx: Misc fixes for buggy insn
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
Here is the latest(last?) round of this series. I
hope I got everything right now.
Scott and Rex, please test and send ACK/NACK.
Jocke
Joakim Tjernlund (8):
8xx: invalidate non present TLBs
8xx: Update TLB asm so it behaves as linux mm expects.
8xx: Tag DAR with 0x00f0 to catch buggy instructions.
8xx: Fixup DAR from buggy dcbX instructions.
8xx: Add missing Guarded setting in DTLB Error.
8xx: Restore _PAGE_WRITETHRU
8xx: start using dcbX instructions in various copy routines
8xx: Remove DIRTY pte handling in DTLB Error.
arch/powerpc/include/asm/pte-8xx.h | 14 +-
arch/powerpc/kernel/head_8xx.S | 308 ++++++++++++++++++++++--------------
arch/powerpc/kernel/misc_32.S | 18 --
arch/powerpc/lib/copy_32.S | 24 ---
arch/powerpc/mm/fault.c | 8 +-
5 files changed, 205 insertions(+), 167 deletions(-)
^ permalink raw reply
* [PATCH 1/8] 8xx: invalidate non present TLBs
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-1-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.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
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 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.
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/8] 8xx: Update TLB asm so it behaves as linux mm expects.
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-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 ?)
- kernel RO/user NA support.
Cons:
- A few more instructions in the TLB Miss routines.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/include/asm/pte-8xx.h | 13 ++---
arch/powerpc/kernel/head_8xx.S | 99 ++++++++++++++++++-----------------
2 files changed, 57 insertions(+), 55 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index dd5ea95..68ba861 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -33,21 +33,20 @@
#define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
#define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
+#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_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 6ded19d..97bd523 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -333,26 +333,20 @@ 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
+ andi. r11, r10, _PAGE_ACCESSED | _PAGE_PRESENT
+ cmpwi cr0, r11, _PAGE_ACCESSED | _PAGE_PRESENT
+ bne- cr0, 2f
+
+ /* Clear PP lsb, 0x400 */
+ rlwinm r10, r10, 0, 22, 20
/* 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 +359,22 @@ InstructionTLBMiss:
lwz r3, 8(r0)
#endif
rfi
+2:
+ mfspr r11, SPRN_SRR1
+ /* clear all error bits as TLB Miss
+ * sets a few unconditionally
+ */
+ rlwinm r11, r11, 0, 0xffff
+ mtspr SPRN_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 +419,27 @@ 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
-#endif
- mfspr r11, SPRN_MD_TWC /* get the pte address again */
- stw r10, 0(r11)
+ /* Both _PAGE_ACCESSED and _PAGE_PRESENT has to be set.
+ * We also need to know if the insn is a load/store, so:
+ * Clear _PAGE_PRESENT and load that which will
+ * trap into DTLB Error with store bit set accordinly.
+ */
+ /* PRESENT=0x1, ACCESSED=0x20
+ * r11 = ((r10 & PRESENT) & ((r10 & ACCESSED) >> 5));
+ * r10 = (r10 & ~PRESENT) | r11;
+ */
+ rlwinm r11, r10, 32-5, 31, 31
+ and r11, r11, r10
+ rlwimi r10, r11, 0, 31, 31
+
+ /* Honour kernel RO, User NA */
+ andi. r11, r10, _PAGE_USER | _PAGE_RW
+ bne- cr0, 5f
+ ori r10,r10, 0x200 /* Extended encoding, bit 22 */
+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 +485,12 @@ DataTLBError:
stw r10, 0(r0)
stw r11, 4(r0)
- /* First, make sure this was a store operation.
+ 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.
*/
- mfspr r10, SPRN_DSISR
- andis. r11, r10, 0x0200 /* If set, indicates store op */
- beq 2f
/* 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 +539,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 4/8] 8xx: Fixup DAR from buggy dcbX instructions.
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-4-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).
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 147 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 143 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index a9f1ace..1d8e4e3 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -494,11 +494,16 @@ DataTLBError:
mfspr r10, SPRN_DAR
cmpwi cr0, r10, 0x00f0
- beq- 2f /* must be a buggy dcbX, icbi insn. */
-
+ beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
+DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
mfspr r11, SPRN_DSISR
- andis. r11, r11, 0x4800 /* !translation or protection */
- bne 2f /* branch if either is set */
+ /* As the DAR fixup may clear store we may have all 3 states zero.
+ * Make sure only 0x0200(store) falls down into DIRTY handling
+ */
+ andis. r11, r11, 0x4a00 /* !translation, protection or store */
+ srwi r11, r11, 16
+ cmpwi cr0, r11, 0x0200 /* just store ? */
+ bne 2f
/* Only Change bit left now, do it here as it is faster
* than trapping to the C fault handler.
*/
@@ -604,6 +609,140 @@ 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 if you don't want to use self modifying code */
+#define NO_SELF_MODIFYING_CODE
+FixupDAR:/* Entry point for dcbx workaround. */
+ /* fetch instruction from memory. */
+ mfspr r10, SPRN_SRR0
+ DO_8xx_CPU6(0x3780, r3)
+ mtspr SPRN_MD_EPN, r10
+ mfspr r11, SPRN_M_TWB /* Get level 1 table entry address */
+ cmplwi cr0, r11, 0x0800
+ blt- 3f /* Branch if user space */
+ lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
+ ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
+ rlwimi r11, r10, 22, 0xffc
+3: lwz r11, 0(r11) /* Get the level 1 entry */
+ 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
+ lwz r11,0(r11)
+/* Check if it really is a dcbx instruction. */
+/* dcbt and dcbtst does not generate DTLB Misses/Errors,
+ * no need to include them here */
+ srwi r10, r11, 26 /* check if major OP code is 31 */
+ cmpwi cr0, r10, 31
+ bne- 141f
+ rlwinm r10, r11, 0, 21, 30
+ cmpwi cr0, r10, 2028 /* Is dcbz? */
+ beq+ 142f
+ cmpwi cr0, r10, 940 /* Is dcbi? */
+ beq+ 142f
+ cmpwi cr0, r10, 108 /* Is dcbst? */
+ beq+ 144f /* Fix up store bit! */
+ cmpwi cr0, r10, 172 /* Is dcbf? */
+ beq+ 142f
+ cmpwi cr0, r10, 1964 /* Is icbi? */
+ beq+ 142f
+141: mfspr r10, SPRN_DAR /* r10 must hold DAR at exit */
+ b DARFixed /* Nope, go back to normal TLB processing */
+
+144: mfspr r10, SPRN_DSISR
+ rlwinm r10, r10,0,7,5 /* Clear store bit for buggy dcbst insn */
+ mtspr SPRN_DSISR, r10
+142: /* continue, it was a dcbx, dcbi instruction. */
+#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 DARFixed /* 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
+ mtctr r11 ;b 154f /* r10 needs special handling */
+ mtctr r11 ;b 153f /* r11 needs special handling */
+ 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
+ add r10, r10, r20 ;b 151f
+ add r10, r10, r21 ;b 151f
+ 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 DARFixed /* 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 6/8] 8xx: Restore _PAGE_WRITETHRU
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-6-git-send-email-Joakim.Tjernlund@transmode.se>
8xx has not had WRITETHRU due to lack of bits in the pte.
After the recent rewrite of the 8xx TLB code, there are
two bits left. Use one of them to WRITETHRU.
Perhaps use the last SW bit to PAGE_SPECIAL or PAGE_FILE?
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/include/asm/pte-8xx.h | 5 +++--
arch/powerpc/kernel/head_8xx.S | 8 ++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index 68ba861..d44826e 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -35,11 +35,12 @@
#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
#define _PAGE_DIRTY 0x0100 /* C: page changed */
-/* These 3 software bits must be masked out when the entry is loaded
- * into the TLB, 2 SW bits left.
+/* These 4 software bits must be masked out when the entry is loaded
+ * into the TLB, 1 SW bit left(0x0080).
*/
#define _PAGE_GUARDED 0x0010 /* software: guarded access */
#define _PAGE_ACCESSED 0x0020 /* software: page referenced */
+#define _PAGE_WRITETHRU 0x0040 /* software: caching is write through */
/* Setting any bits in the nibble with the follow two controls will
* require a TLB exception handler change. It is assumed unused bits
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 18e9901..65e0526 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -422,6 +422,10 @@ DataStoreTLBMiss:
* above.
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
@@ -559,6 +563,10 @@ DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR
* It is bit 27 of both the Linux PTE and the TWC
*/
rlwimi r11, r10, 0, 27, 27
+ /* Insert the WriteThru flag into the TWC from the Linux PTE.
+ * It is bit 25 in the Linux PTE and bit 30 in the TWC
+ */
+ rlwimi r11, r10, 32-5, 30, 30
DO_8xx_CPU6(0x3b80, r3)
mtspr SPRN_MD_TWC, r11
mfspr r11, SPRN_MD_TWC /* get the pte address again */
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/8] 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-3-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().
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
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 97bd523..a9f1ace 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
@@ -445,6 +451,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 */
@@ -485,6 +492,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 */
@@ -508,7 +519,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
@@ -550,6 +562,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 7/8] 8xx: start using dcbX instructions in various copy routines
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-7-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.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
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 da9c0c4..8649f53 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -502,15 +502,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
@@ -535,15 +527,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
@@ -584,7 +567,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 8/8] 8xx: Remove DIRTY pte handling in DTLB Error.
From: Joakim Tjernlund @ 2009-11-04 13:38 UTC (permalink / raw)
To: Scott Wood, Rex Feany, Benjamin Herrenschmidt,
linuxppc-dev@ozlabs.org
In-Reply-To: <1257341920-29277-8-git-send-email-Joakim.Tjernlund@transmode.se>
There is no need to do set the DIRTY bit directly in DTLB Error.
Trap to do_page_fault() and let the generic MM code do the work.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
arch/powerpc/kernel/head_8xx.S | 96 ----------------------------------------
1 files changed, 0 insertions(+), 96 deletions(-)
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 65e0526..d6d70f2 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -500,102 +500,6 @@ DataTLBError:
cmpwi cr0, r10, 0x00f0
beq- FixupDAR /* must be a buggy dcbX, icbi insn. */
DARFixed:/* Return from dcbx instruction bug workaround, r10 holds value of DAR */
- mfspr r11, SPRN_DSISR
- /* As the DAR fixup may clear store we may have all 3 states zero.
- * Make sure only 0x0200(store) falls down into DIRTY handling
- */
- andis. r11, r11, 0x4a00 /* !translation, protection or store */
- srwi r11, r11, 16
- cmpwi cr0, r11, 0x0200 /* just store ? */
- bne 2f
- /* 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
- * the DAR, but not the MD_EPN register. We must copy the 20 most
- * significant bits of the EA from the DAR to MD_EPN before we
- * start walking the page tables. We also need to copy the CASID
- * value from the M_CASID register.
- * Addendum: The EA of a data TLB error is _supposed_ to be stored
- * in DAR, but it seems that this doesn't happen in some cases, such
- * as when the error is due to a dcbi instruction to a page with a
- * TLB that doesn't have the changed bit set. In such cases, there
- * does not appear to be any way to recover the EA of the error
- * since it is neither in DAR nor MD_EPN. As a workaround, the
- * _PAGE_HWWRITE bit is set for all kernel data pages when the PTEs
- * are initialized in mapin_ram(). This will avoid the problem,
- * assuming we only use the dcbi instruction on kernel addresses.
- */
-
- /* DAR is in r10 already */
- rlwinm r11, r10, 0, 0, 19
- ori r11, r11, MD_EVALID
- mfspr r10, SPRN_M_CASID
- rlwimi r11, r10, 0, 28, 31
- DO_8xx_CPU6(0x3780, r3)
- mtspr SPRN_MD_EPN, r11
-
- mfspr r10, SPRN_M_TWB /* Get level 1 table entry address */
-
- /* If we are faulting a kernel address, we have to use the
- * kernel page tables.
- */
- andi. r11, r10, 0x0800
- beq 3f
- lis r11, swapper_pg_dir@h
- ori r11, r11, swapper_pg_dir@l
- rlwimi r10, r11, 0, 2, 19
-3:
- lwz r11, 0(r10) /* Get the level 1 entry */
- rlwinm. r10, r11,0,0,19 /* Extract page descriptor page address */
- beq 2f /* If zero, bail */
-
- /* We have a pte table, so fetch the pte from the table.
- */
- ori r11, r11, 1 /* Set valid bit in physical L2 page */
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11 /* Load pte table base address */
- mfspr r10, SPRN_MD_TWC /* ....and get the pte address */
- lwz r10, 0(r10) /* Get the pte */
- /* Insert the Guarded flag into the TWC from the Linux PTE.
- * It is bit 27 of both the Linux PTE and the TWC
- */
- rlwimi r11, r10, 0, 27, 27
- /* Insert the WriteThru flag into the TWC from the Linux PTE.
- * It is bit 25 in the Linux PTE and bit 30 in the TWC
- */
- rlwimi r11, r10, 32-5, 30, 30
- DO_8xx_CPU6(0x3b80, r3)
- mtspr SPRN_MD_TWC, r11
- mfspr r11, SPRN_MD_TWC /* get the 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 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.
- */
- 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 */
-
- 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
- rfi
-2:
mfspr r10, SPRN_M_TW /* Restore registers */
lwz r11, 0(r0)
mtcr r11
--
1.6.4.4
^ permalink raw reply related
* [PATCH] PCI: Fix regression in powerpc MSI-X
From: Andre Detsch @ 2009-11-04 15:03 UTC (permalink / raw)
To: linuxppc-dev, michael
Patch f598282f5145036312d90875d0ed5c14b49fd8a7 exposed a problem in
powerpc MSI-X functionality, making network interfaces such as ixgbe
and cxgb3 stop to work when MSI-X is enabled. RX interrupts were not
being generated.
The problem was caused because MSI irq was not being effectively
unmasked after device initialization.
Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Index: linux-2.6/arch/powerpc/platforms/pseries/msi.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/msi.c 2009-11-04
06:35:39.000000000 -0700
+++ linux-2.6/arch/powerpc/platforms/pseries/msi.c 2009-11-04
07:23:27.000000000 -0700
@@ -432,8 +432,6 @@ static int rtas_setup_msi_irqs(struct pc
/* Read config space back so we can restore after reset */
read_msi_msg(virq, &msg);
entry->msg = msg;
-
- unmask_msi_irq(virq);
}
return 0;
Index: linux-2.6/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/xics.c 2009-11-04
06:35:39.000000000 -0700
+++ linux-2.6/arch/powerpc/platforms/pseries/xics.c 2009-11-04
07:23:27.000000000 -0700
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/radix-tree.h>
#include <linux/cpu.h>
+#include <linux/msi.h>
#include <linux/of.h>
#include <asm/firmware.h>
@@ -219,6 +220,14 @@ static void xics_unmask_irq(unsigned int
static unsigned int xics_startup(unsigned int virq)
{
+ /*
+ * The generic MSI code returns with the interrupt disabled on the
+ * card, using the MSI mask bits. Firmware doesn't appear to unmask
+ * at that level, so we do it here by hand.
+ */
+ if (irq_to_desc(virq)->msi_desc)
+ unmask_msi_irq(virq);
+
/* unmask it */
xics_unmask_irq(virq);
return 0;
^ 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