* RE: DTS device tree node for dual port RAM
From: EXTERNAL Lange Matthias (AA-DGW/ENG1) @ 2009-03-12 15:19 UTC (permalink / raw)
To: EXTERNAL Lange Matthias (AA-DGW/ENG1); +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40903120632yb46c34bxdecf21f01996bf42@mail.gmail.com>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+matthias.lange=3Dbeissbarth.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matthias.lange=3Dbeissbarth.com@ozl
> abs.org] On Behalf Of Grant Likely
> Sent: Thursday, March 12, 2009 2:32 PM
> To: EXTERNAL Lange Matthias (AA-DGW/ENG1)
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: DTS device tree node for dual port RAM
>
> On Thu, Mar 12, 2009 at 5:24 AM, EXTERNAL Lange Matthias (AA-DGW/ENG1)
> <Matthias.Lange@beissbarth.com> wrote:
> > Hi,
[...]
>
> > interrupts =3D <0 0 0>;
>
> What hardware irq# are you using? See this link for a description of
> what the interrupts property should look like for external IRQs:
I am using hardware irq# 0 which is wired to the critical input line. That'=
s why I was defining the interrupts property to <0 0 0>. So my device tree =
node now looks like this
dpram@40000000 {
compatible =3D "beissbarth,orion-dpram";
interrupts =3D <0 0 0>;
interrupt-parent =3D <&mpc5200_pic>;
};
If I am understanding it correctly I now need to implement a OF platform dr=
iver in which I can use irq_of_parse_and_map() to get the virq for my devic=
e.
Regards,
Matthias Lange.
>
> http://patchwork.ozlabs.org/patch/11349/
>
> To use this property, the irq_of_parse_and_map() function will
> translate from the device tree to a Linux IRQ number.
>
> > interrupt-parent =3D <&mpc5200_pic>;
>
> You probably also want a reg =3D <0 0 0x00400000>; property for mapping
> the address range.
>
> > };
> > };
> >
> > What am I doing wrong? What am I missing?
> >
> > Thanks,
> > Matthias Lange.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: Proposal: [PATCH] Workaround for MPC5121 DTLB errata
From: David Jander @ 2009-03-12 14:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200903121430.49077.david.jander@protonic.nl>
Please note: the proposed patch is actually incomplete, someone with better
knowledge of PowerPC assembly than me should complete it.
According to the errata from Freescale, the proposed workaround should be a
complete LRW (Least-Recently Written) implementation. AFAIK that would
implicate holding an extra table in RAM with LRW information for each entry
in the TLB.
Anyway, with this patch I am experiencing enormous speed-up overall. Some
example tests I have done so far:
- 'mplayer -nosound -benchmark' shows a speedup of roughly 22 %
- 'prboom -timedemo test' (where 'test.lmb' is a prerecorded demo) shows an
increase from 14.1 to 16.7 fps.
Sysnthetic memcpy() benchmarks may show a more drastic improvement (if they
are hit by this bug):
Using 'minibench' from Gunnar Von Boehn, memcpy() speed goes up from 27Mbyte/s
to 173Mbyte/s for memory-2-memory cases.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: DTS device tree node for dual port RAM
From: Grant Likely @ 2009-03-12 13:32 UTC (permalink / raw)
To: EXTERNAL Lange Matthias (AA-DGW/ENG1); +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <44C5CFA72BC0E242A53B64DC1E67DEB80A695E6FE2@SI-MBX10.de.bosch.com>
On Thu, Mar 12, 2009 at 5:24 AM, EXTERNAL Lange Matthias (AA-DGW/ENG1)
<Matthias.Lange@beissbarth.com> wrote:
> Hi,
>
> I am working on a MPC5200-based board. There is a dual port RAM connected=
to the MPC5200 via the localbus. In my setup one can raise an interrupt at=
the MPC5200 to signal new that new data has arrived in the dual port RAM. =
I have already found out that the interrupt delivery actually works (do_IRQ=
gets called when raising the interrupt).
>
> My problem is that my driver (kernel 2.6.24) can not register for the int=
errupt. Each time I call request_irq I get -ENOSYS. I am suspecting that I =
have done something wrong in my dts defining the dual port RAM. I have defi=
ned the device as follows
>
> localbus {
> =A0 =A0 =A0 =A0compatible =3D "fsl,orion-localbus",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,mpc5200-localbus",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "fsl,pq2-localbus";
This should be: compatible =3D "fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple=
-bus";
It doesn't make much sense to claim compatibility with fsl,orion or
fsl,pq2 because the mpc5200 localbus is neither of those.
> =A0 =A0 =A0 =A0#address-cells =3D <2>;
> =A0 =A0 =A0 =A0#size-cells =3D <1>;
> =A0 =A0 =A0 =A0reg =3D <f0010100 40>;
> =A0 =A0 =A0 =A0ranges =3D <0 0 fe000000 00400000>;
>
> =A0 =A0 =A0 =A0dpram@40000000 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_type =3D "dpram";
Don't use device_type. It doesn't make any sense in the flattened
device tree. Use a compatible value instead, and prefix dpram with
the vendor and board name of the platform. ie: compatible =3D
"<company>,<board>-dpram". You should also document what this
compatible value means in Documentation/powerpc/device-tree/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <0 0 0>;
What hardware irq# are you using? See this link for a description of
what the interrupts property should look like for external IRQs:
http://patchwork.ozlabs.org/patch/11349/
To use this property, the irq_of_parse_and_map() function will
translate from the device tree to a Linux IRQ number.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <&mpc5200_pic>;
You probably also want a reg =3D <0 0 0x00400000>; property for mapping
the address range.
> =A0 =A0 =A0 =A0};
> };
>
> What am I doing wrong? What am I missing?
>
> Thanks,
> Matthias Lange.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Proposal: [PATCH] Workaround for MPC5121 DTLB errata
From: David Jander @ 2009-03-12 13:30 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Partial workaround for DTLB errata in MPC5121e processors of die M36P and
older (all currently existing versions).
Due to the bug, the hardware-implemented LRU algorythm always goes to way 1 of
the TLB. This fix forces writes to go to way 0, which would speed up
memory-copy operations where bits 15...19 of source and destination address
are the same.
Signed-off-by: David Jander <david@protonic.nl>
---
arch/powerpc/kernel/head_32.S | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -614,6 +614,14 @@ DataStoreTLBMiss:
*/
mfctr r0
/* Get PTE (linux-style) and check access */
+#ifdef CONFIG_PPC_MPC512x
+/* MPC512x: (partial) workaround for errata in die M36P and earlier:
+ * Force writes to Way 0 (reads are always way 1)
+ */
+ mfspr r3,SPRN_SRR1
+ rlwinm r3,r3,0,15,13 /* Mask out SRR1[WAY] */
+ mtspr SPRN_SRR1,r3
+#endif
mfspr r3,SPRN_DMISS
lis r1,PAGE_OFFSET@h /* check if kernel address */
cmplw 0,r1,r3
^ permalink raw reply
* Re: Next 12 : arch/powerpc/sysdev/axonram build failure
From: Sachin Sant @ 2009-03-12 13:01 UTC (permalink / raw)
To: michael; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <1236860187.12893.5.camel@localhost>
Michael Ellerman wrote:
> So how about this:
>
> >From 7325aea8244ac83d98cde7a509ec8ab5994cdb0e Mon Sep 17 00:00:00 2001
> From: Michael Ellerman <michael@ellerman.id.au>
> Date: Thu, 12 Mar 2009 23:14:58 +1100
> Subject: [PATCH] powerpc/cell: axonram depends on BLOCK
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
Yup that works. Thanks.
Regards
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: 2.6.29-rc7-git2 : crash in kmem_list3_init()
From: Sachin Sant @ 2009-03-12 12:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, cl
In-Reply-To: <49B677AB.1010006@in.ibm.com>
Sachin P. Sant wrote:
> Mel Gorman wrote:
>>
>> Well, the machine must have started with some kernel. What mainline
>> version does that correspond to and can you bisect it?
>>
> The last booted kernel was a 2.6.25 based kernel. I am trying to find out
> the last good kernel.org kernel. I should have that information by
> tomorrow.
Sorry it took some time to get to this.
After lots of build, i found that the problem depends on PAGE_SIZE.
With 4K Page Size i was able to boot 2.6.29-rc7-git2 kernel on this
box. But with 64K page size the machine panics.
Is there any other information i could provide to find a solution
for this issue ?
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: Next 12 : arch/powerpc/sysdev/axonram build failure
From: Michael Ellerman @ 2009-03-12 12:16 UTC (permalink / raw)
To: Sachin Sant; +Cc: Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <49B8C7FA.8090805@in.ibm.com>
On Thu, 2009-03-12 at 13:59 +0530, Sachin Sant wrote:
> Hi Stephen,
>
> Today's next randconfig build on powerpc fails with
>
> CC [M] arch/powerpc/sysdev/axonram.o
> arch/powerpc/sysdev/axonram.c:108: warning: ‘struct request_queue’ declared inside parameter list
> arch/powerpc/sysdev/axonram.c:108: warning: its scope is only this definition or declaration, which is probably not what you want
> arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_make_request’:
<snip>
> arch/powerpc/sysdev/axonram.c:289: error: implicit declaration of function ‘unregister_blkdev’
> arch/powerpc/sysdev/axonram.c:289: error: dereferencing pointer to incomplete type
> arch/powerpc/sysdev/axonram.c:290: error: dereferencing pointer to incomplete type
> arch/powerpc/sysdev/axonram.c:291: error: implicit declaration of function ‘del_gendisk’
> arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_init’:
> arch/powerpc/sysdev/axonram.c:345: error: implicit declaration of function ‘register_blkdev’
> make[1]: *** [arch/powerpc/sysdev/axonram.o] Error 1
> make: *** [arch/powerpc/sysdev] Error 2
>
> CONFIG_BLOCK is not set.
So how about this:
>From 7325aea8244ac83d98cde7a509ec8ab5994cdb0e Mon Sep 17 00:00:00 2001
From: Michael Ellerman <michael@ellerman.id.au>
Date: Thu, 12 Mar 2009 23:14:58 +1100
Subject: [PATCH] powerpc/cell: axonram depends on BLOCK
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index b4ab372..3fb0851 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -266,7 +266,7 @@ config CPM2
config AXON_RAM
tristate "Axon DDR2 memory device driver"
- depends on PPC_IBM_CELL_BLADE
+ depends on PPC_IBM_CELL_BLADE && BLOCK
default m
help
It registers one block device per Axon's DDR2 memory bank found
--
1.6.1.2
^ permalink raw reply related
* DTS device tree node for dual port RAM
From: EXTERNAL Lange Matthias (AA-DGW/ENG1) @ 2009-03-12 11:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi,
I am working on a MPC5200-based board. There is a dual port RAM connected t=
o the MPC5200 via the localbus. In my setup one can raise an interrupt at t=
he MPC5200 to signal new that new data has arrived in the dual port RAM. I =
have already found out that the interrupt delivery actually works (do_IRQ g=
ets called when raising the interrupt).
My problem is that my driver (kernel 2.6.24) can not register for the inter=
rupt. Each time I call request_irq I get -ENOSYS. I am suspecting that I ha=
ve done something wrong in my dts defining the dual port RAM. I have define=
d the device as follows
localbus {
compatible =3D "fsl,orion-localbus",
"fsl,mpc5200-localbus",
"fsl,pq2-localbus";
#address-cells =3D <2>;
#size-cells =3D <1>;
reg =3D <f0010100 40>;
ranges =3D <0 0 fe000000 00400000>;
dpram@40000000 {
device_type =3D "dpram";
interrupts =3D <0 0 0>;
interrupt-parent =3D <&mpc5200_pic>;
};
};
What am I doing wrong? What am I missing?
Thanks,
Matthias Lange.
^ permalink raw reply
* Re: MPC512x DMA to PCI dev
From: Matteo Fortini @ 2009-03-12 10:51 UTC (permalink / raw)
To: linux-ppc list
In-Reply-To: <49B7AA80.2030501@mta.it>
Ok,
I answer to myself, to whomever it may interest: the DMA controller to
use is the PCI_DMA controller, and not the generic DMA controller.
Right now, I'm trying to figure out if there's a generic PCI API I can
extend to talk to the PCI DMA controller.
Matteo Fortini ha scritto:
> Hi all,
> I'm trying to send some data through DMA from a memory buffer to a PCI
> video card VRAM.
>
> While I got that I need to alloc the src buffer through
> dma_alloc_coherent, I don't understand which address I should give as
> the dst address.
>
> I tried both the mapped hw address and an address received from
> pci_map_single, but even if the DMA transfer completes "correctly", I
> have the wrong data in the VRAM in the end.
>
> I read about all the PCI DMA manuals, but it seems they are for letting
> some external DMA device on the PCI bus read/write from/to the main memory.
>
> How do you do that?
>
> Thanks,
> Matteo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Stefan Roese @ 2009-03-12 11:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: lebon, linuxppc-dev
In-Reply-To: <20090312104543.GB3788@zod.rchland.ibm.com>
On Thursday 12 March 2009, Josh Boyer wrote:
> >> Yes, that's also how I use it on canyonlands... now, the wrapper could
> >> probably be used to look at the bd_t anyways, no ?
> >
> >Sure.
>
> Do newer U-Boot versions pass both the dtb and the bd_t?
Both is possible. The user can choose by using different boot commands (with
or without device tree blob). When using the wrapper, the boot command has to
be without the device tree and therefor the bd_t is passed to the kernel.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Josh Boyer @ 2009-03-12 10:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: lebon, linuxppc-dev
In-Reply-To: <200903120924.13378.sr@denx.de>
On Thu, Mar 12, 2009 at 09:24:13AM +0100, Stefan Roese wrote:
>On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
>> On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
>> > Both is possible. Older U-Boot versions only passed the bd_t struct to
>> > the kernel. For those U-Boot's the wrapper is needed. More recent U-Boot
>> > versions support passing a device-tree blob to the kernel. U-Boot patches
>> > the correct memory size in this blob.
>> >
>> > As a matter of fact, I never used the wrapper before. U-Boot supports
>> > passing the device-tree blob to Linux since quite some time now.
>>
>> Yes, that's also how I use it on canyonlands... now, the wrapper could
>> probably be used to look at the bd_t anyways, no ?
>
>Sure.
Do newer U-Boot versions pass both the dtb and the bd_t? If not, the wrapper
would have to look for one, then the other and not get confused.
>> Either get the mem
>> size from there or some flag or version in there can indicate if it's
>> been "fixed".
>
>I don't think that we have some flag and/or version information in the bd_info
>struct. And extending this struct doesn't sound like a good idea to me.
Yeah, we've already had some issues pop up in the past where the bd_t wasn't
correct for a board in the U-Boot version that shipped with it (like the acadia
boards). There's not much that can be done to fix it.
josh
^ permalink raw reply
* DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-12 10:43 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm working on adding PCI support for the Xilinx ML510 FPGA board. The board contains a Virtex-5 FPGA (containing two PPC440 cores), a ALI M1533 pci south bridge, pci slots and more.
I have written code (inspired by the powermac pci code) which initializes the pci soft-core which is in my FPGA. Linux now sees all my pci devices in /proc/bus/pci/devices and the kernel assigned io memory / io port ranges for each device.
Right now I'm working on irq assignment. The FPGA contains a xilinx interrupt controller to which a uart, ethernet, pci slots (inta/b/c/d) and my ALI south bridge (it has its own irq input on the xilinx intc) are connected. The ALI south bridge itself contains a i8259 interrupt controller to which internal USB, IDE and other peripherals are connected.
The problems I'm having are with the DTS file. I'm not fully sure what to put in there and what the kernel is doing with the PCI info. As a start point I looked at mpc8641_hpcn.dts / mpc8572.dts and other freescale files as their boards also contain a i8259 south bridge but this time connected to a ULI M1575 south bridge (it is the successor to the ALI M1533).
The freescale boards define the pci bus like below and connect ULI M1575 peripherals to the i8259 controller. Regarding the entries in the pci interrupt-map what does the fourth column mean? According to source code it means 'interrupt specifier' but what does it mean? In a lot of cases it is 1. Further I believe in this case the entries behind 'mpic' correspond to the inta/b/c/d lines, is that correct? On my board inta is connected to interrupt 5 (intb=4, intc=3, intd=2) of the xilinx intc, so I would need to use those numbers there for my board?
pci0: pcie@f8008000
{
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
..
..
interrupt-map-mask = <0xff00 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 func 0 - PCI slot 1 */
0x8800 0 0 1 &mpic 2 1
0x8800 0 0 2 &mpic 3 1
0x8800 0 0 3 &mpic 4 1
0x8800 0 0 4 &mpic 1 1
..
..
// IDSEL 0x1c USB
0xe000 0 0 1 &i8259 12 2
0xe100 0 0 2 &i8259 9 2
>;
At some point in the file they create some (dummy?) pcie section in which they define a uli1575, an isa bus and attached to that isa bus a i8259. Is this the correct way of doing things? The i8259 driver seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined below but how are those mapped to the south bridge? I have seen some code in kernel/isa-bridge, is that code indeed responsible for setting up these ports?
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x02000000 0x0 0x80000000
0x02000000 0x0 0x80000000
0x0 0x20000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
0x0 0x00100000>;
uli1575@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <0x02000000 0x0 0x80000000
0x02000000 0x0 0x80000000
0x0 0x20000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
0x0 0x00100000>;
isa@1e {
device_type = "isa";
#interrupt-cells = <2>;
#size-cells = <1>;
#address-cells = <2>;
reg = <0xf000 0 0 0 0>;
ranges = <1 0 0x01000000 0 0
0x00001000>;
interrupt-parent = <&i8259>;
i8259: interrupt-controller@20 {
reg = <1 0x20 2
1 0xa0 2
1 0x4d0 2>;
interrupt-controller;
device_type = "interrupt-controller";
#address-cells = <0>;
#interrupt-cells = <2>;
compatible = "chrp,iic";
interrupts = <9 2>;
interrupt-parent = <&mpic>;
};
};
};
};
Thanks,
Roderick Colenbrander
--
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply
* DTS file PCI / i8259 for Xilinx ML510
From: Roderick Colenbrander @ 2009-03-12 10:32 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm working on adding PCI support for the Xilinx ML510 FPGA board. The board contains a Virtex-5 FPGA (containing two PPC440 cores), a ALI M1533 pci south bridge, pci slots and more.
I have written code (inspired by the powermac pci code) which initializes the pci soft-core which is in my FPGA. Linux now sees all my pci devices in /proc/bus/pci/devices and the kernel assigned io memory / io port ranges for each device.
Right now I'm working on irq assignment. The FPGA contains a xilinx interrupt controller to which a uart, ethernet, pci slots (inta/b/c/d) and my ALI south bridge (it has its own irq input on the xilinx intc) are connected. The ALI south bridge itself contains a i8259 interrupt controller to which internal USB, IDE and other peripherals are connected.
The problems I'm having are with the DTS file. I'm not fully sure what to put in there and what the kernel is doing with the PCI info. As a start point I looked at mpc8641_hpcn.dts / mpc8572.dts and other freescale files as their boards also contain a i8259 south bridge but this time connected to a ULI M1575 south bridge (it is the successor to the ALI M1533).
The freescale boards define the pci bus like below and connect ULI M1575 peripherals to the i8259 controller. Regarding the entries in the pci interrupt-map what does the fourth column mean? According to source code it means 'interrupt specifier' but what does it mean? In a lot of cases it is 1. Further I believe in this case the entries behind 'mpic' correspond to the inta/b/c/d lines, is that correct? On my board inta is connected to interrupt 5 (intb=4, intc=3, intd=2) of the xilinx intc, so I would need to use those numbers there for my board?
pci0: pcie@f8008000
{
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
..
..
interrupt-map-mask = <0xff00 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 func 0 - PCI slot 1 */
0x8800 0 0 1 &mpic 2 1
0x8800 0 0 2 &mpic 3 1
0x8800 0 0 3 &mpic 4 1
0x8800 0 0 4 &mpic 1 1
..
..
// IDSEL 0x1c USB
0xe000 0 0 1 &i8259 12 2
0xe100 0 0 2 &i8259 9 2
>;
At some point in the file they create some (dummy?) pcie section in which they define a uli1575, an isa bus and attached to that isa bus a i8259. Is this the correct way of doing things? The i8259 driver seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined below but how are those mapped to the south bridge? I have seen some code in kernel/isa-bridge, is that code indeed responsible for setting up these ports?
pcie@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x02000000 0x0 0x80000000
0x02000000 0x0 0x80000000
0x0 0x20000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
0x0 0x00100000>;
uli1575@0 {
reg = <0 0 0 0 0>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <0x02000000 0x0 0x80000000
0x02000000 0x0 0x80000000
0x0 0x20000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
0x0 0x00100000>;
isa@1e {
device_type = "isa";
#interrupt-cells = <2>;
#size-cells = <1>;
#address-cells = <2>;
reg = <0xf000 0 0 0 0>;
ranges = <1 0 0x01000000 0 0
0x00001000>;
interrupt-parent = <&i8259>;
i8259: interrupt-controller@20 {
reg = <1 0x20 2
1 0xa0 2
1 0x4d0 2>;
interrupt-controller;
device_type = "interrupt-controller";
#address-cells = <0>;
#interrupt-cells = <2>;
compatible = "chrp,iic";
interrupts = <9 2>;
interrupt-parent = <&mpic>;
};
};
};
};
Thanks,
Roderick Colenbrander
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Mikhail Zolotaryov @ 2009-03-12 8:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200903120924.13378.sr@denx.de>
Stefan Roese wrote:
>> Either get the mem
>> size from there or some flag or version in there can indicate if it's
>> been "fixed".
>
> I don't think that we have some flag and/or version information in the bd_info
> struct. And extending this struct doesn't sound like a good idea to me.
May I suggest an easier way ?
The problem we currently have is some evaluation board(s), we know them,
use wrong DDR configuration parameters, so do as U-Boot does - simply
hardcode memory size for these particular board(s), don't calculate, but
use patched function to calculate memory size for all other boards,
including variety of customers' made. To be absolutely sure, we can
check board revision register - it's theoretically possible that future
board revisions will have more or less memory installed.
This way we can avoid U-Boot to Linux compatibility issues.
^ permalink raw reply
* Next 12 : arch/powerpc/sysdev/axonram build failure
From: Sachin Sant @ 2009-03-12 8:29 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-next
In-Reply-To: <20090312171154.11c6ec31.sfr@canb.auug.org.au>
Hi Stephen,
Today's next randconfig build on powerpc fails with
CC [M] arch/powerpc/sysdev/axonram.o
arch/powerpc/sysdev/axonram.c:108: warning: ‘struct request_queue’ declared inside parameter list
arch/powerpc/sysdev/axonram.c:108: warning: its scope is only this definition or declaration, which is probably not what you want
arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_make_request’:
arch/powerpc/sysdev/axonram.c:110: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:118: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:121: error: implicit declaration of function ‘bio_for_each_segment’
arch/powerpc/sysdev/axonram.c:121: error: expected ‘;’ before ‘{’ token
arch/powerpc/sysdev/axonram.c:112: warning: unused variable ‘user_mem’
arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_direct_access’:
arch/powerpc/sysdev/axonram.c:150: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:155: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c: At top level:
arch/powerpc/sysdev/axonram.c:168: error: variable ‘axon_ram_devops’ has initializer but incomplete type
arch/powerpc/sysdev/axonram.c:169: error: unknown field ‘owner’ specified in initializer
arch/powerpc/sysdev/axonram.c:169: warning: excess elements in struct initializer
arch/powerpc/sysdev/axonram.c:169: warning: (near initialization for ‘axon_ram_devops’)
arch/powerpc/sysdev/axonram.c:170: error: unknown field ‘direct_access’ specified in initializer
arch/powerpc/sysdev/axonram.c:171: warning: excess elements in struct initializer
arch/powerpc/sysdev/axonram.c:171: warning: (near initialization for ‘axon_ram_devops’)
arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_probe’:
arch/powerpc/sysdev/axonram.c:228: error: implicit declaration of function ‘alloc_disk’
arch/powerpc/sysdev/axonram.c:228: warning: assignment makes pointer from integer without a cast
arch/powerpc/sysdev/axonram.c:235: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:236: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:237: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:238: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:239: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:241: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:244: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:244: error: implicit declaration of function ‘blk_alloc_queue’
arch/powerpc/sysdev/axonram.c:245: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:251: error: implicit declaration of function ‘set_capacity’
arch/powerpc/sysdev/axonram.c:252: error: implicit declaration of function ‘blk_queue_make_request’
arch/powerpc/sysdev/axonram.c:252: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:253: error: implicit declaration of function ‘blk_queue_hardsect_size’
arch/powerpc/sysdev/axonram.c:253: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:254: error: implicit declaration of function ‘add_disk’
arch/powerpc/sysdev/axonram.c:264: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:279: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:288: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:289: error: implicit declaration of function ‘unregister_blkdev’
arch/powerpc/sysdev/axonram.c:289: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:290: error: dereferencing pointer to incomplete type
arch/powerpc/sysdev/axonram.c:291: error: implicit declaration of function ‘del_gendisk’
arch/powerpc/sysdev/axonram.c: In function ‘axon_ram_init’:
arch/powerpc/sysdev/axonram.c:345: error: implicit declaration of function ‘register_blkdev’
make[1]: *** [arch/powerpc/sysdev/axonram.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
CONFIG_BLOCK is not set.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Stefan Roese @ 2009-03-12 8:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, lebon
In-Reply-To: <1236845549.7086.86.camel@pasglop>
On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
> > Both is possible. Older U-Boot versions only passed the bd_t struct to
> > the kernel. For those U-Boot's the wrapper is needed. More recent U-Boot
> > versions support passing a device-tree blob to the kernel. U-Boot patches
> > the correct memory size in this blob.
> >
> > As a matter of fact, I never used the wrapper before. U-Boot supports
> > passing the device-tree blob to Linux since quite some time now.
>
> Yes, that's also how I use it on canyonlands... now, the wrapper could
> probably be used to look at the bd_t anyways, no ?
Sure.
> Either get the mem
> size from there or some flag or version in there can indicate if it's
> been "fixed".
I don't think that we have some flag and/or version information in the bd_info
struct. And extending this struct doesn't sound like a good idea to me.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Benjamin Herrenschmidt @ 2009-03-12 8:12 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, lebon
In-Reply-To: <200903120905.11542.sr@denx.de>
On Thu, 2009-03-12 at 09:05 +0100, Stefan Roese wrote:
>
> Both is possible. Older U-Boot versions only passed the bd_t struct to the
> kernel. For those U-Boot's the wrapper is needed. More recent U-Boot versions
> support passing a device-tree blob to the kernel. U-Boot patches the correct
> memory size in this blob.
>
> As a matter of fact, I never used the wrapper before. U-Boot supports passing
> the device-tree blob to Linux since quite some time now.
Yes, that's also how I use it on canyonlands... now, the wrapper could
probably be used to look at the bd_t anyways, no ? Either get the mem
size from there or some flag or version in there can indicate if it's
been "fixed".
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Stefan Roese @ 2009-03-12 8:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, lebon
In-Reply-To: <1236843157.7086.83.camel@pasglop>
On Thursday 12 March 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-03-12 at 07:02 +0100, Stefan Roese wrote:
> > I'll apply the U-Boot patch today. But as Josh pointed out, we should
> > try to
> > find a way for the bootwrapper to work in all cases.
>
> uboot is passing some kind of bt_t to the wrapper or a full
> device-tree ?
Both is possible. Older U-Boot versions only passed the bd_t struct to the
kernel. For those U-Boot's the wrapper is needed. More recent U-Boot versions
support passing a device-tree blob to the kernel. U-Boot patches the correct
memory size in this blob.
As a matter of fact, I never used the wrapper before. U-Boot supports passing
the device-tree blob to Linux since quite some time now.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Benjamin Herrenschmidt @ 2009-03-12 7:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, lebon
In-Reply-To: <200903120702.03286.sr@denx.de>
On Thu, 2009-03-12 at 07:02 +0100, Stefan Roese wrote:
>
> I'll apply the U-Boot patch today. But as Josh pointed out, we should
> try to
> find a way for the bootwrapper to work in all cases.
uboot is passing some kind of bt_t to the wrapper or a full
device-tree ?
Ben.
^ permalink raw reply
* Re: Linux boot problem, pc does not point to virtual memory
From: Benjamin Herrenschmidt @ 2009-03-12 7:31 UTC (permalink / raw)
To: FISCHER Thierry; +Cc: linuxppc-dev
In-Reply-To: <49B8A9A1.4090908@sdl.hitachi.co.jp>
On Thu, 2009-03-12 at 15:20 +0900, FISCHER Thierry wrote:
> Hi,
>
> I am having some problem booting linux on Powerpc 405 (xilinx virtex4).
>
> I have the following output on the terminal:
> ******************************************************
> zImage starting: loaded at 0x00400000 (sp: 0x0070feb0)
> Allocating 0x38a79c bytes for kernel ...
> gunzipping (0x00000000 <- 0x0040d000:0x0059ee42)...done 0x367f58 bytes
> Attached initrd image at 0x0059f000-0x0070ef20
> initrd head: 0x1f8b0808
>
> Linux/PowerPC load: console=ttyUL0 root=/dev/ram
> Finalizing device tree... flat tree at 0x71c300
> *******************************************************
>
> The strange thing is that when I check the value of pc register, it does
> not return values of the virtual memory but values like:
> pc :0x0000ebd4
> pc :0x00002148
> pc :0x00002194
> pc :0x00002150 ...
> Instead of values like 0xcXXXXXXX
If it's a 405 it has a real mode (for example when it takes an
exception) so it may just be running in real mode when you sample it.
Cheers
Ben.
> It looks like there is a problem with the MMU or something like that ?
> I have seen similar problems on the xilinx forum but it did not helped
> me so much:
> http://forums.xilinx.com/xlnx/board/message?board.id=ELINUX&message.id=595&query.id=371581#M595
>
> http://forums.xilinx.com/xlnx/board/message?board.id=EDK&message.id=6235&query.id=367949#M6235
>
>
> If anyone has experienced similar problem please let me know.
> Any suggestion is welcomed.
>
> Thanks,
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Linux boot problem, pc does not point to virtual memory
From: FISCHER Thierry @ 2009-03-12 6:20 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am having some problem booting linux on Powerpc 405 (xilinx virtex4).
I have the following output on the terminal:
******************************************************
zImage starting: loaded at 0x00400000 (sp: 0x0070feb0)
Allocating 0x38a79c bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x0059ee42)...done 0x367f58 bytes
Attached initrd image at 0x0059f000-0x0070ef20
initrd head: 0x1f8b0808
Linux/PowerPC load: console=ttyUL0 root=/dev/ram
Finalizing device tree... flat tree at 0x71c300
*******************************************************
The strange thing is that when I check the value of pc register, it does
not return values of the virtual memory but values like:
pc :0x0000ebd4
pc :0x00002148
pc :0x00002194
pc :0x00002150 ...
Instead of values like 0xcXXXXXXX
It looks like there is a problem with the MMU or something like that ?
I have seen similar problems on the xilinx forum but it did not helped
me so much:
http://forums.xilinx.com/xlnx/board/message?board.id=ELINUX&message.id=595&query.id=371581#M595
http://forums.xilinx.com/xlnx/board/message?board.id=EDK&message.id=6235&query.id=367949#M6235
If anyone has experienced similar problem please let me know.
Any suggestion is welcomed.
Thanks,
^ permalink raw reply
* Re: [PATCH] PowerPC 440EPx/GRx fix memory size calculation
From: Stefan Roese @ 2009-03-12 6:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: lebon
In-Reply-To: <49B80BA3.1090301@ru.mvista.com>
On Wednesday 11 March 2009, Valentine Barshak wrote:
> I've been looking at the docs once again and actually I couldn't find an
> explanation there. And I don't have that e-mail from AMCC support
> that I got a while back regarding the issue anymore.
> There might have been some misunderstanding.
> The docs (PPC440EPX UM 19.2 Device Address Mapping) say that the chip
> select field width is always fixed at one bit, but this doesn't actually
> mean that there's always one chip select used.
> The patch works fine on Sequoia and another Sequoia-like board with 1GB
> RAM installed, but it might not work with 2GB RAM. I've tried to play
> with DDR0_10 settings and Sequoia works fine regardless of what's
> actually written to DDR0_10.
> So, probably the best way would be to fix that in u-boot
> amcc/sequoia/sdram.c by doing mtsdram(DDR0_10, 0x00000100); instead of
> mtsdram(DDR0_10, 0x00000300);
> Sorry, for confusion, but after reviewing the docs, I think that
> only REDUC interpretation has to be fixed. The chips select part should
> be fixed in u-boot sdram code for Sequoia as was originally proposed by
> Mikhail.
>
> Stefan, could you please take a look?
I'll apply the U-Boot patch today. But as Josh pointed out, we should try to
find a way for the bootwrapper to work in all cases.
Best regards,
Stefan
^ permalink raw reply
* [PATCH 3/3] powerpc: Add virtual processor dispatch trace log
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236830152.728754.855135891014.1.gpush@pingu>
pseries SPLPAR machines are able to retrieve a log of dispatch and
preempt events from the hypervisor. With this information, we can
see when and why each dispatch & preempt is occuring.
This change adds a set of debugfs files allowing userspace to read this
dispatch log.
Based on initial patches from Nishanth Aravamudan <nacc@us.ibm.com>.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/platforms/pseries/Kconfig | 10
arch/powerpc/platforms/pseries/Makefile | 1
arch/powerpc/platforms/pseries/dtl.c | 274 ++++++++++++++++++++++++
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10
4 files changed, 295 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index ddc2a30..730a5cd 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -63,3 +63,13 @@ config CMM
makes sense for a system running in an LPAR where the unused pages
will be reused for other LPARs. The interface allows firmware to
balance memory across many LPARs.
+
+config DTL
+ bool "Dispatch Trace Log"
+ depends on PPC_SPLPAR && DEBUG_FS
+ help
+ SPLPAR machines can log hypervisor preempt & dispatch events to a
+ kernel buffer. Saying Y here will enable logging these events,
+ which are accessible through a debugfs file.
+
+ Say N if you are unsure.
diff --git a/arch/powerpc/platforms/pseries/Makefile b/arch/powerpc/platforms/pseries/Makefile
index dfe574a..1b388b3 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_HVCS) += hvcserver.o
obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
obj-$(CONFIG_PHYP_DUMP) += phyp_dump.o
obj-$(CONFIG_CMM) += cmm.o
+obj-$(CONFIG_DTL) += dtl.o
diff --git a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
new file mode 100644
index 0000000..dc9b0f8
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/dtl.c
@@ -0,0 +1,274 @@
+/*
+ * Virtual Processor Dispatch Trace Log
+ *
+ * (C) Copyright IBM Corporation 2009
+ *
+ * Author: Jeremy Kerr <jk@ozlabs.org>
+ *
+ * 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, 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/init.h>
+#include <linux/debugfs.h>
+#include <asm/smp.h>
+#include <asm/system.h>
+#include <asm/uaccess.h>
+
+#include "plpar_wrappers.h"
+
+/*
+ * Layout of entries in the hypervisor's DTL buffer. Although we don't
+ * actually access the internals of an entry (we only need to know the size),
+ * we might as well define it here for reference.
+ */
+struct dtl_entry {
+ u8 dispatch_reason;
+ u8 preempt_reason;
+ u16 processor_id;
+ u32 enqueue_to_dispatch_time;
+ u32 ready_to_enqueue_time;
+ u32 waiting_to_ready_time;
+ u64 timebase;
+ u64 fault_addr;
+ u64 srr0;
+ u64 srr1;
+};
+
+struct dtl {
+ struct dtl_entry *buf;
+ struct dentry *file;
+ int cpu;
+ int buf_entries;
+ u64 last_idx;
+};
+static DEFINE_PER_CPU(struct dtl, dtl);
+
+/*
+ * Dispatch trace log event mask:
+ * 0x7: 0x1: voluntary virtual processor waits
+ * 0x2: time-slice preempts
+ * 0x4: virtual partition memory page faults
+ */
+static u8 dtl_event_mask = 0x7;
+
+
+/*
+ * Size of per-cpu log buffers. Default is just under 16 pages worth.
+ */
+static int dtl_buf_entries = (16 * 85);
+
+
+static int dtl_enable(struct dtl *dtl)
+{
+ unsigned long addr;
+ int ret, hwcpu;
+
+ /* only allow one reader */
+ if (dtl->buf)
+ return -EBUSY;
+
+ /* we need to store the original allocation size for use during read */
+ dtl->buf_entries = dtl_buf_entries;
+
+ dtl->buf = kmalloc_node(dtl->buf_entries * sizeof(struct dtl_entry),
+ GFP_KERNEL, cpu_to_node(dtl->cpu));
+ if (!dtl->buf) {
+ printk(KERN_WARNING "%s: buffer alloc failed for cpu %d\n",
+ __func__, dtl->cpu);
+ return -ENOMEM;
+ }
+
+ /* Register our dtl buffer with the hypervisor. The HV expects the
+ * buffer size to be passed in the second word of the buffer */
+ ((u32 *)dtl->buf)[1] = dtl->buf_entries * sizeof(struct dtl_entry);
+
+ hwcpu = get_hard_smp_processor_id(dtl->cpu);
+ addr = __pa(dtl->buf);
+ ret = register_dtl(hwcpu, addr);
+ if (ret) {
+ printk(KERN_WARNING "%s: DTL registration for cpu %d (hw %d) "
+ "failed with %d\n", __func__, dtl->cpu, hwcpu, ret);
+ kfree(dtl->buf);
+ return -EIO;
+ }
+
+ /* set our initial buffer indices */
+ dtl->last_idx = lppaca[dtl->cpu].dtl_idx = 0;
+
+ /* enable event logging */
+ lppaca[dtl->cpu].dtl_enable_mask = dtl_event_mask;
+
+ return 0;
+}
+
+static void dtl_disable(struct dtl *dtl)
+{
+ int hwcpu = get_hard_smp_processor_id(dtl->cpu);
+
+ lppaca[dtl->cpu].dtl_enable_mask = 0x0;
+
+ unregister_dtl(hwcpu, __pa(dtl->buf));
+
+ kfree(dtl->buf);
+ dtl->buf = NULL;
+ dtl->buf_entries = 0;
+}
+
+/* file interface */
+
+static int dtl_file_open(struct inode *inode, struct file *filp)
+{
+ struct dtl *dtl = inode->i_private;
+ int rc;
+
+ rc = dtl_enable(dtl);
+ if (rc)
+ return rc;
+
+ filp->private_data = dtl;
+ return 0;
+}
+
+static int dtl_file_release(struct inode *inode, struct file *filp)
+{
+ struct dtl *dtl = inode->i_private;
+ dtl_disable(dtl);
+ return 0;
+}
+
+static ssize_t dtl_file_read(struct file *filp, char __user *buf, size_t len,
+ loff_t *pos)
+{
+ int rc, cur_idx, last_idx, n_read, n_req, read_size;
+ struct dtl *dtl;
+
+ if ((len % sizeof(struct dtl_entry)) != 0)
+ return -EINVAL;
+
+ dtl = filp->private_data;
+
+ /* requested number of entries to read */
+ n_req = len / sizeof(struct dtl_entry);
+
+ /* actual number of entries read */
+ n_read = 0;
+
+ cur_idx = lppaca[dtl->cpu].dtl_idx;
+ last_idx = dtl->last_idx;
+
+ if (cur_idx - last_idx > dtl->buf_entries) {
+ pr_debug("%s: hv buffer overflow for cpu %d, samples lost\n",
+ __func__, dtl->cpu);
+ }
+
+ cur_idx %= dtl->buf_entries;
+ last_idx %= dtl->buf_entries;
+
+ /* read the tail of the buffer if we've wrapped */
+ if (last_idx > cur_idx) {
+ read_size = min(n_req, dtl->buf_entries - last_idx);
+
+ rc = copy_to_user(buf, &dtl->buf[last_idx],
+ read_size * sizeof(struct dtl_entry));
+ if (rc)
+ return -EFAULT;
+
+ last_idx = 0;
+ n_req -= read_size;
+ n_read += read_size;
+ buf += read_size * sizeof(struct dtl_entry);
+ }
+
+ /* .. and now the head */
+ read_size = min(n_req, cur_idx - last_idx);
+ rc = copy_to_user(buf, &dtl->buf[last_idx],
+ read_size * sizeof(struct dtl_entry));
+ if (rc)
+ return -EFAULT;
+
+ n_read += read_size;
+ dtl->last_idx += n_read;
+
+ return n_read * sizeof(struct dtl_entry);
+}
+
+static struct file_operations dtl_fops = {
+ .open = dtl_file_open,
+ .release = dtl_file_release,
+ .read = dtl_file_read,
+ .llseek = no_llseek,
+};
+
+static struct dentry *dtl_dir;
+
+static int dtl_setup_file(struct dtl *dtl)
+{
+ char name[10];
+
+ sprintf(name, "cpu-%d", dtl->cpu);
+
+ dtl->file = debugfs_create_file(name, 0400, dtl_dir, dtl, &dtl_fops);
+ if (!dtl->file)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int dtl_init(void)
+{
+ struct dentry *event_mask_file, *buf_entries_file;
+ int rc, i;
+
+ if (!firmware_has_feature(FW_FEATURE_SPLPAR))
+ return -ENODEV;
+
+ /* set up common debugfs structure */
+
+ rc = -ENOMEM;
+ dtl_dir = debugfs_create_dir("dtl", powerpc_debugfs_root);
+ if (!dtl_dir) {
+ printk(KERN_WARNING "%s: can't create dtl root dir\n",
+ __func__);
+ goto err;
+ }
+
+ event_mask_file = debugfs_create_x8("dtl_event_mask", 0600,
+ dtl_dir, &dtl_event_mask);
+ buf_entries_file = debugfs_create_u32("dtl_buf_entries", 0600,
+ dtl_dir, &dtl_buf_entries);
+
+ if (!event_mask_file || !buf_entries_file) {
+ printk(KERN_WARNING "%s: can't create dtl files\n", __func__);
+ goto err_remove_dir;
+ }
+
+ /* set up the per-cpu log structures */
+ for_each_possible_cpu(i) {
+ struct dtl *dtl = &per_cpu(dtl, i);
+ dtl->cpu = i;
+
+ rc = dtl_setup_file(dtl);
+ if (rc)
+ goto err_remove_dir;
+ }
+
+ return 0;
+
+err_remove_dir:
+ debugfs_remove_recursive(dtl_dir);
+err:
+ return rc;
+}
+arch_initcall(dtl_init);
diff --git a/arch/powerpc/platforms/pseries/plpar_wrappers.h b/arch/powerpc/platforms/pseries/plpar_wrappers.h
index d967c18..a24a6b2 100644
--- a/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ b/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -43,6 +43,16 @@ static inline long register_slb_shadow(unsigned long cpu, unsigned long vpa)
return vpa_call(0x3, cpu, vpa);
}
+static inline long unregister_dtl(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x6, cpu, vpa);
+}
+
+static inline long register_dtl(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x2, cpu, vpa);
+}
+
static inline long plpar_page_set_loaned(unsigned long vpa)
{
unsigned long cmo_page_sz = cmo_get_page_size();
^ permalink raw reply related
* [PATCH 2/3] powerpc: Add dispatch trace log fields to lppaca
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1236830152.728754.855135891014.1.gpush@pingu>
PAPR v2.3 defines fields in the virtual processor area for a dispatch
trace log (DLT). Since we'd like to use the DLT, add the necessary
fields to struct lppaca.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/include/asm/lppaca.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index b063121..68235f7 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -97,7 +97,7 @@ struct lppaca {
u64 saved_gpr4; // Saved GPR4 x28-x2F
u64 saved_gpr5; // Saved GPR5 x30-x37
- u8 reserved4; // Reserved x38-x38
+ u8 dtl_enable_mask; // Dispatch Trace Log mask x38-x38
u8 donate_dedicated_cpu; // Donate dedicated CPU cycles x39-x39
u8 fpregs_in_use; // FP regs in use x3A-x3A
u8 pmcregs_in_use; // PMC regs in use x3B-x3B
@@ -134,7 +134,9 @@ struct lppaca {
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=============================================================================
u32 page_ins; // CMO Hint - # page ins by OS x00-x03
- u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
+ u8 reserved8[148]; // Reserved x04-x97
+ volatile u64 dtl_idx; // Dispatch Trace Log head idx x98-x9F
+ u8 reserved9[96]; // Reserved xA0-xFF
} __attribute__((__aligned__(0x400)));
extern struct lppaca lppaca[];
^ permalink raw reply related
* [PATCH 1/3] powerpc: Fix page_ins details in lppaca comments
From: Jeremy Kerr @ 2009-03-12 3:55 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev
The page_ins member ends at byte 0x3, not 0x4. Also, fix up the
alignment.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
---
arch/powerpc/include/asm/lppaca.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/lppaca.h b/arch/powerpc/include/asm/lppaca.h
index 25aaa97..b063121 100644
--- a/arch/powerpc/include/asm/lppaca.h
+++ b/arch/powerpc/include/asm/lppaca.h
@@ -133,7 +133,7 @@ struct lppaca {
//=============================================================================
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=============================================================================
- u32 page_ins; // CMO Hint - # page ins by OS x00-x04
+ u32 page_ins; // CMO Hint - # page ins by OS x00-x03
u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
} __attribute__((__aligned__(0x400)));
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox