* mscan status on DENX Linux 2.6 Kernel Tree
From: moises.dominguez @ 2011-04-07 9:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
Hi,
Up to now I've been working ltib over and ads5121 based board.
So as not to work with frozen images I would like to change to u-boot and
kernel from denx. I did the following:
- Download and compile u-boot: OK.
- Download and kernel (mpc512x_defconfig): compilation fails if I enable
"Freescale MPC5xxx onboard CAN controller" with this message:
.
LD kernel/built-in.o
CC drivers/net/can/mscan/mscan.o
CC drivers/net/can/mscan/mpc5xxx_can.o
drivers/net/can/mscan/mpc5xxx_can.c: In function 'mpc5xxx_can_probe':
drivers/net/can/mscan/mpc5xxx_can.c:263: error: 'of_dev' undeclared (first
use in this function)
.
I have not much experience with this stuff but I've notice that there are
recent patches on mpc5xxx.c file, last from 2011-02-28 so I suppose this
should work.
Am I missing something? I also wonder if ads5121-Rev4 is fully supported in
Linux Denx.
Thanks,
Moises.
[-- Attachment #2: Type: text/html, Size: 4028 bytes --]
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-07 11:25 UTC (permalink / raw)
To: Dave Airlie; +Cc: Greg KH, linuxppc-dev, LKML, Uwe Kleine-König
In-Reply-To: <BANLkTimAJ-s_3A3L1YGfoFLmd4bpu2jWVA@mail.gmail.com>
Hi Dave,
> This is the old DRM driver for radeon, which relies on userspace to
> start X then calls the kernel
Actually, even the old DRM driver occasionally hangs on this machine,
I suspect a missing barrier, but I might be completely off base.
The system is up, only X uses 100% of one core and according to
gdb X is there:
(gdb) info stack
#0 0x0fbafb08 in ioctl () from /lib/libc.so.6
#1 0x0f7be1c8 in drmDMA () from /usr/lib/libdrm.so.2
#2 0x0f65330c in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so
#3 0x0f65380c in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so
#4 0x0f6f89b8 in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so
#5 0x0f562538 in ?? () from /usr/lib/xorg/modules/libexa.so
#6 0x0f56298c in ?? () from /usr/lib/xorg/modules/libexa.so
#7 0x0f56351c in ?? () from /usr/lib/xorg/modules/libexa.so
#8 0x0f55fba0 in ?? () from /usr/lib/xorg/modules/libexa.so
#9 0x0f56ab18 in ?? () from /usr/lib/xorg/modules/libexa.so
#10 0x0f56b810 in ?? () from /usr/lib/xorg/modules/libexa.so
#11 0x100f168c in ?? ()
#12 0x100df0fc in CompositePicture ()
#13 0x0f56a748 in ?? () from /usr/lib/xorg/modules/libexa.so
#14 0x100dee08 in CompositeTrapezoids ()
#15 0x100eb318 in ?? ()
#16 0x100e3ae8 in ?? ()
#17 0x1004a1f0 in ?? ()
#18 0x1001d0d4 in ?? ()
#19 0x0faea63c in ?? () from /lib/libc.so.6
#20 0x0faea800 in __libc_start_main () from /lib/libc.so.6
#21 0x00000000 in ?? ()
I don't know how to get more details.
Regards,
Gabriel
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Gabriel Paubert @ 2011-04-07 11:33 UTC (permalink / raw)
To: Dave Airlie; +Cc: Greg KH, linuxppc-dev, LKML, Uwe Kleine-König
In-Reply-To: <BANLkTimAJ-s_3A3L1YGfoFLmd4bpu2jWVA@mail.gmail.com>
Hi Dave,
sorry, in my previous message I forgot the strace
output, which is an inifinite loop of the following:
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(7, 0xc0286429, 0xffdf9bb8) = -1 EBUSY (Device or resource busy)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn() = ? (mask now [])
ioctl(7, 0xc0286429, 0xffdf9bb8) = -1 EBUSY (Device or resource busy)
Note: fd 7 is /dev/dri/card0.
Regards,
Gabriel
^ permalink raw reply
* [PATCH] rtas: Only sleep in rtas_busy_delay if we have useful work to do
From: Anton Blanchard @ 2011-04-07 11:54 UTC (permalink / raw)
To: benh, paulus; +Cc: nacc, linuxppc-dev, miltonm
RTAS returns extended error codes as a hint of how long the
OS might want to wait before retrying a call. If we have nothing
else useful to do we may as well call back straight away.
This was found when testing the new dynamic dma window feature.
Firmware split the zeroing of the TCE table into 32k chunks but
returned 9901 (which is a suggested wait of 10ms). All up this took
about 10 minutes to complete since msleep is jiffies based and will
round 10ms up to 20ms.
With the patch below we take 3 seconds to complete the same test.
The hint firmware is returning in the RTAS call should definitely
be decreased, but even if we slept 1ms each iteration this would
take 32s.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/rtas.c 2011-04-05 11:19:35.023234011 +1000
+++ linux-2.6/arch/powerpc/kernel/rtas.c 2011-04-07 21:25:24.646414629 +1000
@@ -494,7 +494,7 @@ unsigned int rtas_busy_delay(int status)
might_sleep();
ms = rtas_busy_delay_time(status);
- if (ms)
+ if (ms && need_resched())
msleep(ms);
return ms;
^ permalink raw reply
* Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
From: Michel Dänzer @ 2011-04-07 14:04 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Greg KH, Uwe Kleine-König, Dave Airlie, linuxppc-dev, LKML
In-Reply-To: <20110406204327.GA11148@iram.es>
On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote:=20
>=20
> The probem is that, at least on one of my machines, the new driver
> does not work: the system hangs (apparently solid, but it's before
> networking starts up and I've not yet hooked up a serial console),=20
> after the "radeon: ib pool ready" message.
Does radeon.agpmode=3D-1 radeon.no_wb=3D1 help?
You might be able to get more information via netconsole if you prevent
the radeon module from loading automatically (or load it with
radeon.modeset=3D0 first) and then load it e.g. via ssh with modeset=3D1.
It would be interesting to see at least all agp/drm/radeon related
kernel messages before the problem occurs.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH][v2] powerpc/85xx: P1020 DTS : re-organize dts files
From: Grant Likely @ 2011-04-07 14:29 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: meet2prabhu, devicetree-discuss, linuxppc-dev, kumar.gala
In-Reply-To: <1302167455-21538-1-git-send-email-prabhakar@freescale.com>
On Thu, Apr 07, 2011 at 02:40:55PM +0530, Prabhakar Kushwaha wrote:
> Creates P1020si.dtsi, containing information for the P1020 SoC. Modifies dts
> files for P1020 based systems to use dtsi file
>
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> Acked-by: Kumar Gala <kumar.gala@freescale.com>
Looks good to me.
Acked-by: Grant Likely <grant.likelY@secretlab.ca>
g.
> ---
> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch master)
>
> Please see mpc5200b.dtsi for reference.
>
> Tested on P1020RDB
>
> Changes for v2: Incorporated Grant Likely's comment
> -updated model name
>
> arch/powerpc/boot/dts/p1020rdb.dts | 316 +------------------------------
> arch/powerpc/boot/dts/p1020si.dtsi | 377 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 380 insertions(+), 313 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/p1020si.dtsi
>
> diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
> index e0668f8..7ed4793 100644
> --- a/arch/powerpc/boot/dts/p1020rdb.dts
> +++ b/arch/powerpc/boot/dts/p1020rdb.dts
> @@ -9,12 +9,11 @@
> * option) any later version.
> */
>
> -/dts-v1/;
> +/include/ "p1020si.dtsi"
> +
> / {
> - model = "fsl,P1020";
> + model = "fsl,P1020RDB";
> compatible = "fsl,P1020RDB";
> - #address-cells = <2>;
> - #size-cells = <2>;
>
> aliases {
> serial0 = &serial0;
> @@ -26,34 +25,11 @@
> pci1 = &pci1;
> };
>
> - cpus {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - PowerPC,P1020@0 {
> - device_type = "cpu";
> - reg = <0x0>;
> - next-level-cache = <&L2>;
> - };
> -
> - PowerPC,P1020@1 {
> - device_type = "cpu";
> - reg = <0x1>;
> - next-level-cache = <&L2>;
> - };
> - };
> -
> memory {
> device_type = "memory";
> };
>
> localbus@ffe05000 {
> - #address-cells = <2>;
> - #size-cells = <1>;
> - compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
> - reg = <0 0xffe05000 0 0x1000>;
> - interrupts = <19 2>;
> - interrupt-parent = <&mpic>;
>
> /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
> ranges = <0x0 0x0 0x0 0xef000000 0x01000000
> @@ -165,88 +141,14 @@
> };
>
> soc@ffe00000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - device_type = "soc";
> - compatible = "fsl,p1020-immr", "simple-bus";
> - ranges = <0x0 0x0 0xffe00000 0x100000>;
> - bus-frequency = <0>; // Filled out by uboot.
> -
> - ecm-law@0 {
> - compatible = "fsl,ecm-law";
> - reg = <0x0 0x1000>;
> - fsl,num-laws = <12>;
> - };
> -
> - ecm@1000 {
> - compatible = "fsl,p1020-ecm", "fsl,ecm";
> - reg = <0x1000 0x1000>;
> - interrupts = <16 2>;
> - interrupt-parent = <&mpic>;
> - };
> -
> - memory-controller@2000 {
> - compatible = "fsl,p1020-memory-controller";
> - reg = <0x2000 0x1000>;
> - interrupt-parent = <&mpic>;
> - interrupts = <16 2>;
> - };
> -
> i2c@3000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - cell-index = <0>;
> - compatible = "fsl-i2c";
> - reg = <0x3000 0x100>;
> - interrupts = <43 2>;
> - interrupt-parent = <&mpic>;
> - dfsrr;
> rtc@68 {
> compatible = "dallas,ds1339";
> reg = <0x68>;
> };
> };
>
> - i2c@3100 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - cell-index = <1>;
> - compatible = "fsl-i2c";
> - reg = <0x3100 0x100>;
> - interrupts = <43 2>;
> - interrupt-parent = <&mpic>;
> - dfsrr;
> - };
> -
> - serial0: serial@4500 {
> - cell-index = <0>;
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <0x4500 0x100>;
> - clock-frequency = <0>;
> - interrupts = <42 2>;
> - interrupt-parent = <&mpic>;
> - };
> -
> - serial1: serial@4600 {
> - cell-index = <1>;
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <0x4600 0x100>;
> - clock-frequency = <0>;
> - interrupts = <42 2>;
> - interrupt-parent = <&mpic>;
> - };
> -
> spi@7000 {
> - cell-index = <0>;
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "fsl,espi";
> - reg = <0x7000 0x1000>;
> - interrupts = <59 0x2>;
> - interrupt-parent = <&mpic>;
> - mode = "cpu";
>
> fsl_m25p80@0 {
> #address-cells = <1>;
> @@ -294,66 +196,7 @@
> };
> };
>
> - gpio: gpio-controller@f000 {
> - #gpio-cells = <2>;
> - compatible = "fsl,mpc8572-gpio";
> - reg = <0xf000 0x100>;
> - interrupts = <47 0x2>;
> - interrupt-parent = <&mpic>;
> - gpio-controller;
> - };
> -
> - L2: l2-cache-controller@20000 {
> - compatible = "fsl,p1020-l2-cache-controller";
> - reg = <0x20000 0x1000>;
> - cache-line-size = <32>; // 32 bytes
> - cache-size = <0x40000>; // L2,256K
> - interrupt-parent = <&mpic>;
> - interrupts = <16 2>;
> - };
> -
> - dma@21300 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - compatible = "fsl,eloplus-dma";
> - reg = <0x21300 0x4>;
> - ranges = <0x0 0x21100 0x200>;
> - cell-index = <0>;
> - dma-channel@0 {
> - compatible = "fsl,eloplus-dma-channel";
> - reg = <0x0 0x80>;
> - cell-index = <0>;
> - interrupt-parent = <&mpic>;
> - interrupts = <20 2>;
> - };
> - dma-channel@80 {
> - compatible = "fsl,eloplus-dma-channel";
> - reg = <0x80 0x80>;
> - cell-index = <1>;
> - interrupt-parent = <&mpic>;
> - interrupts = <21 2>;
> - };
> - dma-channel@100 {
> - compatible = "fsl,eloplus-dma-channel";
> - reg = <0x100 0x80>;
> - cell-index = <2>;
> - interrupt-parent = <&mpic>;
> - interrupts = <22 2>;
> - };
> - dma-channel@180 {
> - compatible = "fsl,eloplus-dma-channel";
> - reg = <0x180 0x80>;
> - cell-index = <3>;
> - interrupt-parent = <&mpic>;
> - interrupts = <23 2>;
> - };
> - };
> -
> mdio@24000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "fsl,etsec2-mdio";
> - reg = <0x24000 0x1000 0xb0030 0x4>;
>
> phy0: ethernet-phy@0 {
> interrupt-parent = <&mpic>;
> @@ -369,10 +212,6 @@
> };
>
> mdio@25000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "fsl,etsec2-tbi";
> - reg = <0x25000 0x1000 0xb1030 0x4>;
>
> tbi0: tbi-phy@11 {
> reg = <0x11>;
> @@ -381,97 +220,25 @@
> };
>
> enet0: ethernet@b0000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - device_type = "network";
> - model = "eTSEC";
> - compatible = "fsl,etsec2";
> - fsl,num_rx_queues = <0x8>;
> - fsl,num_tx_queues = <0x8>;
> - local-mac-address = [ 00 00 00 00 00 00 ];
> - interrupt-parent = <&mpic>;
> fixed-link = <1 1 1000 0 0>;
> phy-connection-type = "rgmii-id";
>
> - queue-group@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb0000 0x1000>;
> - interrupts = <29 2 30 2 34 2>;
> - };
> -
> - queue-group@1 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb4000 0x1000>;
> - interrupts = <17 2 18 2 24 2>;
> - };
> };
>
> enet1: ethernet@b1000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - device_type = "network";
> - model = "eTSEC";
> - compatible = "fsl,etsec2";
> - fsl,num_rx_queues = <0x8>;
> - fsl,num_tx_queues = <0x8>;
> - local-mac-address = [ 00 00 00 00 00 00 ];
> - interrupt-parent = <&mpic>;
> phy-handle = <&phy0>;
> tbi-handle = <&tbi0>;
> phy-connection-type = "sgmii";
>
> - queue-group@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb1000 0x1000>;
> - interrupts = <35 2 36 2 40 2>;
> - };
> -
> - queue-group@1 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb5000 0x1000>;
> - interrupts = <51 2 52 2 67 2>;
> - };
> };
>
> enet2: ethernet@b2000 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - device_type = "network";
> - model = "eTSEC";
> - compatible = "fsl,etsec2";
> - fsl,num_rx_queues = <0x8>;
> - fsl,num_tx_queues = <0x8>;
> - local-mac-address = [ 00 00 00 00 00 00 ];
> - interrupt-parent = <&mpic>;
> phy-handle = <&phy1>;
> phy-connection-type = "rgmii-id";
>
> - queue-group@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb2000 0x1000>;
> - interrupts = <31 2 32 2 33 2>;
> - };
> -
> - queue-group@1 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - reg = <0xb6000 0x1000>;
> - interrupts = <25 2 26 2 27 2>;
> - };
> };
>
> usb@22000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "fsl-usb2-dr";
> - reg = <0x22000 0x1000>;
> - interrupt-parent = <&mpic>;
> - interrupts = <28 0x2>;
> phy_type = "ulpi";
> };
>
> @@ -481,82 +248,15 @@
> it enables USB2. OTOH, U-Boot does create a new node
> when there isn't any. So, just comment it out.
> usb@23000 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> - compatible = "fsl-usb2-dr";
> - reg = <0x23000 0x1000>;
> - interrupt-parent = <&mpic>;
> - interrupts = <46 0x2>;
> phy_type = "ulpi";
> };
> */
>
> - sdhci@2e000 {
> - compatible = "fsl,p1020-esdhc", "fsl,esdhc";
> - reg = <0x2e000 0x1000>;
> - interrupts = <72 0x2>;
> - interrupt-parent = <&mpic>;
> - /* Filled in by U-Boot */
> - clock-frequency = <0>;
> - };
> -
> - crypto@30000 {
> - compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
> - "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
> - reg = <0x30000 0x10000>;
> - interrupts = <45 2 58 2>;
> - interrupt-parent = <&mpic>;
> - fsl,num-channels = <4>;
> - fsl,channel-fifo-len = <24>;
> - fsl,exec-units-mask = <0xbfe>;
> - fsl,descriptor-types-mask = <0x3ab0ebf>;
> - };
> -
> - mpic: pic@40000 {
> - interrupt-controller;
> - #address-cells = <0>;
> - #interrupt-cells = <2>;
> - reg = <0x40000 0x40000>;
> - compatible = "chrp,open-pic";
> - device_type = "open-pic";
> - };
> -
> - msi@41600 {
> - compatible = "fsl,p1020-msi", "fsl,mpic-msi";
> - reg = <0x41600 0x80>;
> - msi-available-ranges = <0 0x100>;
> - interrupts = <
> - 0xe0 0
> - 0xe1 0
> - 0xe2 0
> - 0xe3 0
> - 0xe4 0
> - 0xe5 0
> - 0xe6 0
> - 0xe7 0>;
> - interrupt-parent = <&mpic>;
> - };
> -
> - global-utilities@e0000 { //global utilities block
> - compatible = "fsl,p1020-guts";
> - reg = <0xe0000 0x1000>;
> - fsl,has-rstcr;
> - };
> };
>
> pci0: pcie@ffe09000 {
> - compatible = "fsl,mpc8548-pcie";
> - device_type = "pci";
> - #interrupt-cells = <1>;
> - #size-cells = <2>;
> - #address-cells = <3>;
> - reg = <0 0xffe09000 0 0x1000>;
> - bus-range = <0 255>;
> ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
> 0x1000000 0x0 0x00000000 0 0xffc10000 0x0 0x10000>;
> - clock-frequency = <33333333>;
> - interrupt-parent = <&mpic>;
> - interrupts = <16 2>;
> pcie@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> @@ -573,18 +273,8 @@
> };
>
> pci1: pcie@ffe0a000 {
> - compatible = "fsl,mpc8548-pcie";
> - device_type = "pci";
> - #interrupt-cells = <1>;
> - #size-cells = <2>;
> - #address-cells = <3>;
> - reg = <0 0xffe0a000 0 0x1000>;
> - bus-range = <0 255>;
> ranges = <0x2000000 0x0 0x80000000 0 0x80000000 0x0 0x20000000
> 0x1000000 0x0 0x00000000 0 0xffc00000 0x0 0x10000>;
> - clock-frequency = <33333333>;
> - interrupt-parent = <&mpic>;
> - interrupts = <16 2>;
> pcie@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> diff --git a/arch/powerpc/boot/dts/p1020si.dtsi b/arch/powerpc/boot/dts/p1020si.dtsi
> new file mode 100644
> index 0000000..f6f1100
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/p1020si.dtsi
> @@ -0,0 +1,377 @@
> +/*
> + * P1020si Device Tree Source
> + *
> + * Copyright 2011 Freescale Semiconductor Inc.
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +/ {
> + compatible = "fsl,P1020";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,P1020@0 {
> + device_type = "cpu";
> + reg = <0x0>;
> + next-level-cache = <&L2>;
> + };
> +
> + PowerPC,P1020@1 {
> + device_type = "cpu";
> + reg = <0x1>;
> + next-level-cache = <&L2>;
> + };
> + };
> +
> + localbus@ffe05000 {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + compatible = "fsl,p1020-elbc", "fsl,elbc", "simple-bus";
> + reg = <0 0xffe05000 0 0x1000>;
> + interrupts = <19 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + soc@ffe00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + compatible = "fsl,p1020-immr", "simple-bus";
> + ranges = <0x0 0x0 0xffe00000 0x100000>;
> + bus-frequency = <0>; // Filled out by uboot.
> +
> + ecm-law@0 {
> + compatible = "fsl,ecm-law";
> + reg = <0x0 0x1000>;
> + fsl,num-laws = <12>;
> + };
> +
> + ecm@1000 {
> + compatible = "fsl,p1020-ecm", "fsl,ecm";
> + reg = <0x1000 0x1000>;
> + interrupts = <16 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + memory-controller@2000 {
> + compatible = "fsl,p1020-memory-controller";
> + reg = <0x2000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <16 2>;
> + };
> +
> + i2c@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <43 2>;
> + interrupt-parent = <&mpic>;
> + dfsrr;
> + };
> +
> + i2c@3100 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <1>;
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <43 2>;
> + interrupt-parent = <&mpic>;
> + dfsrr;
> + };
> +
> + serial0: serial@4500 {
> + cell-index = <0>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4500 0x100>;
> + clock-frequency = <0>;
> + interrupts = <42 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + serial1: serial@4600 {
> + cell-index = <1>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <0x4600 0x100>;
> + clock-frequency = <0>;
> + interrupts = <42 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + spi@7000 {
> + cell-index = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,espi";
> + reg = <0x7000 0x1000>;
> + interrupts = <59 0x2>;
> + interrupt-parent = <&mpic>;
> + mode = "cpu";
> + };
> +
> + gpio: gpio-controller@f000 {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8572-gpio";
> + reg = <0xf000 0x100>;
> + interrupts = <47 0x2>;
> + interrupt-parent = <&mpic>;
> + gpio-controller;
> + };
> +
> + L2: l2-cache-controller@20000 {
> + compatible = "fsl,p1020-l2-cache-controller";
> + reg = <0x20000 0x1000>;
> + cache-line-size = <32>; // 32 bytes
> + cache-size = <0x40000>; // L2,256K
> + interrupt-parent = <&mpic>;
> + interrupts = <16 2>;
> + };
> +
> + dma@21300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,eloplus-dma";
> + reg = <0x21300 0x4>;
> + ranges = <0x0 0x21100 0x200>;
> + cell-index = <0>;
> + dma-channel@0 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + cell-index = <0>;
> + interrupt-parent = <&mpic>;
> + interrupts = <20 2>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + cell-index = <1>;
> + interrupt-parent = <&mpic>;
> + interrupts = <21 2>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + cell-index = <2>;
> + interrupt-parent = <&mpic>;
> + interrupts = <22 2>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x180 0x80>;
> + cell-index = <3>;
> + interrupt-parent = <&mpic>;
> + interrupts = <23 2>;
> + };
> + };
> +
> + mdio@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,etsec2-mdio";
> + reg = <0x24000 0x1000 0xb0030 0x4>;
> +
> + };
> +
> + mdio@25000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,etsec2-tbi";
> + reg = <0x25000 0x1000 0xb1030 0x4>;
> +
> + };
> +
> + enet0: ethernet@b0000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "fsl,etsec2";
> + fsl,num_rx_queues = <0x8>;
> + fsl,num_tx_queues = <0x8>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupt-parent = <&mpic>;
> +
> + queue-group@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb0000 0x1000>;
> + interrupts = <29 2 30 2 34 2>;
> + };
> +
> + queue-group@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb4000 0x1000>;
> + interrupts = <17 2 18 2 24 2>;
> + };
> + };
> +
> + enet1: ethernet@b1000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "fsl,etsec2";
> + fsl,num_rx_queues = <0x8>;
> + fsl,num_tx_queues = <0x8>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupt-parent = <&mpic>;
> +
> + queue-group@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb1000 0x1000>;
> + interrupts = <35 2 36 2 40 2>;
> + };
> +
> + queue-group@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb5000 0x1000>;
> + interrupts = <51 2 52 2 67 2>;
> + };
> + };
> +
> + enet2: ethernet@b2000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "fsl,etsec2";
> + fsl,num_rx_queues = <0x8>;
> + fsl,num_tx_queues = <0x8>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupt-parent = <&mpic>;
> +
> + queue-group@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb2000 0x1000>;
> + interrupts = <31 2 32 2 33 2>;
> + };
> +
> + queue-group@1 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xb6000 0x1000>;
> + interrupts = <25 2 26 2 27 2>;
> + };
> + };
> +
> + usb@22000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl-usb2-dr";
> + reg = <0x22000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <28 0x2>;
> + };
> +
> + /* USB2 is shared with localbus, so it must be disabled
> + by default. We can't put 'status = "disabled";' here
> + since U-Boot doesn't clear the status property when
> + it enables USB2. OTOH, U-Boot does create a new node
> + when there isn't any. So, just comment it out.
> + usb@23000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl-usb2-dr";
> + reg = <0x23000 0x1000>;
> + interrupt-parent = <&mpic>;
> + interrupts = <46 0x2>;
> + phy_type = "ulpi";
> + };
> + */
> +
> + sdhci@2e000 {
> + compatible = "fsl,p1020-esdhc", "fsl,esdhc";
> + reg = <0x2e000 0x1000>;
> + interrupts = <72 0x2>;
> + interrupt-parent = <&mpic>;
> + /* Filled in by U-Boot */
> + clock-frequency = <0>;
> + };
> +
> + crypto@30000 {
> + compatible = "fsl,sec3.1", "fsl,sec3.0", "fsl,sec2.4",
> + "fsl,sec2.2", "fsl,sec2.1", "fsl,sec2.0";
> + reg = <0x30000 0x10000>;
> + interrupts = <45 2 58 2>;
> + interrupt-parent = <&mpic>;
> + fsl,num-channels = <4>;
> + fsl,channel-fifo-len = <24>;
> + fsl,exec-units-mask = <0xbfe>;
> + fsl,descriptor-types-mask = <0x3ab0ebf>;
> + };
> +
> + mpic: pic@40000 {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <0x40000 0x40000>;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + };
> +
> + msi@41600 {
> + compatible = "fsl,p1020-msi", "fsl,mpic-msi";
> + reg = <0x41600 0x80>;
> + msi-available-ranges = <0 0x100>;
> + interrupts = <
> + 0xe0 0
> + 0xe1 0
> + 0xe2 0
> + 0xe3 0
> + 0xe4 0
> + 0xe5 0
> + 0xe6 0
> + 0xe7 0>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + global-utilities@e0000 { //global utilities block
> + compatible = "fsl,p1020-guts";
> + reg = <0xe0000 0x1000>;
> + fsl,has-rstcr;
> + };
> + };
> +
> + pci0: pcie@ffe09000 {
> + compatible = "fsl,mpc8548-pcie";
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <0 0xffe09000 0 0x1000>;
> + bus-range = <0 255>;
> + clock-frequency = <33333333>;
> + interrupt-parent = <&mpic>;
> + interrupts = <16 2>;
> + };
> +
> + pci1: pcie@ffe0a000 {
> + compatible = "fsl,mpc8548-pcie";
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <0 0xffe0a000 0 0x1000>;
> + bus-range = <0 255>;
> + clock-frequency = <33333333>;
> + interrupt-parent = <&mpic>;
> + interrupts = <16 2>;
> + };
> +};
> --
> 1.7.3
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-04-07 16:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev
In-Reply-To: <1302150177.2458.30.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On Thu, 07 Apr 2011, Benjamin Herrenschmidt wrote:
>
> > > 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.
> >
> > Sorry for the nag, but am I missing something about the way the register and
> > the previous values are reset in the overflow interrupt handler?
>
> Well, not all counters get interrupts right ? Some counters are just
> free running... I'm not sure when that power_pmu_read() function is
> actually used by the core, I'm not that familiar with perf, but I'd say
> better safe than sorry. When comparing counter values, doing in a way
> that is generally safe vs. wraparounds. Eventually do a helper for that.
>
> Cheers,
> Ben.
I am honestly not sure, I was under the assumption that all counters would
generate an interrupt if they overflowed. I do not have the hardware docs to
prove this, so I will have a V3 that (I think/hope) addresses your concerns out
momentarily.
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-07 16:52 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Linux PPC, Tejun Heo, Jeff Garzik, Moffett, Kyle D,
linux-ide@vger.kernel.org
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F87416BDD0@039-SN1MPN1-004.039d.mgd.msft.net>
Hello Prabhakar,
thanks for your response. My answer below:
On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
<B32579@freescale.com> wrote:
> Hi Leon,
>
> Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
>
> In order to work in legacy mode, IDSEL entries are required.
>
No, the p1020rdb and p2020rdb do not have the IDSEL entries:
http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020rdb.dts
whereas the p2020ds has:
http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020ds.dts
What would the correct IDSEL entries be?
Also, did you see the reference to Felix' thread?
"Problem with mini-PCI-E slot on P2020RDB"
Best regards,
Leon.
> --Prabhakar
>
>> -----Original Message-----
>> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-
>> owner@vger.kernel.org] On Behalf Of Leon Woestenberg
>> Sent: Thursday, April 07, 2011 12:20 AM
>> To: Jeff Garzik
>> Cc: Moffett, Kyle D; Linux PPC; linux-ide@vger.kernel.org; Tejun Heo
>> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>>
>> Hello Jeff, all,
>>
>> On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik <jeff@garzik.org> wrote:
>> > On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
>> >> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
>> >>> after investigating problems with sata_sil24.c on a freescale p2020
>> >>> soc, I wonder if this driver works on powerpc at all?
>> >>>
>> >>> Does anyone know of a working setup of sata_sil24 on a big endian
>> >>> powerpc system?
>> >>
>> >> Our P2020 boards work fine with legacy PCI interrupts (I think it's a
>> >> sil3124 over PCI-E); the only deficiency is that MSI does not seem to
>> work.
>> >>
>> >
>> > We've definitely had issues with sata_sil24 + MSI, also...
>> >
>> > sata_sil24 does work on big endian in general.
>> >
>>
>> On my system, I have the contrary to Kyle's experience (thanks for
>> sharing).
>>
>> PowerPC P2020RDB
>> vanilla 2.6.38
>> Sil3132 on mini-PCI Express card
>>
>>
>> Enabling msi gets me further than disabling it (default).
>>
>> modprobe sata_sil
>>
>> [ =A0 =A08.834613] sata_sil24 0001:03:00.0: version 1.1
>> [ =A0 =A08.885581] scsi0 : sata_sil24
>> [ =A0 =A08.901420] scsi1 : sata_sil24
>> [ =A0 =A08.904642] ata1: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0004000 irq 16
>> [ =A0 =A08.911961] ata2: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0006000 irq 16
>> [ =A0 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>> [ =A0 14.906986] eth0: no IPv6 routers present
>> [ =A0 16.099016] ata1.00: qc timeout (cmd 0xec)
>> [ =A0 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
>> [ =A0 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>> [ =A0 28.303026] ata1.00: qc timeout (cmd 0xec)
>> [ =A0 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
>> [ =A0 28.313233] ata1: limiting SATA link speed to 1.5 Gbps
>> [ =A0 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10)
>>
>>
>> modprobe sata_sil msi=3D1
>>
>> [ =A0 92.984120] sata_sil24 0001:03:00.0: version 1.1
>> [ =A0 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
>> virtual irq 41
>> [ =A0 92.996229] sata_sil24 0001:03:00.0: Using MSI
>> [ =A0 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
>> [ =A0 93.011628] scsi2 : sata_sil24
>> [ =A0 93.022463] scsi3 : sata_sil24
>> [ =A0 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0004000 irq 41
>> [ =A0 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0006000 irq 41
>> [ =A0 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>> [ =A0 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
>> -84148995 sactive 0x0)
>> [ =A0 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
>> UDMA/133
>> [ =A0 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
>> 31/32)
>> [ =A0 95.230905] ata3.00: configured for UDMA/100
>> [ =A0 95.235399] scsi 2:0:0:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0INTE=
L
>> SSDSA2M080 2CV1 PQ: 0 ANSI: 5
>> [ =A0 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
>> [ =A0 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
>> (80.0 GB/74.5 GiB)
>> [ =A0 95.260219] sd 2:0:0:0: [sda] Write Protect is off
>> [ =A0 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
>> [ =A0 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [ =A0 95.283779] =A0sda: sda1 sda2 sda3 sda4
>> [ =A0 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
>> [ =A0 95.965897] EXT3-fs: barriers not enabled
>> [ =A0 95.977279] kjournald starting. =A0Commit interval 5 seconds
>> [ =A0 95.983296] EXT3-fs (sda2): using internal journal
>> [ =A0 95.988143] EXT3-fs (sda2): recovery complete
>> [ =A0 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data
>> mode
>> [ =A0 96.111587] NTFS volume version 3.1.
>> [ =A0 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
>>
>> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D1000
>> 1000+0 records in
>> 1000+0 records out
>> 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd
>> if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D10000
>> 10000+0 records in
>> 10000+0 records out
>> 40960000 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s
>>
>> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D100000
>>
>> That stalls, I see the controller fail. See dmesg below:
>>
>> ^C^Cdd: reading `/dev/sda': Input/output error
>> 51804+0 records in
>> 51804+0 records out
>> 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s
>> dd: closing input file `/dev/sda': Bad file descriptor
>>
>>
>> [ =A0 92.984120] sata_sil24 0001:03:00.0: version 1.1
>> [ =A0 92.988897] irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to
>> virtual irq 41
>> [ =A0 92.996229] sata_sil24 0001:03:00.0: Using MSI
>> [ =A0 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering
>> [ =A0 93.011628] scsi2 : sata_sil24
>> [ =A0 93.022463] scsi3 : sata_sil24
>> [ =A0 93.025695] ata3: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0004000 irq 41
>> [ =A0 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
>> 0xc0006000 irq 41
>> [ =A0 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
>> [ =A0 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag
>> -84148995 sactive 0x0)
>> [ =A0 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
>> UDMA/133
>> [ =A0 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
>> 31/32)
>> [ =A0 95.230905] ata3.00: configured for UDMA/100
>> [ =A0 95.235399] scsi 2:0:0:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0INTE=
L
>> SSDSA2M080 2CV1 PQ: 0 ANSI: 5
>> [ =A0 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0
>> [ =A0 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
>> (80.0 GB/74.5 GiB)
>> [ =A0 95.260219] sd 2:0:0:0: [sda] Write Protect is off
>> [ =A0 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
>> [ =A0 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [ =A0 95.283779] =A0sda: sda1 sda2 sda3 sda4
>> [ =A0 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk
>> [ =A0 95.965897] EXT3-fs: barriers not enabled
>> [ =A0 95.977279] kjournald starting. =A0Commit interval 5 seconds
>> [ =A0 95.983296] EXT3-fs (sda2): using internal journal
>> [ =A0 95.988143] EXT3-fs (sda2): recovery complete
>> [ =A0 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data
>> mode
>> [ =A0 96.111587] NTFS volume version 3.1.
>> [ =A0 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
>> [ =A0285.891036] ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0=
x6
>> frozen [ =A0285.898099] ata3.00: failed command: READ FPDMA QUEUED [
>> 285.903250] ata3.00: cmd 60/00:00:e0:53:06/01:00:00:00:00/40 tag 0 ncq
>> 131072 in
>> [ =A0285.903255] =A0 =A0 =A0 =A0 =A0res 40/00:00:00:00:00/00:00:00:00:00=
/00 Emask
>> 0x4 (timeout)
>> [ =A0285.918028] ata3.00: status: { DRDY } [ =A0285.921689] ata3.00: fai=
led
>> command: READ FPDMA QUEUED [ =A0285.926836] ata3.00: cmd
>> 60/00:08:e0:52:06/01:00:00:00:00/40 tag 1 ncq 131072 in
>> [ =A0285.926841] =A0 =A0 =A0 =A0 =A0res 40/00:00:00:00:00/00:00:00:00:00=
/00 Emask
>> 0x4 (timeout)
>> [ =A0285.941615] ata3.00: status: { DRDY } [ =A0285.945281] ata3: hard
>> resetting link [ =A0288.055034] ata3: SATA link up 3.0 Gbps (SStatus 123
>> SControl 0) [ =A0293.058999] ata3.00: qc timeout (cmd 0xec) [ =A0293.063=
106]
>> ata3.00: failed to IDENTIFY (I/O error, err_mask=3D0x4) [ =A0293.069198]
>> ata3.00: revalidation failed (errno=3D-5) [ =A0293.074077] ata3: hard
>> resetting link [ =A0295.259018] ata3: SATA link up 3.0 Gbps (SStatus 123
>> SControl 0)
>>
>> What can I do next to investigate and help fix this issue?
>>
>>
>> Regards,
>> --
>> Leon
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>> the body of a message to majordomo@vger.kernel.org More majordomo info a=
t
>> http://vger.kernel.org/majordomo-info.html
>
>
>
--=20
Leon
^ permalink raw reply
* [PATCH V3] POWER: perf_event: Skip updating kernel counters if register value shrinks
From: Eric B Munson @ 2011-04-07 16:52 UTC (permalink / raw)
To: benh
Cc: a.p.zijlstra, linux-kernel, paulus, anton, acme, mingo,
linuxppc-dev, stable, Eric B Munson
Because of speculative event roll back, it is possible for some event coutners
to decrease between reads on POWER7. This causes a problem with the way that
counters are updated. Delta calues are calculated in a 64 bit value and the
top 32 bits are masked. If the register value has decreased, this leaves us
with a very large positive value added to the kernel counters. This patch
protects against this by skipping the update if the delta would be negative.
This can lead to a lack of precision in the coutner values, but from my testing
the value is typcially fewer than 10 samples at a time.
Signed-off-by: Eric B Munson <emunson@mgebm.net>
Cc: stable@kernel.org
---
Changes from V2:
Create a helper that should handle counter roll back as well as registers that
might be allowed to roll over
Changes from V1:
Updated patch leader
Added stable CC
Use an s32 to hold delta values and discard any values that are less than 0
arch/powerpc/kernel/perf_event.c | 40 +++++++++++++++++++++++++++++++------
1 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
index 97e0ae4..78bf933 100644
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -398,6 +398,28 @@ static int check_excludes(struct perf_event **ctrs, unsigned int cflags[],
return 0;
}
+static u64 check_and_compute_delta(s64 prev, s64 val)
+{
+ /*
+ * Because the PerfMon registers are only 32 bits wide, the delta
+ * should not overflow.
+ */
+ u64 delta = 0;
+
+ /*
+ * 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 unless we rolled a counter over. If this is the
+ * case or prev < val, calculate the delta nd return it, otherwise
+ * return 0. This can lead to a small lack of precision in the
+ * counters.
+ */
+ if (((prev & 0x80000000) && !(val & 0x80000000)) || (val > prev))
+ delta = (val - prev) & 0xfffffffful;
+
+ return delta;
+}
+
static void power_pmu_read(struct perf_event *event)
{
s64 val, delta, prev;
@@ -416,10 +438,11 @@ static void power_pmu_read(struct perf_event *event)
prev = local64_read(&event->hw.prev_count);
barrier();
val = read_pmc(event->hw.idx);
+ delta = check_and_compute_delta(prev, val);
+ if (!delta)
+ return;
} while (local64_cmpxchg(&event->hw.prev_count, prev, val) != prev);
- /* The counters are only 32 bits wide */
- delta = (val - prev) & 0xfffffffful;
local64_add(delta, &event->count);
local64_sub(delta, &event->hw.period_left);
}
@@ -449,8 +472,9 @@ static void freeze_limited_counters(struct cpu_hw_events *cpuhw,
val = (event->hw.idx == 5) ? pmc5 : pmc6;
prev = local64_read(&event->hw.prev_count);
event->hw.idx = 0;
- delta = (val - prev) & 0xfffffffful;
- local64_add(delta, &event->count);
+ delta = check_and_compute_delta(prev, val);
+ if (delta)
+ local64_add(delta, &event->count);
}
}
@@ -458,14 +482,16 @@ static void thaw_limited_counters(struct cpu_hw_events *cpuhw,
unsigned long pmc5, unsigned long pmc6)
{
struct perf_event *event;
- u64 val;
+ u64 val, prev;
int i;
for (i = 0; i < cpuhw->n_limited; ++i) {
event = cpuhw->limited_counter[i];
event->hw.idx = cpuhw->limited_hwidx[i];
val = (event->hw.idx == 5) ? pmc5 : pmc6;
- local64_set(&event->hw.prev_count, val);
+ prev = local64_read(&event->hw.prev_count);
+ if (check_and_compute_delta(prev, val))
+ local64_set(&event->hw.prev_count, val);
perf_event_update_userpage(event);
}
}
@@ -1197,7 +1223,7 @@ static void record_and_restart(struct perf_event *event, unsigned long val,
/* we don't have to worry about interrupts here */
prev = local64_read(&event->hw.prev_count);
- delta = (val - prev) & 0xfffffffful;
+ delta = check_and_compute_delta(prev, val);
local64_add(delta, &event->count);
/*
--
1.7.1
^ permalink raw reply related
* Re: known working sata_sil24.c setup on powerpc platforms?
From: Leon Woestenberg @ 2011-04-07 16:54 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <4D9D7575.1030200@ge.com>
Hello Martyn,
thanks for a confirmation.
On Thu, Apr 7, 2011 at 10:27 AM, Martyn Welch <martyn.welch@ge.com> wrote:
> On 06/04/11 18:00, Leon Woestenberg wrote:
>>
>> Does anyone know of a working setup of sata_sil24 on a big endian
>> powerpc system?
>
> Yes, I think we even use it on a p2020 board, though I think our current
> kernel on that product is 2.6.34.
>
Could you check if that's using MSI or legacy interrupting on PCIe?
Thanks in advance for the effort,
Regards,
--
Leon
^ permalink raw reply
* Re: halt/reset on assert?
From: kevin diggs @ 2011-04-07 17:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andreas Schwab, linuxppc-dev, Evan Lavelle
In-Reply-To: <1302162933.2458.33.camel@pasglop>
On Thu, Apr 7, 2011 at 2:55 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2011-04-06 at 14:01 +0100, Evan Lavelle wrote:
>> #define MY_ASSERT(expr) if(!(expr)) BUG()
>
> Make it
>
> #define MY_ASSERT(expr) do { if .... } while(0)
>
> To ensure it has proper single statement semantics in C.
>
So THAT'S why they do this!!!!!! Now I just have to figure out what
'proper single statement semantics' means!
THANKS!!!
kevin
> Cheers,
> Ben.
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Leon Woestenberg @ 2011-04-07 17:20 UTC (permalink / raw)
To: linuxppc-dev
Cc: Mahajan Vivek-B08308, Felix Radensky, Aggrwal Poonam-B10812,
Kushwaha Prabhakar-B32579
In-Reply-To: <4B2A946E.4040907@embedded-sol.com>
Hello,
On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky <felix@embedded-sol.com> wr=
ote:
> Kumar Gala wrote:
>> On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote:
>>>> Thanks a lot. If I understand you correctly, the only way I can get
>>>> ath9k driver to work on this board using legacy interrupts is to wait =
for a
>>>> hardware fix. Right ?
>>>>
>>> Correct
>>
>> I'm confused. =A0What's the issue with IRQ0 on the P2020RDB? =A0Is it us=
ed for
>> another purpose?
>
> There's a problem with IRQ0 with respect to mini-PCI-E slot. I have Ather=
os
> wireless card plugged
> into it. ath9k wireless driver for this card uses legacy PCI-E interrupts=
,
> and I get "irq 16: nobody cared"
> message when driver executes request_irq(). Vivek has come to a conclusio=
n
> that the problem is
> related to incorrect IRQ0 routing for mini-PCI-E slot on P2020RDB.
>
I would like to understand this issue better, as I seem to be running
into something similar, and it puts my board design on hold.
Can someone (from Freescale) explain what happens if a PCI Express end
point on the mini-PCIe slot raises a legacy interrupt, and where this
goes wrong?
>From what document or source code file can I conclude that the PCIe
legacy interrupt is shared with IRQ0?
I found this:
P1020E/P2020E RDB System Errata, Last Update: 2/15/2010:
Problem:IRQ0 held low
Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N.
See R420 in Rev D schematic.
Add 4.7K pull-up (to 3.3.V) for MCU_INT_N.
See R423 in Rev D schematic.
Regards,
--=20
Leon
^ permalink raw reply
* Re: [PATCH] rtas: Only sleep in rtas_busy_delay if we have useful work to do
From: Nishanth Aravamudan @ 2011-04-07 18:11 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev, miltonm
In-Reply-To: <20110407215407.4f6ca50f@kryten>
On 07.04.2011 [21:54:07 +1000], Anton Blanchard wrote:
>
> RTAS returns extended error codes as a hint of how long the
> OS might want to wait before retrying a call. If we have nothing
> else useful to do we may as well call back straight away.
>
> This was found when testing the new dynamic dma window feature.
> Firmware split the zeroing of the TCE table into 32k chunks but
> returned 9901 (which is a suggested wait of 10ms). All up this took
> about 10 minutes to complete since msleep is jiffies based and will
> round 10ms up to 20ms.
>
> With the patch below we take 3 seconds to complete the same test.
> The hint firmware is returning in the RTAS call should definitely
> be decreased, but even if we slept 1ms each iteration this would
> take 32s.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Nishanth Aravamudan <nacc@us.ibm.com>
> ---
>
> Index: linux-2.6/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/rtas.c 2011-04-05 11:19:35.023234011 +1000
> +++ linux-2.6/arch/powerpc/kernel/rtas.c 2011-04-07 21:25:24.646414629 +1000
> @@ -494,7 +494,7 @@ unsigned int rtas_busy_delay(int status)
>
> might_sleep();
> ms = rtas_busy_delay_time(status);
> - if (ms)
> + if (ms && need_resched())
> msleep(ms);
>
> return ms;
^ permalink raw reply
* Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
From: RONETIX - Asen Dimov @ 2011-04-07 18:39 UTC (permalink / raw)
To: Daniel Walker
Cc: Randy Dunlap, Mike Frysinger, Arnd Bergmann, Nicolas Pitre,
Tony Lindgren, linux-arm-msm, Greg Kroah-Hartman, linux-kernel,
FUJITA Tomonori, Andrew Morton, linuxppc-dev, Alan Cox
In-Reply-To: <1291145141-18301-1-git-send-email-dwalker@codeaurora.org>
Hello,
On 11/30/2010 09:25 PM, Daniel Walker wrote:
> This driver adds a basic console that uses the arm JTAG
> DCC to transfer data back and forth. It has support for
> ARMv6 and ARMv7.
>
> This console is created under the HVC driver, and should be named
> /dev/hvcX (or /dev/hvc0 for example).
>
> Cc: Tony Lindgren<tony@atomide.com>
> Cc: Arnd Bergmann<arnd@arndb.de>
> Cc: Nicolas Pitre<nico@fluxnic.net>
> Cc: Greg Kroah-Hartman<gregkh@suse.de>
> Cc: Mike Frysinger<vapier@gentoo.org>
> Signed-off-by: Daniel Walker<dwalker@codeaurora.org>
> ---
> drivers/char/Kconfig | 9 +++
> drivers/char/Makefile | 1 +
> drivers/char/hvc_dcc.c | 133 ++++++++++++++++++++++++++++++++++++++++++++++++
...
this DCC driver implements "one channel", but what about implementing
"multiple channels". For example reserve few(3) bits for channel number,
and two bits for carried data, then fill the rest bytes with with some data
and send the word(32 bits) over DCC. On the Linux side writing on /dev/hvcX
puts the number X as channel number, and on the other side the CPU
emulator gets the data and redistribute it to TCP/IP socket.
I have started write some code implementing this. Are there any one
interested
in this multiple channels, and are there any one started to work on it?
Regards,
Asen
^ permalink raw reply
* Re: [PATCH] drivers: char: hvc: add arm JTAG DCC console support
From: Mike Frysinger @ 2011-04-07 18:57 UTC (permalink / raw)
To: RONETIX - Asen Dimov
Cc: Randy Dunlap, Daniel Walker, Arnd Bergmann, Nicolas Pitre,
Tony Lindgren, linux-arm-msm, Greg Kroah-Hartman, linux-kernel,
FUJITA Tomonori, Andrew Morton, linuxppc-dev, Alan Cox
In-Reply-To: <4D9E04F0.5010004@ronetix.at>
On Thu, Apr 7, 2011 at 14:39, RONETIX - Asen Dimov wrote:
> On 11/30/2010 09:25 PM, Daniel Walker wrote:
>> This driver adds a basic console that uses the arm JTAG
>> DCC to transfer data back and forth. It has support for
>> ARMv6 and ARMv7.
>>
>> This console is created under the HVC driver, and should be named
>> /dev/hvcX (or /dev/hvc0 for example).
>>
>> =C2=A0drivers/char/Kconfig =C2=A0 | =C2=A0 =C2=A09 +++
>> =C2=A0drivers/char/Makefile =C2=A0| =C2=A0 =C2=A01 +
>> =C2=A0drivers/char/hvc_dcc.c | =C2=A0133
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>
> ...
>
> this DCC driver implements "one channel", but what about implementing
> "multiple channels". For example reserve few(3) bits for channel number,
> and two bits for carried data, then fill the rest bytes with with some da=
ta
> and send the word(32 bits) over DCC. On the Linux side writing on /dev/hv=
cX
> puts the number X as channel number, and on the other side the CPU
> emulator gets the data and redistribute it to TCP/IP socket.
>
> I have started write some code implementing this. Are there any one
> interested
> in this multiple channels, and are there any one started to work on it?
this sort of multiplexing of the data stream sounds like the job for
userspace ? or maybe a line discipline ? inserting structured data
into the kernel driver doesnt sound right to me ...
-mike
^ permalink raw reply
* [PATCH] lib: Consolidate DEBUG_PER_CPU_MAPS
From: Stephen Boyd @ 2011-04-07 19:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-arch, x86, linuxppc-dev, linux-kernel
DEBUG_PER_CPU_MAPS is used in lib/cpumask.c as well as in
inlcude/linux/cpumask.h and thus it has outgrown its use within x86
and powerpc alone. Any arch with SMP support may want to get some
more debugging, so make this option generic.
Cc: linux-arch@vger.kernel.org
Cc: x86@kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
I don't know what tree to send this through, so I'm sending it to
Andrew. I suppose mm is as good as anything.
arch/powerpc/Kconfig.debug | 12 ------------
arch/x86/Kconfig.debug | 11 -----------
lib/Kconfig.debug | 11 +++++++++++
3 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2d38a50..12a8d18 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -44,18 +44,6 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
-config DEBUG_PER_CPU_MAPS
- bool "Debug access to per_cpu maps"
- depends on DEBUG_KERNEL
- depends on SMP
- default n
- ---help---
- Say Y to verify that the per_cpu map being accessed has
- been setup. Adds a fair amount of code to kernel memory
- and decreases performance.
-
- Say N if unsure.
-
config HCALL_STATS
bool "Hypervisor call instrumentation"
depends on PPC_PSERIES && DEBUG_FS && TRACEPOINTS
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 615e188..1bf8839 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -75,17 +75,6 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
-config DEBUG_PER_CPU_MAPS
- bool "Debug access to per_cpu maps"
- depends on DEBUG_KERNEL
- depends on SMP
- ---help---
- Say Y to verify that the per_cpu map being accessed has
- been setup. Adds a fair amount of code to kernel memory
- and decreases performance.
-
- Say N if unsure.
-
config X86_PTDUMP
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c768bcd..c792431 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -993,6 +993,17 @@ config DEBUG_FORCE_WEAK_PER_CPU
To ensure that generic code follows the above rules, this
option forces all percpu variables to be defined as weak.
+config DEBUG_PER_CPU_MAPS
+ bool "Debug access to per_cpu maps"
+ depends on DEBUG_KERNEL
+ depends on SMP
+ help
+ Say Y to verify that the per_cpu map being accessed has
+ been set up. This adds a fair amount of code to kernel memory
+ and decreases performance.
+
+ Say N if unsure.
+
config LKDTM
tristate "Linux Kernel Dump Test Tool Module"
depends on DEBUG_FS
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Kumar Gala @ 2011-04-07 19:38 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110406130257.2d31beaa@schlenkerla.am.freescale.net>
On Apr 6, 2011, at 1:02 PM, Scott Wood wrote:
> On Wed, 6 Apr 2011 07:29:03 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>=20
>> diff --git a/arch/powerpc/include/asm/cputable.h =
b/arch/powerpc/include/asm/cputable.h
>> index be3cdf9..9028a9e 100644
>> --- a/arch/powerpc/include/asm/cputable.h
>> +++ b/arch/powerpc/include/asm/cputable.h
>> @@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
>> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
>> CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
>> CPU_FTR_DBELL)
>> +#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB =
| \
>> + CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
>=20
> E5500 cannot doze or nap in the way meant by existing code (MSR[WE]).
Should I drop them for e500mc as well?
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
From: Scott Wood @ 2011-04-07 19:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7597043B-4C16-47F7-8AF7-111A5815545E@kernel.crashing.org>
On Thu, 7 Apr 2011 14:38:57 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 6, 2011, at 1:02 PM, Scott Wood wrote:
>
> > On Wed, 6 Apr 2011 07:29:03 -0500
> > Kumar Gala <galak@kernel.crashing.org> wrote:
> >
> >> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> >> index be3cdf9..9028a9e 100644
> >> --- a/arch/powerpc/include/asm/cputable.h
> >> +++ b/arch/powerpc/include/asm/cputable.h
> >> @@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
> >> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> >> CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> >> CPU_FTR_DBELL)
> >> +#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
> >> + CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> >
> > E5500 cannot doze or nap in the way meant by existing code (MSR[WE]).
>
> Should I drop them for e500mc as well?
Yes.
-Scott
^ permalink raw reply
* Re: halt/reset on assert?
From: Benjamin Herrenschmidt @ 2011-04-07 21:48 UTC (permalink / raw)
To: kevin diggs; +Cc: Andreas Schwab, linuxppc-dev, Evan Lavelle
In-Reply-To: <BANLkTimX==Ei2Sn=86svSajHNX+0G1WM9w@mail.gmail.com>
On Thu, 2011-04-07 at 12:04 -0500, kevin diggs wrote:
> On Thu, Apr 7, 2011 at 2:55 AM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2011-04-06 at 14:01 +0100, Evan Lavelle wrote:
> >> #define MY_ASSERT(expr) if(!(expr)) BUG()
> >
> > Make it
> >
> > #define MY_ASSERT(expr) do { if .... } while(0)
> >
> > To ensure it has proper single statement semantics in C.
> >
> So THAT'S why they do this!!!!!! Now I just have to figure out what
> 'proper single statement semantics' means!
Thing what happens without the do { ... } while(0) if you have code
that looks like:
if (enable_debug)
MY_ASSERT(foo);
else
something_else;
Ben.
^ permalink raw reply
* RE: known working sata_sil24.c setup on powerpc platforms?
From: Kushwaha Prabhakar-B32579 @ 2011-04-08 3:44 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Tejun Heo, Jeff Garzik, Linux PPC, linux-ide@vger.kernel.org,
Moffett, Kyle D, Gupta Maneesh-B18878
In-Reply-To: <BANLkTin1KoJ8EsV49naEAZjmq=EZLHXZpQ@mail.gmail.com>
> -----Original Message-----
> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-
> owner@vger.kernel.org] On Behalf Of Leon Woestenberg
> Sent: Thursday, April 07, 2011 10:23 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Moffett, Kyle D; Linux PPC; linux-ide@vger.kernel.org; Tejun Heo;
> Jeff Garzik
> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
>=20
> Hello Prabhakar,
>=20
> thanks for your response. My answer below:
>=20
> On Thu, Apr 7, 2011 at 6:48 AM, Kushwaha Prabhakar-B32579
> <B32579@freescale.com> wrote:
> > Hi Leon,
> >
> > Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node?
> >
> > In order to work in legacy mode, IDSEL entries are required.
> >
> No, the p1020rdb and p2020rdb do not have the IDSEL entries:
>=20
> http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020rdb.dts
>=20
> whereas the p2020ds has:
>=20
> http://lxr.linux.no/#linux+v2.6.38/arch/powerpc/boot/dts/p2020ds.dts
>=20
>=20
> What would the correct IDSEL entries be?
For legacy interrupt to work IDSEL values are required.. please find the co=
rrect IDSEL values for pci0/1.
pci0: pcie@ffe09000 {
---
---
interrupt-map-mask =3D <0xf800 0x0 0x0 0x7>;
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x4 0x1
0000 0x0 0x0 0x2 &mpic 0x5 0x1
0000 0x0 0x0 0x3 &mpic 0x6 0x1
0000 0x0 0x0 0x4 &mpic 0x7 0x1
>;
---
---
};
pci1: pcie@ffe0a000 {
---
---
interrupt-map-mask =3D <0xf800 0x0 0x0 0x7>;
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x0 0x1
0000 0x0 0x0 0x2 &mpic 0x1 0x1
0000 0x0 0x0 0x3 &mpic 0x2 0x1
0000 0x0 0x0 0x4 &mpic 0x3 0x1
>;
---
---
};
};
Please try with this.. I am in process of pushing these IDSEL values to ups=
tream.=20
> Also, did you see the reference to Felix' thread?
> "Problem with mini-PCI-E slot on P2020RDB"
>=20
I will look into it..=20
--Prabhakar
> >
> >> -----Original Message-----
> >> From: linux-ide-owner@vger.kernel.org [mailto:linux-ide-
> >> owner@vger.kernel.org] On Behalf Of Leon Woestenberg
> >> Sent: Thursday, April 07, 2011 12:20 AM
> >> To: Jeff Garzik
> >> Cc: Moffett, Kyle D; Linux PPC; linux-ide@vger.kernel.org; Tejun Heo
> >> Subject: Re: known working sata_sil24.c setup on powerpc platforms?
> >>
> >> Hello Jeff, all,
> >>
> >> On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik <jeff@garzik.org> wrote:
> >> > On 04/06/2011 01:48 PM, Moffett, Kyle D wrote:
> >> >> On Apr 06, 2011, at 13:00, Leon Woestenberg wrote:
> >> >>> after investigating problems with sata_sil24.c on a freescale
> >> >>> p2020 soc, I wonder if this driver works on powerpc at all?
> >> >>>
> >> >>> Does anyone know of a working setup of sata_sil24 on a big endian
> >> >>> powerpc system?
> >> >>
> >> >> Our P2020 boards work fine with legacy PCI interrupts (I think
> >> >> it's a
> >> >> sil3124 over PCI-E); the only deficiency is that MSI does not seem
> >> >> to
> >> work.
> >> >>
> >> >
> >> > We've definitely had issues with sata_sil24 + MSI, also...
> >> >
> >> > sata_sil24 does work on big endian in general.
> >> >
> >>
> >> On my system, I have the contrary to Kyle's experience (thanks for
> >> sharing).
> >>
> >> PowerPC P2020RDB
> >> vanilla 2.6.38
> >> Sil3132 on mini-PCI Express card
> >>
> >>
> >> Enabling msi gets me further than disabling it (default).
> >>
> >> modprobe sata_sil
> >>
> >> [ =A0 =A08.834613] sata_sil24 0001:03:00.0: version 1.1 [ =A0 =A08.885=
581]
> >> scsi0 : sata_sil24 [ =A0 =A08.901420] scsi1 : sata_sil24 [ =A0 =A08.90=
4642]
> >> ata1: SATA max UDMA/100 host m128@0xc0000000 port 0xc0004000 irq 16 [
>=20
> >> 8.911961] ata2: SATA max UDMA/100 host m128@0xc0000000 port
> >> 0xc0006000 irq 16 [ =A0 11.095127] ata1: SATA link up 3.0 Gbps (SStatu=
s
> >> 123 SControl 0) [ =A0 14.906986] eth0: no IPv6 routers present [
> >> 16.099016] ata1.00: qc timeout (cmd 0xec) [ =A0 16.103128] ata1.00:
> >> failed to IDENTIFY (I/O error, err_mask=3D0x4) [ =A0 18.299050] ata1:
> >> SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ =A0 28.303026]
> >> ata1.00: qc timeout (cmd 0xec) [ =A0 28.307139] ata1.00: failed to
> >> IDENTIFY (I/O error, err_mask=3D0x4) [ =A0 28.313233] ata1: limiting S=
ATA
> >> link speed to 1.5 Gbps [ =A0 30.523059] ata1: SATA link up 1.5 Gbps
> >> (SStatus 113 SControl 10)
> >>
> >>
> >> modprobe sata_sil msi=3D1
> >>
> >> [ =A0 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ =A0 92.988897]
> >> irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 41 [
>=20
> >> 92.996229] sata_sil24 0001:03:00.0: Using MSI [ =A0 93.000675]
> >> sata_sil24 0001:03:00.0: enabling bus mastering [ =A0 93.011628] scsi2
> >> : sata_sil24 [ =A0 93.022463] scsi3 : sata_sil24 [ =A0 93.025695] ata3=
:
> >> SATA max UDMA/100 host m128@0xc0000000 port 0xc0004000 irq 41 [
> >> 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
> >> 0xc0006000 irq 41 [ =A0 95.203029] ata3: SATA link up 3.0 Gbps (SStatu=
s
> >> 123 SControl 0) [ =A0 95.209045] ata3: spurious interrupt (slot_stat
> >> 0x0 active_tag
> >> -84148995 sactive 0x0)
> >> [ =A0 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
> >> UDMA/133
> >> [ =A0 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
> >> 31/32)
> >> [ =A0 95.230905] ata3.00: configured for UDMA/100 [ =A0 95.235399] scs=
i
> >> 2:0:0:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0INTEL SSDSA2M080 2CV1 PQ=
: 0 ANSI:
> >> 5 [ =A0 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [
> >> 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
> >> (80.0 GB/74.5 GiB)
> >> [ =A0 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ =A0 95.26506=
3]
> >> sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ =A0 95.270500] sd 2:0:0:0:
> >> [sda] Write cache: enabled, read cache:
> >> enabled, doesn't support DPO or FUA
> >> [ =A0 95.283779] =A0sda: sda1 sda2 sda3 sda4 [ =A0 95.289482] sd 2:0:0=
:0:
> >> [sda] Attached SCSI disk [ =A0 95.965897] EXT3-fs: barriers not enable=
d
> >> [ =A0 95.977279] kjournald starting. =A0Commit interval 5 seconds [
> >> 95.983296] EXT3-fs (sda2): using internal journal [ =A0 95.988143]
> >> EXT3-fs (sda2): recovery complete [ =A0 95.992504] EXT3-fs (sda2):
> >> mounted filesystem with writeback data mode [ =A0 96.111587] NTFS
> >> volume version 3.1.
> >> [ =A0 97.331005] ata4: SATA link down (SStatus 0 SControl 0)
> >>
> >> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D1000
> >> 1000+0 records in
> >> 1000+0 records out
> >> 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~#
> >> dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D10000
> >> 10000+0 records in
> >> 10000+0 records out
> >> 40960000 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s
> >>
> >> root@p1020rdb:~# dd if=3D/dev/sda of=3D/dev/null bs=3D4k count=3D10000=
0
> >>
> >> That stalls, I see the controller fail. See dmesg below:
> >>
> >> ^C^Cdd: reading `/dev/sda': Input/output error
> >> 51804+0 records in
> >> 51804+0 records out
> >> 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s
> >> dd: closing input file `/dev/sda': Bad file descriptor
> >>
> >>
> >> [ =A0 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ =A0 92.988897]
> >> irq: irq 0 on host /soc@ffe00000/msi@41600 mapped to virtual irq 41 [
>=20
> >> 92.996229] sata_sil24 0001:03:00.0: Using MSI [ =A0 93.000675]
> >> sata_sil24 0001:03:00.0: enabling bus mastering [ =A0 93.011628] scsi2
> >> : sata_sil24 [ =A0 93.022463] scsi3 : sata_sil24 [ =A0 93.025695] ata3=
:
> >> SATA max UDMA/100 host m128@0xc0000000 port 0xc0004000 irq 41 [
> >> 93.033023] ata4: SATA max UDMA/100 host m128@0xc0000000 port
> >> 0xc0006000 irq 41 [ =A0 95.203029] ata3: SATA link up 3.0 Gbps (SStatu=
s
> >> 123 SControl 0) [ =A0 95.209045] ata3: spurious interrupt (slot_stat
> >> 0x0 active_tag
> >> -84148995 sactive 0x0)
> >> [ =A0 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max
> >> UDMA/133
> >> [ =A0 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth
> >> 31/32)
> >> [ =A0 95.230905] ata3.00: configured for UDMA/100 [ =A0 95.235399] scs=
i
> >> 2:0:0:0: Direct-Access =A0 =A0 ATA =A0 =A0 =A0INTEL SSDSA2M080 2CV1 PQ=
: 0 ANSI:
> >> 5 [ =A0 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [
> >> 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks:
> >> (80.0 GB/74.5 GiB)
> >> [ =A0 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ =A0 95.26506=
3]
> >> sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ =A0 95.270500] sd 2:0:0:0:
> >> [sda] Write cache: enabled, read cache:
> >> enabled, doesn't support DPO or FUA
> >> [ =A0 95.283779] =A0sda: sda1 sda2 sda3 sda4 [ =A0 95.289482] sd 2:0:0=
:0:
> >> [sda] Attached SCSI disk [ =A0 95.965897] EXT3-fs: barriers not enable=
d
> >> [ =A0 95.977279] kjournald starting. =A0Commit interval 5 seconds [
> >> 95.983296] EXT3-fs (sda2): using internal journal [ =A0 95.988143]
> >> EXT3-fs (sda2): recovery complete [ =A0 95.992504] EXT3-fs (sda2):
> >> mounted filesystem with writeback data mode [ =A0 96.111587] NTFS
> >> volume version 3.1.
> >> [ =A0 97.331005] ata4: SATA link down (SStatus 0 SControl 0) [
> >> 285.891036] ata3.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6
> >> frozen [ =A0285.898099] ata3.00: failed command: READ FPDMA QUEUED [
> >> 285.903250] ata3.00: cmd 60/00:00:e0:53:06/01:00:00:00:00/40 tag 0
> >> ncq
> >> 131072 in
> >> [ =A0285.903255] =A0 =A0 =A0 =A0 =A0res 40/00:00:00:00:00/00:00:00:00:=
00/00 Emask
> >> 0x4 (timeout)
> >> [ =A0285.918028] ata3.00: status: { DRDY } [ =A0285.921689] ata3.00:
> >> failed
> >> command: READ FPDMA QUEUED [ =A0285.926836] ata3.00: cmd
> >> 60/00:08:e0:52:06/01:00:00:00:00/40 tag 1 ncq 131072 in [
> >> 285.926841] =A0 =A0 =A0 =A0 =A0res 40/00:00:00:00:00/00:00:00:00:00/00=
Emask
> >> 0x4 (timeout)
> >> [ =A0285.941615] ata3.00: status: { DRDY } [ =A0285.945281] ata3: hard
> >> resetting link [ =A0288.055034] ata3: SATA link up 3.0 Gbps (SStatus
> >> 123 SControl 0) [ =A0293.058999] ata3.00: qc timeout (cmd 0xec) [
> >> 293.063106]
> >> ata3.00: failed to IDENTIFY (I/O error, err_mask=3D0x4) [ =A0293.06919=
8]
> >> ata3.00: revalidation failed (errno=3D-5) [ =A0293.074077] ata3: hard
> >> resetting link [ =A0295.259018] ata3: SATA link up 3.0 Gbps (SStatus
> >> 123 SControl 0)
> >>
> >> What can I do next to investigate and help fix this issue?
> >>
> >>
> >> Regards,
> >> --
> >> Leon
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-ide"
> >> in the body of a message to majordomo@vger.kernel.org More majordomo
> >> info at http://vger.kernel.org/majordomo-info.html
> >
> >
> >
>=20
>=20
>=20
> --
> Leon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Kushwaha Prabhakar-B32579 @ 2011-04-08 3:53 UTC (permalink / raw)
To: Leon Woestenberg, linuxppc-dev@ozlabs.org
Cc: Mahajan Vivek-B08308, Felix Radensky, Aggrwal Poonam-B10812,
Gupta Maneesh-B18878
In-Reply-To: <BANLkTimf8uwgew3YPcNxdNj+4XamPhbxbQ@mail.gmail.com>
> -----Original Message-----
> From: Leon Woestenberg [mailto:leon.woestenberg@gmail.com]
> Sent: Thursday, April 07, 2011 10:50 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Kumar Gala; Mahajan Vivek-B08308; Aggrwal Poonam-B10812; Felix
> Radensky; Kushwaha Prabhakar-B32579
> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hello,
>=20
> On Thu, Dec 17, 2009 at 9:28 PM, Felix Radensky <felix@embedded-sol.com>
> wrote:
> > Kumar Gala wrote:
> >> On Dec 17, 2009, at 2:59 AM, Mahajan Vivek-B08308 wrote:
> >>>> Thanks a lot. If I understand you correctly, the only way I can get
> >>>> ath9k driver to work on this board using legacy interrupts is to
> >>>> wait for a hardware fix. Right ?
> >>>>
> >>> Correct
> >>
> >> I'm confused. =A0What's the issue with IRQ0 on the P2020RDB? =A0Is it
> >> used for another purpose?
> >
> > There's a problem with IRQ0 with respect to mini-PCI-E slot. I have
> > Atheros wireless card plugged into it. ath9k wireless driver for this
> > card uses legacy PCI-E interrupts, and I get "irq 16: nobody cared"
> > message when driver executes request_irq(). Vivek has come to a
> > conclusion that the problem is related to incorrect IRQ0 routing for
> > mini-PCI-E slot on P2020RDB.
> >
>=20
> I would like to understand this issue better, as I seem to be running
> into something similar, and it puts my board design on hold.
>=20
> Can someone (from Freescale) explain what happens if a PCI Express end
> point on the mini-PCIe slot raises a legacy interrupt, and where this
> goes wrong?
>=20
> From what document or source code file can I conclude that the PCIe
> legacy interrupt is shared with IRQ0?
>=20
>=20
> I found this:
>=20
> P1020E/P2020E RDB System Errata, Last Update: 2/15/2010:
> Problem:IRQ0 held low
> Fix: Add 4.7K pull-up (to 3.3.V) for RTC_INT_N.
> See R420 in Rev D schematic.
> Add 4.7K pull-up (to 3.3.V) for MCU_INT_N.
> See R423 in Rev D schematic.
>=20
>=20
Hello Leon,
Yes you are right, PCIe leagacy interrupt is shared with IRQ0. For Atheros=
issue.=20
Can you please try followings, Meanwhile I will try to dig into it.
http://old.nabble.com/Problem-with-mini-PCI-E-slot-on-P2020RDB-td2680203=
8.html
Regarding sata_sil24, Please see my e-mail on Linux-ide for correct IDSEL v=
alue.=20
Please first try IDSEL value mentioned in email on Linux-ide. Then try this=
URL..
--Prabhakar
^ permalink raw reply
* Re: [PATCH] mm: Check we have the right vma in access_process_vm()
From: Michael Ellerman @ 2011-04-08 7:17 UTC (permalink / raw)
To: Michel Lespinasse
Cc: aarcange, Andrew Morton, riel, linuxppc-dev, hughd, linux-kernel,
linux-mm
In-Reply-To: <BANLkTi=RJ2GHvHQ3mZiQ-L-MTVUQH-V-eA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
On Mon, 2011-04-04 at 23:42 -0700, Michel Lespinasse wrote:
> On Mon, Apr 4, 2011 at 11:24 PM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
> > In access_process_vm() we need to check that we have found the right
> > vma, not the following vma, before we try to access it. Otherwise
> > we might call the vma's access routine with an address which does
> > not fall inside the vma.
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> Please note that the code has moved into __access_remote_vm() in
> current linus tree.
Ah good point, if git hadn't done such a good job of merging it I would
have noticed :)
I'll send a new version with a corrected changelog.
> Also, should len be truncated before calling vma->vm_ops->access() so
> that we can guarantee it won't overflow past the end of the vma ?
The access implementations I've looked at check len, but I guess it
could be truncated on the way in. But maybe that's being paranoid, I
dunno.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] powerpc/book3e: Fix extlb size
From: Michael Ellerman @ 2011-04-08 7:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Kumar Gala
The calculation of the size for the exception save area of the TLB
miss handler is wrong, luckily it's too big not too small.
Rework it to make it a bit clearer, and also correct. We want 3 save
areas, each EX_TLB_SIZE _bytes_.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/paca.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index ec57540..c3416ca 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -106,7 +106,8 @@ struct paca_struct {
pgd_t *pgd; /* Current PGD */
pgd_t *kernel_pgd; /* Kernel PGD */
u64 exgen[8] __attribute__((aligned(0x80)));
- u64 extlb[EX_TLB_SIZE*3] __attribute__((aligned(0x80)));
+ /* We can have up to 3 levels of reentrancy in the TLB miss handler */
+ u64 extlb[3][EX_TLB_SIZE / sizeof(u64)] __attribute__((aligned(0x80)));
u64 exmc[8]; /* used for machine checks */
u64 excrit[8]; /* used for crit interrupts */
u64 exdbg[8]; /* used for debug interrupts */
--
1.7.1
^ permalink raw reply related
* [PATCH] mm: Check we have the right vma in __access_remote_vm()
From: Michael Ellerman @ 2011-04-08 7:24 UTC (permalink / raw)
To: linux-kernel
Cc: aarcange, Andrew Morton, riel, linuxppc-dev, hughd, linux-mm,
walken
In __access_remote_vm() we need to check that we have found the right
vma, not the following vma, before we try to access it. Otherwise we
might call the vma's access routine with an address which does not
fall inside the vma.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
mm/memory.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 9da8cab..ce999ca 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3678,7 +3678,7 @@ static int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm,
*/
#ifdef CONFIG_HAVE_IOREMAP_PROT
vma = find_vma(mm, addr);
- if (!vma)
+ if (!vma || vma->vm_start > addr)
break;
if (vma->vm_ops && vma->vm_ops->access)
ret = vma->vm_ops->access(vma, addr, buf,
--
1.7.1
^ permalink raw reply related
* [PATCH] powerpc: Fix oops if scan_dispatch_log is called too early
From: Anton Blanchard @ 2011-04-08 7:44 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
We currently enable interrupts before the dispatch log for the boot
cpu is setup. If a timer interrupt comes in early enough we oops in
scan_dispatch_log:
Unable to handle kernel paging request for data at address 0x00000010
...
.scan_dispatch_log+0xb0/0x170
.account_system_vtime+0xa0/0x220
.irq_enter+0x88/0xc0
.do_IRQ+0x48/0x230
The patch below adds a check to scan_dispatch_log to ensure the
dispatch log has been allocated.
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: <stable@kernel.org>
---
Index: powerpc.git/arch/powerpc/kernel/time.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/time.c 2011-04-05 18:38:40.814489516 +1000
+++ powerpc.git/arch/powerpc/kernel/time.c 2011-04-08 12:16:41.864748155 +1000
@@ -229,6 +229,9 @@ static u64 scan_dispatch_log(u64 stop_tb
u64 stolen = 0;
u64 dtb;
+ if (!dtl)
+ return 0;
+
if (i == vpa->dtl_idx)
return 0;
while (i < vpa->dtl_idx) {
^ 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