* [PATCH 1/2] pseries: phyp dump: Disable phyp-dump through boot-var.
From: Manish Ahuja @ 2008-03-22 0:38 UTC (permalink / raw)
To: linuxppc-dev, kexec, paulus; +Cc: mahuja, smaneesh, linasvepstas, ssant
The goal of these 2 patches is to ensure that there is only one dumping
mechanism enabled at any given time. These patches depend upon phyp-dump
patches posted earlier.
Patch 1:
Addition of boot-variable "phyp_dump", which takes values [0/1] for disabling/
enabling phyp_dump at boot time. Kdump can use this on cmdline (phyp_dump=0)
to disable phyp-dump during boot when enabling itself. This will ensure only
one dumping mechanism is active at any given time.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
---
arch/powerpc/kernel/prom.c | 5 +++++
arch/powerpc/platforms/pseries/phyp_dump.c | 18 ++++++++++++++++++
include/asm-powerpc/phyp_dump.h | 1 +
3 files changed, 24 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22 00:42:02.000000000 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22 01:07:43.000000000 -0500
@@ -460,3 +460,21 @@ int __init early_init_dt_scan_phyp_dump(
*((unsigned long *)&sizes[4]);
return 1;
}
+
+/* Look for phyp_dump= cmdline option */
+static int __init early_phyp_dump_enabled(char *p)
+{
+ phyp_dump_info->phyp_dump_at_boot = 1;
+
+ if (!p)
+ return 0;
+
+ if (strncmp(p, "1", 1) == 0)
+ phyp_dump_info->phyp_dump_at_boot = 1;
+ else if (strncmp(p, "0", 1) == 0)
+ phyp_dump_info->phyp_dump_at_boot = 0;
+
+ return 0;
+}
+early_param("phyp_dump", early_phyp_dump_enabled);
+
Index: 2.6.25-rc1/include/asm-powerpc/phyp_dump.h
===================================================================
--- 2.6.25-rc1.orig/include/asm-powerpc/phyp_dump.h 2008-03-22 00:42:02.000000000 -0500
+++ 2.6.25-rc1/include/asm-powerpc/phyp_dump.h 2008-03-22 00:42:08.000000000 -0500
@@ -25,6 +25,7 @@ struct phyp_dump {
unsigned long init_reserve_start;
unsigned long init_reserve_size;
/* Check status during boot if dump supported, active & present*/
+ unsigned long phyp_dump_at_boot;
unsigned long phyp_dump_configured;
unsigned long phyp_dump_is_active;
/* store cpu & hpte size */
Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c 2008-03-22 00:42:02.000000000 -0500
+++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-03-22 00:42:54.000000000 -0500
@@ -1059,6 +1059,11 @@ static void __init phyp_dump_reserve_mem
return;
}
+ if (!phyp_dump_info->phyp_dump_at_boot) {
+ printk(KERN_INFO "Phyp-dump disabled at boot time\n");
+ return;
+ }
+
if (phyp_dump_info->phyp_dump_is_active) {
/* Reserve *everything* above RMR.Area freed by userland tools*/
base = PHYP_DUMP_RMR_END;
^ permalink raw reply
* [PATCH 2/2] pseries: phyp dump: inform kdump, phyp-dump is loaded.
From: Manish Ahuja @ 2008-03-22 0:40 UTC (permalink / raw)
To: linuxppc-dev, kexec, paulus; +Cc: mahuja, smaneesh, linasvepstas, ssant
Patch 2:
Addition of /sys/kernel/phyp_dump_active so that kdump init scripts may
look for it and take appropriate action if this file is found. This
file is only loaded when phyp_dump has been registered.
Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
---
arch/powerpc/platforms/pseries/phyp_dump.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
===================================================================
--- 2.6.25-rc1.orig/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22 01:07:43.000000000 -0500
+++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-03-22 01:08:56.000000000 -0500
@@ -182,6 +182,18 @@ static void print_dump_header(const stru
#endif
}
+static ssize_t show_phyp_dump_active(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+
+ /* create filesystem entry so kdump is phyp-dump aware */
+ return sprintf(buf, "%lx\n", phyp_dump_info->phyp_dump_at_boot);
+}
+
+static struct kobj_attribute pdl = __ATTR(phyp_dump_active, 0600,
+ show_phyp_dump_active,
+ NULL);
+
static void register_dump_area(struct phyp_dump_header *ph, unsigned long addr)
{
int rc;
@@ -204,7 +216,13 @@ static void register_dump_area(struct ph
printk(KERN_ERR "phyp-dump: unexpected error (%d) on "
"register\n", rc);
print_dump_header(ph);
+ return;
}
+
+ rc = sysfs_create_file(kernel_kobj, &pdl.attr);
+ if (rc)
+ printk(KERN_ERR "phyp-dump: unable to create sysfs"
+ " file (%d)\n", rc);
}
static
^ permalink raw reply
* Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
From: Anatolij Gustschin @ 2008-03-22 0:41 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080321235633.GB345@frozen.semihalf.com>
Bartlomiej Sieka wrote:
> The bulk of this patch is taken from
> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
> other updates, in particluar one posted by Anatolij Gustschin, which fixes
> an Oops during boot.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
> ---
> Anatolij, would you like to add your S-O-B?
Signed-off-by: Anatolij Gustschin <agust@denx.de>
>
> diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
> index 30737ea..8b2e8e4 100644
> --- a/arch/powerpc/boot/dts/cm5200.dts
> +++ b/arch/powerpc/boot/dts/cm5200.dts
> @@ -159,6 +159,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -212,13 +213,31 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "fsl,mpc5200b-mdio";
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> @@ -231,4 +250,22 @@
> reg = <8000 4000>;
> };
> };
> +
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 fc000000 2000000>;
> +
> + // 16-bit flash device at LocalPlus Bus CS0
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 2000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> + };
> };
> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
> index 76951ab..9ca81ff 100644
> --- a/arch/powerpc/boot/dts/motionpro.dts
> +++ b/arch/powerpc/boot/dts/motionpro.dts
> @@ -127,6 +127,13 @@
> interrupt-parent = <&mpc5200_pic>;
> };
>
> + mscan@900 {
> + compatible = "mpc5200b-mscan\0mpc5200-mscan";
> + interrupts = <2 11 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + reg = <900 80>;
> + };
> +
> mscan@980 {
> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
> interrupts = <2 12 0>;
> @@ -148,7 +155,6 @@
> interrupt-parent = <&mpc5200_pic>;
> };
>
> -
> spi@f00 {
> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> reg = <f00 20>;
> @@ -164,6 +170,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -209,10 +216,26 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "fsl,mpc5200b-mdio";
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <2>;
> + };
> };
>
> ata@3a00 {
> @@ -223,11 +246,19 @@
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> +
> + rtc@68 {
> + device_type = "rtc";
> + compatible = "dallas,ds1339";
> + reg = <68>;
> + };
> };
>
> sram@8000 {
> @@ -240,7 +271,8 @@
> compatible = "fsl,lpb";
> #address-cells = <2>;
> #size-cells = <1>;
> - ranges = <1 0 50000000 00010000
> + ranges = <0 0 ff000000 01000000
> + 1 0 50000000 00010000
> 2 0 50010000 00010000
> 3 0 50020000 00010000>;
>
> @@ -271,31 +303,15 @@
> compatible = "promess,pro_module_dio";
> reg = <3 800 2>;
> };
> - };
>
> - pci@f0000d00 {
> - #interrupt-cells = <1>;
> - #size-cells = <2>;
> - #address-cells = <3>;
> - device_type = "pci";
> - compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
> - reg = <f0000d00 100>;
> - interrupt-map-mask = <f800 0 0 7>;
> - interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> - c000 0 0 2 &mpc5200_pic 1 1 3
> - c000 0 0 3 &mpc5200_pic 1 2 3
> - c000 0 0 4 &mpc5200_pic 1 3 3
> -
> - c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> - c800 0 0 2 &mpc5200_pic 1 2 3
> - c800 0 0 3 &mpc5200_pic 1 3 3
> - c800 0 0 4 &mpc5200_pic 0 0 3>;
> - clock-frequency = <0>; // From boot loader
> - interrupts = <2 8 0 2 9 0 2 a 0>;
> - interrupt-parent = <&mpc5200_pic>;
> - bus-range = <0 0>;
> - ranges = <42000000 0 80000000 80000000 0 20000000
> - 02000000 0 a0000000 a0000000 0 10000000
> - 01000000 0 00000000 b0000000 0 01000000>;
> + // 16-bit flash device at LocalPlus Bus CS0
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 01000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> };
> };
> diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
> index c86464f..bbac984 100644
> --- a/arch/powerpc/boot/dts/tqm5200.dts
> +++ b/arch/powerpc/boot/dts/tqm5200.dts
> @@ -83,6 +83,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -127,10 +128,26 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
> + compatible = "fsl,mpc5200b-mdio";
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> ata@3a00 {
> @@ -141,11 +158,19 @@
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> +
> + rtc@68 {
> + device_type = "rtc";
> + compatible = "dallas,ds1307";
> + reg = <68>;
> + };
> };
>
> sram@8000 {
> @@ -154,6 +179,23 @@
> };
> };
>
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 fc000000 02000000>;
> +
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 02000000>;
> + bank-width = <4>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> + };
> +
> pci@f0000d00 {
> #interrupt-cells = <1>;
> #size-cells = <2>;
>
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts
From: Josh Boyer @ 2008-03-22 1:14 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <9638a186ce2754343d4d349e55c15e2a@kernel.crashing.org>
On Fri, 21 Mar 2008 18:28:38 +0100
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >>> As for the DTS, maybe a "compatible" property in the CPU might make
> >>> some
> >>> sense with a content along the lines of "ppc440x6" or whatever rev of
> >>> the 440 core it is.
> >>>
> >>> What do you think ?
> >>
> >> Good idea. I'll try to come up with a list for all existing 4xx SoC's
> >> and it's
> >> core versions.
> >
> > I don't really care either way, but what does that buy us? Merely
> > documentation?
>
> Obviously, as long as the kernel doesn't use the device tree for probing
> the CPUs available, additions to the device tree here don't affect the
> kernel at all ;-P
Yes, of course. I meant were there other plans for it. Ben and I had
a brief discussion of some of the possible uses and it seems pretty
sane.
josh
^ permalink raw reply
* Re: dcr stuff.
From: Josh Boyer @ 2008-03-22 1:17 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080321190524.4F3491CE0087@mail160-dub.bigfish.com>
On Fri, 21 Mar 2008 12:05:40 -0700
"Stephen Neuendorffer" <stephen.neuendorffer@xilinx.com> wrote:
>
> Is anybody working on the dcr infrastructure?
>
> In particular, there seems to be inconsistency between what the kernel
> does and what ePAPR thinks it should. The code in the kernel selects
> mmio or native access based on a Kconfig parameter and uses some device
> tree parameters to correctly configure the mmio access, whereas ePAPR
> doesn't seem to document all the device tree attributes (in particular,
> dcr-mmio-stride and dcr-mmio-range) and provides a dynamic binding for
> dcr-access-method...
Code can be fixed if needs be. Keep in mind that ePAPR isn't publicly
available yet.
> Is there a plan here? (In particular, in FPGA designs, its possible to
> have crazy things like multiple independent dcr busses, some using
> native access, some using mmio. Or even if there is one bus, many of
> the existing non-linux drivers we have assume native or mmio access.
> I'd like to clean this up, obviously.. :)
Clean it up how? I'd hate to add bloat to boards with native DCR
access just because a few require oddities.
If it ain't broke, don't fix it.
josh
^ permalink raw reply
* Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
From: Grant Likely @ 2008-03-22 3:14 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev, Anatolij Gustschin, Paul Mackerras
In-Reply-To: <20080321235633.GB345@frozen.semihalf.com>
On Fri, Mar 21, 2008 at 5:56 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
> The bulk of this patch is taken from
> http://patchwork.ozlabs.org/linuxppc/patch?q=Balakowicz&id=16197, with few
> other updates, in particluar one posted by Anatolij Gustschin, which fixes
> an Oops during boot.
>
> Signed-off-by: Marian Balakowicz <m8@semihalf.com>
Comments below.
> ---
> Anatolij, would you like to add your S-O-B?
>
> diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
> index 30737ea..8b2e8e4 100644
> --- a/arch/powerpc/boot/dts/cm5200.dts
> +++ b/arch/powerpc/boot/dts/cm5200.dts
> @@ -159,6 +159,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -212,13 +213,31 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
Drop device type; it's unneeded and unused.
> + compatible = "fsl,mpc5200b-mdio";
Should technically be "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio"; (I
know the lite5200b.dts doesn't have this either, but I'll write a
patch right now to fix it so that it's correct in .25)
I regret introducing "fsl,mpc5200b-*" at all since the 5200b is really
just a bug fix of the 5200 except for a very few incompatible device
changes. Just the nodes for specific incompatible devices need to
claim 5200b-<blah> in their compatible string (without claiming
5200-<blah>). It seems to me that specific silicon revision
differences by conventional is too fine grained for the compatible
field and if really needed can be discovered from the SVR.
I may even drop it in the .26 series. All device trees in the wild
claim compatibility with both so it won't break any existing boards.
heh; I guess that's just a long winded way to say make sure
fsl,mpc5200-mdio is in there so it remains possible to drop
mpc5200b-mdio in the future.
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
inconsistent indentation?
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> @@ -231,4 +250,22 @@
> reg = <8000 4000>;
> };
> };
> +
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 fc000000 2000000>;
> +
> + // 16-bit flash device at LocalPlus Bus CS0
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 2000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> + };
> };
> diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
> index 76951ab..9ca81ff 100644
> --- a/arch/powerpc/boot/dts/motionpro.dts
> +++ b/arch/powerpc/boot/dts/motionpro.dts
> @@ -127,6 +127,13 @@
> interrupt-parent = <&mpc5200_pic>;
> };
>
> + mscan@900 {
> + compatible = "mpc5200b-mscan\0mpc5200-mscan";
"mpc5200b-mscan", "mpc5200-mscan"; The '\0' is depreciated.
> + interrupts = <2 11 0>;
> + interrupt-parent = <&mpc5200_pic>;
> + reg = <900 80>;
> + };
> +
> mscan@980 {
> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
> interrupts = <2 12 0>;
> @@ -148,7 +155,6 @@
> interrupt-parent = <&mpc5200_pic>;
> };
>
> -
> spi@f00 {
> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> reg = <f00 20>;
> @@ -164,6 +170,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -209,10 +216,26 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
Drop device type
> + compatible = "fsl,mpc5200b-mdio";
Same here; should include fsl,mpc5200-mdio
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <2>;
> + };
> };
>
> ata@3a00 {
> @@ -223,11 +246,19 @@
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> +
> + rtc@68 {
> + device_type = "rtc";
> + compatible = "dallas,ds1339";
> + reg = <68>;
> + };
> };
>
> sram@8000 {
> @@ -240,7 +271,8 @@
> compatible = "fsl,lpb";
> #address-cells = <2>;
> #size-cells = <1>;
> - ranges = <1 0 50000000 00010000
> + ranges = <0 0 ff000000 01000000
> + 1 0 50000000 00010000
> 2 0 50010000 00010000
> 3 0 50020000 00010000>;
>
> @@ -271,31 +303,15 @@
> compatible = "promess,pro_module_dio";
> reg = <3 800 2>;
> };
> - };
>
> - pci@f0000d00 {
> - #interrupt-cells = <1>;
> - #size-cells = <2>;
> - #address-cells = <3>;
> - device_type = "pci";
> - compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
> - reg = <f0000d00 100>;
> - interrupt-map-mask = <f800 0 0 7>;
> - interrupt-map = <c000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> - c000 0 0 2 &mpc5200_pic 1 1 3
> - c000 0 0 3 &mpc5200_pic 1 2 3
> - c000 0 0 4 &mpc5200_pic 1 3 3
> -
> - c800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> - c800 0 0 2 &mpc5200_pic 1 2 3
> - c800 0 0 3 &mpc5200_pic 1 3 3
> - c800 0 0 4 &mpc5200_pic 0 0 3>;
> - clock-frequency = <0>; // From boot loader
> - interrupts = <2 8 0 2 9 0 2 a 0>;
> - interrupt-parent = <&mpc5200_pic>;
> - bus-range = <0 0>;
> - ranges = <42000000 0 80000000 80000000 0 20000000
> - 02000000 0 a0000000 a0000000 0 10000000
> - 01000000 0 00000000 b0000000 0 01000000>;
> + // 16-bit flash device at LocalPlus Bus CS0
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 01000000>;
> + bank-width = <2>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> };
> };
> diff --git a/arch/powerpc/boot/dts/tqm5200.dts b/arch/powerpc/boot/dts/tqm5200.dts
> index c86464f..bbac984 100644
> --- a/arch/powerpc/boot/dts/tqm5200.dts
> +++ b/arch/powerpc/boot/dts/tqm5200.dts
> @@ -83,6 +83,7 @@
> };
>
> dma-controller@1200 {
> + device_type = "dma-controller";
> compatible = "fsl,mpc5200-bestcomm";
> reg = <1200 80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> @@ -127,10 +128,26 @@
> ethernet@3000 {
> device_type = "network";
> compatible = "fsl,mpc5200-fec";
> - reg = <3000 800>;
> + reg = <3000 400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> + phy-handle = <&phy0>;
> + };
> +
> + mdio@3000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
ditto
> + compatible = "fsl,mpc5200b-mdio";
ditto
> + reg = <3000 400>; // fec range, since we need to setup fec interrupts
> + interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
> + interrupt-parent = <&mpc5200_pic>;
> +
> + phy0:ethernet-phy@0 {
> + device_type = "ethernet-phy";
> + reg = <0>;
> + };
> };
>
> ata@3a00 {
> @@ -141,11 +158,19 @@
> };
>
> i2c@3d40 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> compatible = "fsl,mpc5200-i2c","fsl-i2c";
> reg = <3d40 40>;
> interrupts = <2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> +
> + rtc@68 {
> + device_type = "rtc";
> + compatible = "dallas,ds1307";
> + reg = <68>;
> + };
> };
>
> sram@8000 {
> @@ -154,6 +179,23 @@
> };
> };
>
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 fc000000 02000000>;
> +
> + flash@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 02000000>;
> + bank-width = <4>;
> + device-width = <2>;
> + #size-cells = <1>;
> + #address-cells = <1>;
> + };
> + };
> +
> pci@f0000d00 {
> #interrupt-cells = <1>;
> #size-cells = <2>;
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [POWERPC] mpc5200-fec: Fix possible NULL dereference in mdio driver
From: Grant Likely @ 2008-03-22 3:20 UTC (permalink / raw)
To: linux-kernel, paulus, linuxppc-dev
If the reg property is missing from the phy node (unlikely, but possible),
then the kernel will oops with a NULL pointer dereference.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This one is a bugfix that should go in for 2.6.25. Paul, can you please
pick it up?
Thanks,
g.
drivers/net/fec_mpc52xx_phy.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fec_mpc52xx_phy.c b/drivers/net/fec_mpc52xx_phy.c
index 1837584..6a3ac4e 100644
--- a/drivers/net/fec_mpc52xx_phy.c
+++ b/drivers/net/fec_mpc52xx_phy.c
@@ -109,7 +109,8 @@ static int mpc52xx_fec_mdio_probe(struct of_device *of, const struct of_device_i
int irq = irq_of_parse_and_map(child, 0);
if (irq != NO_IRQ) {
const u32 *id = of_get_property(child, "reg", NULL);
- bus->irq[*id] = irq;
+ if (id)
+ bus->irq[*id] = irq;
}
}
--
1.5.4.3
^ permalink raw reply related
* [PATCH] [POWERPC] mpc5200: fix incorrect compatible string for the mdio node
From: Grant Likely @ 2008-03-22 3:25 UTC (permalink / raw)
To: linux-kernel, paulus, linuxppc-dev
The MDIO node in the lite5200b.dts file needs to also claim compatibility
with the older mpc5200 chip.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paul, this one should also go in for .26
arch/powerpc/boot/dts/lite5200b.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/lite5200b.dts
index 30eaeab..001c955 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -270,7 +270,7 @@
mdio@3000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "fsl,mpc5200b-mdio";
+ compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
reg = <0x3000 0x400>; // fec range, since we need to setup fec interrupts
interrupts = <2 5 0>; // these are for "mii command finished", not link changes & co.
interrupt-parent = <&mpc5200_pic>;
--
1.5.4.3
^ permalink raw reply related
* [PATCH] [POWERPC] mpc5200: fix null dereference if bestcomm fails to initialize
From: Grant Likely @ 2008-03-22 3:41 UTC (permalink / raw)
To: linux-kernel, paulus, linuxppc-dev
If the bestcomm initialization fails, calls to the task allocate
function should fail gracefully instead of oopsing with a NULL deref.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Paul, here's another bug fix that I'd like picked up for .25
arch/powerpc/sysdev/bestcomm/bestcomm.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c
index f589999..f9cd04e 100644
--- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
+++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
@@ -52,6 +52,10 @@ bcom_task_alloc(int bd_count, int bd_size, int priv_size)
int i, tasknum = -1;
struct bcom_task *tsk;
+ /* Don't try to do anything is bestcomm init failed */
+ if (!bcom_eng)
+ return NULL;
+
/* Get and reserve a task num */
spin_lock(&bcom_eng->lock);
--
1.5.4.3
^ permalink raw reply related
* Re: [POWERPC] mpc52xx: Amalgamated dts fixes and updates
From: Grant Likely @ 2008-03-22 3:47 UTC (permalink / raw)
To: Bartlomiej Sieka, Grant Likely, linuxppc-dev, Anatolij Gustschin,
Paul Mackerras
In-Reply-To: <20080322001242.GA29812@localhost.localdomain>
On Fri, Mar 21, 2008 at 6:12 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Sat, Mar 22, 2008 at 12:56:35AM +0100, Bartlomiej Sieka wrote:
> > diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
> > index 30737ea..8b2e8e4 100644
> > --- a/arch/powerpc/boot/dts/cm5200.dts
> > +++ b/arch/powerpc/boot/dts/cm5200.dts
> > @@ -159,6 +159,7 @@
> > };
> >
> > dma-controller@1200 {
> > + device_type = "dma-controller";
>
> This is not right. If adding device_type here fixes something, then
> the driver is wrong and should be fixed instead.
I just sent a patch that fixes the driver bug.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 1/2 v2] [POWERPC] Add PPC4xx L2-cache support (440GX)
From: Stefan Roese @ 2008-03-22 10:28 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for the 256k L2 cache found on some IBM/AMCC
4xx PPC's. It introduces a common 4xx SoC file (sysdev/ppc4xx_soc.c)
which currently "only" adds the L2 cache init code. Other common 4xx
stuff can be added later here.
The L2 cache handling code is a copy of Eugene's code in arch/ppc
with small modifications.
Tested on AMCC Taishan 440GX.
Signed-off-by: Stefan Roese <sr@denx.de>
---
Small changes included as suggested by Stephen Rothwell. It also removes
mentioning 460EX/GT, since L2 cache handling on these PPC's is not clear
right now.
arch/powerpc/Kconfig | 3 +
arch/powerpc/platforms/44x/Kconfig | 2 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/ppc4xx_soc.c | 178 ++++++++++++++++++++++++++++++++++++
include/asm-powerpc/dcr-regs.h | 78 ++++++++++++++++
5 files changed, 258 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/ppc4xx_soc.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1189d8d..69d4738 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -490,6 +490,9 @@ config FSL_PCI
bool
select PPC_INDIRECT_PCI
+config 4xx_SOC
+ bool
+
# Yes MCA RS/6000s exist but Linux-PPC does not currently support any
config MCA
bool
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 83155fe..061ba3c 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -120,6 +120,7 @@ config 440GP
config 440GX
bool
+ select 4xx_SOC
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
select IBM_NEW_EMAC_ZMII #test only
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 15f3e85..851a0be 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PPC_INDIRECT_PCI) += indirect_pci.o
obj-$(CONFIG_PPC_I8259) += i8259.o
obj-$(CONFIG_IPIC) += ipic.o
obj-$(CONFIG_4xx) += uic.o
+obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
new file mode 100644
index 0000000..4847555
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -0,0 +1,178 @@
+/*
+ * IBM/AMCC PPC4xx SoC setup code
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * L2 cache routines cloned from arch/ppc/syslib/ibm440gx_common.c which is:
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ * Copyright (c) 2003 - 2006 Zultys Technologies
+ *
+ * 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.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/of_platform.h>
+
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
+
+static u32 dcrbase;
+
+/*
+ * L2-cache
+ */
+
+/* Issue L2C diagnostic command */
+static inline u32 l2c_diag(u32 addr)
+{
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, addr);
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_DIAG);
+ while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
+ ;
+
+ return mfdcr(dcrbase + DCRN_L2C0_DATA);
+}
+
+static irqreturn_t l2c_error_handler(int irq, void *dev)
+{
+ u32 sr = mfdcr(dcrbase + DCRN_L2C0_SR);
+
+ if (sr & L2C_SR_CPE) {
+ /* Read cache trapped address */
+ u32 addr = l2c_diag(0x42000000);
+ printk(KERN_EMERG "L2C: Cache Parity Error, addr[16:26] = 0x%08x\n",
+ addr);
+ }
+ if (sr & L2C_SR_TPE) {
+ /* Read tag trapped address */
+ u32 addr = l2c_diag(0x82000000) >> 16;
+ printk(KERN_EMERG "L2C: Tag Parity Error, addr[16:26] = 0x%08x\n",
+ addr);
+ }
+
+ /* Clear parity errors */
+ if (sr & (L2C_SR_CPE | L2C_SR_TPE)){
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
+ } else {
+ printk(KERN_EMERG "L2C: LRU error\n");
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int __init ppc4xx_l2c_probe(void)
+{
+ struct device_node *np;
+ u32 r;
+ unsigned long flags;
+ int irq;
+ const u32 *dcrreg;
+ u32 dcrbase_isram;
+ int len;
+
+ np = of_find_compatible_node(np, NULL, "ibm,l2-cache");
+ if (!np)
+ return 0;
+
+ /* Map DCRs */
+ dcrreg = of_get_property(np, "dcr-reg", &len);
+ if (!dcrreg || (len != 4 * sizeof(u32))) {
+ printk(KERN_ERR "%s: Can't get DCR register base !",
+ np->full_name);
+ of_node_put(np);
+ return -ENODEV;
+ }
+ dcrbase_isram = dcrreg[0];
+ dcrbase = dcrreg[2];
+
+ /* Get and map irq number from device tree */
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ printk(KERN_ERR "irq_of_parse_and_map failed\n");
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ /* Install error handler */
+ if (request_irq(irq, l2c_error_handler, IRQF_DISABLED, "L2C", 0) < 0) {
+ printk(KERN_ERR "Cannot install L2C error handler"
+ ", cache is not enabled\n");
+ of_node_put(np);
+ return -ENODEV;
+ }
+
+ local_irq_save(flags);
+ asm volatile ("sync" ::: "memory");
+
+ /* Disable SRAM */
+ mtdcr(dcrbase_isram + DCRN_SRAM0_DPC,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_DPC) & ~SRAM_DPC_ENABLE);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB0CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB0CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB1CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB1CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB2CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB2CR) & ~SRAM_SBCR_BU_MASK);
+ mtdcr(dcrbase_isram + DCRN_SRAM0_SB3CR,
+ mfdcr(dcrbase_isram + DCRN_SRAM0_SB3CR) & ~SRAM_SBCR_BU_MASK);
+
+ /* Enable L2_MODE without ICU/DCU */
+ r = mfdcr(dcrbase + DCRN_L2C0_CFG) &
+ ~(L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_SS_MASK);
+ r |= L2C_CFG_L2M | L2C_CFG_SS_256;
+ mtdcr(dcrbase + DCRN_L2C0_CFG, r);
+
+ mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
+
+ /* Hardware Clear Command */
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_HCC);
+ while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
+ ;
+
+ /* Clear Cache Parity and Tag Errors */
+ mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
+
+ /* Enable 64G snoop region starting at 0 */
+ r = mfdcr(dcrbase + DCRN_L2C0_SNP0) &
+ ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
+ r |= L2C_SNP_SSR_32G | L2C_SNP_ESR;
+ mtdcr(dcrbase + DCRN_L2C0_SNP0, r);
+
+ r = mfdcr(dcrbase + DCRN_L2C0_SNP1) &
+ ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
+ r |= 0x80000000 | L2C_SNP_SSR_32G | L2C_SNP_ESR;
+ mtdcr(dcrbase + DCRN_L2C0_SNP1, r);
+
+ asm volatile ("sync" ::: "memory");
+
+ /* Enable ICU/DCU ports */
+ r = mfdcr(dcrbase + DCRN_L2C0_CFG);
+ r &= ~(L2C_CFG_DCW_MASK | L2C_CFG_PMUX_MASK | L2C_CFG_PMIM
+ | L2C_CFG_TPEI | L2C_CFG_CPEI | L2C_CFG_NAM | L2C_CFG_NBRM);
+ r |= L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_TPC | L2C_CFG_CPC | L2C_CFG_FRAN
+ | L2C_CFG_CPIM | L2C_CFG_TPIM | L2C_CFG_LIM | L2C_CFG_SMCM;
+
+ /* Check for 460EX/GT special handling */
+ if (of_device_is_compatible(np, "ibm,l2-cache-460ex"))
+ r |= L2C_CFG_RDBW;
+
+ mtdcr(dcrbase + DCRN_L2C0_CFG, r);
+
+ asm volatile ("sync; isync" ::: "memory");
+ local_irq_restore(flags);
+
+ printk(KERN_INFO "256k L2-cache enabled\n");
+
+ of_node_put(np);
+ return 0;
+}
+arch_initcall(ppc4xx_l2c_probe);
diff --git a/include/asm-powerpc/dcr-regs.h b/include/asm-powerpc/dcr-regs.h
index 9f1fb98..29b0ece 100644
--- a/include/asm-powerpc/dcr-regs.h
+++ b/include/asm-powerpc/dcr-regs.h
@@ -68,4 +68,82 @@
#define SDR0_UART3 0x0123
#define SDR0_CUST0 0x4000
+/*
+ * All those DCR register addresses are offsets from the base address
+ * for the SRAM0 controller (e.g. 0x20 on 440GX). The base address is
+ * excluded here and configured in the device tree.
+ */
+#define DCRN_SRAM0_SB0CR 0x00
+#define DCRN_SRAM0_SB1CR 0x01
+#define DCRN_SRAM0_SB2CR 0x02
+#define DCRN_SRAM0_SB3CR 0x03
+#define SRAM_SBCR_BU_MASK 0x00000180
+#define SRAM_SBCR_BS_64KB 0x00000800
+#define SRAM_SBCR_BU_RO 0x00000080
+#define SRAM_SBCR_BU_RW 0x00000180
+#define DCRN_SRAM0_BEAR 0x04
+#define DCRN_SRAM0_BESR0 0x05
+#define DCRN_SRAM0_BESR1 0x06
+#define DCRN_SRAM0_PMEG 0x07
+#define DCRN_SRAM0_CID 0x08
+#define DCRN_SRAM0_REVID 0x09
+#define DCRN_SRAM0_DPC 0x0a
+#define SRAM_DPC_ENABLE 0x80000000
+
+/*
+ * All those DCR register addresses are offsets from the base address
+ * for the SRAM0 controller (e.g. 0x30 on 440GX). The base address is
+ * excluded here and configured in the device tree.
+ */
+#define DCRN_L2C0_CFG 0x00
+#define L2C_CFG_L2M 0x80000000
+#define L2C_CFG_ICU 0x40000000
+#define L2C_CFG_DCU 0x20000000
+#define L2C_CFG_DCW_MASK 0x1e000000
+#define L2C_CFG_TPC 0x01000000
+#define L2C_CFG_CPC 0x00800000
+#define L2C_CFG_FRAN 0x00200000
+#define L2C_CFG_SS_MASK 0x00180000
+#define L2C_CFG_SS_256 0x00000000
+#define L2C_CFG_CPIM 0x00040000
+#define L2C_CFG_TPIM 0x00020000
+#define L2C_CFG_LIM 0x00010000
+#define L2C_CFG_PMUX_MASK 0x00007000
+#define L2C_CFG_PMUX_SNP 0x00000000
+#define L2C_CFG_PMUX_IF 0x00001000
+#define L2C_CFG_PMUX_DF 0x00002000
+#define L2C_CFG_PMUX_DS 0x00003000
+#define L2C_CFG_PMIM 0x00000800
+#define L2C_CFG_TPEI 0x00000400
+#define L2C_CFG_CPEI 0x00000200
+#define L2C_CFG_NAM 0x00000100
+#define L2C_CFG_SMCM 0x00000080
+#define L2C_CFG_NBRM 0x00000040
+#define L2C_CFG_RDBW 0x00000008 /* only 460EX/GT */
+#define DCRN_L2C0_CMD 0x01
+#define L2C_CMD_CLR 0x80000000
+#define L2C_CMD_DIAG 0x40000000
+#define L2C_CMD_INV 0x20000000
+#define L2C_CMD_CCP 0x10000000
+#define L2C_CMD_CTE 0x08000000
+#define L2C_CMD_STRC 0x04000000
+#define L2C_CMD_STPC 0x02000000
+#define L2C_CMD_RPMC 0x01000000
+#define L2C_CMD_HCC 0x00800000
+#define DCRN_L2C0_ADDR 0x02
+#define DCRN_L2C0_DATA 0x03
+#define DCRN_L2C0_SR 0x04
+#define L2C_SR_CC 0x80000000
+#define L2C_SR_CPE 0x40000000
+#define L2C_SR_TPE 0x20000000
+#define L2C_SR_LRU 0x10000000
+#define L2C_SR_PCS 0x08000000
+#define DCRN_L2C0_REVID 0x05
+#define DCRN_L2C0_SNP0 0x06
+#define DCRN_L2C0_SNP1 0x07
+#define L2C_SNP_BA_MASK 0xffff0000
+#define L2C_SNP_SSR_MASK 0x0000f000
+#define L2C_SNP_SSR_32G 0x0000f000
+#define L2C_SNP_ESR 0x00000800
+
#endif /* __DCR_REGS_H__ */
--
1.5.4.4
^ permalink raw reply related
* [PATCH 2/2 v2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
From: Stefan Roese @ 2008-03-22 10:29 UTC (permalink / raw)
To: linuxppc-dev
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese <sr@denx.de>
---
Unit address removed.
arch/powerpc/boot/dts/taishan.dts | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..d0bff33 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -104,6 +104,16 @@
// FIXME: anything else?
};
+ L2C0: l2c {
+ compatible = "ibm,l2-cache-440gx", "ibm,l2-cache";
+ dcr-reg = <20 8 /* Internal SRAM DCR's */
+ 30 8>; /* L2 cache DCR's */
+ cache-line-size = <20>; /* 32 bytes */
+ cache-size = <40000>; /* L2, 256K */
+ interrupt-parent = <&UIC2>;
+ interrupts = <17 1>;
+ };
+
plb {
compatible = "ibm,plb-440gx", "ibm,plb4";
#address-cells = <2>;
--
1.5.4.4
^ permalink raw reply related
* Re: Oops with TQM5200 on TQM5200
From: Anatolij Gustschin @ 2008-03-22 10:49 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40803201427r2a756fd9v54f88b6e95a20aab@mail.gmail.com>
Grant Likely wrote:
> On Thu, Mar 20, 2008 at 10:17 AM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>> Anatolij Gustschin wrote:
>> > Hello Wolfgang,
>> >
>> > Wolfgang Grandegger wrote:
>> >
>> >> I just tried Linux 2.6.25-rc6 on my TQM5200 module and got the attached
>> >> oops. Are there any known patches fixing the problems?
>> >
>> > try the patch below for tqm5200.dts, rebuild dtb and boot
>> > again. Not sure if it works for Linux 2.6.25-rc6, but for
>> > 2.6.25-rc3 it does.
>>
>> It helps 2.6.25-rc6 too - thanks Anatolij.
>>
>>
>> >
>> > Anatolij
>> > --
>> > diff --git a/arch/powerpc/boot/dts/tqm5200.dts
>> > b/arch/powerpc/boot/dts/tqm5200.dts
>> > index c86464f..7c23bb3 100644
>> > --- a/arch/powerpc/boot/dts/tqm5200.dts
>> > +++ b/arch/powerpc/boot/dts/tqm5200.dts
>> > @@ -83,6 +83,7 @@
>> > };
>> >
>> > dma-controller@1200 {
>> > + device_type = "dma-controller";
>>
>> This actually fixes the Oops.
>
> Hmm, this sounds like a band-aid; the kernel shouldn't oops if this is
> missing from the device tree. Fail, perhaps, but oops is worrisome.
> Would someone like to investigate?
results of some further investigation:
the "bestcomm-core" driver defines its of_match table as follows
static struct of_device_id mpc52xx_bcom_of_match[] = {
{ .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
{ .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
{},
};
so while registering the driver the drivers probe function won't be
called because of_match_node shows unexpected behavior in the case
that device tree node lacks device_type = "dma-controller" definition.
here is the current of_match_node code for quick reference:
drivers/of/base.c:309
const struct of_device_id *of_match_node(const struct of_device_id *matches,
const struct device_node *node)
{
while (matches->name[0] || matches->type[0] || matches->compatible[0]) {
int match = 1;
if (matches->name[0])
match &= node->name
&& !strcmp(matches->name, node->name);
if (matches->type[0])
match &= node->type
&& !strcmp(matches->type, node->type);
if (matches->compatible[0])
match &= of_device_is_compatible(node,
matches->compatible);
if (match)
return matches;
matches++;
}
return NULL;
}
So, the bestcomm-core driver provided the type field, but the
device tree node lacks it. The "if (matches->type[0])" case is true
and "node->type && !strcmp(matches->type, node->type)" evaluates to
zero, so match flag is set to zero. Now there is still a chance that
compatible property will match but even if it is the case, match flag
remains zero:
"match &= of_device_is_compatible(node, matches->compatible)" always
sets match flag to zero if match was zero previously. of_match_node
returns NULL, the bestcomm-core driver probe won't be called and thus
the drivers bcom_engine structure won't be allocated. Referencing this
structure later causes observed Oops.
Checking bcom_eng pointer for NULL before referencing data pointed
by it prevents oopsing, but fec driver still doesn't work (because
of the lost bestcomm match and resulted task allocation failure).
Actually the compatible property exists and should match and so
the fec driver shoud work.
I suggest removing .type = "dma-controller" from the bestcomm driver's
mpc52xx_bcom_of_match table to solve the problem.
What do you think?
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c
index f589999..137d830 100644
--- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
+++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
@@ -484,8 +484,8 @@ mpc52xx_bcom_remove(struct of_device *op)
}
static struct of_device_id mpc52xx_bcom_of_match[] = {
- { .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
- { .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
+ { .compatible = "fsl,mpc5200-bestcomm", },
+ { .compatible = "mpc5200-bestcomm", },
{},
};
^ permalink raw reply related
* Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
From: Joakim Tjernlund @ 2008-03-22 11:51 UTC (permalink / raw)
To: Li Yang, Netdev, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <989B956029373F45A0B8AF029708189001D19565@zch01exm26.fsl.freescale.net>
Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG5ldGRldi1vd25lckB2Z2Vy
Lmtlcm5lbC5vcmcNCj4+IFttYWlsdG86bmV0ZGV2LW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24g
QmVoYWxmIE9mIEpvYWtpbSBUamVybmx1bmQNCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMTgsIDIw
MDggMTE6MTEgUE0NCj4+IFRvOiBOZXRkZXY7IExpIFlhbmcNCj4+IENjOiBKb2FraW0gVGplcm5s
dW5kDQo+PlN1YmplY3Q6IFtQQVRDSF0gdWNjX2dldGg6IEFkZCA4IGJ5dGVzIHRvIG1heCBUWCBm
cmFtZSBmb3IgVkxBTnMNCj4+DQo+PiBDcmVhdGluZyBhIFZMQU4gaW50ZXJmYWNlIG9uIHRvcCBv
ZiB1Y2NfZ2V0aCBhZGRzIDQgYnl0ZXMgdG8NCj4+IHRoZSBmcmFtZSBhbmQgdGhlIEhXIGNvbnRy
b2xsZXIgaXMgbm90IHByZXBhcmVkIHRvIFRYIGEgZnJhbWUNCj4+IGJpZ2dlciB0aGFuIDE1MTgg
Ynl0ZXMgd2hpY2ggaXMgNCBieXRlcyB0b28gc21hbGwgZm9yIGEgZnVsbA0KPj4gVkxBTiBmcmFt
ZS4gQWxzbyBhZGQgNCBleHRyYSBieXRlcyBmb3IgZnV0dXJlIGV4cGFuc2lvbi4NCj4gDQo+IElN
TywgVkxBTiBhbmQgSnVtYm8gcGFja2V0IHN1cHBvcnQgaXMgbm90IGdlbmVyYWwgY2FzZSBvZiBF
dGhlcm5ldC4NCj4gQ291bGQgeW91IG1ha2UgdGhpcyBjaGFuZ2Ugb3B0aW9uYWw/ICBUaGFua3Mu
DQo+IA0KPiAtIExlbyANCg0KaG1tLCBJIGRvIG5vdCBhZ3JlZS4gVkxBTiBpcyBjb21tb24gdG9k
YXkuDQoNCklmIHlvdSB3ZXJlIHRvIGVuYWJsZSBIVyBzdXBwb3J0IGZvciBWTEFOIHRoZW4gdGhl
IGV0aGVybmV0IGNvbnRyb2xsZXIgd291bGQgaW5qZWN0IGFuIGV4dHJhIDQgYnl0ZXMgaW50byB0
aGUgZnJhbWUuIA0KVGhpcyBjaGFuZ2UgZG9lcyBub3QgY2hhbmdlIHRoZSB2aXNpYmxlIE1UVSBm
b3IgdGhlIHVzZXIuIEFzIGlzIG5vdywgc29mdCBWTEFOIGlzIHNpbGVudGx5IGJyb2tlbi4gRG8g
eW91DQpyZWFsbHkgd2FudCB0aGUgdXNlciB0byBmaW5kIGFuZCB0dXJuIG9uIGEgY29udHJvbGxl
ciBzcGVjaWZpYyBmZWF0dXJlIHRvIHVzZSBWTEFOPw0KDQpXaGF0IGRvZXMgbmV0ZGV2IHBlb3Bs
ZSB0aGluaz8gDQoNCiBKb2NrZSANCg0KDQo=
^ permalink raw reply
* Re: Oops with TQM5200 on TQM5200
From: Grant Likely @ 2008-03-22 14:39 UTC (permalink / raw)
To: Anatolij Gustschin, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <47E4E421.8060806@denx.de>
On Sat, Mar 22, 2008 at 4:49 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Checking bcom_eng pointer for NULL before referencing data pointed
> by it prevents oopsing, but fec driver still doesn't work (because
> of the lost bestcomm match and resulted task allocation failure).
> Actually the compatible property exists and should match and so
> the fec driver shoud work.
>
> I suggest removing .type = "dma-controller" from the bestcomm driver's
> mpc52xx_bcom_of_match table to solve the problem.
>
> What do you think?
Yes, I agree. .compatible is completely sufficient to match the
device so .type is superfluous in this case. Removing it is
appropriate.
I've already sent a patch to fix the null pointer deref.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Paul, here's one more bug fix to pick up for .25. (I think we're done now)
Cheers,
g.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> diff --git a/arch/powerpc/sysdev/bestcomm/bestcomm.c b/arch/powerpc/sysdev/bestcomm/bestcomm.c
> index f589999..137d830 100644
> --- a/arch/powerpc/sysdev/bestcomm/bestcomm.c
> +++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
> @@ -484,8 +484,8 @@ mpc52xx_bcom_remove(struct of_device *op)
> }
>
> static struct of_device_id mpc52xx_bcom_of_match[] = {
> - { .type = "dma-controller", .compatible = "fsl,mpc5200-bestcomm", },
> - { .type = "dma-controller", .compatible = "mpc5200-bestcomm", },
> + { .compatible = "fsl,mpc5200-bestcomm", },
> + { .compatible = "mpc5200-bestcomm", },
> {},
> };
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-22 14:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, John Linn
In-Reply-To: <18403.32257.725539.470771@cargo.ozlabs.ibm.com>
On Fri, Mar 21, 2008 at 3:21 AM, Paul Mackerras <paulus@samba.org> wrote:
> Grant Likely writes:
>
> > Personally, I'm not fond of this approach. There is already some
> > traction to using the reg-shift property to specify spacing, and I
> > think it would be appropriate to also define a reg-offset property to
> > handle the +3 offset and then let the xilinx 16550 nodes use those.
>
> Why do we need a reg-offset property when we can just add the offset
> to the appropriate word(s) in the reg property?
Primarily because the device creates 32 byte registers starting at 0;
but they are also big-endian byte accessible so a byte read at offset
8 also works. reg-offset seems to be a better description of the
hardware to me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-03-22 15:06 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, John Linn
In-Reply-To: <47E3B189.6060002@ru.mvista.com>
On Fri, Mar 21, 2008 at 7:00 AM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> wrote:
> Grant Likely wrote:
> > Personally, I'm not fond of this approach. There is already some
> > traction to using the reg-shift property to specify spacing, and I
> > think it would be appropriate to also define a reg-offset property to
> > handle the +3 offset and then let the xilinx 16550 nodes use those.
>
> That's making things only worse than the mere "reg-shift" idea. I think
> that both are totally wrong. Everything about the programming interface should
> be said in the "compatible" and possibly "model" properties. of_serial driver
> should recognize them and pass the necessary details to 8250.c. As for me, I'm
> strongly against plaguing the device tree with the *Linux driver
> implementation specifics* (despite I was trying this with MTD -- there it
> seemed somewhat more grounded :-).
Not true. Compatible defines what the node is describing. It is
perfectly valid for a compatible value definition to also defines some
additional properties that can be queried for interface details.
Xilinx is completely free to define a "xlnx,..." compatible value for
their ns16550 compatible device. However, 'sparse' ns16550 devices
are a common and well known variation so I think it is valid and
reasonable to define a compatible binding for this case.
As for using a new binding like "sparse16550" instead of extending
"ns16550"; it is because reg-shift and reg-offset would be required
nodes and therefore is not compatible with drivers using the original
ns16550 binding. Using a new namespace gives freedom to define the
required properties.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: crash in init_ipic_sysfs on efika
From: Sven Luther @ 2008-03-22 15:25 UTC (permalink / raw)
To: Grant Likely; +Cc: Olaf Hering, sven, Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40803211151w688a8d61sba9d0d0e6cdc7833@mail.gmail.com>
On Fri, Mar 21, 2008 at 12:51:46PM -0600, Grant Likely wrote:
> On Fri, Mar 21, 2008 at 7:14 AM, Matt Sealey <matt@genesi-usa.com> wrote:
> > Is the MPC5200B PSC-AC97 driver in there?
>
> Audio drivers need to go in via one of the ALSA developers and I
> haven't been paying close enough attention to know if it has not in
> yet.
BTW, it was reported to me that the ethernet drivers don't get
autoloaded by udev. Is this a failure of udev missing the of_plateform
support, or a deficiency of the ethernet drivers ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-22 16:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Paul Mackerras, John Linn
In-Reply-To: <fa686aa40803220750h1d86589am9a26aeeb359178b7@mail.gmail.com>
Grant Likely wrote:
>> > Personally, I'm not fond of this approach. There is already some
>> > traction to using the reg-shift property to specify spacing, and I
>> > think it would be appropriate to also define a reg-offset property to
>> > handle the +3 offset and then let the xilinx 16550 nodes use those.
>> Why do we need a reg-offset property when we can just add the offset
>> to the appropriate word(s) in the reg property?
> Primarily because the device creates 32 byte registers starting at 0;
> but they are also big-endian byte accessible so a byte read at offset
> 8 also works. reg-offset seems to be a better description of the
> hardware to me.
Ugh... I was just going is it possible to access the chip registers as
32-bit entities, and employ UPIO_MEM32 mode of 8250.c -- just to avoid that
reg-offset wart. Now you're telling everybody that it's completely
superfluous... :-)
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for Xilinx uart 16550.
From: Sergei Shtylyov @ 2008-03-22 16:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn
In-Reply-To: <fa686aa40803220806w3288ab8ew754404a5aee152cf@mail.gmail.com>
Grant Likely wrote:
>> > Personally, I'm not fond of this approach. There is already some
>> > traction to using the reg-shift property to specify spacing, and I
>> > think it would be appropriate to also define a reg-offset property to
>> > handle the +3 offset and then let the xilinx 16550 nodes use those.
>> That's making things only worse than the mere "reg-shift" idea. I think
>> that both are totally wrong. Everything about the programming interface should
>> be said in the "compatible" and possibly "model" properties. of_serial driver
>> should recognize them and pass the necessary details to 8250.c. As for me, I'm
>> strongly against plaguing the device tree with the *Linux driver
>> implementation specifics* (despite I was trying this with MTD -- there it
>> seemed somewhat more grounded :-).
> Not true. Compatible defines what the node is describing. It is
> perfectly valid for a compatible value definition to also defines some
> additional properties that can be queried for interface details.
> Xilinx is completely free to define a "xlnx,..." compatible value for
> their ns16550 compatible device. However, 'sparse' ns16550 devices
> are a common and well known variation so I think it is valid and
> reasonable to define a compatible binding for this case.
We have been mostly talking about the 16550-compatible devices which
external circuitry makes "sparse" so far. This is surely not a property of a
16550 device to be "sparse" or not, although some say that this doesn't
matter. :-)
> As for using a new binding like "sparse16550" instead of extending
That "sparse16550" again... what if it's a superset of 16550 (not an
uncommon case too), will you also define "sparce16650", "sparse16570", and so
on? :-)
> "ns16550"; it is because reg-shift and reg-offset would be required
> nodes and therefore is not compatible with drivers using the original
> ns16550 binding. Using a new namespace gives freedom to define the
> required properties.
You'll have to define several namespaces I'm afraid...
> Cheers,
> g.
WBR, Sergei
^ permalink raw reply
* [PATCH] POWERPC: Move a.out.h to header-y since it doesn't check __KERNEL__.
From: Robert P. J. Day @ 2008-03-22 19:05 UTC (permalink / raw)
To: Linux PPC Mailing List
Since a.out.h doesn't check the value of __KERNEL__, there's no point
in unifdef'ing it.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
diff --git a/include/asm-powerpc/Kbuild b/include/asm-powerpc/Kbuild
index 5f640e5..7381916 100644
--- a/include/asm-powerpc/Kbuild
+++ b/include/asm-powerpc/Kbuild
@@ -1,5 +1,6 @@
include include/asm-generic/Kbuild.asm
+header-y += a.out.h
header-y += auxvec.h
header-y += ioctls.h
header-y += mman.h
@@ -23,7 +24,6 @@ header-y += sigcontext.h
header-y += statfs.h
header-y += ps3fb.h
-unifdef-y += a.out.h
unifdef-y += asm-compat.h
unifdef-y += bootx.h
unifdef-y += byteorder.h
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply related
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 19:35 UTC (permalink / raw)
To: Étienne Bersac; +Cc: linuxppc-dev
In-Reply-To: <1201348525.6859.1.camel@thilivren>
On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> From: Étienne Bersac <bersace@gmail.com>
>
> Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> windfarm_pm81 driver from Benjamin Herrenschmidt.
Is it just coincidence, or does it only seem to stop the fans when I
cat /sys/devices/platform/windfarm.0/cpu-temp ?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: Benjamin Herrenschmidt @ 2008-03-22 22:13 UTC (permalink / raw)
To: David Woodhouse; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206214508.9540.89.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 19:35 +0000, David Woodhouse wrote:
> On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > From: Étienne Bersac <bersace@gmail.com>
> >
> > Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> > 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> > windfarm_pm81 driver from Benjamin Herrenschmidt.
>
> Is it just coincidence, or does it only seem to stop the fans when I
> cat /sys/devices/platform/windfarm.0/cpu-temp ?
Is it actually working ?
If the SMU thinks there is no fan control done by the OS, it will ramp
them up ... but bring them back down when it gets ping.
So if for some reason the control loop isn't starting (because it can't
find something it wants on this machine), the fans will stay up, but
you'll cause such a "ping" when reading the CPU temp.
That may be bogus, just thinking what it could be...
Ben.
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:02 UTC (permalink / raw)
To: benh; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206223998.7197.13.camel@pasglop>
On Sun, 2008-03-23 at 09:13 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2008-03-22 at 19:35 +0000, David Woodhouse wrote:
> > On Sat, 2008-01-26 at 12:55 +0100, Étienne Bersac wrote:
> > > From: Étienne Bersac <bersace@gmail.com>
> > >
> > > Implement a new driver named windfarm_pm121 which drive fans on PowerMac
> > > 12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
> > > windfarm_pm81 driver from Benjamin Herrenschmidt.
> >
> > Is it just coincidence, or does it only seem to stop the fans when I
> > cat /sys/devices/platform/windfarm.0/cpu-temp ?
>
> Is it actually working ?
>
> If the SMU thinks there is no fan control done by the OS, it will ramp
> them up ... but bring them back down when it gets ping.
>
> So if for some reason the control loop isn't starting (because it can't
> find something it wants on this machine), the fans will stay up, but
> you'll cause such a "ping" when reading the CPU temp.
Yeah, there's weird shit going on with the sensor/control registration.
I think GCC is be miscompiling it -- the sequence of
all = all && pm121_register_control(foo...);
all = all && pm121_register_control(bar...);
is bailing out as soon as 'all' gets set to zero. Despite the fact that
pm121_register_control() quite blatantly has side-effects.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] windfarm: add PowerMac 12,1 support
From: David Woodhouse @ 2008-03-22 23:14 UTC (permalink / raw)
To: benh; +Cc: Étienne Bersac, linuxppc-dev
In-Reply-To: <1206226966.9540.104.camel@pmac.infradead.org>
On Sat, 2008-03-22 at 23:02 +0000, David Woodhouse wrote:
>
> Yeah, there's weird shit going on with the sensor/control
> registration.
> I think GCC is be miscompiling it -- the sequence of
> all = all && pm121_register_control(foo...);
> all = all && pm121_register_control(bar...);
> is bailing out as soon as 'all' gets set to zero. Despite the fact
> that pm121_register_control() quite blatantly has side-effects.
That's after I fix the names in pm121_new_control() and fix
pm121_register_control() to set controls[id] instead of always setting
controls[FAN_OD], btw. Without that I don't think it could ever have
worked.
But it's still broken. I'll try to cut it down and file a GCC bug...
.pm121_new_control:
.LFB929:
.loc 1 883 0
.LVL44:
mflr 0
.LCFI38:
std 0,16(1)
.LCFI39:
std 30,-16(1)
.LCFI40:
std 31,-8(1)
.LCFI41:
stdu 1,-128(1)
.LCFI42:
ld 30,.LCTOC0@toc(2)
mr 31,3
.loc 1 886 0
ld 9,.LC47-.LCTOC1(30)
lwz 0,48(9)
cmpwi 7,0,0
bne 7,.L31
.LVL45:
.loc 1 889 0
ld 4,.LC49-.LCTOC1(30)
li 5,2
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 890 0
mr 3,31
ld 4,.LC51-.LCTOC1(30)
li 5,1
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 891 0
mr 3,31
ld 4,.LC53-.LCTOC1(30)
li 5,0
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 892 0
mr 3,31
ld 4,.LC55-.LCTOC1(30)
li 5,3
bl .pm121_register_control
cmpdi 7,3,0
beq 7,.L31
.loc 1 895 0
ld 3,.LC57-.LCTOC1(30)
bl .printk
nop
.loc 1 896 0
ld 9,.LC47-.LCTOC1(30)
li 0,1
stw 0,48(9)
.LVL46:
.L31:
.loc 1 898 0
addi 1,1,128
ld 0,16(1)
mtlr 0
ld 30,-16(1)
ld 31,-8(1)
.LVL47:
blr
--
dwmw2
^ 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