* Re: kexec on ppc64
From: Michael Neuling @ 2010-09-07 23:49 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev, kexec
In-Reply-To: <0D324CAF-2A5D-4363-9000-7EB48179C11C@freescale.com>
> I'm trying to determine how kexec'ing works on 64 bit powerpc. When
> allocating a region for the kexec'ed kernel is it ever the same as the
> currently running kernel or do you always boot the kexec'ed kernel
> from a different memory region? I understand that a crash kernel will
> be in a different region, however I was hoping to confirm the behavior
> for a normal "kexec -e".
The kernel will be loaded at a non zero address, but it will copy itself
to zero before it starts running.
Mikey
^ permalink raw reply
* Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
From: Andrew Morton @ 2010-09-07 22:38 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Matt Fleming, Albert Herranz, linux-mmc, linux-kernel,
linuxppc-dev, Ben Dooks, Pierre Ossman
In-Reply-To: <20100714130728.GA27339@oksana.dev.rtsoft.ru>
On Wed, 14 Jul 2010 17:07:28 +0400
Anton Vorontsov <avorontsov@mvista.com> wrote:
> Hi all,
>
> Currently the sdhci driver does everything in the atomic context.
> And what is worse, PIO transfers are made from the IRQ handler.
>
> This causes huge latencies (up to 120 ms). On some P2020 SOCs,
> DMA and card detection is broken, which means that kernel polls
> for the card via PIO transfers every second. Needless to say
> that this is quite bad.
>
> So, this patch set reworks sdhci code to avoid atomic context,
> almost completely. We only do two device memory operations
> in the atomic context, and all the rest is threaded.
>
> I noticed no throughput drop neither with PIO transfers nor
> with DMA (tested on MPC8569E CPU), while latencies should be
> greatly improved.
>
This patchset isn't causing any problems yet, but may do so in the
future and will impact the validity of any testing. It seems to be
kind of stuck. Should I drop it all?
^ permalink raw reply
* Re: drivers/ata/sata_dwc_460ex.c fails to build
From: Wolfgang Denk @ 2010-09-07 21:00 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linuxppc-dev, Prodyut Hazarika, Mark Miesfeld
In-Reply-To: <5205dc59ca0e0fd65e50d80eeff60d01@mail.gmail.com>
Dear Rupjyoti Sarmah,
In message <5205dc59ca0e0fd65e50d80eeff60d01@mail.gmail.com> you wrote:
>
> The current mainline 2.6.36-rc3 does not report any error while building
> the SATA driver.
It reports a lot of warnings, though:
-> git describe
v2.6.36-rc3
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag':
drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue':
drivers/ata/sata_dwc_460ex.c:1476: warning: 'err' is used uninitialized in this function
drivers/ata/sata_dwc_460ex.c:1465: note: 'err' was declared here
drivers/scsi/constants.c: In function 'scsi_print_sense':
drivers/scsi/constants.c:1407: warning: zero-length printf format string
drivers/scsi/constants.c:1413: warning: zero-length printf format string
drivers/scsi/constants.c: In function 'scsi_print_result':
drivers/scsi/constants.c:1456: warning: zero-length printf format string
drivers/scsi/sd.c: In function 'sd_print_sense_hdr':
drivers/scsi/sd.c:2628: warning: zero-length printf format string
drivers/scsi/sd.c:2630: warning: zero-length printf format string
drivers/scsi/sd.c: In function 'sd_print_result':
drivers/scsi/sd.c:2636: warning: zero-length printf format string
And the ``'err' is used uninitialized'' warning is indeed a valid one.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
What is mind? No matter. What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
^ permalink raw reply
* Re: [PATCH] mpc8308_p1m: support for MPC8308 P1M board
From: Scott Wood @ 2010-09-07 20:28 UTC (permalink / raw)
To: Ilya Yanok; +Cc: vlad, linuxppc-dev, wd, dzu
In-Reply-To: <1283854143-2299-1-git-send-email-yanok@emcraft.com>
On Tue, 7 Sep 2010 12:09:03 +0200
Ilya Yanok <yanok@emcraft.com> wrote:
> + compatible = "mpc8308_p1m";
This needs a vendor prefix.
> + i2c0@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3000 0x100>;
> + interrupts = <14 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + fram@50 {
> + compatible = "ramtron,24c64";
> + reg = <0x50>;
> + };
> + };
> +
> + i2c1@3100 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cell-index = <0>;
> + compatible = "fsl-i2c";
> + reg = <0x3100 0x100>;
> + interrupts = <15 0x8>;
> + interrupt-parent = <&ipic>;
> + dfsrr;
> + pwm@28 {
> + compatible = "maxim,ds1050";
> + reg = <0x28>;
> + };
> + sensor0@48 {
> + compatible = "maxim,max6625";
> + reg = <0x48>;
> + };
> + sensor1@49 {
> + compatible = "maxim,max6625";
> + reg = <0x49>;
> + };
> + sensor2@4b {
> + compatible = "maxim,max6625";
> + reg = <0x4b>;
> + };
> + };
Why "i2c0@3000" and "i2c1@3100" rather than "i2c@3000" and "i2c@3100"?
Likewise for the sensor nodes.
Drop cell-index; it's not part of the fsl i2c binding (plus, they
probably shouldn't both be zero...).
> + enet0: ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x24000 0x1000>;
> +
> + cell-index = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <0x24000 0x1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <32 0x8 33 0x8 34 0x8>;
> + interrupt-parent = <&ipic>;
> + phy-handle = < &phy1 >;
> + fsl,magic-packet;
8308 does not have magic packet.
> + gpio@c00 {
> + #gpio-cells = <2>;
> + device_type = "gpio";
> + compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
> + reg = <0xc00 0x18>;
> + interrupts = <74 0x8>;
> + interrupt-parent = <&ipic>;
> + gpio-controller;
> + };
Drop device_type.
> + pci0: pcie@e0009000 {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + compatible = "fsl,mpc8308-pcie", "fsl,mpc8314-pcie";
> + reg = <0xe0009000 0x00001000
> + 0xb0000000 0x01000000>;
> + ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
> + 0x01000000 0 0x00000000 0xb1000000 0 0x00800000>;
> + bus-range = <0 0>;
> + interrupt-map-mask = <0xf800 0 0 7>;
> + interrupt-map = <0 0 0 1 &ipic 1 8
> + 0 0 0 2 &ipic 1 8
> + 0 0 0 3 &ipic 1 8
> + 0 0 0 4 &ipic 1 8>;
Should interrupt-map-mask be <0 0 0 7>? Or possibly <0 0 0 0> with
just one map entry?
-Scott
^ permalink raw reply
* Re: Small issue at init with spi_mpc8xxx.c with CPM1
From: Scott Wood @ 2010-09-07 20:00 UTC (permalink / raw)
To: LEROY Christophe; +Cc: Kumar Gala, LinuxPPC-dev
In-Reply-To: <4C86031D.5080804@c-s.fr>
On Tue, 7 Sep 2010 11:17:17 +0200
LEROY Christophe <christophe.leroy@c-s.fr> wrote:
>
> Dear Kumar,
>
> I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1)
>
> Unlike cpm_uart that maps the parameter ram directly using
> of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed().
>
> This has two impacts in the .dts file:
> * The driver must be declared with pram at 1d80 instead of 3d80 whereas
> it is not a child of muram@2000 but a child of cpm@9c0
> * muram@2000/data@0 must be declared with reg = <0x0 0x2000> whereas
> is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate
> space from parameters ram.
>
> Maybe I misunderstood something ?
Don't make the device tree lie, fix the driver instead.
The allocator should not be given any chunks of muram that are
dedicated to a fixed purpose -- it might hand it out to something else
before you reserve it. I don't think that cpm_muram_alloc_fixed() has
any legitimate use at all.
-Scott
^ permalink raw reply
* linux-2.6.36-rc3 bug report
From: d binderman @ 2010-09-07 19:00 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Hello there=2C
I just tried out cppcheck-1.44 on the linux-2.6.36-rc3 source code.
It said
Checking arch/powerpc/kernel/ppc970-pmu.c...
[arch/powerpc/kernel/ppc970-pmu.c:171]: (style) Redundant assignment of "ma=
sk" in switch
The source code is
=A0=A0=A0=A0=A0=A0=A0 case PM_VPU:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mask =3D 0x4c=3B=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 /* byte 0 bits 2=2C3=2C6 */
=A0=A0=A0=A0=A0=A0=A0 case PM_LSU0:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* byte 2 bits 0=2C2=2C3=2C4=
=2C6=3B all of byte 1 */
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mask =3D 0x085dff00=3B
=A0=A0=A0=A0=A0=A0=A0 case PM_LSU1L:
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 mask =3D 0x50 << 24=3B=A0=A0=
=A0=A0=A0 /* byte 3 bits 4=2C6 */
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 break=3B
It looks to me like a missing break on the first and second cases.
Suggest code rework.
Regards
David Binderman
=
^ permalink raw reply
* [RFC] arch/powerpc: Remove duplicate/redundant Altivec entries
From: Matthew McClintock @ 2010-09-07 18:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock
In lieu of having multiple similiar lines, we can just have one
generic cpu-as line for CONFIG_ALTIVEC
---
Was hoping to get comments about this change and if anyone sees any potential
problems?
arch/powerpc/Makefile | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index e07d499..4e88b42 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -131,8 +131,7 @@ KBUILD_CFLAGS += -mno-sched-epilog
endif
cpu-as-$(CONFIG_4xx) += -Wa,-m405
-cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
-cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
+cpu-as-$(CONFIG_ALTIVEC) += -Wa,-maltivec
cpu-as-$(CONFIG_E500) += -Wa,-me500
cpu-as-$(CONFIG_E200) += -Wa,-me200
--
1.6.6.1
^ permalink raw reply related
* kexec on ppc64
From: Matthew McClintock @ 2010-09-07 18:34 UTC (permalink / raw)
To: kexec; +Cc: linuxppc-dev
All,
I'm trying to determine how kexec'ing works on 64 bit powerpc. When =
allocating a region for the kexec'ed kernel is it ever the same as the =
currently running kernel or do you always boot the kexec'ed kernel from =
a different memory region? I understand that a crash kernel will be in a =
different region, however I was hoping to confirm the behavior for a =
normal "kexec -e".
Thanks,
Matthew=
^ permalink raw reply
* [PATCH] mpc8308_p1m: support for MPC8308 P1M board
From: Ilya Yanok @ 2010-09-07 10:09 UTC (permalink / raw)
To: linuxppc-dev, wd, dzu, vlad; +Cc: Ilya Yanok
This patch adds support for MPC8308 P1M board.
Supported devices:
DUART
Dual Ethernet
NOR flash
Both I2C controllers
USB in peripheral mode
PCI Express
Signed-off-by: Ilya Yanok <yanok@emcraft.com>
---
arch/powerpc/boot/dts/mpc8308_p1m.dts | 340 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/Kconfig | 4 +-
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 3 +-
3 files changed, 344 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8308_p1m.dts
diff --git a/arch/powerpc/boot/dts/mpc8308_p1m.dts b/arch/powerpc/boot/dts/mpc8308_p1m.dts
new file mode 100644
index 0000000..159a0d0
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8308_p1m.dts
@@ -0,0 +1,340 @@
+/*
+ * mpc8308_p1m Device Tree Source
+ *
+ * Copyright 2010 Ilya Yanok, Emcraft Systems, yanok@emcraft.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "mpc8308_p1m";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ serial0 = &serial0;
+ serial1 = &serial1;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8308@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <16384>;
+ i-cache-size = <16384>;
+ timebase-frequency = <0>; // from bootloader
+ bus-frequency = <0>; // from bootloader
+ clock-frequency = <0>; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x08000000>; // 128MB at 0
+ };
+
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8315-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <77 0x8>;
+ interrupt-parent = <&ipic>;
+
+ ranges = <0x0 0x0 0xfc000000 0x04000000
+ 0x1 0x0 0xfbff0000 0x00008000
+ 0x2 0x0 0xfbff8000 0x00008000>;
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x4000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ u-boot@0 {
+ reg = <0x0 0x60000>;
+ read-only;
+ };
+ env@60000 {
+ reg = <0x60000 0x20000>;
+ };
+ env1@80000 {
+ reg = <0x80000 0x20000>;
+ };
+ kernel@a0000 {
+ reg = <0xa0000 0x200000>;
+ };
+ dtb@2a0000 {
+ reg = <0x2a0000 0x20000>;
+ };
+ ramdisk@2c0000 {
+ reg = <0x2c0000 0x640000>;
+ };
+ user@700000 {
+ reg = <0x700000 0x3900000>;
+ };
+ };
+
+ can@1,0 {
+ compatible = "nxp,sja1000";
+ reg = <0x1 0x0 0x80>;
+ interrupts = <18 0x8>;
+ interrups-parent = <&ipic>;
+ };
+
+ cpld@2,0 {
+ compatible = "cpld";
+ reg = <0x2 0x0 0x8>;
+ interrupts = <48 0x8>;
+ interrups-parent = <&ipic>;
+ };
+ };
+
+ immr@e0000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8308-immr", "simple-bus";
+ ranges = <0 0xe0000000 0x00100000>;
+ reg = <0xe0000000 0x00000200>;
+ bus-frequency = <0>;
+
+ i2c0@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <14 0x8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ fram@50 {
+ compatible = "ramtron,24c64";
+ reg = <0x50>;
+ };
+ };
+
+ i2c1@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <15 0x8>;
+ interrupt-parent = <&ipic>;
+ dfsrr;
+ pwm@28 {
+ compatible = "maxim,ds1050";
+ reg = <0x28>;
+ };
+ sensor0@48 {
+ compatible = "maxim,max6625";
+ reg = <0x48>;
+ };
+ sensor1@49 {
+ compatible = "maxim,max6625";
+ reg = <0x49>;
+ };
+ sensor2@4b {
+ compatible = "maxim,max6625";
+ reg = <0x4b>;
+ };
+ };
+
+ usb@23000 {
+ compatible = "fsl-usb2-dr";
+ reg = <0x23000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupt-parent = <&ipic>;
+ interrupts = <38 0x8>;
+ dr_mode = "peripheral";
+ phy_type = "ulpi";
+ };
+
+ enet0: ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x24000 0x1000>;
+
+ cell-index = <0>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x24000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <32 0x8 33 0x8 34 0x8>;
+ interrupt-parent = <&ipic>;
+ phy-handle = < &phy1 >;
+ fsl,magic-packet;
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-mdio";
+ reg = <0x520 0x20>;
+ phy1: ethernet-phy@1 {
+ interrupt-parent = <&ipic>;
+ interrupts = <17 0x8>;
+ reg = <0x1>;
+ device_type = "ethernet-phy";
+ };
+ phy2: ethernet-phy@2 {
+ interrupt-parent = <&ipic>;
+ interrupts = <19 0x8>;
+ reg = <0x2>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ enet1: ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ cell-index = <1>;
+ device_type = "network";
+ model = "eTSEC";
+ compatible = "gianfar";
+ reg = <0x25000 0x1000>;
+ ranges = <0x0 0x25000 0x1000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <35 0x8 36 0x8 37 0x8>;
+ interrupt-parent = <&ipic>;
+ phy-handle = < &phy2 >;
+ fsl,magic-packet;
+
+ mdio@520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,gianfar-tbi";
+ reg = <0x520 0x20>;
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+ };
+
+ serial0: serial@4500 {
+ cell-index = <0>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4500 0x100>;
+ clock-frequency = <133333333>;
+ interrupts = <9 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ serial1: serial@4600 {
+ cell-index = <1>;
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x4600 0x100>;
+ clock-frequency = <133333333>;
+ interrupts = <10 0x8>;
+ interrupt-parent = <&ipic>;
+ };
+
+ gpio@c00 {
+ #gpio-cells = <2>;
+ device_type = "gpio";
+ compatible = "fsl,mpc8308-gpio", "fsl,mpc8349-gpio";
+ reg = <0xc00 0x18>;
+ interrupts = <74 0x8>;
+ interrupt-parent = <&ipic>;
+ gpio-controller;
+ };
+
+ timer@500 {
+ compatible = "fsl,mpc8308-gtm", "fsl,gtm";
+ reg = <0x500 0x100>;
+ interrupts = <90 8 78 8 84 8 72 8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <133333333>;
+ };
+
+ /* IPIC
+ * interrupts cell = <intr #, sense>
+ * sense values match linux IORESOURCE_IRQ_* defines:
+ * sense == 8: Level, low assertion
+ * sense == 2: Edge, high-to-low change
+ */
+ ipic: interrupt-controller@700 {
+ compatible = "fsl,ipic";
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <0x700 0x100>;
+ device_type = "ipic";
+ };
+
+ ipic-msi@7c0 {
+ compatible = "fsl,ipic-msi";
+ reg = <0x7c0 0x40>;
+ msi-available-ranges = <0x0 0x100>;
+ interrupts = < 0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8 >;
+ interrupt-parent = < &ipic >;
+ };
+
+ };
+
+ pci0: pcie@e0009000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "fsl,mpc8308-pcie", "fsl,mpc8314-pcie";
+ reg = <0xe0009000 0x00001000
+ 0xb0000000 0x01000000>;
+ ranges = <0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xb1000000 0 0x00800000>;
+ bus-range = <0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <0 0 0 1 &ipic 1 8
+ 0 0 0 2 &ipic 1 8
+ 0 0 0 3 &ipic 1 8
+ 0 0 0 4 &ipic 1 8>;
+ interrupts = <0x1 0x8>;
+ interrupt-parent = <&ipic>;
+ clock-frequency = <0>;
+
+ pcie@0 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ reg = <0 0 0 0 0>;
+ ranges = <0x02000000 0 0xa0000000
+ 0x02000000 0 0xa0000000
+ 0 0x10000000
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00800000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 021763a..73f4135 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -10,12 +10,12 @@ menuconfig PPC_83xx
if PPC_83xx
config MPC830x_RDB
- bool "Freescale MPC830x RDB"
+ bool "Freescale MPC830x RDB and derivatives"
select DEFAULT_UIMAGE
select PPC_MPC831x
select FSL_GTM
help
- This option enables support for the MPC8308 RDB board.
+ This option enables support for the MPC8308 RDB and MPC8308 P1M boards.
config MPC831x_RDB
bool "Freescale MPC831x RDB"
diff --git a/arch/powerpc/platforms/83xx/mpc830x_rdb.c b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
index ac102ee..aa7ef69 100644
--- a/arch/powerpc/platforms/83xx/mpc830x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc830x_rdb.c
@@ -65,7 +65,8 @@ static int __init mpc830x_rdb_probe(void)
unsigned long root = of_get_flat_dt_root();
return of_flat_dt_is_compatible(root, "MPC8308RDB") ||
- of_flat_dt_is_compatible(root, "fsl,mpc8308rdb");
+ of_flat_dt_is_compatible(root, "fsl,mpc8308rdb") ||
+ of_flat_dt_is_compatible(root, "mpc8308_p1m");
}
static struct of_device_id __initdata of_bus_ids[] = {
--
1.6.2.5
^ permalink raw reply related
* Re: pci_request_regions() failure
From: tiejun.chen @ 2010-09-07 9:24 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev
In-Reply-To: <AANLkTi=bDOtCxW9VuXrSyAiCLoFCvWoskORpc_1ebDe7@mail.gmail.com>
Ravi Gupta wrote:
> Hi Tiejun,
>
> Thanks for the reply. I am sending you the updated dmesg O/P(after enabling
> CONFIG_PCI_DEBUG) as attachment as well as at the end of the mail.
>
> As far as driver is concern, I am trying the pci_skel driver available as
> example with LDD book with slight modifications.
Current LDD 3rd may be old for 2.6.35 on some sections :)
>
> Driver Code:
> ================================================================
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/pci.h>
>
> /* PCI IDs */
> static struct pci_device_id ids[] = {
> { PCI_DEVICE(0x1204, 0xe250) },
> { 0, }
> };
> MODULE_DEVICE_TABLE(pci, ids);
>
> static unsigned char skel_get_revision(struct pci_dev *dev)
> {
> u8 revision;
>
> pci_read_config_byte(dev, PCI_REVISION_ID, &revision);
> return revision;
> }
>
> static u16 skel_get_vendor_id(struct pci_dev *dev)
> {
> u16 vendor_id;
>
> pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id);
> return vendor_id;
> }
>
> static u16 skel_get_device_id(struct pci_dev *dev)
> {
> u16 device_id;
>
> pci_read_config_word(dev, PCI_DEVICE_ID, &device_id);
> return device_id;
> }
>
> static int probe(struct pci_dev *dev, const struct pci_device_id *id)
> {
> /* Do probing type stuff here.
> * Like calling request_region();
> */
> int err, i;
> printk(KERN_ALERT "PCI driver: Probe function\n");
>
> /*
> * Enable the bus-master bit values.
> * Some PCI BIOSes fail to set the master-enable bit.
> * Some demos support being an initiator, so need bus master ability.
> */
> err = pci_request_regions(dev, "pci_skell");
> if (err) {
> printk(KERN_ERR "request region failed :%d\n", err);
> return err;
> }
>
> pci_set_master(dev);
>
> if ((err = pci_enable_device(dev)) != 0) {
> printk(KERN_ERR "Unable to Enable PCI device:%d\n", err);
> return err;
> }
>
> printk(KERN_ALERT "PCI driver Vendor ID = %x\n", skel_get_vendor_id(dev));
> printk(KERN_ALERT "PCI driver Device ID = %x\n", skel_get_device_id(dev));
> printk(KERN_ALERT "PCI driver Revision = %d\n", skel_get_revision(dev));
> return 0;
> }
>
> static void remove(struct pci_dev *dev)
> {
> /* clean up any allocated resources and stuff here.
> * like call release_region();
> */
> }
>
> static struct pci_driver pci_driver = {
> .name = "pci_skel",
> .id_table = ids,
> .probe = probe,
> .remove = remove,
> };
>
> static int __init pci_skel_init(void)
> {
> printk(KERN_ALERT "PCI driver: Init function\n");
> return pci_register_driver(&pci_driver);
> }
>
> static void __exit pci_skel_exit(void)
> {
> printk(KERN_ALERT "PCI driver: Exit function\n");
> pci_unregister_driver(&pci_driver);
> }
>
> MODULE_LICENSE("GPL");
>
> module_init(pci_skel_init);
> module_exit(pci_skel_exit);
> ================================================================
>
> The above code fails at the pci_request_regions(dev, "pci_skell"); call,
> with -EBUSY(-16) i.e resource busy error. If I don't request for resources
> and directly enable the pci device by calling pci_device_enable(), it gives
> the error message
>
> PCI driver: Init function
> PCI driver: Probe function
> pci_skel 0001:02:00.0: device not available (can't reserve [mem
> 0x00000000-0x0003ffff])
> Unable to Enable PCI device:-22
> pci_skel: probe of 0001:02:00.0 failed with error -22
Your PCI device should be one virtual device so I think the above should be as
we understood. You know 0x00000000 ~ 0x00003ffff should not be allowed to
reserved.
>
>
>
>> Especially I want to know how/where you get
>> these two range, a8000000-a803ffff and a8040000-a807ffff. You wired them
> firstly
>> on the driver or allocated by the kernel?
>
> Actually as I said before, I tried my device on i386 machine and there I got
> two ranges fe900000-fe93ffff and fe940000-fe97ffff, so from there I am
> guessing that on PowerPC also, it should allocate two ranges
> a8000000-a803ffff and a8040000-a807ffff resp.
I think you should do the following sequence in the probe function of your PCI
driver.
1. pci_enable_device(pdev);
2. pci_request_regions(pdev, DRV_NAME);
3. pci_set_master(pdev);
......
>
>
>
> lspci output
> ================================================================
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
> 21)
> 0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
> (rev 21)
> 0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
> Unknown device e250 ----------> My device
> ================================================================
>
> Dmesg with CONFIG_PCI_DEBUG enable.
> ================================================================
> Using MPC837x RDB/WLAN machine description
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Linux version 2.6.35 (okapi@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
> 4.2-171)) #13 Tue Sep 7 11:37:47 IST 2010
> Found initrd at 0xcf46d000:0xcf7b15b7
> Found legacy serial port 0 for /immr@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=399999996, speed=0
> Found legacy serial port 1 for /immr@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=399999996, speed=0
> bootconsole [udbg0] enabled
> Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
> PCI host bridge /pci@e0008500 (primary) ranges:
> MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
> MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
> IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
> No pci config register base in dev tree, using default
> Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
> PCI host bridge /pcie@e0009000 ranges:
> MEM 0x00000000a8000000..0x00000000b7ffffff -> 0x00000000a8000000
> IO 0x00000000b8000000..0x00000000b87fffff -> 0x0000000000000000
> No pci config register base in dev tree, using default
> Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
> PCI host bridge /pcie@e000a000 ranges:
> MEM 0x00000000c8000000..0x00000000d7ffffff -> 0x00000000c8000000
> IO 0x00000000d8000000..0x00000000d87fffff -> 0x0000000000000000
> Top of RAM: 0x10000000, Total RAM: 0x10000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00010000
> Normal empty
> HighMem empty
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00010000
> On node 0 totalpages: 65536
> free_area_init_node: node 0, pgdat c04285e8, node_mem_map c0482000
> DMA zone: 512 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 65024 pages, LIFO batch:15
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: root=/dev/ram ramdisk_size=120000 rw ip=10.20.50.230:10
> .20.50.70:10.20.50.50:255.255.0.0:PowerQUICC:eth0:off console=ttyS0,115200
> mtdparts=nand:4m(kernel),-(jffs2)
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> High memory: 0k
> Memory: 251884k/262144k available (4072k kernel code, 10260k reserved, 244k
> data, 267k bss, 192k init)
> Kernel virtual memory layout:
> * 0xfffcf000..0xfffff000 : fixmap
> * 0xff800000..0xffc00000 : highmem PTEs
> * 0xfe6f7000..0xff800000 : early ioremap
> * 0xd1000000..0xfe6f7000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> RCU-based detection of stalled CPUs is disabled.
> Verbose stalled-CPUs detection is disabled.
> NR_IRQS:512
> IPIC (128 IRQ sources) at d1000700
> time_init: decrementer frequency = 99.999999 MHz
> time_init: processor frequency = 799.999992 MHz
> clocksource: timebase mult[2800000] shift[22] registered
> clockevent: decrementer mult[19999995] shift[32] cpu[0]
> Console: colour dummy device 80x25
> pid_max: default: 32768 minimum: 301
> Security Framework initialized
> SELinux: Disabled at boot.
> Mount-cache hash table entries: 512
> Initializing cgroup subsys ns
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> NET: Registered protocol family 16
> irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 38
> __irq_set_trigger: setting type, irq = 38, flags = 8
> ipic_set_irq_type function, with virq = 38, flow = 8
> irq: irq 74 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 74
> __irq_set_trigger: setting type, irq = 74, flags = 8
> ipic_set_irq_type function, with virq = 74, flow = 8
> irq: irq 75 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 75
> __irq_set_trigger: setting type, irq = 75, flags = 8
> ipic_set_irq_type function, with virq = 75, flow = 8
> PCI: Probing PCI hardware
> pci_bus 0000:00: scanning bus
> pci 0000:00:00.0: found [1957:00c6] class 000b20 header type 00
> pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
> pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
> pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
> pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x238
> pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x48
> pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci 0000:00:00.0: supports D1 D2
> pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
> pci 0000:00:00.0: PME# disabled
> pci_bus 0000:00: fixups for bus
> pci_bus 0000:00: bus scan returning with max=00
> pci_bus 0001:01: scanning bus
> pci 0001:01:00.0: found [1957:00c6] class 000b20 header type 01
> pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
> pci 0001:01:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
> pci 0001:01:00.0: calling pcibios_fixup_resources+0x0/0x238
> pci 0001:01:00.0: calling quirk_fsl_pcie_header+0x0/0x48
> pci 0001:01:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci 0001:01:00.0: supports D1 D2
> pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
> pci 0001:01:00.0: PME# disabled
> pci_bus 0001:01: fixups for bus
> pci 0001:01:00.0: scanning [bus 01-ff] behind bridge, pass 0
> pci 0001:01:00.0: bus configuration invalid, reconfiguring
> pci 0001:01:00.0: scanning [bus 00-00] behind bridge, pass 1
> pci_bus 0001:02: scanning bus
> pci 0001:02:00.0: found [1204:e250] class 000000 header type 00
> pci 0001:02:00.0: reg 10: [mem 0xfffc0000-0xffffffff]
> pci 0001:02:00.0: reg 14: [mem 0xfffc0000-0xffffffff]
These infos make me confused. 0xfxxxxxxx should not be original BARs value and
also cannot be allocated for resources successfully by the kernel.
Often the kernel get them to allocate as PCI bus range. For example,
Firstly checking.....
-------
pci 0001:02:00.0: reg 10: [mem 0x00000000-0x00003fff 64bit]
pci 0001:02:00.0: reg 18: [io 0x0000-0x00ff]
pci 0001:02:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
Then allocating as the following:
-------
pci 0001:02:00.0: BAR 6: assigned [mem 0xa0000000-0xa001ffff pref]
pci 0001:02:00.0: BAR 0: assigned [mem 0xa0020000-0xa0023fff 64bit]
pci 0001:02:00.0: BAR 0: set to [mem 0xa0020000-0xa0023fff 64bit] (PCI address
[0xa0020000-0xa0023fff]
So I think your device BARs should be pre-allocated incorrectly by the
bootloader since your device is so special. Maybe this is just why that's
different from you saw on x86. As a result we cannot re-allocated into PCI bus
range as the kernel expect.
Looks we need some pci_fixup to modify them. Firstly I think you'd better 'zero'
all BARs of your PCI device on the function, pci_scan_device, on the file,
drivers/pci/probe.c. On there you can dedicate that once your device is probed.
Please check the each BAR's value again after the above fix.
Best Regards
Tiejun
> pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x238
> pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1c0
> pci_bus 0001:02: fixups for bus
> pci 0001:01:00.0: PCI bridge to [bus 02-ff]
> pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
> pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
> pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
> (disabled)
> irq: irq 1 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
> irq 16
> __irq_set_trigger: setting type, irq = 16, flags = 8
> ipic_set_irq_type function, with virq = 16, flow = 8
> pci_bus 0001:02: bus scan returning with max=02
> pci_bus 0001:01: bus scan returning with max=02
> pci_bus 0002:03: scanning bus
> pci_bus 0002:03: fixups for bus
> pci_bus 0002:03: bus scan returning with max=03
> PCI->OF bus map:
> 0 -> 0
> 1 -> 0
> 3 -> 0
> PCI: Cannot allocate resource region 0 of device 0001:02:00.0, will remap
> PCI: Cannot allocate resource region 1 of device 0001:02:00.0, will remap
> pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
> pci 0001:01:00.0: PCI bridge to [bus 02-02]
> pci 0001:01:00.0: bridge window [io disabled]
> pci 0001:01:00.0: bridge window [mem 0xa8000000-0xa80fffff]
> pci 0001:01:00.0: bridge window [mem pref disabled]
> pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
> pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
> pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
> pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
> pci_bus 0001:01: resource 1 [mem 0xa8000000-0xb7ffffff]
> pci_bus 0001:02: resource 1 [mem 0xa8000000-0xa80fffff]
> pci_bus 0002:03: resource 0 [io 0xfeffc000-0xff7fbfff]
> pci_bus 0002:03: resource 1 [mem 0xc8000000-0xd7ffffff]
> Registering qe_ic with sysfs...
> Registering ipic with sysfs...
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> SCSI subsystem initialized
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x740
> pci 0001:01:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0001:01:00.0: calling quirk_usb_early_handoff+0x0/0x740
> pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x44
> pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x740
> PCI: CLS 32 bytes, default 32
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd
> Freeing initrd memory: 3345k freed
> irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
> irq 17
> __irq_set_trigger: setting type, irq = 17, flags = 8
> ipic_set_irq_type function, with virq = 17, flow = 8
> irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 18
> __irq_set_trigger: setting type, irq = 18, flags = 8
> ipic_set_irq_type function, with virq = 18, flow = 8
> irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 80
> __irq_set_trigger: setting type, irq = 80, flags = 8
> ipic_set_irq_type function, with virq = 80, flow = 8
> audit: initializing netlink socket (disabled)
> type=2000 audit(0.212:1): initialized
> JFFS2 version 2.2. (NAND) � 2001-2006 Red Hat, Inc.
> SGI XFS with security attributes, large block/inode numbers, no debug
> enabled
> msgmni has been set to 498
> alg: No test for cipher_null (cipher_null-generic)
> alg: No test for ecb(cipher_null) (ecb-cipher_null)
> alg: No test for digest_null (digest_null-generic)
> alg: No test for compress_null (compress_null-generic)
> alg: No test for stdrng (krng)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 17) is a 16550A
> console [ttyS0] enabled, bootconsole disabled
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 18) is a 16550A
> brd: module loaded
> of_mpc8xxx_spi_probe function called.
> irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 19
> __irq_set_trigger: setting type, irq = 19, flags = 8
> ipic_set_irq_type function, with virq = 19, flow = 8
> mpc8xxx_spi_probe function called.
> mpc8xxx_spi e0007000.spi: at 0xd1078000 (irq = 19), CPU mode
> irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 32
> __irq_set_trigger: setting type, irq = 32, flags = 8
> ipic_set_irq_type function, with virq = 32, flow = 8
> irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 33
> __irq_set_trigger: setting type, irq = 33, flags = 8
> ipic_set_irq_type function, with virq = 33, flow = 8
> irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 34
> __irq_set_trigger: setting type, irq = 34, flags = 8
> ipic_set_irq_type function, with virq = 34, flow = 8
> eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00:00:00:0a
> eth0: Running with NAPI enabled
> eth0: RX BD ring size for Q[0]: 256
> eth0: TX BD ring size for Q[0]: 256
> irq: irq 35 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 35
> __irq_set_trigger: setting type, irq = 35, flags = 8
> ipic_set_irq_type function, with virq = 35, flow = 8
> irq: irq 36 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 36
> __irq_set_trigger: setting type, irq = 36, flags = 8
> ipic_set_irq_type function, with virq = 36, flow = 8
> irq: irq 37 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 37
> __irq_set_trigger: setting type, irq = 37, flags = 8
> ipic_set_irq_type function, with virq = 37, flow = 8
> eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
> eth1: Running with NAPI enabled
> eth1: RX BD ring size for Q[0]: 256
> eth1: TX BD ring size for Q[0]: 256
> ucc_geth: QE UCC Gigabit Ethernet Controller
> Freescale PowerQUICC MII Bus: probed
> irq: irq 17 on host /immr@e0000000/interrupt-controller@700 mapped to
> virtual irq 20
> __irq_set_trigger: setting type, irq = 20, flags = 8
> ipic_set_irq_type function, with virq = 20, flow = 8
> Freescale PowerQUICC MII Bus: probed
> mice: PS/2 mouse device common for all mice
> Skipping unavailable LED gpio -19 (pwr)
> Skipping unavailable LED gpio -19 (hdd)
> TCP cubic registered
> NET: Registered protocol family 17
> registered taskstats version 1
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 192k init
> PHY: mdio@e0024520:02 - Link is Up - 10/Half
> ================================================================
>
> Regards
> Ravi Gupta
>
^ permalink raw reply
* Small issue at init with spi_mpc8xxx.c with CPM1
From: LEROY Christophe @ 2010-09-07 9:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC-dev
Dear Kumar,
I have a small issue in the init of spi_mpc8xxx.c with MPC866 (CPM1)
Unlike cpm_uart that maps the parameter ram directly using
of_iomap(np,1), spi_mpc8xxx.c uses cpm_muram_alloc_fixed().
This has two impacts in the .dts file:
* The driver must be declared with pram at 1d80 instead of 3d80 whereas
it is not a child of muram@2000 but a child of cpm@9c0
* muram@2000/data@0 must be declared with reg = <0x0 0x2000> whereas
is should be reg=<0x0 0x1c00> to avoid cpm_muram_alloc() to allocate
space from parameters ram.
Maybe I misunderstood something ?
Regards
Christophe Leroy
^ permalink raw reply
* Re: pci_request_regions() failure
From: Ravi Gupta @ 2010-09-07 7:20 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <4C85CCD6.3020504@windriver.com>
[-- Attachment #1.1: Type: text/plain, Size: 17006 bytes --]
Hi Tiejun,
Thanks for the reply. I am sending you the updated dmesg O/P(after enabling
CONFIG_PCI_DEBUG) as attachment as well as at the end of the mail.
As far as driver is concern, I am trying the pci_skel driver available as
example with LDD book with slight modifications.
Driver Code:
================================================================
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/pci.h>
/* PCI IDs */
static struct pci_device_id ids[] = {
{ PCI_DEVICE(0x1204, 0xe250) },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, ids);
static unsigned char skel_get_revision(struct pci_dev *dev)
{
u8 revision;
pci_read_config_byte(dev, PCI_REVISION_ID, &revision);
return revision;
}
static u16 skel_get_vendor_id(struct pci_dev *dev)
{
u16 vendor_id;
pci_read_config_word(dev, PCI_VENDOR_ID, &vendor_id);
return vendor_id;
}
static u16 skel_get_device_id(struct pci_dev *dev)
{
u16 device_id;
pci_read_config_word(dev, PCI_DEVICE_ID, &device_id);
return device_id;
}
static int probe(struct pci_dev *dev, const struct pci_device_id *id)
{
/* Do probing type stuff here.
* Like calling request_region();
*/
int err, i;
printk(KERN_ALERT "PCI driver: Probe function\n");
/*
* Enable the bus-master bit values.
* Some PCI BIOSes fail to set the master-enable bit.
* Some demos support being an initiator, so need bus master ability.
*/
err = pci_request_regions(dev, "pci_skell");
if (err) {
printk(KERN_ERR "request region failed :%d\n", err);
return err;
}
pci_set_master(dev);
if ((err = pci_enable_device(dev)) != 0) {
printk(KERN_ERR "Unable to Enable PCI device:%d\n", err);
return err;
}
printk(KERN_ALERT "PCI driver Vendor ID = %x\n", skel_get_vendor_id(dev));
printk(KERN_ALERT "PCI driver Device ID = %x\n", skel_get_device_id(dev));
printk(KERN_ALERT "PCI driver Revision = %d\n", skel_get_revision(dev));
return 0;
}
static void remove(struct pci_dev *dev)
{
/* clean up any allocated resources and stuff here.
* like call release_region();
*/
}
static struct pci_driver pci_driver = {
.name = "pci_skel",
.id_table = ids,
.probe = probe,
.remove = remove,
};
static int __init pci_skel_init(void)
{
printk(KERN_ALERT "PCI driver: Init function\n");
return pci_register_driver(&pci_driver);
}
static void __exit pci_skel_exit(void)
{
printk(KERN_ALERT "PCI driver: Exit function\n");
pci_unregister_driver(&pci_driver);
}
MODULE_LICENSE("GPL");
module_init(pci_skel_init);
module_exit(pci_skel_exit);
================================================================
The above code fails at the pci_request_regions(dev, "pci_skell"); call,
with -EBUSY(-16) i.e resource busy error. If I don't request for resources
and directly enable the pci device by calling pci_device_enable(), it gives
the error message
PCI driver: Init function
PCI driver: Probe function
pci_skel 0001:02:00.0: device not available (can't reserve [mem
0x00000000-0x0003ffff])
Unable to Enable PCI device:-22
pci_skel: probe of 0001:02:00.0 failed with error -22
> Especially I want to know how/where you get
> these two range, a8000000-a803ffff and a8040000-a807ffff. You wired them
firstly
> on the driver or allocated by the kernel?
Actually as I said before, I tried my device on i386 machine and there I got
two ranges fe900000-fe93ffff and fe940000-fe97ffff, so from there I am
guessing that on PowerPC also, it should allocate two ranges
a8000000-a803ffff and a8040000-a807ffff resp.
lspci output
================================================================
0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
21)
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
(rev 21)
0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Unknown device e250 ----------> My device
================================================================
Dmesg with CONFIG_PCI_DEBUG enable.
================================================================
Using MPC837x RDB/WLAN machine description
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35 (okapi@okapi) (gcc version 4.2.3 (Sourcery G++ Lite
4.2-171)) #13 Tue Sep 7 11:37:47 IST 2010
Found initrd at 0xcf46d000:0xcf7b15b7
Found legacy serial port 0 for /immr@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=399999996, speed=0
Found legacy serial port 1 for /immr@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=399999996, speed=0
bootconsole [udbg0] enabled
Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
PCI host bridge /pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
PCI host bridge /pcie@e0009000 ranges:
MEM 0x00000000a8000000..0x00000000b7ffffff -> 0x00000000a8000000
IO 0x00000000b8000000..0x00000000b87fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
PCI host bridge /pcie@e000a000 ranges:
MEM 0x00000000c8000000..0x00000000d7ffffff -> 0x00000000c8000000
IO 0x00000000d8000000..0x00000000d87fffff -> 0x0000000000000000
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal empty
HighMem empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c04285e8, node_mem_map c0482000
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram ramdisk_size=120000 rw ip=10.20.50.230:10
.20.50.70:10.20.50.50:255.255.0.0:PowerQUICC:eth0:off console=ttyS0,115200
mtdparts=nand:4m(kernel),-(jffs2)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
High memory: 0k
Memory: 251884k/262144k available (4072k kernel code, 10260k reserved, 244k
data, 267k bss, 192k init)
Kernel virtual memory layout:
* 0xfffcf000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xfe6f7000..0xff800000 : early ioremap
* 0xd1000000..0xfe6f7000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:512
IPIC (128 IRQ sources) at d1000700
time_init: decrementer frequency = 99.999999 MHz
time_init: processor frequency = 799.999992 MHz
clocksource: timebase mult[2800000] shift[22] registered
clockevent: decrementer mult[19999995] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
NET: Registered protocol family 16
irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 38
__irq_set_trigger: setting type, irq = 38, flags = 8
ipic_set_irq_type function, with virq = 38, flow = 8
irq: irq 74 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 74
__irq_set_trigger: setting type, irq = 74, flags = 8
ipic_set_irq_type function, with virq = 74, flow = 8
irq: irq 75 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 75
__irq_set_trigger: setting type, irq = 75, flags = 8
ipic_set_irq_type function, with virq = 75, flow = 8
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: found [1957:00c6] class 000b20 header type 00
pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci_bus 0000:00: bus scan returning with max=00
pci_bus 0001:01: scanning bus
pci 0001:01:00.0: found [1957:00c6] class 000b20 header type 01
pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:01:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0001:01:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0001:01:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0001:01:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0001:01:00.0: supports D1 D2
pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
pci 0001:01:00.0: PME# disabled
pci_bus 0001:01: fixups for bus
pci 0001:01:00.0: scanning [bus 01-ff] behind bridge, pass 0
pci 0001:01:00.0: bus configuration invalid, reconfiguring
pci 0001:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:02: scanning bus
pci 0001:02:00.0: found [1204:e250] class 000000 header type 00
pci 0001:02:00.0: reg 10: [mem 0xfffc0000-0xffffffff]
pci 0001:02:00.0: reg 14: [mem 0xfffc0000-0xffffffff]
pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci_bus 0001:02: fixups for bus
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref]
(disabled)
irq: irq 1 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
irq 16
__irq_set_trigger: setting type, irq = 16, flags = 8
ipic_set_irq_type function, with virq = 16, flow = 8
pci_bus 0001:02: bus scan returning with max=02
pci_bus 0001:01: bus scan returning with max=02
pci_bus 0002:03: scanning bus
pci_bus 0002:03: fixups for bus
pci_bus 0002:03: bus scan returning with max=03
PCI->OF bus map:
0 -> 0
1 -> 0
3 -> 0
PCI: Cannot allocate resource region 0 of device 0001:02:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0001:02:00.0, will remap
pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
pci 0001:01:00.0: PCI bridge to [bus 02-02]
pci 0001:01:00.0: bridge window [io disabled]
pci 0001:01:00.0: bridge window [mem 0xa8000000-0xa80fffff]
pci 0001:01:00.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
pci_bus 0001:01: resource 1 [mem 0xa8000000-0xb7ffffff]
pci_bus 0001:02: resource 1 [mem 0xa8000000-0xa80fffff]
pci_bus 0002:03: resource 0 [io 0xfeffc000-0xff7fbfff]
pci_bus 0002:03: resource 1 [mem 0xc8000000-0xd7ffffff]
Registering qe_ic with sysfs...
Registering ipic with sysfs...
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:01:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:01:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x740
PCI: CLS 32 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 3345k freed
irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to virtual
irq 17
__irq_set_trigger: setting type, irq = 17, flags = 8
ipic_set_irq_type function, with virq = 17, flow = 8
irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 18
__irq_set_trigger: setting type, irq = 18, flags = 8
ipic_set_irq_type function, with virq = 18, flow = 8
irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 80
__irq_set_trigger: setting type, irq = 80, flags = 8
ipic_set_irq_type function, with virq = 80, flow = 8
audit: initializing netlink socket (disabled)
type=2000 audit(0.212:1): initialized
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
SGI XFS with security attributes, large block/inode numbers, no debug
enabled
msgmni has been set to 498
alg: No test for cipher_null (cipher_null-generic)
alg: No test for ecb(cipher_null) (ecb-cipher_null)
alg: No test for digest_null (digest_null-generic)
alg: No test for compress_null (compress_null-generic)
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 17) is a 16550A
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 18) is a 16550A
brd: module loaded
of_mpc8xxx_spi_probe function called.
irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 19
__irq_set_trigger: setting type, irq = 19, flags = 8
ipic_set_irq_type function, with virq = 19, flow = 8
mpc8xxx_spi_probe function called.
mpc8xxx_spi e0007000.spi: at 0xd1078000 (irq = 19), CPU mode
irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 32
__irq_set_trigger: setting type, irq = 32, flags = 8
ipic_set_irq_type function, with virq = 32, flow = 8
irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 33
__irq_set_trigger: setting type, irq = 33, flags = 8
ipic_set_irq_type function, with virq = 33, flow = 8
irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 34
__irq_set_trigger: setting type, irq = 34, flags = 8
ipic_set_irq_type function, with virq = 34, flow = 8
eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00:00:00:0a
eth0: Running with NAPI enabled
eth0: RX BD ring size for Q[0]: 256
eth0: TX BD ring size for Q[0]: 256
irq: irq 35 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 35
__irq_set_trigger: setting type, irq = 35, flags = 8
ipic_set_irq_type function, with virq = 35, flow = 8
irq: irq 36 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 36
__irq_set_trigger: setting type, irq = 36, flags = 8
ipic_set_irq_type function, with virq = 36, flow = 8
irq: irq 37 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 37
__irq_set_trigger: setting type, irq = 37, flags = 8
ipic_set_irq_type function, with virq = 37, flow = 8
eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
eth1: Running with NAPI enabled
eth1: RX BD ring size for Q[0]: 256
eth1: TX BD ring size for Q[0]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
Freescale PowerQUICC MII Bus: probed
irq: irq 17 on host /immr@e0000000/interrupt-controller@700 mapped to
virtual irq 20
__irq_set_trigger: setting type, irq = 20, flags = 8
ipic_set_irq_type function, with virq = 20, flow = 8
Freescale PowerQUICC MII Bus: probed
mice: PS/2 mouse device common for all mice
Skipping unavailable LED gpio -19 (pwr)
Skipping unavailable LED gpio -19 (hdd)
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 192k init
PHY: mdio@e0024520:02 - Link is Up - 10/Half
================================================================
Regards
Ravi Gupta
[-- Attachment #1.2: Type: text/html, Size: 18171 bytes --]
[-- Attachment #2: dmesg_log --]
[-- Type: application/octet-stream, Size: 12441 bytes --]
Using MPC837x RDB/WLAN machine description
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.35 (okapi@okapi) (gcc version 4.2.3 (Sourcery G++ Lite 4.2-171)) #13 Tue Sep 7 11:37:47 IST 2010
Found initrd at 0xcf46d000:0xcf7b15b7
Found legacy serial port 0 for /immr@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=399999996, speed=0
Found legacy serial port 1 for /immr@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=399999996, speed=0
bootconsole [udbg0] enabled
Found FSL PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0
PCI host bridge /pci@e0008500 (primary) ranges:
MEM 0x0000000090000000..0x000000009fffffff -> 0x0000000090000000
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000 Prefetch
IO 0x00000000e0300000..0x00000000e03fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e0009000. Firmware bus number: 0->255
PCI host bridge /pcie@e0009000 ranges:
MEM 0x00000000a8000000..0x00000000b7ffffff -> 0x00000000a8000000
IO 0x00000000b8000000..0x00000000b87fffff -> 0x0000000000000000
No pci config register base in dev tree, using default
Found FSL PCI host bridge at 0x00000000e000a000. Firmware bus number: 0->255
PCI host bridge /pcie@e000a000 ranges:
MEM 0x00000000c8000000..0x00000000d7ffffff -> 0x00000000c8000000
IO 0x00000000d8000000..0x00000000d87fffff -> 0x0000000000000000
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00010000
Normal empty
HighMem empty
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00010000
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c04285e8, node_mem_map c0482000
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/ram ramdisk_size=120000 rw ip=10.20.50.230:10.20.50.70:10.20.50.50:255.255.0.0:PowerQUICC:eth0:off console=ttyS0,115200 mtdparts=nand:4m(kernel),-(jffs2)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
High memory: 0k
Memory: 251884k/262144k available (4072k kernel code, 10260k reserved, 244k data, 267k bss, 192k init)
Kernel virtual memory layout:
* 0xfffcf000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xfe6f7000..0xff800000 : early ioremap
* 0xd1000000..0xfe6f7000 : vmalloc & ioremap
Hierarchical RCU implementation.
RCU-based detection of stalled CPUs is disabled.
Verbose stalled-CPUs detection is disabled.
NR_IRQS:512
IPIC (128 IRQ sources) at d1000700
time_init: decrementer frequency = 99.999999 MHz
time_init: processor frequency = 799.999992 MHz
clocksource: timebase mult[2800000] shift[22] registered
clockevent: decrementer mult[19999995] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Security Framework initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 512
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
NET: Registered protocol family 16
irq: irq 38 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 38
__irq_set_trigger: setting type, irq = 38, flags = 8
ipic_set_irq_type function, with virq = 38, flow = 8
irq: irq 74 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 74
__irq_set_trigger: setting type, irq = 74, flags = 8
ipic_set_irq_type function, with virq = 74, flow = 8
irq: irq 75 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 75
__irq_set_trigger: setting type, irq = 75, flags = 8
ipic_set_irq_type function, with virq = 75, flow = 8
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:00.0: found [1957:00c6] class 000b20 header type 00
pci 0000:00:00.0: reg 10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 18: [mem 0x00000000-0x0fffffff 64bit pref]
pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:00.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci_bus 0000:00: bus scan returning with max=00
pci_bus 0001:01: scanning bus
pci 0001:01:00.0: found [1957:00c6] class 000b20 header type 01
pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:01:00.0: calling fixup_hide_host_resource_fsl+0x0/0x58
pci 0001:01:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0001:01:00.0: calling quirk_fsl_pcie_header+0x0/0x48
pci 0001:01:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci 0001:01:00.0: supports D1 D2
pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot
pci 0001:01:00.0: PME# disabled
pci_bus 0001:01: fixups for bus
pci 0001:01:00.0: scanning [bus 01-ff] behind bridge, pass 0
pci 0001:01:00.0: bus configuration invalid, reconfiguring
pci 0001:01:00.0: scanning [bus 00-00] behind bridge, pass 1
pci_bus 0001:02: scanning bus
pci 0001:02:00.0: found [1204:e250] class 000000 header type 00
pci 0001:02:00.0: reg 10: [mem 0xfffc0000-0xffffffff]
pci 0001:02:00.0: reg 14: [mem 0xfffc0000-0xffffffff]
pci 0001:02:00.0: calling pcibios_fixup_resources+0x0/0x238
pci 0001:02:00.0: calling quirk_resource_alignment+0x0/0x1c0
pci_bus 0001:02: fixups for bus
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
irq: irq 1 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 16
__irq_set_trigger: setting type, irq = 16, flags = 8
ipic_set_irq_type function, with virq = 16, flow = 8
pci_bus 0001:02: bus scan returning with max=02
pci_bus 0001:01: bus scan returning with max=02
pci_bus 0002:03: scanning bus
pci_bus 0002:03: fixups for bus
pci_bus 0002:03: bus scan returning with max=03
PCI->OF bus map:
0 -> 0
1 -> 0
3 -> 0
PCI: Cannot allocate resource region 0 of device 0001:02:00.0, will remap
PCI: Cannot allocate resource region 1 of device 0001:02:00.0, will remap
pci 0001:01:00.0: BAR 8: assigned [mem 0xa8000000-0xa80fffff]
pci 0001:01:00.0: PCI bridge to [bus 02-02]
pci 0001:01:00.0: bridge window [io disabled]
pci 0001:01:00.0: bridge window [mem 0xa8000000-0xa80fffff]
pci 0001:01:00.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xfffff]
pci_bus 0000:00: resource 1 [mem 0x90000000-0x9fffffff]
pci_bus 0000:00: resource 2 [mem 0x80000000-0x8fffffff pref]
pci_bus 0001:01: resource 0 [io 0xff7fe000-0xffffdfff]
pci_bus 0001:01: resource 1 [mem 0xa8000000-0xb7ffffff]
pci_bus 0001:02: resource 1 [mem 0xa8000000-0xa80fffff]
pci_bus 0002:03: resource 0 [io 0xfeffc000-0xff7fbfff]
pci_bus 0002:03: resource 1 [mem 0xc8000000-0xd7ffffff]
Registering qe_ic with sysfs...
Registering ipic with sysfs...
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
pci 0000:00:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0000:00:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:01:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:01:00.0: calling quirk_usb_early_handoff+0x0/0x740
pci 0001:02:00.0: calling quirk_cardbus_legacy+0x0/0x44
pci 0001:02:00.0: calling quirk_usb_early_handoff+0x0/0x740
PCI: CLS 32 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 3345k freed
irq: irq 9 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 17
__irq_set_trigger: setting type, irq = 17, flags = 8
ipic_set_irq_type function, with virq = 17, flow = 8
irq: irq 10 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 18
__irq_set_trigger: setting type, irq = 18, flags = 8
ipic_set_irq_type function, with virq = 18, flow = 8
irq: irq 80 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 80
__irq_set_trigger: setting type, irq = 80, flags = 8
ipic_set_irq_type function, with virq = 80, flow = 8
audit: initializing netlink socket (disabled)
type=2000 audit(0.212:1): initialized
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
SGI XFS with security attributes, large block/inode numbers, no debug enabled
msgmni has been set to 498
alg: No test for cipher_null (cipher_null-generic)
alg: No test for ecb(cipher_null) (ecb-cipher_null)
alg: No test for digest_null (digest_null-generic)
alg: No test for compress_null (compress_null-generic)
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 17) is a 16550A
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 18) is a 16550A
brd: module loaded
of_mpc8xxx_spi_probe function called.
irq: irq 16 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 19
__irq_set_trigger: setting type, irq = 19, flags = 8
ipic_set_irq_type function, with virq = 19, flow = 8
mpc8xxx_spi_probe function called.
mpc8xxx_spi e0007000.spi: at 0xd1078000 (irq = 19), CPU mode
irq: irq 32 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 32
__irq_set_trigger: setting type, irq = 32, flags = 8
ipic_set_irq_type function, with virq = 32, flow = 8
irq: irq 33 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 33
__irq_set_trigger: setting type, irq = 33, flags = 8
ipic_set_irq_type function, with virq = 33, flow = 8
irq: irq 34 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 34
__irq_set_trigger: setting type, irq = 34, flags = 8
ipic_set_irq_type function, with virq = 34, flow = 8
eth0: Gianfar Ethernet Controller Version 1.2, 04:00:00:00:00:0a
eth0: Running with NAPI enabled
eth0: RX BD ring size for Q[0]: 256
eth0: TX BD ring size for Q[0]: 256
irq: irq 35 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 35
__irq_set_trigger: setting type, irq = 35, flags = 8
ipic_set_irq_type function, with virq = 35, flow = 8
irq: irq 36 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 36
__irq_set_trigger: setting type, irq = 36, flags = 8
ipic_set_irq_type function, with virq = 36, flow = 8
irq: irq 37 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 37
__irq_set_trigger: setting type, irq = 37, flags = 8
ipic_set_irq_type function, with virq = 37, flow = 8
eth1: Gianfar Ethernet Controller Version 1.2, 00:00:00:00:00:00
eth1: Running with NAPI enabled
eth1: RX BD ring size for Q[0]: 256
eth1: TX BD ring size for Q[0]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
Freescale PowerQUICC MII Bus: probed
irq: irq 17 on host /immr@e0000000/interrupt-controller@700 mapped to virtual irq 20
__irq_set_trigger: setting type, irq = 20, flags = 8
ipic_set_irq_type function, with virq = 20, flow = 8
Freescale PowerQUICC MII Bus: probed
mice: PS/2 mouse device common for all mice
Skipping unavailable LED gpio -19 (pwr)
Skipping unavailable LED gpio -19 (hdd)
TCP cubic registered
NET: Registered protocol family 17
registered taskstats version 1
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 192k init
PHY: mdio@e0024520:02 - Link is Up - 10/Half
^ permalink raw reply
* RE:
From: Rupjyoti Sarmah @ 2010-09-07 6:29 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Prodyut Hazarika, Mark Miesfeld
In-Reply-To: <20100902061423.19D66153A79@gemini.denx.de>
Hi Wolfgang,
The current mainline 2.6.36-rc3 does not report any error while building
the SATA driver.
Regards,
Rup
-----Original Message-----
From: Rupjyoti Sarmah [mailto:rsarmah@apm.com]
Sent: Thursday, September 02, 2010 8:22 PM
To: 'Wolfgang Denk'
Cc: 'linuxppc-dev@ozlabs.org'; 'Prodyut Hazarika'; 'Mark Miesfeld'
Subject: RE:
Hi Wolfgang,
Sorry that I did not have a chance to check it recently.
Regards,
Rup
-----Original Message-----
From: Wolfgang Denk [mailto:wd@denx.de]
Sent: Thursday, September 02, 2010 11:44 AM
To: Rupjyoti Sarmah; Prodyut Hazarika; Mark Miesfeld
Cc: linuxppc-dev@ozlabs.org
Subject: Re:
Dear Rupjyoti, Prodyut, Mark,
two weeks ago I wrote:
In message <20100818205646.57783157D71@gemini.denx.de> you wrote:
>
> drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
> Do you have any hints how to fix that?
Any comments or ideas how to fix this?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is an illusion perpetrated by the manufacturers of space.
^ permalink raw reply
* Re: pci_request_regions() failure
From: tiejun.chen @ 2010-09-07 5:25 UTC (permalink / raw)
To: Ravi Gupta; +Cc: linuxppc-dev
In-Reply-To: <AANLkTim5kasMWC6u-mhQyCRiPv1w7BCg7o-mBfy28DfS@mail.gmail.com>
Ravi Gupta wrote:
> Hi,
>
> I am facing a problem while requesting pci resource. I have some data that I
> am hopeful will help address the issue.
>
> I am currently running on a MPC837xERDB board(powerpc) with a 2.6.35 kernel.
> The problem is that whenever I insert the card (LatticeECP2M PCI Express
> Development Kit<http://www.latticesemi.com/products/developmenthardware/developmentkits/pciexpressdevkitecp2m/index.cfm>)
> in pci-express slot 0 and try to load my driver module, I get a
> pci_request_regions() failure(error -EBUSY). The interesting thing is the
> region that it fails for. According to /proc/iomem, slot0 has
> a8000000-b7ffffff as its memory ranges. However, the memory region requested
> by my device is a8000000-a803ffff and a8040000-a807ffff which falls in the
> slot0 range. But after boot up when I look at /proc/iomem, there is a
> already allocated resource range present there, which overlaps with the
> range refined in my device, hence the pci_request_regions() fails.
>
> Output of lspci
> 0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
> 21)
> 0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
> (rev 21)
> 0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
> Unknown device e250 ---> My device
>
> Contents of /pro/iomem file
> # cat /proc/iomem
> 80000000-8fffffff : /pci@e0008500
> 90000000-9fffffff : /pci@e0008500
> a8000000-b7ffffff : /pcie@e0009000
> a8000000-a80fffff : PCI Bus 0001:02 ---> colprit range
> c8000000-d7ffffff : /pcie@e000a000
> e0004500-e0004507 : serial
> e0004600-e0004607 : serial
> e0023000-e0023fff : usb
>
> Now my doubt is, who is allocating this range and why? It seem to me a
I think the kernel don't allocate the used PCI range to another PCI device. So
you can enable CONFIG_PCI_DEBUG then execute 'dmesg' to get more information.
Before you don't load your module the kernel still can probe the plugged PCI
device and allocate/reserve appropriate PCI range for your device. Then you can
acquire the proper PCI IO/MEM range from there when loading device module. This
process should be transparent for the PCI device driver so I think this is
correct by '/proc/iomem'.
You can refer the following example on one PPC target.
Boot without enabling the given PCI device, e1000e.
------
c00000000-c1fffffff : /pcie@ffe200000
c00000000-c1fffffff : PCI Bus 0000:01
c00000000-c0001ffff : 0000:01:00.0
c00020000-c0003ffff : 0000:01:00.0
Boot with enable e1000e PCI device.
------
c00000000-c1fffffff : /pcie@ffe200000
c00000000-c1fffffff : PCI Bus 0000:01
c00000000-c0001ffff : 0000:01:00.0
c00000000-c0001ffff : e1000e
c00020000-c0003ffff : 0000:01:00.0
c00020000-c0003ffff : e1000e
So I think you can build your driver into the kernel to try again, or maybe you
should check your driver codes. Especially I want to know how/where you get
these two range, a8000000-a803ffff and a8040000-a807ffff. You wired them firstly
on the driver or allocated by the kernel?
Best Regards
Tiejun
> kernel bug as I also tried my device on i386 machine(opensuse, linux 2.6.35
> i.e the same kernel version on powerpc board) and there everything works
> fine. I don't know where to start to fix it. Please suggest.
>
> Output of lspci
>
> scooby:~ # lspci
> 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
> Controller (rev 10)
> 00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express
> Root Port (rev 10)
> 00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
> Integrated Graphics Controller (rev 10)
> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
> Audio Controller (rev 01)
> 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
> 1 (rev 01)
> 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
> 2 (rev 01)
> 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
> 3 (rev 01)
> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
> Controller #1 (rev 01)
> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
> Controller #2 (rev 01)
> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
> Controller #3 (rev 01)
> 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
> Controller #4 (rev 01)
> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
> Controller (rev 01)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
> 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
> Bridge (rev 01)
> 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
> (rev 01)
> 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA
> IDE Controller (rev 01)
> 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev
> 01)
> 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B
> PCI Express Gigabit Ethernet controller (rev 01)
> 04:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
> Device e250 ----------> My device
> 05:06.0 Serial controller: Device 4348:3253 (rev 10)
>
> Contents of /proc/iomem on i386 machine
>
> cat /proc/iomem
> .
> .
> .
> fe900000-fe9fffff : PCI Bus 0000:04
> fe900000-fe93ffff : 0000:04:00.0 ------------->My device
> fe940000-fe97ffff : 0000:04:00.0 ------------->My device
> fea00000-feafffff : PCI Bus 0000:03
> fea00000-fea1ffff : 0000:03:00.0
> fea20000-fea20fff : 0000:03:00.0
> fea20000-fea20fff : r8169
> .
> .
> .
>
> Regards,
>
> Ravi
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] drivers/net/fs_enet/fs_enet-main.c: Add of_node_put to avoid memory leak
From: David Miller @ 2010-09-07 1:29 UTC (permalink / raw)
To: julia
Cc: netdev, devicetree-discuss, kernel-janitors, linux-kernel,
vbordug, linuxppc-dev
In-Reply-To: <1283595164-29146-1-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Sat, 4 Sep 2010 12:12:43 +0200
> In this case, a device_node structure is stored in another structure that
> is then freed without first decrementing the reference count of the
> device_node structure.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
* Re: [v2 PATCH] ucc_geth: fix ethtool set ring param bug
From: David Miller @ 2010-09-06 20:22 UTC (permalink / raw)
To: liang.li; +Cc: netdev, avorontsov, linuxppc-dev
In-Reply-To: <1283443364-2136-1-git-send-email-liang.li@windriver.com>
From: Liang Li <liang.li@windriver.com>
Date: Fri, 3 Sep 2010 00:02:44 +0800
> + printk(KERN_INFO "Stopping interface %s.\n", netdev->name);
...
> + printk(KERN_INFO "Reactivating interface %s.\n", netdev->name);
Please get rid of these log messages.
Also, this isn't the way to implement this.
Abstract out the one and only operation that can fail when you change
the ring size, which is the memory allocations, into seperate code.
Allocate the newly sized rings first, and if that fails abort the
ring size change attempt. This will let the device continue to
function and operate properly even if the ring resizing fails.
Then stop the RX/TX DMA, switch the ring pointers and configuration
inside of the device, restart RX/TX DMA, and finally free up the
old ring memory.
I know why you want to use *_close() and *_open(), it requires less
coding and work on your part. But this is why the error handling
behavior is difficult and what happens on failure (device goes down
and becomes inoperative) is extremely unpleasant for the user.
The user should be able to make this kind of change over an SSH
shell that uses the interface itself, and not expect to lose
connectivity completely just because the ring allocation fails.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/8] drivers/i2c/busses/i2c-pasemi.c: Fix unsigned return type
From: Olof Johansson @ 2010-09-06 16:30 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, linux-kernel, linux-i2c,
Ben Dooks (embedded platforms), Jean Delvare (PC drivers, core),
linuxppc-dev
In-Reply-To: <1283713226-8429-5-git-send-email-julia@diku.dk>
On Sun, Sep 05, 2010 at 09:00:22PM +0200, Julia Lawall wrote:
> The function has an unsigned return type, but returns a negative constant
> to indicate an error condition. The result of calling the function is
> always stored in a variable of type (signed) int, and thus unsigned can be
> dropped from the return type.
>
> A sematic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @exists@
> identifier f;
> constant C;
> @@
>
> unsigned f(...)
> { <+...
> * return -C;
> ...+> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Olof Johansson @ 2010-09-06 15:45 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <01bb9090932e6984c887273078fd586f@mail.gmail.com>
On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
> >
> > Then the device tree identifier, and the cpu setup functions, etc,
> > should indicate
> > 464, not APM821xx.
> This is new SoC based on 464 cpu core. All the previous SoC device tree
> CPU portion uses SoC name.
Hm, you're right. Confusing.
Still, the cpu setup functions would make more sense to have the core
name in, not the SoC name. Especially since multiple SoC families might
use the same core, etc.
> > Also, why add yet another defconfig? Isn't the eval board similar to
> > many others and can be supported with just a tweak of some existing
> > common defconfig instead?
> >
> Every new board needs new defconfig. And it is not same as others. It has
> Different features from other.
Actually, it doesn't. Linus has had a strong pushback to the ARM community
because of this mentality. arch/powerpc already has 100 defconfigs.
The use of devicetrees means that only the actual devices on your board,
will be configured, so it doesn't do any damage to compile in more drivers
than you happen to have. Thus generating a defconfig that is a superset
of some of your more common boards, or for example one per family of boards.
One of the arguments for having custom defconfigs per board is that customers that
base designs off of your eval board needs them. But they will make other changes
to the config to add drivers for whatever additional devices they have anyway.
-Olof
^ permalink raw reply
* RE: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Tirumala Marri @ 2010-09-06 14:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20100906141513.GA15942@hansolo.jdub.homelinux.org>
> >Every new board needs new defconfig. And it is not same as others. It
> has
> >Different features from other.
>
> You make it sound as if that is a hard and fixed rule. It's not. Not
> all
> boards need a defconfig. Also, there was recent work to trim the
> defconfigs
> that exist today down so they are not so large. I suggest you do the
> same
> if you want the defconfig included.
[Marri] Mr Josh sure let me take a look at it
-Marri
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: André Schwarz @ 2010-09-06 14:37 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <4C84D334.6060008@matrix-vision.de>
Anton,
looks like I should have looked at include/spi/spi.h earlier :
/*
* INTERFACES between SPI master-side drivers and SPI infrastructure.
* (There's no SPI slave support for Linux yet...)
*/
...this is what I've been looking for.
thanks for your help and sorry for the noise.
Regards,
André
On Mon, 2010-09-06 at 13:40 +0200, Andre Schwarz wrote:
> Anton,
>
> > we're about to get new MPC8377 based hardware with various peripherals.
> >> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> >> how to define a proper dts...
> >>
> >> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
> >> device - but how can I represent the created SPI bus ?
> > Um.. the same as the other SPI buses? I.e.
> >
> > i2c-controller { /* SOC I2C controller */
> > spi-controller { /* The I2C-to-SPI bridge */
> > spi-device@0 {
> > };
> > spi-device@1 {
> > };
> > };
> > };
> >
> ok , thanks - looks straight forward.
> Is this any more than plain definition, i.e. will this trigger any I2C
> or SPI device registration/linking ?
> >> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> >> I2C slave or an SPI host driver ?
> > It should be an I2C driver that registers an SPI master (i.e.
> > calls spi_alloc_master() and spi_register_master()).
> hmm - ok. Will have to do it manually then ...
>
> I still wonder how to make the driver arch-generic *and* of-capable.
> Do we need a generic I2C slave driver that can be probed along with an
> "of glue driver" or should the of-binding be part of a single device
> driver ?
>
> Sorry for the dumb questions - looks like I expected a little too much
> functionality already existing.
>
>
> Regards,
> André
>
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
^ permalink raw reply
* [PATCH 04/14] arch/{s390,powerpc}: Removing undead ifdef __KERNEL__
From: Christian Dietrich @ 2010-09-06 14:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Alexander Graf, K.Prasad,
Dave Kleikamp, Martin Schwidefsky, Heiko Carstens, linux390,
linuxppc-dev, linux-kernel, linux-s390
Cc: vamos-dev
In-Reply-To: <cover.1283782698.git.qy03fugy@stud.informatik.uni-erlangen.de>
The __KERNEL__ ifdef isn't necessary at this point, because it is
checked in an outer ifdef level already and has no effect here.
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
---
arch/powerpc/include/asm/processor.h | 2 --
arch/powerpc/include/asm/vdso_datapage.h | 2 --
arch/s390/include/asm/processor.h | 4 ----
3 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 19c05b0..3defd7a 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -122,7 +122,6 @@ extern struct task_struct *last_task_used_spe;
TASK_UNMAPPED_BASE_USER32 : TASK_UNMAPPED_BASE_USER64 )
#endif
-#ifdef __KERNEL__
#ifdef __powerpc64__
#define STACK_TOP_USER64 TASK_SIZE_USER64
@@ -139,7 +138,6 @@ extern struct task_struct *last_task_used_spe;
#define STACK_TOP_MAX STACK_TOP
#endif /* __powerpc64__ */
-#endif /* __KERNEL__ */
typedef struct {
unsigned long seg;
diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h
index 08679c5..25e3922 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -116,9 +116,7 @@ struct vdso_data {
#endif /* CONFIG_PPC64 */
-#ifdef __KERNEL__
extern struct vdso_data *vdso_data;
-#endif
#endif /* __ASSEMBLY__ */
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 73e2598..0e2a436 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -52,8 +52,6 @@ extern int get_cpu_capability(unsigned int *);
#endif /* __s390x__ */
-#ifdef __KERNEL__
-
#ifndef __s390x__
#define STACK_TOP (1UL << 31)
#define STACK_TOP_MAX (1UL << 31)
@@ -63,8 +61,6 @@ extern int get_cpu_capability(unsigned int *);
#endif /* __s390x__ */
-#endif
-
#define HAVE_ARCH_PICK_MMAP_LAYOUT
typedef struct {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 00/14] Removing dead code
From: Christian Dietrich @ 2010-09-06 14:35 UTC (permalink / raw)
To: Lennert Buytenhek, Russell King, Yoshinori Sato, Kyle McMartin,
Helge Deller, James E.J. Bottomley, Akinobu Mita,
Benjamin Herrenschmidt, Paul Mackerras, Alexander Graf, K.Prasad,
Dave Kleikamp, Martin Schwidefsky, Heiko Carstens, linux390,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Borislav Petkov, David S. Miller, Roland Dreier, Alexey Dobriyan,
Joe Perches, Juergen E. Fischer, Tejun Heo, Krzysztof Helt,
Andrew Morton, Geert Uytterhoeven, Petr Vandrovec, Jean Delvare,
Arnaldo Carvalho de Melo, Eric W. Biederman, Ben Hutchings,
Cyrill Gorcunov, Peter Zijlstra, Mike Galbraith, Dipankar Sarma,
Paul E. McKenney, Josh Triplett, Lai Jiangshan, linux-arm-kernel,
linux-kernel, linux-parisc, linuxppc-dev, linux-s390, netdev,
linux-scsi, linux-fbdev
Cc: vamos-dev
Hi all!
As part of the VAMOS[0] research project at the University of Erlangen
we are looking at multiple integrity errors in linux' configuration
system.
I've been running a check on the whole sourcetree for
code block which are undead. This means they can't be deselected and
are always in the kernel if the enviroment of the block is
selected. They have often the form of
#ifdef ABC
....
#ifdef ABC
fooooo
#endif
#endif
Here the ifdefs of the inner block can be removed without any harm. At
this point we just checked the source code (for the undead), but we
want to do a crosscheck with the Kconfig for undead code blocks in the
future.
I build the patches against a vanilla kernel (v2.6.36-rc3) in order to
try if the kernel compiles with this patches.
Please keep me informed of this patch getting confirmed / merged so we
can keep track of it.
Regards
Christian Dietrich
[0] http://vamos1.informatik.uni-erlangen.de/
Christian Dietrich (14):
arch/arm: Removing undead ifdef __ASSEMBLY__
arch/h8300: Removing dead ifdef __H8300_TLB_H__
arch/parisc: Removing undead ifdef CONFIG_PA20
arch/{s390,powerpc}: Removing undead ifdef __KERNEL__
arch/x86: Removing undead ifdef ACPI/X86_IO_ACPI
drivers/net: Removing undead ifdef CHELSIO_T1_1G
drivers/scsi: Removing undead ifdef __ISAPNP__
drivers/scsi: Removing undead ifdef CONFIG_PCI
drivers/scsi: Removing undead ifdef REAL_DMA
drivers/video: Removing undead ifdef ATAFB_FALCON
drivers/video: Removing undead ifdef CONFIG_FB_MATROX_G
include/linux: Removing undead ifdef __KERNEL__
kernel/: Removing undead ifdef CONFIG_SMP
kernel/: Removing undead ifdef CONFIG_DEBUG_LOCK_ALLOC
arch/arm/mach-ixp23xx/include/mach/platform.h | 3 ---
arch/h8300/include/asm/tlb.h | 13 -------------
arch/parisc/kernel/unaligned.c | 3 ---
arch/powerpc/include/asm/processor.h | 2 --
arch/powerpc/include/asm/vdso_datapage.h | 2 --
arch/s390/include/asm/processor.h | 4 ----
arch/x86/kernel/early-quirks.c | 2 --
drivers/net/chelsio/subr.c | 2 --
drivers/scsi/aha152x.c | 2 --
drivers/scsi/aic7xxx_old.c | 2 --
drivers/scsi/atari_NCR5380.c | 6 ------
drivers/video/atafb.c | 2 --
drivers/video/matrox/matroxfb_DAC1064.c | 5 +----
include/linux/socket.h | 6 +-----
kernel/sched.c | 4 +---
kernel/srcu.c | 2 --
16 files changed, 3 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-06 14:15 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <01bb9090932e6984c887273078fd586f@mail.gmail.com>
On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
>>
>> Then the device tree identifier, and the cpu setup functions, etc,
>> should indicate
>> 464, not APM821xx.
>This is new SoC based on 464 cpu core. All the previous SoC device tree
>CPU portion uses SoC name.
>
>>
>> Also, why add yet another defconfig? Isn't the eval board similar to
>> many others and can be supported with just a tweak of some existing
>> common defconfig instead?
>>
>Every new board needs new defconfig. And it is not same as others. It has
>Different features from other.
You make it sound as if that is a hard and fixed rule. It's not. Not all
boards need a defconfig. Also, there was recent work to trim the defconfigs
that exist today down so they are not so large. I suggest you do the same
if you want the defconfig included.
josh
^ permalink raw reply
* pci_request_regions() failure
From: Ravi Gupta @ 2010-09-06 12:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]
Hi,
I am facing a problem while requesting pci resource. I have some data that I
am hopeful will help address the issue.
I am currently running on a MPC837xERDB board(powerpc) with a 2.6.35 kernel.
The problem is that whenever I insert the card (LatticeECP2M PCI Express
Development Kit<http://www.latticesemi.com/products/developmenthardware/developmentkits/pciexpressdevkitecp2m/index.cfm>)
in pci-express slot 0 and try to load my driver module, I get a
pci_request_regions() failure(error -EBUSY). The interesting thing is the
region that it fails for. According to /proc/iomem, slot0 has
a8000000-b7ffffff as its memory ranges. However, the memory region requested
by my device is a8000000-a803ffff and a8040000-a807ffff which falls in the
slot0 range. But after boot up when I look at /proc/iomem, there is a
already allocated resource range present there, which overlaps with the
range refined in my device, hence the pci_request_regions() fails.
Output of lspci
0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
21)
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
(rev 21)
0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Unknown device e250 ---> My device
Contents of /pro/iomem file
# cat /proc/iomem
80000000-8fffffff : /pci@e0008500
90000000-9fffffff : /pci@e0008500
a8000000-b7ffffff : /pcie@e0009000
a8000000-a80fffff : PCI Bus 0001:02 ---> colprit range
c8000000-d7ffffff : /pcie@e000a000
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0023000-e0023fff : usb
Now my doubt is, who is allocating this range and why? It seem to me a
kernel bug as I also tried my device on i386 machine(opensuse, linux 2.6.35
i.e the same kernel version on powerpc board) and there everything works
fine. I don't know where to start to fix it. Please suggest.
Output of lspci
scooby:~ # lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller (rev 10)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express
Root Port (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 10)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
3 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA
IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev
01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B
PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Device e250 ----------> My device
05:06.0 Serial controller: Device 4348:3253 (rev 10)
Contents of /proc/iomem on i386 machine
cat /proc/iomem
.
.
.
fe900000-fe9fffff : PCI Bus 0000:04
fe900000-fe93ffff : 0000:04:00.0 ------------->My device
fe940000-fe97ffff : 0000:04:00.0 ------------->My device
fea00000-feafffff : PCI Bus 0000:03
fea00000-fea1ffff : 0000:03:00.0
fea20000-fea20fff : 0000:03:00.0
fea20000-fea20fff : r8169
.
.
.
Regards,
Ravi
[-- Attachment #2: Type: text/html, Size: 4529 bytes --]
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: Andre Schwarz @ 2010-09-06 11:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <20100903120858.GA19380@oksana.dev.rtsoft.ru>
Anton,
> we're about to get new MPC8377 based hardware with various peripherals.
>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>> how to define a proper dts...
>>
>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>> device - but how can I represent the created SPI bus ?
> Um.. the same as the other SPI buses? I.e.
>
> i2c-controller { /* SOC I2C controller */
> spi-controller { /* The I2C-to-SPI bridge */
> spi-device@0 {
> };
> spi-device@1 {
> };
> };
> };
>
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>> I2C slave or an SPI host driver ?
> It should be an I2C driver that registers an SPI master (i.e.
> calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
I still wonder how to make the driver arch-generic *and* of-capable.
Do we need a generic I2C slave driver that can be probed along with an
"of glue driver" or should the of-binding be part of a single device
driver ?
Sorry for the dumb questions - looks like I expected a little too much
functionality already existing.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
^ 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