* [PATCH] edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores
From: Kumar Gala @ 2011-03-31 22:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: bluesmoke-devel, dougthompson
Only the e500v1/v2 cores have HID1[RXFE] so we should attempt to set or
clear this register bit on them. Otherwise we get crashes like:
NIP: c0579f84 LR: c006d550 CTR: c0579f84
REGS: ef857ec0 TRAP: 0700 Not tainted (2.6.38.2-00072-gf15ba3c)
MSR: 00021002 <ME,CE> CR: 22044022 XER: 00000000
TASK = ef8559c0[1] 'swapper' THREAD: ef856000 CPU: 0
GPR00: c006d538 ef857f70 ef8559c0 00000000 00000004 00000000 00000000 00000000
GPR08: c0590000 c30170a8 00000000 c30170a8 00000001 0fffe000 00000000 00000000
GPR16: 00000000 7ffa0e60 00000000 00000000 7ffb0bd8 7ff3b844 c05be000 00000000
GPR24: 00000000 00000000 c05c28b0 c0579fac 00000000 00029002 00000000 c0579f84
NIP [c0579f84] mpc85xx_mc_clear_rfxe+0x0/0x28
LR [c006d550] on_each_cpu+0x34/0x50
Call Trace:
[ef857f70] [c006d538] on_each_cpu+0x1c/0x50 (unreliable)
[ef857f90] [c057a070] mpc85xx_mc_init+0xc4/0xdc
[ef857fa0] [c0001cd4] do_one_initcall+0x34/0x1a8
[ef857fd0] [c055d9d8] kernel_init+0x17c/0x218
[ef857ff0] [c000cda4] kernel_thread+0x4c/0x68
Instruction dump:
40be0018 3c60c052 3863c70c 4be9baad 3be0ffed 4bd7c99d 80010014 7fe3fb78
83e1000c 38210010 7c0803a6 4e800020 <7c11faa6> 54290024 81290008
3d60c06e
Oops: Exception in kernel mode, sig: 4 [#2]
---[ end trace 49ff3b8f93efde1a ]---
Also use the HID1_RFXE define rather than a magic number.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Doug, unless otherwise told I plan on pushing this via the powerpc.git tree
- k
drivers/edac/mpc85xx_edac.c | 29 ++++++++++++++++++++---------
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b123bb3..5aef2ed 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -1150,13 +1150,14 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
- mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
+ mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~HID1_RFXE));
}
#endif
static int __init mpc85xx_mc_init(void)
{
int res = 0;
+ u32 pvr = 0;
printk(KERN_INFO "Freescale(R) MPC85xx EDAC driver, "
"(C) 2006 Montavista Software\n");
@@ -1186,12 +1187,17 @@ static int __init mpc85xx_mc_init(void)
#endif
#ifdef CONFIG_FSL_SOC_BOOKE
- /*
- * need to clear HID1[RFXE] to disable machine check int
- * so we can catch it
- */
- if (edac_op_state == EDAC_OPSTATE_INT)
- on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ /*
+ * need to clear HID1[RFXE] to disable machine check int
+ * so we can catch it
+ */
+ if (edac_op_state == EDAC_OPSTATE_INT)
+ on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+ }
#endif
return 0;
@@ -1209,10 +1215,15 @@ static void __exit mpc85xx_mc_restore_hid1(void *data)
static void __exit mpc85xx_mc_exit(void)
{
#ifdef CONFIG_FSL_SOC_BOOKE
- on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ u32 pvr = mfspr(SPRN_PVR);
+
+ if ((PVR_VER(pvr) == PVR_VER_E500V1) ||
+ (PVR_VER(pvr) == PVR_VER_E500V2)) {
+ on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+ }
#endif
#ifdef CONFIG_PCI
- of_unregister_platform_driver(&mpc85xx_pci_err_driver);
+ of_unregistr_platform_driver(&mpc85xx_pci_err_driver);
#endif
of_unregister_platform_driver(&mpc85xx_l2_err_driver);
of_unregister_platform_driver(&mpc85xx_mc_err_driver);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Kumar Gala @ 2011-03-31 21:26 UTC (permalink / raw)
To: Leon Woestenberg; +Cc: meet2prabhu, linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <AANLkTi=HSU42BJCVY+GoRE1WzU8auUK9vRyz8YrNZ8B_@mail.gmail.com>
On Mar 31, 2011, at 6:44 AM, Leon Woestenberg wrote:
> Hello Prabhakar, Kumar,
>=20
> (I missed the original post, due to temporarely being unsubscribed, I
> am responding to Kumar's reply).
>=20
> On Thu, Mar 31, 2011 at 10:22 AM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>> On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
>>=20
>>> PCIe memory address space is 1:1 mapped with u-boot.
>>>=20
>>> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the =
address map
>>> changes in u-boot.
>>>=20
> Does this mean u-boot and Linux versions should be selectively =
matched, or not?
=46rom time to time they have to be. PCIe was broken between u-boot & =
linux on these boards.
> What commit in u-boot does this apply to?
=
http://git.denx.de/?p=3Du-boot.git;a=3Dcommit;h=3Db0c5ceb305054aadf2f810b0=
b7bfcc94926b78ad
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: Implement dma_mmap_coherent()
From: Benjamin Herrenschmidt @ 2011-03-31 21:05 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: tiwai, linuxppc-dev
In-Reply-To: <20110331203921.56030@gmx.net>
On Thu, 2011-03-31 at 22:39 +0200, Gerhard Pircher wrote:
> Anyway, it compiles with explicit type casts and I could test it on my
> semi-noncoherent AmigaOne. So far it works just fine with the VIA
> onboard
> sound and a Soundblaster Live PCI card.
>
> Thanks a lot for the fix!
Yes, the version I sent to Linus has that fixed, I forgot to send it to
the list also :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Implement dma_mmap_coherent()
From: Gerhard Pircher @ 2011-03-31 20:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: tiwai
-------- Original-Nachricht --------
> Datum: Fri, 25 Mar 2011 17:50:06 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
> CC: Takashi Iwai <tiwai@suse.de>
> Betreff: [PATCH] powerpc: Implement dma_mmap_coherent()
> This is used by Alsa to mmap buffers allocated with dma_alloc_coherent()
> into userspace. We need a special variant to handle machines with
> non-coherent DMAs as those buffers have "special" virt addresses and
> require non-cachable mappings
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Dunno if anybody with CONFIG_NOT_COHERENT_CACHE has some audio device
> that uses dma buffers (ie not usb-audio) and wants to try that out...
> should fix a long standing problem.
Compilation fails here with these error messages:
> CC arch/powerpc/mm/dma-noncoherent.o
> arch/powerpc/mm/dma-noncoherent.c: In function ‘__dma_get_coherent_pfn’:
> arch/powerpc/mm/dma-noncoherent.c:413: error: invalid operands to binary >> (have ‘void *’ and ‘int’)
> cc1: warnings being treated as errors
> arch/powerpc/mm/dma-noncoherent.c:414: error: passing argument 2 of ‘pud_offset’ makes integer from pointer without a cast
> arch/powerpc/mm/dma-noncoherent.c:415: error: passing argument 2 of ‘pmd_offset’ makes integer from pointer without a cast
> arch/powerpc/mm/dma-noncoherent.c:416: error: invalid operands to binary >> (have ‘void *’ and ‘int’)
> make[1]: *** [arch/powerpc/mm/dma-noncoherent.o] Fehler 1
> make: *** [arch/powerpc/mm] Fehler 2
Anyway, it compiles with explicit type casts and I could test it on my
semi-noncoherent AmigaOne. So far it works just fine with the VIA onboard
sound and a Soundblaster Live PCI card.
Thanks a lot for the fix!
regards,
Gerhard
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-31 20:38 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <4D94B810.4000107@goop.org>
On Thu, 2011-03-31 at 10:21 -0700, Jeremy Fitzhardinge wrote:
>
> No, its the same accessors for both, since the need to distinguish them
> hasn't really come up. Could you put a "if (preemptable()) return;"
> guard in your implementations?
That would be a band-aid but would probably do the trick for now
for !-rt, tho it wouldn't do the right thing for -rt...
> Otherwise I have no objections to passing the mm in (we'll probably just
> continue to ignore the arg in x86-land).
Ben.
^ permalink raw reply
* [PATCH] powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP.
From: Paul Gortmaker @ 2011-03-31 17:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Gortmaker
Commit b3df895aebe091b1657 "powerpc/kexec: Add support for FSL-BookE"
introduced the original PPC_STD_MMU_64 checks around the function
crash_kexec_wait_realmode(). Then commit c2be05481f61252
"powerpc: Fix default_machine_crash_shutdown #ifdef botch" changed
the ifdef around the calling site to add a check on SMP, but the
ifdef around the function itself was left unchanged, leaving an
unused function for PPC_STD_MMU_64=y and SMP=n
Rather than have two ifdefs that can get out of sync like this,
simply put the corrected conditional around the function and use
a stub to get rid of one set of ifdefs completely.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/kernel/crash.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d569e2..3d3d416 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -163,7 +163,7 @@ static void crash_kexec_prepare_cpus(int cpu)
}
/* wait for all the CPUs to hit real mode but timeout if they don't come in */
-#ifdef CONFIG_PPC_STD_MMU_64
+#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
static void crash_kexec_wait_realmode(int cpu)
{
unsigned int msecs;
@@ -188,6 +188,8 @@ static void crash_kexec_wait_realmode(int cpu)
}
mb();
}
+#else
+static inline void crash_kexec_wait_realmode(int cpu) {}
#endif
/*
@@ -344,9 +346,7 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
crash_save_cpu(regs, crashing_cpu);
crash_kexec_prepare_cpus(crashing_cpu);
cpu_set(crashing_cpu, cpus_in_crash);
-#if defined(CONFIG_PPC_STD_MMU_64) && defined(CONFIG_SMP)
crash_kexec_wait_realmode(crashing_cpu);
-#endif
machine_kexec_mask_interrupts();
--
1.7.3.3
^ permalink raw reply related
* Re: mmotm threatens ppc preemption again
From: Jeremy Fitzhardinge @ 2011-03-31 17:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <1301532729.2407.16.camel@pasglop>
On 03/30/2011 05:52 PM, Benjamin Herrenschmidt wrote:
> We deal with preemption already since the PTL turns into a mutex on -rt,
> so we could bring that patch into mainline. The easiest approach however
> for now would be to not do the kernel batched updates on kernel
> (solution 4), and I can sort it out later if I want to enable it.
>
> The problem is that it's hard for me to "fix" that with the current
> accessors as arch_enter_lazy_mmu_mode() don't get any argument that
> could point me to which mm is being operated on.
>
> Jeremy, I haven't had a chance to look at your patches in detail, do
> you just use those accessors or do you create new ones for batching
> kernel updates in which case powerpc could just make them do nothing ?
>
> Else, we could have one patch that adds an mm argument accross the tree,
> it shouldn't be too hard.
No, its the same accessors for both, since the need to distinguish them
hasn't really come up. Could you put a "if (preemptable()) return;"
guard in your implementations?
Otherwise I have no objections to passing the mm in (we'll probably just
continue to ignore the arg in x86-land).
Thanks,
J
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-03-31 16:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1301551476.2407.61.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]
On Thu, 31 Mar 2011, Benjamin Herrenschmidt wrote:
> On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> > On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
> >
> > > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > > Here I made the assumption that the hardware would never remove more events in
> > > > a speculative roll back than it had added. This is not a situation I
> > > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > > this time.
> > >
> > > I'm not thinking about underflow but rollover... or that isn't possible
> > > with those counters ? IE. They don't wrap back to 0 after hitting
> > > ffffffff ?
> > >
> >
> > They do roll over to 0 after ffffffff, but I thought that case was already
> > covered by the perf_event_interrupt. Are you concerned that we will reset a
> > counter and speculative roll back will underflow that counter?
>
> No, but take this part of the patch:
>
> > --- a/arch/powerpc/kernel/perf_event.c
> > +++ b/arch/powerpc/kernel/perf_event.c
> > @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> > prev = local64_read(&event->hw.prev_count);
> > barrier();
> > val = read_pmc(event->hw.idx);
> > + /*
> > + * POWER7 can roll back counter values, if the new value is
> > + * smaller than the previous value it will cause the delta
> > + * and the counter to have bogus values. If this is the
> > + * case skip updating anything until the counter grows again.
> > + * This can lead to a small lack of precision in the counters.
> > + */
> > + if (val < prev)
> > + return;
> > } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
>
> Doesn't that mean that power_pmu_read() can only ever increase the value of
> the perf_event and so will essentially -stop- once the counter rolls over ?
>
> Similar comments every where you do this type of comparison.
>
Sorry for being so dense on this, but I think that when a counter overflows
both the register value and the previous value are reset so we should continue
seeing new event counts after the overflow interrupt handler puts the counter
back into a sane state. What am I not seeing?
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: dtc: remove obsolete .gitignore entries
From: Grant Likely @ 2011-03-31 15:58 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev
In-Reply-To: <1299948250-32084-1-git-send-email-w.sang@pengutronix.de>
On Sat, Mar 12, 2011 at 05:44:10PM +0100, Wolfram Sang wrote:
> dtc was moved and .gitignores have been added to the new location. So, we can
> delete the old, forgotten ones.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
It's Ben's jurisdiction, but I've picked it up into my
devicetree/merge branch anyway. If I don't hear from Ben either way
then I'll push it out to Linus next week.
g.
> ---
> arch/powerpc/boot/.gitignore | 1 -
> arch/powerpc/boot/dtc-src/.gitignore | 3 ---
> 2 files changed, 0 insertions(+), 4 deletions(-)
> delete mode 100644 arch/powerpc/boot/dtc-src/.gitignore
>
> diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
> index 3d80c3e..12da77e 100644
> --- a/arch/powerpc/boot/.gitignore
> +++ b/arch/powerpc/boot/.gitignore
> @@ -1,5 +1,4 @@
> addnote
> -dtc
> empty.c
> hack-coff
> infblock.c
> diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore
> deleted file mode 100644
> index a7c3f94..0000000
> --- a/arch/powerpc/boot/dtc-src/.gitignore
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -dtc-lexer.lex.c
> -dtc-parser.tab.c
> -dtc-parser.tab.h
> --
> 1.7.2.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Leon Woestenberg @ 2011-03-31 11:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: meet2prabhu, linuxppc-dev, Prabhakar Kushwaha
In-Reply-To: <38B7F1DC-21FC-4723-AF41-E66E04DF0B1F@kernel.crashing.org>
Hello Prabhakar, Kumar,
(I missed the original post, due to temporarely being unsubscribed, I
am responding to Kumar's reply).
On Thu, Mar 31, 2011 at 10:22 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
>
>> PCIe memory address space is 1:1 mapped with u-boot.
>>
>> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the address map
>> changes in u-boot.
>>
Does this mean u-boot and Linux versions should be selectively matched, or not?
What commit in u-boot does this apply to?
Regards,
--
Leon
^ permalink raw reply
* configure FPGA
From: SACHIN SOLANKI @ 2011-03-31 9:42 UTC (permalink / raw)
To: linuxppc-dev
hi sir,
i want to store some bit stream to compect flesh in diffrenrt memory
location.is it possible through powerPC control programing that we
can select sinrgle bit stream from complect flesh card and configure
fpga.
looking forward for reply....
^ permalink raw reply
* Re: [PATCH] powerpc/dts:Update PCIe memory maps to match u-boot of Px020RDB
From: Kumar Gala @ 2011-03-31 8:22 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: meet2prabhu, linuxppc-dev
In-Reply-To: <1301028465-3897-1-git-send-email-prabhakar@freescale.com>
On Mar 24, 2011, at 11:47 PM, Prabhakar Kushwaha wrote:
> PCIe memory address space is 1:1 mapped with u-boot.
>=20
> Update dts of Px020RDB i.e. P1020RDB and P2020RDB to match the address =
map
> changes in u-boot.
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Kumar Gala <kumar.gala@freescale.com>
> ---
> Based upon =
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git =
(Branch master)
>=20
> arch/powerpc/boot/dts/p1020rdb.dts | 12 ++++++------
> arch/powerpc/boot/dts/p2020rdb.dts | 12 ++++++------
> arch/powerpc/boot/dts/p2020rdb_camp_core0.dts | 4 ++--
> arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 10 +++++-----
> 4 files changed, 19 insertions(+), 19 deletions(-)
applied to 'merge'
- k=
^ permalink raw reply
* [PATCH] powerpc/85xx: Don't add disabled PCIe devices
From: Prabhakar Kushwaha @ 2011-03-31 7:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: meet2prabhu, Prabhakar Kushwaha
PCIe nodes with the property status="disabled" are not usable and so
avoid adding "disabled" PCIe bridge with the system.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Acked-by: Kumar Gala <kumar.gala@freescale.com>
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master)
arch/powerpc/sysdev/fsl_pci.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index f8f7f28..68ca929 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -324,6 +324,11 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
struct resource rsrc;
const int *bus_range;
+ if (!of_device_is_available(dev)) {
+ pr_warning("%s: disabled\n", dev->full_name);
+ return -ENODEV;
+ }
+
pr_debug("Adding PCI host bridge %s\n", dev->full_name);
/* Fetch host bridge registers address */
--
1.7.3
^ permalink raw reply related
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Benjamin Herrenschmidt @ 2011-03-31 6:04 UTC (permalink / raw)
To: Eric B Munson
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <20110330183656.GA2564@mgebm.net>
On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
> On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
>
> > On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > > Here I made the assumption that the hardware would never remove more events in
> > > a speculative roll back than it had added. This is not a situation I
> > > encoutered in my limited testing, so I didn't think underflow was possible. I
> > > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > > this time.
> >
> > I'm not thinking about underflow but rollover... or that isn't possible
> > with those counters ? IE. They don't wrap back to 0 after hitting
> > ffffffff ?
> >
>
> They do roll over to 0 after ffffffff, but I thought that case was already
> covered by the perf_event_interrupt. Are you concerned that we will reset a
> counter and speculative roll back will underflow that counter?
No, but take this part of the patch:
> --- a/arch/powerpc/kernel/perf_event.c
> +++ b/arch/powerpc/kernel/perf_event.c
> @@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
> prev = local64_read(&event->hw.prev_count);
> barrier();
> val = read_pmc(event->hw.idx);
> + /*
> + * POWER7 can roll back counter values, if the new value is
> + * smaller than the previous value it will cause the delta
> + * and the counter to have bogus values. If this is the
> + * case skip updating anything until the counter grows again.
> + * This can lead to a small lack of precision in the counters.
> + */
> + if (val < prev)
> + return;
> } while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
Doesn't that mean that power_pmu_read() can only ever increase the value of
the perf_event and so will essentially -stop- once the counter rolls over ?
Similar comments every where you do this type of comparison.
Cheers,
Ben.
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: Grant Likely @ 2011-03-31 3:43 UTC (permalink / raw)
To: Andre Schwarz; +Cc: LinuxPPC List
In-Reply-To: <4D92071E.3060906@matrix-vision.de>
On Tue, Mar 29, 2011 at 06:21:50PM +0200, Andre Schwarz wrote:
> On 03/25/2011 10:28 AM, Andre Schwarz wrote:
> >Grant, Anton,
>
> got it.
> providing modalis = "spidev" within spi_board_info works like a charme ...
Good. Glad you got it sorted out.
g.
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-31 0:52 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <4D939B88.5020707@goop.org>
On Wed, 2011-03-30 at 14:07 -0700, Jeremy Fitzhardinge wrote:
>
> 1. Change the locking rules for kernel updates to also require a pte lock
> 2. Special-case batched kernel updates to include a pte lock
> 3. Make Power deal with preemption during a batched kernel update
> 4. Never do batched kernel updates on Power
> 5. Never do batched kernel updates (the current state)
We deal with preemption already since the PTL turns into a mutex on -rt,
so we could bring that patch into mainline. The easiest approach however
for now would be to not do the kernel batched updates on kernel
(solution 4), and I can sort it out later if I want to enable it.
The problem is that it's hard for me to "fix" that with the current
accessors as arch_enter_lazy_mmu_mode() don't get any argument that
could point me to which mm is being operated on.
Jeremy, I haven't had a chance to look at your patches in detail, do
you just use those accessors or do you create new ones for batching
kernel updates in which case powerpc could just make them do nothing ?
Else, we could have one patch that adds an mm argument accross the tree,
it shouldn't be too hard.
Later on, I can bring in the stuff from -rt stuff to enable lazy
batching of kernel pages on power if I wish to do so.
Cheers,
Ben
^ permalink raw reply
* Re: [PATCH v2 5/5] xhci: Remove recursive call to xhci_handle_event
From: Matt Evans @ 2011-03-30 23:10 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: sarah.a.sharp, linuxppc-dev, linux-usb, Sergei Shtylyov
In-Reply-To: <20110329200017.GA25480@dtor-ws.eng.vmware.com>
On 30/03/11 07:00, Dmitry Torokhov wrote:
> On Sunday, March 27, 2011 09:53:00 pm Matt Evans wrote:
>> @@ -2282,7 +2284,7 @@ hw_died:
>> /* FIXME this should be a delayed service routine
>> * that clears the EHB.
>> */
>> - xhci_handle_event(xhci);
>> + while (xhci_handle_event(xhci)) {}
>>
>
> I must admit I dislike the style with empty loop bodies, do you think
> we could have something like below instead?
Well, although I don't mind empty while()s at all (they're clean and obvious
IMHO) I would remove an empty blightful while loop with something like this:
do {
ret = xhci_handle_event(xhci);
} while (ret > 0);
;-) (Not sure that refactoring its contents into the IRQ handler is a good idea,
if that area's going to be revisited soon to extend error
handling/reporting.)
Cheers,
Matt
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Jeremy Fitzhardinge @ 2011-03-30 21:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Hugh Dickins, Peter Zijlstra
In-Reply-To: <20110330135332.9c322e40.akpm@linux-foundation.org>
On 03/30/2011 01:53 PM, Andrew Morton wrote:
> On Mon, 21 Mar 2011 13:22:30 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:
>>>> As long as the races to avoid are between map/unmap vs. access, yes, it
>>>> -should- be fine, and we used to not do demand faulting on kernel space
>>>> (but for how long ?). I'm wondering why we don't just stick a ptl in
>>>> there or is there a good reason why we can't ?
>>> We can - but we usually prefer to avoid unnecessary locking.
>>> An arch function which locks init_mm.page_table_lock on powerpc,
>>> but does nothing on others?
>> That still means gratuitous differences between how the normal and
>> kernel page tables are handled. Maybe that's not worth bothering ...
> So what will we do here? I still have
>
> mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
> mm-add-apply_to_page_range_batch.patch
> ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
> vmalloc-use-plain-pte_clear-for-unmaps.patch
> vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
> vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
> vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
> xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
> xen-grant-table-use-apply_to_page_range_batch.patch
>
> floating around and at some stage they may cause merge problems.
Well, my understanding of the situation is:
1. There's a basic asymmetry between user and kernel pagetables, in
that the former has a standard pte locking scheme, whereas the
latter uses ad-hoc locking depending on what particular subsystem
is doing the changes (presumably to its own private piece of
kernel virtual address space)
2. Power was assuming that all lazy mmu updates were done under
spinlock, or are at least non-preemptable. This is incompatible
with 1), but it was moot because no kernel updates were done lazily
3. These patches add the first instance of lazy mmu updates, which
reveals the mismatch between Power's expectations and the actual
locking rules.
So the options are:
1. Change the locking rules for kernel updates to also require a pte lock
2. Special-case batched kernel updates to include a pte lock
3. Make Power deal with preemption during a batched kernel update
4. Never do batched kernel updates on Power
5. Never do batched kernel updates (the current state)
1 seems like a big change.
2 is pretty awkward, and has the side-effect of increasing preemption
latencies (since if you're doing enough updates to be worth batching,
you'll be disabling preemption for a longish time).
I don't know how complex 3 is; I guess it depends on the details of the
batched hashtable update thingy.
4 looks like it should be simple.
5 is the default do-nothing state, but it seems unfair on anyone who can
actually take advantage of batched updates.
Ben, how hard would something like 3 or 4 be to implement?
Thanks,
J
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Andrew Morton @ 2011-03-30 20:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Jeremy Fitzhardinge, Hugh Dickins, Peter Zijlstra
In-Reply-To: <1300674150.2402.207.camel@pasglop>
On Mon, 21 Mar 2011 13:22:30 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:
> > > As long as the races to avoid are between map/unmap vs. access, yes, it
> > > -should- be fine, and we used to not do demand faulting on kernel space
> > > (but for how long ?). I'm wondering why we don't just stick a ptl in
> > > there or is there a good reason why we can't ?
> >
> > We can - but we usually prefer to avoid unnecessary locking.
> > An arch function which locks init_mm.page_table_lock on powerpc,
> > but does nothing on others?
>
> That still means gratuitous differences between how the normal and
> kernel page tables are handled. Maybe that's not worth bothering ...
So what will we do here? I still have
mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
mm-add-apply_to_page_range_batch.patch
ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
vmalloc-use-plain-pte_clear-for-unmaps.patch
vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
xen-grant-table-use-apply_to_page_range_batch.patch
floating around and at some stage they may cause merge problems.
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-03-30 18:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1301433165.2402.689.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 838 bytes --]
On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
> On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
> > Here I made the assumption that the hardware would never remove more events in
> > a speculative roll back than it had added. This is not a situation I
> > encoutered in my limited testing, so I didn't think underflow was possible. I
> > will send out a V2 using the signed 32 bit delta and remeber to CC stable
> > this time.
>
> I'm not thinking about underflow but rollover... or that isn't possible
> with those counters ? IE. They don't wrap back to 0 after hitting
> ffffffff ?
>
They do roll over to 0 after ffffffff, but I thought that case was already
covered by the perf_event_interrupt. Are you concerned that we will reset a
counter and speculative roll back will underflow that counter?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: checking status semantics with compatible functions
From: Grant Likely @ 2011-03-30 14:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev list, devicetree-discuss, Prabhakar Kushwaha
In-Reply-To: <C1B3133E-0EEE-49E9-9E3A-35026CFA78E9@kernel.crashing.org>
On Wed, Mar 30, 2011 at 03:26:29AM -0500, Kumar Gala wrote:
> [Adding proper lists on CC]
>
> - k
>
> On Mar 30, 2011, at 3:07 AM, Kumar Gala wrote:
>
> > Grant,
> >
> > We have a few helper functions like:
> >
> > drivers/of/base.c:EXPORT_SYMBOL(of_device_is_compatible);
> > drivers/of/base.c:EXPORT_SYMBOL(of_find_compatible_node);
> >
> > That we use in places like arch/powerpc/platform/85xx/mpc85xx_ds.c:
> >
> > for_each_node_by_type(np, "pci") {
> > if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
> > of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
> > of_device_is_compatible(np, "fsl,p2020-pcie")) {
> >
> > It seems like we should check 'status' in these cases with
> > 'of_device_is_available'. I'm thinking that we should have
> > versions of the helpers that also do the 'of_device_is_available'
> > checking. Or should we just change the helpers to call
> > of_device_is_available?
Yes, of_device_is_available() should be checked, but it should not be
added directly to of_device_is_compatible(). I'm okay with adding
a helper variant that does the of_device_is_compatible() check.
In that particular case, I'd also suggest using for_each_matching_node().
g.
^ permalink raw reply
* Re: [PATCH] powerpc: rename get_irq_desc_data and get_irq_desc_chip
From: Thomas Gleixner @ 2011-03-30 13:32 UTC (permalink / raw)
To: Richard Cochran; +Cc: Lennert Buytenhek, linuxppc-dev, linux-kernel
In-Reply-To: <20110330132504.GA31832@riccoc20.at.omicron.at>
On Wed, 30 Mar 2011, Richard Cochran wrote:
> These two functions disappeared in commit
>
> 0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1
> "genirq: Remove compat code"
>
> but they still exist in qe_ic.h.
> This patch renames the function to their new names.
oops. I really need to figure out to teach coccinelle not to ignore
header files.
^ permalink raw reply
* [PATCH] powerpc: rename get_irq_desc_data and get_irq_desc_chip
From: Richard Cochran @ 2011-03-30 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: Lennert Buytenhek, Thomas Gleixner, linuxppc-dev
These two functions disappeared in commit
0c6f8a8b917ad361319c8ace3e9f28e69bfdb4c1
"genirq: Remove compat code"
but they still exist in qe_ic.h.
This patch renames the function to their new names.
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
arch/powerpc/include/asm/qe_ic.h | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/qe_ic.h b/arch/powerpc/include/asm/qe_ic.h
index 9e2cb20..f706164 100644
--- a/arch/powerpc/include/asm/qe_ic.h
+++ b/arch/powerpc/include/asm/qe_ic.h
@@ -81,7 +81,7 @@ int qe_ic_set_high_priority(unsigned int virq, unsigned int priority, int high);
static inline void qe_ic_cascade_low_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -91,7 +91,7 @@ static inline void qe_ic_cascade_low_ipic(unsigned int irq,
static inline void qe_ic_cascade_high_ipic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq != NO_IRQ)
@@ -101,9 +101,9 @@ static inline void qe_ic_cascade_high_ipic(unsigned int irq,
static inline void qe_ic_cascade_low_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
@@ -114,9 +114,9 @@ static inline void qe_ic_cascade_low_mpic(unsigned int irq,
static inline void qe_ic_cascade_high_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
@@ -127,9 +127,9 @@ static inline void qe_ic_cascade_high_mpic(unsigned int irq,
static inline void qe_ic_cascade_muxed_mpic(unsigned int irq,
struct irq_desc *desc)
{
- struct qe_ic *qe_ic = get_irq_desc_data(desc);
+ struct qe_ic *qe_ic = irq_desc_get_handler_data(desc);
unsigned int cascade_irq;
- struct irq_chip *chip = get_irq_desc_chip(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
cascade_irq = qe_ic_get_high_irq(qe_ic);
if (cascade_irq == NO_IRQ)
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4]PPC4xx: Adding PCI(E) MSI support
From: Rupjyoti Sarmah @ 2011-03-30 9:10 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This patch adds MSI support for 440SPe, 460Ex, 460Sx and 405Ex.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
Signed-off-by: Tirumala R Marri <tmarri@apm.com>
---
v4:
* Updated the coding style as per recommendation by Philipp
* The goto style code removed as per suggestion
v3:
* Rebased to Josh next tree
* Cleanup and remove some unwanted log msg.
* Remove list member and its references.
* Keep msi_data local reference.
v2:
* Remove or add blank lines at appropriate places.
* Added BITMAP as it is easy to request and free the MSIs
* Removed UPPER_4BITS_OF36BIT & LOWER_32BITS_OF36BIT;
* Remove unused feature variable.
* Remove initialization of "virq".
* remove static int_no varaible and replace with bitmap.
* Eliminated reading count from DTS tree and added a macro.
* Remove printK.
* Remove else in setup_irqs.
* Free interrupts in teardown_msi_interrupts().
* Print contraints in check_device().
* Replace ioremap with of_iomap().
* Use msi_data in setup_pcieh_hw().
* Don't unmap in the setup_pcieh_hw().
* don't use WARN_ON.
* Remove ppc4xx_msi_ids[].
---
arch/powerpc/boot/dts/canyonlands.dts | 18 ++
arch/powerpc/boot/dts/katmai.dts | 18 ++
arch/powerpc/boot/dts/kilauea.dts | 28 ++++
arch/powerpc/boot/dts/redwood.dts | 20 +++
arch/powerpc/platforms/40x/Kconfig | 2 +
arch/powerpc/platforms/44x/Kconfig | 6 +
arch/powerpc/sysdev/Kconfig | 7 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_msi.c | 277 +++++++++++++++++++++++++++++++++
9 files changed, 377 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_msi.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 2779f08..22dd6ae 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -530,5 +530,23 @@
0x0 0x0 0x0 0x3 &UIC3 0x12 0x4 /* swizzled int C */
0x0 0x0 0x0 0x4 &UIC3 0x13 0x4 /* swizzled int D */>;
};
+
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0xC 0x10000000 0x100>;
+ sdr-base = <0x36C>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts = <0 1 2 3>;
+ interrupt-parent = <&UIC3>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC3 0x18 1
+ 1 &UIC3 0x19 1
+ 2 &UIC3 0x1A 1
+ 3 &UIC3 0x1B 1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 7c3be5e..f913dbe 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -442,6 +442,24 @@
0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int D */>;
};
+ MSI: ppc4xx-msi@400300000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x4 0x00300000 0x100>;
+ sdr-base = <0x3B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts =<0 1 2 3>;
+ interrupt-parent = <&UIC0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC0 0xC 1
+ 1 &UIC0 0x0D 1
+ 2 &UIC0 0x0E 1
+ 3 &UIC0 0x0F 1>;
+ };
+
I2O: i2o@400100000 {
compatible = "ibm,i2o-440spe";
reg = <0x00000004 0x00100000 0x100>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 89edb16..1613d6e 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -403,5 +403,33 @@
0x0 0x0 0x0 0x3 &UIC2 0xd 0x4 /* swizzled int C */
0x0 0x0 0x0 0x4 &UIC2 0xe 0x4 /* swizzled int D */>;
};
+
+ MSI: ppc4xx-msi@C10000000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x0 0xEF620000 0x100>;
+ sdr-base = <0x4B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <12>;
+ interrupts = <0 1 2 3 4 5 6 7 8 9 0xA 0xB 0xC 0xD>;
+ interrupt-parent = <&UIC2>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC2 0x10 1
+ 1 &UIC2 0x11 1
+ 2 &UIC2 0x12 1
+ 2 &UIC2 0x13 1
+ 2 &UIC2 0x14 1
+ 2 &UIC2 0x15 1
+ 2 &UIC2 0x16 1
+ 2 &UIC2 0x17 1
+ 2 &UIC2 0x18 1
+ 2 &UIC2 0x19 1
+ 2 &UIC2 0x1A 1
+ 2 &UIC2 0x1B 1
+ 2 &UIC2 0x1C 1
+ 3 &UIC2 0x1D 1>;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/redwood.dts b/arch/powerpc/boot/dts/redwood.dts
index 81636c0..d86a3a4 100644
--- a/arch/powerpc/boot/dts/redwood.dts
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -358,8 +358,28 @@
0x0 0x0 0x0 0x4 &UIC3 0xb 0x4 /* swizzled int D */>;
};
+ MSI: ppc4xx-msi@400300000 {
+ compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
+ reg = < 0x4 0x00300000 0x100
+ 0x4 0x00300000 0x100>;
+ sdr-base = <0x3B0>;
+ msi-data = <0x00000000>;
+ msi-mask = <0x44440000>;
+ interrupt-count = <3>;
+ interrupts =<0 1 2 3>;
+ interrupt-parent = <&UIC0>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = <0 &UIC0 0xC 1
+ 1 &UIC0 0x0D 1
+ 2 &UIC0 0x0E 1
+ 3 &UIC0 0x0F 1>;
+ };
+
};
+
chosen {
linux,stdout-path = "/plb/opb/serial@ef600200";
};
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index b721764..92aeee6 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -57,6 +57,8 @@ config KILAUEA
select 405EX
select PPC40x_SIMPLE
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC405EX evaluation board.
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index f485fc5..f10cc7f 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -74,6 +74,8 @@ config KATMAI
select 440SPe
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC440SPe evaluation board.
@@ -118,6 +120,8 @@ config CANYONLANDS
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII
help
@@ -144,6 +148,8 @@ config REDWOOD
select 460SX
select PCI
select PPC4xx_PCI_EXPRESS
+ select PCI_MSI
+ select 4xx_MSI
help
This option enables support for the AMCC PPC460SX Redwood board.
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..32f5a40 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -7,8 +7,15 @@ config PPC4xx_PCI_EXPRESS
depends on PCI && 4xx
default n
+config 4xx_MSI
+ bool
+ depends on PCI_MSI
+ depends on PCI && 4xx
+ default n
+
config PPC_MSI_BITMAP
bool
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+ default y if 4xx_MSI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 1e0c933..5d92e29 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
+obj-$(CONFIG_4xx_MSI) += ppc4xx_msi.o
obj-$(CONFIG_PPC4xx_CPM) += ppc4xx_cpm.o
obj-$(CONFIG_PPC4xx_GPIO) += ppc4xx_gpio.o
diff --git a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
new file mode 100644
index 0000000..ab69edb
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -0,0 +1,277 @@
+/*
+ * Adding PCI-E MSI support for PPC4XX SoCs.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Authors: Tirumala R Marri <tmarri@apm.com>
+ * Feng Kan <fkan@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <linux/irq.h>
+#include <linux/bootmem.h>
+#include <linux/pci.h>
+#include <linux/msi.h>
+#include <linux/of_platform.h>
+#include <linux/interrupt.h>
+#include <asm/prom.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+#include <boot/dcr.h>
+#include <asm/dcr-regs.h>
+#include <asm/msi_bitmap.h>
+
+#define PEIH_TERMADH 0x00
+#define PEIH_TERMADL 0x08
+#define PEIH_MSIED 0x10
+#define PEIH_MSIMK 0x18
+#define PEIH_MSIASS 0x20
+#define PEIH_FLUSH0 0x30
+#define PEIH_FLUSH1 0x38
+#define PEIH_CNTRST 0x48
+#define NR_MSI_IRQS 4
+
+struct ppc4xx_msi {
+ u32 msi_addr_lo;
+ u32 msi_addr_hi;
+ void __iomem *msi_regs;
+ int msi_virqs[NR_MSI_IRQS];
+ struct msi_bitmap bitmap;
+ struct device_node *msi_dev;
+};
+
+static struct ppc4xx_msi ppc4xx_msi;
+
+static int ppc4xx_msi_init_allocator(struct platform_device *dev,
+ struct ppc4xx_msi *msi_data)
+{
+ int err;
+
+ err = msi_bitmap_alloc(&msi_data->bitmap, NR_MSI_IRQS,
+ dev->dev.of_node);
+ if (err)
+ return err;
+
+ err = msi_bitmap_reserve_dt_hwirqs(&msi_data->bitmap);
+ if (err < 0) {
+ msi_bitmap_free(&msi_data->bitmap);
+ return err;
+ }
+
+ return 0;
+}
+
+static int ppc4xx_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
+{
+ int int_no = -ENOMEM;
+ unsigned int virq;
+ struct msi_msg msg;
+ struct msi_desc *entry;
+ struct ppc4xx_msi *msi_data = &ppc4xx_msi;
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ int_no = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
+ if (int_no >= 0)
+ break;
+ if (int_no < 0) {
+ pr_debug("%s: fail allocating msi interrupt\n",
+ __func__);
+ }
+ virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
+ if (virq == NO_IRQ) {
+ dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
+ msi_bitmap_free_hwirqs(&msi_data->bitmap, int_no, 1);
+ return -ENOSPC;
+ }
+ set_irq_data(virq, (void *)int_no);
+ dev_dbg(&dev->dev, "%s: virq = %d\n", __func__, virq);
+
+ /* Setup msi address space */
+ msg.address_hi = msi_data->msi_addr_hi;
+ msg.address_lo = msi_data->msi_addr_lo;
+
+ set_irq_msi(virq, entry);
+ msg.data = int_no;
+ write_msi_msg(virq, &msg);
+ }
+ return 0;
+}
+
+void ppc4xx_teardown_msi_irqs(struct pci_dev *dev)
+{
+ struct msi_desc *entry;
+ struct ppc4xx_msi *msi_data = &ppc4xx_msi;
+
+ dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");
+
+ list_for_each_entry(entry, &dev->msi_list, list) {
+ if (entry->irq == NO_IRQ)
+ continue;
+ set_irq_msi(entry->irq, NULL);
+ msi_bitmap_free_hwirqs(&msi_data->bitmap,
+ virq_to_hw(entry->irq), 1);
+ irq_dispose_mapping(entry->irq);
+ }
+}
+
+static int ppc4xx_msi_check_device(struct pci_dev *pdev, int nvec, int type)
+{
+ dev_dbg(&pdev->dev, "PCIE-MSI:%s called. vec %x type %d\n",
+ __func__, nvec, type);
+ if (type == PCI_CAP_ID_MSIX)
+ pr_debug("ppc4xx msi: MSI-X untested, trying anyway.\n");
+
+ return 0;
+}
+
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+ struct resource res, struct ppc4xx_msi *msi)
+{
+ const u32 *msi_data;
+ const u32 *msi_mask;
+ const u32 *sdr_addr;
+ dma_addr_t msi_phys;
+ void *msi_virt;
+
+ sdr_addr = of_get_property(dev->dev.of_node, "sdr-base", NULL);
+ if (!sdr_addr)
+ return -1;
+
+ SDR0_WRITE(sdr_addr, (u64)res.start >> 32); /*HIGH addr */
+ SDR0_WRITE(sdr_addr + 1, res.start & 0xFFFFFFFF); /* Low addr */
+
+
+ msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
+ if (msi->msi_dev)
+ return -ENODEV;
+
+ msi->msi_regs = of_iomap(msi->msi_dev, 0);
+ if (!msi->msi_regs) {
+ dev_err(&dev->dev, "of_iomap problem failed\n");
+ return -ENOMEM;
+ }
+ dev_dbg(&dev->dev, "PCIE-MSI: msi register mapped 0x%x 0x%x\n",
+ (u32) (msi->msi_regs + PEIH_TERMADH), (u32) (msi->msi_regs));
+
+ msi_virt = dma_alloc_coherent(&dev->dev, 64, &msi_phys, GFP_KERNEL);
+ msi->msi_addr_hi = 0x0;
+ msi->msi_addr_lo = (u32) msi_phys;
+ dev_dbg(&dev->dev, "PCIE-MSI: msi address 0x%x\n", msi->msi_addr_lo);
+
+ /* Progam the Interrupt handler Termination addr registers */
+ out_be32(msi->msi_regs + PEIH_TERMADH, msi->msi_addr_hi);
+ out_be32(msi->msi_regs + PEIH_TERMADL, msi->msi_addr_lo);
+
+ msi_data = of_get_property(dev->dev.of_node, "msi-data", NULL);
+ if (!msi_data)
+ return -1;
+ msi_mask = of_get_property(dev->dev.of_node, "msi-mask", NULL);
+ if (!msi_mask)
+ return -1;
+ /* Program MSI Expected data and Mask bits */
+ out_be32(msi->msi_regs + PEIH_MSIED, *msi_data);
+ out_be32(msi->msi_regs + PEIH_MSIMK, *msi_mask);
+
+ return 0;
+}
+
+static int ppc4xx_of_msi_remove(struct platform_device *dev)
+{
+ struct ppc4xx_msi *msi = dev->dev.platform_data;
+ int i;
+ int virq;
+
+ for (i = 0; i < NR_MSI_IRQS; i++) {
+ virq = msi->msi_virqs[i];
+ if (virq != NO_IRQ)
+ irq_dispose_mapping(virq);
+ }
+
+ if (msi->bitmap.bitmap)
+ msi_bitmap_free(&msi->bitmap);
+ iounmap(msi->msi_regs);
+ of_node_put(msi->msi_dev);
+ kfree(msi);
+
+ return 0;
+}
+
+static int __devinit ppc4xx_msi_probe(struct platform_device *dev)
+{
+ struct ppc4xx_msi *msi;
+ struct resource res;
+ int err = 0;
+
+ msi = &ppc4xx_msi;/*keep the msi data for further use*/
+
+ dev_dbg(&dev->dev, "PCIE-MSI: Setting up MSI support...\n");
+
+ msi = kzalloc(sizeof(struct ppc4xx_msi), GFP_KERNEL);
+ if (!msi) {
+ dev_err(&dev->dev, "No memory for MSI structure\n");
+ return -ENOMEM;
+ }
+ dev->dev.platform_data = msi;
+
+ /* Get MSI ranges */
+ err = of_address_to_resource(dev->dev.of_node, 0, &res);
+ if (err) {
+ dev_err(&dev->dev, "%s resource error!\n",
+ dev->dev.of_node->full_name);
+ goto error_out;
+ }
+
+ if (ppc4xx_setup_pcieh_hw(dev, res, msi))
+ goto error_out;
+
+ err = ppc4xx_msi_init_allocator(dev, msi);
+ if (err) {
+ dev_err(&dev->dev, "Error allocating MSI bitmap\n");
+ goto error_out;
+ }
+
+ ppc_md.setup_msi_irqs = ppc4xx_setup_msi_irqs;
+ ppc_md.teardown_msi_irqs = ppc4xx_teardown_msi_irqs;
+ ppc_md.msi_check_device = ppc4xx_msi_check_device;
+ return err;
+
+error_out:
+ ppc4xx_of_msi_remove(dev);
+ return err;
+}
+static const struct of_device_id ppc4xx_msi_ids[] = {
+ {
+ .compatible = "amcc,ppc4xx-msi",
+ },
+ {}
+};
+static struct platform_driver ppc4xx_msi_driver = {
+ .probe = ppc4xx_msi_probe,
+ .remove = ppc4xx_of_msi_remove,
+ .driver = {
+ .name = "ppc4xx-msi",
+ .owner = THIS_MODULE,
+ .of_match_table = ppc4xx_msi_ids,
+ },
+
+};
+
+static __init int ppc4xx_msi_init(void)
+{
+ return platform_driver_register(&ppc4xx_msi_driver);
+}
+
+subsys_initcall(ppc4xx_msi_init);
--
1.5.6.3
^ permalink raw reply related
* Re: checking status semantics with compatible functions
From: Kumar Gala @ 2011-03-30 8:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev list, devicetree-discuss, Prabhakar Kushwaha
In-Reply-To: <9BC4C90E-090F-4961-A242-10D769C08738@kernel.crashing.org>
[Adding proper lists on CC]
- k
On Mar 30, 2011, at 3:07 AM, Kumar Gala wrote:
> Grant,
>=20
> We have a few helper functions like:
>=20
> drivers/of/base.c:EXPORT_SYMBOL(of_device_is_compatible);
> drivers/of/base.c:EXPORT_SYMBOL(of_find_compatible_node);
>=20
> That we use in places like arch/powerpc/platform/85xx/mpc85xx_ds.c:
>=20
> for_each_node_by_type(np, "pci") {
> if (of_device_is_compatible(np, "fsl,mpc8540-pci") ||
> of_device_is_compatible(np, "fsl,mpc8548-pcie") ||
> of_device_is_compatible(np, "fsl,p2020-pcie")) {
>=20
> It seems like we should check 'status' in these cases with =
'of_device_is_available'. I'm thinking that we should have versions of =
the helpers that also do the 'of_device_is_available' checking. Or =
should we just change the helpers to call of_device_is_available?
>=20
> - k
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ 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