Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
Hello Stephen,
Stephen Rothwell wrote:
On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
[...]
+struct cpm_pin {
+int port, pin, flags;
+};
I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like, moving this struct
in cpm1.h and ...
+static void __init init_ioports(void)
+{
+int i;
+
+for (i = 0; i ARRAY_SIZE(mgsuvd_pins); i++) {
+struct cpm_pin *pin = mgsuvd_pins[i];
+cpm1_set_pin(pin-port, pin-pin, pin-flags);
+}
And the code that uses them ...
making in arch/powerpc/sysdev/cpm1.c a function
cpm1_setup_pins (struct cpm_pin *pins) ?
+static void __init mgsuvd_setup_arch(void)
+{
+struct device_node *cpu;
+
+cpu = of_find_node_by_type(NULL, cpu);
+if (cpu != 0) {
cpu is a pointer, so cpu != NULL or just cpu
+const unsigned int *fp;
+
+fp = of_get_property(cpu, clock-frequency, NULL);
+if (fp != 0)
Ditto for fp test
Its no longer necessary, thanks to Scott
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
Hi Heiko,
On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
[...]
+struct cpm_pin {
+ int port, pin, flags;
+};
I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like, moving this struct
in cpm1.h and ...
Yes or somewhere else appropriate.
+ for (i = 0; i ARRAY_SIZE(mgsuvd_pins); i++) {
+ struct cpm_pin *pin = mgsuvd_pins[i];
+ cpm1_set_pin(pin-port, pin-pin, pin-flags);
+ }
And the code that uses them ...
making in arch/powerpc/sysdev/cpm1.c a function
cpm1_setup_pins (struct cpm_pin *pins) ?
Yes.
This is not necessary for your patch, but would be a nice cleanup later.
N.B. this struct is alos used by users of cpm2_set_pin().
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpTpsZFLoAhE.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
Hello Stephen,
Stephen Rothwell wrote:
On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher [EMAIL PROTECTED] wrote:
[...]
+struct cpm_pin {
+ int port, pin, flags;
+};
I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like, moving this struct
in cpm1.h and ...
Yes or somewhere else appropriate.
+ for (i = 0; i ARRAY_SIZE(mgsuvd_pins); i++) {
+ struct cpm_pin *pin = mgsuvd_pins[i];
+ cpm1_set_pin(pin-port, pin-pin, pin-flags);
+ }
And the code that uses them ...
making in arch/powerpc/sysdev/cpm1.c a function
cpm1_setup_pins (struct cpm_pin *pins) ?
Yes.
This is not necessary for your patch, but would be a nice cleanup later.
N.B. this struct is alos used by users of cpm2_set_pin().
OK. Another thought about this. Shouldnt this table go in the dts?
A device node like
cpm_pin {
pins = port pin flags;
};
would be nice, or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] 8xx: Add support for the MPC852 based board from keymile.
Hello,
Add support for the MPC852 based mgsuvd board from keymile
to arch/powerpc. Supported SMC1 (serial console),
SCC3 Ethernet (10Mbps hdx)
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgsuvd.dts | 158 +++
arch/powerpc/configs/mgsuvd_defconfig | 827 +
arch/powerpc/platforms/8xx/Kconfig|7 +
arch/powerpc/platforms/8xx/Makefile |1 +
arch/powerpc/platforms/8xx/mgsuvd.c | 97
5 files changed, 1090 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgsuvd.dts
create mode 100644 arch/powerpc/configs/mgsuvd_defconfig
create mode 100644 arch/powerpc/platforms/8xx/mgsuvd.c
diff --git a/arch/powerpc/boot/dts/mgsuvd.dts b/arch/powerpc/boot/dts/mgsuvd.dts
new file mode 100644
index 000..eb6ad3b
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgsuvd.dts
@@ -0,0 +1,158 @@
+/*
+ * MGSUVD Device Tree Source
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher [EMAIL PROTECTED]
+ *
+ * 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.
+ */
+
+
+/ {
+ model = MGSUVD;
+ compatible = keymile,mgsuvd;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = d#16;
+ i-cache-line-size = d#16;
+ d-cache-size = d#8192;
+ i-cache-size = d#8192;
+ timebase-frequency = 0; /* Filled in by u-boot
*/
+ bus-frequency = 0;/* Filled in by u-boot
*/
+ clock-frequency = 0; /* Filled in by u-boot
*/
+ interrupts = f 2; /* decrementer
interrupt */
+ interrupt-parent = PIC;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 400; /* Filled in by u-boot */
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,pq1-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = fff00100 40;
+
+ ranges =
+ 0 0 f000 0100
+ ; /* Filled in by u-boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 100;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 8;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 8 2;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = a f6;
+ };
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc885, fsl,pq1-soc;
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 fff0 4000;
+
+ PIC: [EMAIL PROTECTED] {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0 24;
+ compatible = fsl,pq1-pic;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,cpm1;
+ command-proc = 9c0;
+ interrupts = 0; /* cpm error interrupt */
+ interrupt-parent = CPM_PIC;
+ reg = 9c0 10;
+ ranges;
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 2000 2000;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,cpm-muram-data;
+ reg = 800 1800;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc885-brg,
+fsl,cpm1-brg,
+
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: On Mon, Mar 17, 2008 at 9:57 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote: [...] we were hoping that the changes would go upstream (in 2.6.25). I can see that the .dts files for those boards are in the mainline already, but I see no trace of for example _defconfig files -- could you shed some light on this? Yes, the separate dts files have been dropped in preference for a single mpc5200_defconfig for all 5200 boards. Ah, yes. I was searching for patches by Marian, and missed the defconfig unification patch by you. BTW: I can't find it using its description from the commit log (i.e., [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards) in Nabble's archive of linuxppc ML; searching patchwork.ozlabs.org/linuxppc fails as well. Should I search using some other description? Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
Grant Likely wrote: On Mon, Mar 17, 2008 at 4:28 PM, Wolfgang Denk [EMAIL PROTECTED] wrote: [...] It may be argued that this code should be moved somewhere else, but I don't remeber to have seen any such review comments. The LED code just hasn't been picked up. IIRC, it was reworked to make it a proper driver in drivers/leds. Grant, Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-proid=16617 I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. Richard -- could pick up the above mentioned Motion-PRO LED driver for upstream inclusion? It started as a MPC5200-specific thing posted to linuxppc-dev and got reviewed there, with the intent to go upstream via Grant (MPC52XX maintainer). However, it seems that it should be merged through your subsystem. Thanks, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant, I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console Grant Likely schrieb: On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz [EMAIL PROTECTED] wrote: All, I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints. Up to now the systems have been running on 2.6.19 without any problems. This is what I've done so far : - get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage. - latest bootloader (u-boot 1.3.2) is running fine with dtb support. - Kernel and RFS images are available via bootp/tftp - device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly. - Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x10, 0x60, 0x5F). - nothing more happens. It looks like the console isn't working properly - maybe worse ... Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc000 to get the physical address). __log_buf should give you clues about how far booting progresses. (c033d4b4 b __log_buf) yields all zeroes - nothing logged at all. Examining the CPU state with the bdi shows : Target CPU: MPC8280/8220/5200 (Zeppo) Target state : debug mode Debug entry cause : COP halt Current PC: 0xc000552c Current CR: 0x4842 Current MSR : 0x9032 Current LR: 0xc00166c0 The program counter shows the adress of irq_set_virq_count which has a BUG() macro. Looks like this one evaluates to true. What do you think ? The kernel has been build using the MPC5200 simple setup. I've added our board identifier mv,mvbluecougar to the list of supported boards in the mpc52xx_simple.c file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ? Yes, this should be enough (on a side note; it should probably be matrix-vision,bluecougar unless of''mv' is your company's stock ticker symbol). As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ? That is correct. The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or advanced features like mtd partitions. All I want to get working is the serial console on /dev/ttyPSC0. Cheers, g. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
On Mon, 2008-03-17 at 18:08 -0500, Timur Tabi wrote: Joakim Tjernlund wrote: eth0 is also up, was it commit 4942bd80e83d13bf394df4a8109bee39d861820f that fixed that bug? Yep. Unfortunately, I don't really know enough about the ucc_geth driver to know what could be wrong. I just noticed your message and remembered that old bug. Found it, the eth1 i/f on this board isn't working and does not generate any clocks which makes ugeth_graceful_stop_tx() hang forever. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote: Grant Likely wrote: The LED code just hasn't been picked up. IIRC, it was reworked to make it a proper driver in drivers/leds. Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-proid=16617 I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. Richard -- could pick up the above mentioned Motion-PRO LED driver for upstream inclusion? It started as a MPC5200-specific thing posted to linuxppc-dev and got reviewed there, with the intent to go upstream via Grant (MPC52XX maintainer). However, it seems that it should be merged through your subsystem. There are some tweaks this driver needs before it can be merged. Firstly, it seems to re implement a timer to make the LED blink and I'm not keen on doing that. I notice that you have default_trigger = timer but that won't make it activate at boot which is probably why the other code exists? I will accept a patch which allows the default timer state to be configurable (either from the defconfig or from the commandline) which should solve your problem? Secondly, can you confirm what of_get_property(op-node, label, NULL); returns and whether this conforms to the LED naming guidelines? Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant, sorry for having troubled you. Looks like the build system has been in an invalid state... After doing a git-pull and make distclean + make mpc5200_defconfig the system is finally up and running. Using mpc5200-simple-platform machine description Linux version 2.6.25-rc6-00978-g275c005-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #9 Tue Mar 18 11:25:07 CET 2008 Found initrd at 0xc397a000:0xc3c0 arch/powerpc/platforms/52xx/mpc52xx_common.c: Error mapping XLB in mpc52xx_setup_cpu(). Expect some abnormal behavior Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: root=/dev/ram ro rootfstype=squashfs ip=192.168.65.57::192.168.65.15:255.255.255.0 console=ttyPSC0,115200N8 e1000.TxDescriptors=1500 e1000.SmartPowerDownEnable=1 MPC52xx PIC is up and running! PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[79364d9] shift[22] registered console [ttyPSC0] enabled regards, Andre Andre Schwarz schrieb: Grant, I've pulled the latest git and built a mpc5200_simple system with a minimal dts. There's not a single char put on the console Grant Likely schrieb: On Sun, Mar 16, 2008 at 1:15 PM, André Schwarz [EMAIL PROTECTED] wrote: All, I'm quite stuck in getting our MPC5200B based systems work on 2.6.24+ ... maybe someone could give me some hints. Up to now the systems have been running on 2.6.19 without any problems. This is what I've done so far : - get a recent system with 2.6.19 running and keep the toolchain (gcc 4.0) including RFS uImage. - latest bootloader (u-boot 1.3.2) is running fine with dtb support. - Kernel and RFS images are available via bootp/tftp - device tree blob seems ok, i.e. u-boot can display the blob and fill in all clocks correctly. - Kernel gets called with Kernel, RFS and dtb on suitable adresses (0x10, 0x60, 0x5F). - nothing more happens. It looks like the console isn't working properly - maybe worse ... Can you either halt the processor or reset the board and access memory after this point? You should see if you can access __log_buf (Look in System.map for the address and subtract 0xc000 to get the physical address). __log_buf should give you clues about how far booting progresses. (c033d4b4 b __log_buf) yields all zeroes - nothing logged at all. Examining the CPU state with the bdi shows : Target CPU: MPC8280/8220/5200 (Zeppo) Target state : debug mode Debug entry cause : COP halt Current PC: 0xc000552c Current CR: 0x4842 Current MSR : 0x9032 Current LR: 0xc00166c0 The program counter shows the adress of irq_set_virq_count which has a BUG() macro. Looks like this one evaluates to true. What do you think ? The kernel has been build using the MPC5200 simple setup. I've added our board identifier mv,mvbluecougar to the list of supported boards in the mpc52xx_simple.c file. This identifier is used in the dtb as well of course. This should be enough along with a valid device tree blob, isn't it ? Did I miss anything already ? Yes, this should be enough (on a side note; it should probably be matrix-vision,bluecougar unless of''mv' is your company's stock ticker symbol). As far as I did understand by reading the docs it should be possible running a general MPC52xx kernel with a custom dtb ? Is this correct ? That is correct. The dts file has already been reduced to a minimum, i.e. only the cpu, pic, xlb and a few nodes like psc1 and psc2 are present. No bestcomm, pci, ata or advanced features like mtd partitions. All I want to get working is the serial console on /dev/ttyPSC0. Cheers, g. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Mon, 17 Mar 2008 20:42:14 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Mon, Mar 17, 2008 at 6:26 PM, Wolfgang Denk [EMAIL PROTECTED] wrote: Dear Grant, in message [EMAIL PROTECTED] you wrote: However, I have declined (for now) to pick up the defconfigs for those boards and instead merged in the config features they require into the mpc5200 defconfig. My primary reason for doing so is to increase the likelyhood that full featured kernels are built and tested so that situations where board ports conflict with each other are caught and fixed. I know what you mean, and I agree with the idea. Unfortunately I think it's impossible to implement, especially on such embedded processors with their high level of pin multiplexing. For example, if you want to include testing of the FEC ethernet driver, you will probably fail to test the second USB port. I think it's simply not possible to test all possible options in a single kernel configuration - first it doesn't work (for example because of pin multiplexing issues), second you will likely not be able to find hardware that implements all features at once. I don't think this example really applies. Yes, I agree that I cannot test all the functions, but that does not preclude building in all the drivers and making sure that they don't cause a conflict by just being present. For instance, I can build a single kernel image right now that should boot and fully run on the Efika, lite5200, tqm and motion pro boards (although the Efika has a different wrapper). I can only test it on the Efika and lite5200 boards and I have to rely on other people for the boards I don't have. If it breaks; I expect to receive an irate email in my Inbox telling me to fix it! pin multiplexing shouldn't be an issue at all. Only the devices which are instantiated in the device tree will actually get initialized so if the pins aren't hooked up then it shouldn't be in the tree. That's not entirely true. Devices that are muxed can be added to the tree just fine. What I've done on 440 boards that have devices that share pins is to add a status = disabled; property to the device that doesn't have pins at the moment. See my patch for of_device_is_available for how to query that. I'll be throwing that in my tree soon if Paul doesn't pick it up. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] Add PPC4xx L2-cache support (440GX 460EX/GT)
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 just a copy of Eugene's code in arch/ppc
with small modifications.
Tested on AMCC Taishan 440GX and Canyonlands 460EX.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |3 +
arch/powerpc/platforms/44x/Kconfig |2 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/ppc4xx_soc.c | 174
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 000..4847555
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -0,0 +1,174 @@
+/*
+ * IBM/AMCC PPC4xx SoC setup code
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese [EMAIL PROTECTED]
+ *
+ * L2 cache routines cloned from arch/ppc/syslib/ibm440gx_common.c which is:
+ * Eugene Surovegin [EMAIL PROTECTED] or [EMAIL PROTECTED]
+ * 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(0x4200);
+ 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(0x8200) 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 = NULL;
+ 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);
+ return
[PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
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: [EMAIL PROTECTED] {
+ 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 = 4; /* L2, 256K */
+ interrupt-parent = UIC2;
+ interrupts = 17 1;
+ };
+
plb {
compatible = ibm,plb-440gx, ibm,plb4;
#address-cells = 2;
--
1.5.4.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] net: NEWEMAC: Support for Pause packets in EMAC driver
Benjamin Herrenschmidt wrote: http://marc.info/?l=linux-netdevm=120449748701492w=2 I sent it to Ben with netdev on CC because you asked the various people sending NEWEMAC patches to you to find a single person. So from now on, what are we going to do? It seems we're playing net maintainer russian roulette for NEWEMAC and it's getting old. I'm happy to collect the patches. I said I would do it, I was just taken aback a bit by Jeff suddenly merging two of Stefan patches directly :-) I was actually planning this week to post a serie of all the pending EMAC patches for final review. Cheers, Ben. FYI, These are the NEWEMAC patches I've sent: http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052114.html (This is a TAH csum fix, that I don't see on the patchwork for some reason) and a couple of PHY clock workarounds http://patchwork.ozlabs.org/linuxppc/patch?id=17211 http://patchwork.ozlabs.org/linuxppc/patch?id=17212 The latter two patches depend on the dcri_clrset one: http://patchwork.ozlabs.org/linuxppc/patch?id=17199 Ben, could you please also take a look at the PCIe dcri_clrset stuff here http://patchwork.ozlabs.org/linuxppc/patch?id=17214 (not EMAC related) Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz [EMAIL PROTECTED] wrote: Grant, sorry for having troubled you. Looks like the build system has been in an invalid state... After doing a git-pull and make distclean + make mpc5200_defconfig the system is finally up and running. Heh; I hate it when that happens. :-) Congratulations. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
Joakim Tjernlund wrote: Found it, the eth1 i/f on this board isn't working and does not generate any clocks which makes ugeth_graceful_stop_tx() hang forever. Well, that doesn't make it very graceful, does it? :-) Can you fix this yourself, or do you want me to file an internal bug report? If so, can you email me a detailed description of the problem? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Force 4K pages for IO addresses.
Benjamin Herrenschmidt wrote: On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote: On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote: Currently HEA requires 4K pages for IO resources. Just set the pages size to IO to 4K. Well, that's too bad. Why penalize all platforms for it? I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to waste tlb and erat space. We would have to make that pSeries specific for now I suppose... We don't have a way to know that there can be an EHEA right ? It may not be in the device-tree at boot and dynamically added to the partition... The ibm,drc-names property of the root node should have HEA strings in it on systems where EHEA can potentially be present. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote: Grant, Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-proid=16617 I need to look at it again, but it is a lot of code for a very simple thing and I wasn't sure if I should be the one to pick it up because it is in drivers/leds which has a different maintainer. I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer. Richard -- could pick up the above mentioned Motion-PRO LED driver for upstream inclusion? It started as a MPC5200-specific thing posted to linuxppc-dev and got reviewed there, with the intent to go upstream via Grant (MPC52XX maintainer). However, it seems that it should be merged through your subsystem. Okay, I've taken another look at the driver and I've figured out what has been bothering me about it. It seems to me that the motion pro led driver is just the first of many that we will see (seeing as some many people find the blinking lights rather soothing) and it's a non trivial amount of code. (Note: I'm not actually opposed to this driver if Richard is okay with it; but I do think that in the long term we should move towards a more generic approach) In essence, this driver sets up two GPIO pins to drive LEDs. A pretty common approach for putting LEDs on a board. In this case each GPIO bank only contains 1 pin; but I imagine that on other boards there will be multiple pins in a GPIO bank, only some of which actually used for blinking LEDs. I've started thinking that it would be better to split things up in the device tree to have one node for each GPIO block and a single LED node that maps LEDs to gpio pins. That would allow a common driver to be written for all GPIO driven LEDs with a single block of device tree parsing code. Plus, it allows other devices to use GPIO pins within the same block (not an issue for the motion pro board; but when other boards start coming on-line it would allow us to reduce the amount of board specific code). Finally, it means that the timer pin GPIO driver can be used for more than just flashing an attached LED. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
On Tue, Mar 18, 2008 at 09:04:14AM +0100, Heiko Schocher wrote:
OK. Another thought about this. Shouldnt this table go in the dts?
A device node like
cpm_pin {
pins = port pin flags;
};
would be nice, or?
Well, the device tree is a mechanism for communicating from the firmware
to the kernel, and if we could control the firmware better we'd just make
it set the pins properly to begin with. :-)
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant Likely schrieb: On Tue, Mar 18, 2008 at 4:34 AM, Andre Schwarz [EMAIL PROTECTED] wrote: Grant, sorry for having troubled you. Looks like the build system has been in an invalid state... After doing a git-pull and make distclean + make mpc5200_defconfig the system is finally up and running. Heh; I hate it when that happens. :-) Congratulations. g. Grant, this leads to the next questions ... :-) I've read some discussions about the interrupt-map attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course. Maybe you can clarify this ? Taken from motionpro.dts ... 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; First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ? 2nd + 3rd paramter : no clue ! can you explain ? 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ? 5th : ok - parent pic 6th ... 8th : IRQ representation of the parent pic, which gives : 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have number 1..3 inside MAIN level. 8th : should be 3 = level low which is default for PCI. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
On Tue, 2008-03-18 at 09:32 -0500, Timur Tabi wrote: Joakim Tjernlund wrote: Found it, the eth1 i/f on this board isn't working and does not generate any clocks which makes ugeth_graceful_stop_tx() hang forever. Well, that doesn't make it very graceful, does it? :-) Nope, :) Can you fix this yourself, or do you want me to file an internal bug report? If so, can you email me a detailed description of the problem? I fixed it by adding a counter which aborts after 100 loops. If you could move along the 2 patches I sent today, Add Fixed PHY support for ucc_geth and ucc_geth: Add 8 bytes to max TX frame for VLANs into 2.6.25 that would be great :) Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 83xx: MPC837xRDB's VSC7385 ethernet switch isn't on the MDIO bus
Joakim Tjernlund wrote: I fixed it by adding a counter which aborts after 100 loops. If you could move along the 2 patches I sent today, Add Fixed PHY support for ucc_geth and ucc_geth: Add 8 bytes to max TX frame for VLANs into 2.6.25 that would be great :) I have no control over that, sorry. You'll have to ask Jeff G or maybe Kumar to pick up those patches. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsl_elbc_nand: fix mtd name
Currently fsl_elbc_nand doesn't initialize mtd-name, and this causes nand_get_flash_type() to assign name that is equal to chip type, like this: [EMAIL PROTECTED]:~# cat /proc/mtd dev:size erasesize name mtd0: 0080 0001 fe00.flash mtd1: 0200 4000 NAND 32MiB 3,3V 8-bit mtd0 is physmap_of flash (normal name), and mtd1 is fsl_elbc_nand. Despite inconsistency, with mtd name like this specifying paritions from the kernel command line becomes a torture (though, I didn't tried and not sure if mtdparts= can handle spaces at all). Plus, this causes real bugs when multiple fsl_elbc_nand chips registered. With this patch applied fsl_elbc_nand chip will have proper name: [EMAIL PROTECTED]:~# cat /proc/mtd dev:size erasesize name mtd0: 0080 0001 fe00.flash mtd1: 0200 4000 e060.flash p.s. We can't use priv-dev-bus_id as in physmap_of, because fsl_elbc_nand pretends to be a localbus controller, so its bus_id is address.localbus, which is incorrect and thus will also not work for multiple chips. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- drivers/mtd/nand/fsl_elbc_nand.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c index b025dfe..54a9d83 100644 --- a/drivers/mtd/nand/fsl_elbc_nand.c +++ b/drivers/mtd/nand/fsl_elbc_nand.c @@ -974,6 +974,8 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv) nand_release(priv-mtd); + kfree(priv-mtd.name); + if (priv-vbase) iounmap(priv-vbase); @@ -1050,6 +1052,8 @@ static int fsl_elbc_chip_probe(struct fsl_elbc_ctrl *ctrl, if (ret) goto err; + priv-mtd.name = kasprintf(GFP_KERNEL, %x.flash, res.start); + #ifdef CONFIG_MTD_PARTITIONS /* First look for RedBoot table or partitions on the command * line, these take precedence over device tree information */ -- 1.5.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 83xx: mpc837x_rdb: add simple-bus compatible matching
This is needed to probe nor and nand flashes on the localbus.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
index 9c498b7..a653a38 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_rdb.c
@@ -81,6 +81,7 @@ static void __init mpc837x_rdb_setup_arch(void)
static struct of_device_id mpc837x_ids[] = {
{ .type = soc, },
{ .compatible = soc, },
+ { .compatible = simple-bus, },
{},
};
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl_elbc_nand: fix mtd name
On Tue, Mar 18, 2008 at 06:43:44PM +0300, Anton Vorontsov wrote: With this patch applied fsl_elbc_nand chip will have proper name: [EMAIL PROTECTED]:~# cat /proc/mtd dev:size erasesize name mtd0: 0080 0001 fe00.flash mtd1: 0200 4000 e060.flash p.s. We can't use priv-dev-bus_id as in physmap_of, because fsl_elbc_nand pretends to be a localbus controller, so its bus_id is address.localbus, which is incorrect and thus will also not work for multiple chips. Acked-by: Scott Wood [EMAIL PROTECTED] -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
In message [EMAIL PROTECTED] you wrote: Hi, I found the following bug at kernel boot up on my power machine with 2.6.25-rc6 kernel. USB Mass Storage support registered. mice: PS/2 mouse device common for all mice Unable to handle kernel paging request for data at address 0xd82e Faulting instruction address: 0xc074ded8 cpu 0x0: Vector: 300 (Data Access) at [c0003e073aa0] pc: c074ded8: .f71805f_find+0x44/0x32c lr: c074e1f8: .f71805f_init+0x38/0x194 sp: c0003e073d20 msr: 80009032 dar: d82e dsisr: 4200 current = 0xc000220851c0 paca= 0xc07c2700 pid = 1, comm = swapper enter ? for help [c0003e073dc0] c074e1f8 .f71805f_init+0x38/0x194 [c0003e073ea0] c0724bdc .kernel_init+0x204/0x3c8 [c0003e073f90] c0025df4 .kernel_thread+0x4c/0x68 Is this an all yes or random config? CONFIG_SENSORS_F71805F doesn't appear in any of the powerpc def configs. Anyway, I'm guessing the driver hasn't checked the device tree and is probing somewhere it shouldn't. Mikey For further reference some of the debug info is: 0:mon r R00 = d82e R16 = 41c0 R01 = c0003e073d20 R17 = c066ecc8 R02 = c08f4458 R18 = R03 = 002e R19 = 003a1000 R04 = c0003e073e30 R20 = 0235a3d0 R05 = c0003e073e34 R21 = c075a3d0 R06 = 2444 R22 = 0235a640 R07 = c0010bcc R23 = c075a640 R08 = c0003e073570 R24 = c066fe90 R09 = d800 R25 = R10 = cf9c2d60 R26 = c0003e07 R11 = ff87 R27 = c0003e073e30 R12 = R28 = c0003e073e34 R13 = c07c2700 R29 = 002e R14 = R30 = c0880278 R15 = c0670448 R31 = c078e050 pc = c074ded8 .f71805f_find+0x44/0x32c lr = c074e1f8 .f71805f_init+0x38/0x194 msr = 80009032 cr = 2442 ctr = c074e1c0 xer = 0005 trap = 300 dar = d82e dsisr = 4200 0:mon e cpu 0x0: Vector: 300 (Data Access) at [c0003e073aa0] pc: c074ded8: .f71805f_find+0x44/0x32c lr: c074e1f8: .f71805f_init+0x38/0x194 sp: c0003e073d20 msr: 80009032 dar: d82e dsisr: 4200 current = 0xc000220851c0 paca= 0xc07c2700 pid = 1, comm = swapper 0:mon di %pc c074ded8 7d6919ae stbxr11,r9,r3 c074dedc 3901 li r8,1 c074dee0 990d01dc stb r8,476(r13) c074dee4 e93f ld r9,0(r31) c074dee8 7c034a14 add r0,r3,r9 c074deec 7c0004ac sync c074def0 7d6919ae stbxr11,r9,r3 c074def4 990d01dc stb r8,476(r13) c074def8 38800023 li r4,35 c074defc 4bcc95e1 bl c04174dc# .superio_inw+0x0/0x134 c074df00 3940ffed li r10,-19 c074df04 5463043e clrlwi r3,r3,16 c074df08 2f831934 cmpwi cr7,r3,6452 c074df0c 409e0260 bne cr7,c074e16c# .f71805f_find+0x2d8/0x32c c074df10 e93e8038 ld r9,-32712(r30) c074df14 a069 lhz r3,0(r9) 0:mon Thanks Sudhir Kumar ISTL, IBM Bangalore ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] fsl_elbc_nand: fix mtd name
On Tue, Mar 18, 2008 at 06:58:14PM +0300, Anton Vorontsov wrote: Oops, forgot the NULL checking. [snip] + if (priv-mtd.name) + kfree(priv-mtd.name); + Not needed; kfree(NULL) is a no-op. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
On Tue, 18 Mar 2008 09:04:14 +0100
Heiko Schocher wrote:
Hello Stephen,
Stephen Rothwell wrote:
On Tue, 18 Mar 2008 08:13:06 +0100 Heiko Schocher [EMAIL PROTECTED]
wrote:
Stephen Rothwell wrote:
On Fri, 14 Mar 2008 10:24:30 +0100 Heiko Schocher [EMAIL PROTECTED]
wrote:
[...]
+struct cpm_pin {
+int port, pin, flags;
+};
I wish someone would consolidate all these definitions of cpm_pin.
Hmm... do you mean something like, moving this struct
in cpm1.h and ...
Yes or somewhere else appropriate.
+for (i = 0; i ARRAY_SIZE(mgsuvd_pins); i++) {
+struct cpm_pin *pin = mgsuvd_pins[i];
+cpm1_set_pin(pin-port, pin-pin, pin-flags);
+}
And the code that uses them ...
making in arch/powerpc/sysdev/cpm1.c a function
cpm1_setup_pins (struct cpm_pin *pins) ?
Yes.
This is not necessary for your patch, but would be a nice cleanup
later. N.B. this struct is alos used by users of cpm2_set_pin().
OK. Another thought about this. Shouldnt this table go in the dts?
A device node like
cpm_pin {
pins = port pin flags;
};
would be nice, or?
This has been a disputable question some time ago, and decided (or it looks
like decided) that devtree describes hardware, and not the way it is configured
at the moment. Therefor, best way for pin stuff is considered, as Scott
mentioned, to set up stuff inside the firmware.
-Vitaly
bye,
Heiko
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
Dear Scott, in message [EMAIL PROTECTED] you wrote: Well, the device tree is a mechanism for communicating from the firmware to the kernel, and if we could control the firmware better we'd just make it set the pins properly to begin with. :-) Is this just a comment, or do you oppose Heiko's suggestion? Other uses of the device tree seem possible and reasonable, too. For example, we can use the device tree to configure the firmware (U-Boot in this case). Using the device tree to describe the pin configuration of the hardware sounds easier to me than hard-coding it in some source (or header) file - no matter if this is in the kernel and/or in the firmware. What do you think? 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: [EMAIL PROTECTED] A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. - Seneca ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz [EMAIL PROTECTED] wrote: I've read some discussions about the interrupt-map attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course. Maybe you can clarify this ? Taken from motionpro.dts ... First, you also need to look at interrupt-map-mask to interpret these values; from motionpro.dts: interrupt-map-mask = f800 0 0 7; which is applied to the unit interrupt specifier to figure out how to map onto the interrupt controller. The /size/ of this field is obtained by adding #address-cells with #interrupt-cells. (3+1=4). 'f8' refers to the upper 5 bits of the interrupt identifier which is a number from 0-31 which relates to the IDSEL line as you guessed. The '7' covers the lower 3 bits of the interrupt specifier which can be 1, 2, 3 or 4. The 120 bits in the middle are irrelevant, so interrupt-map-mask leaves them as zeros. 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; First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ? I don't remember how this is encoded. On the lite5200, idsel is wired to d0 and d1 for slots 1 and 2 respectively, yet these values suggest slots 24 and 25. I'll need to look at this again later. 2nd + 3rd paramter : no clue ! can you explain ? first 3 cells are the unit address and is #address-cells large. Only the first cell contains real data. 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ? you only need entries for irq lines that are wired up. If your board does not wire up _B, _C and _D, then don't have an entry for them. However, if they are wired up then you should describe them. 5th : ok - parent pic Correct. 6th ... 8th : IRQ representation of the parent pic, which gives : 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have number 1..3 inside MAIN level. 8th : should be 3 = level low which is default for PCI. Correct. There is also some good information here: http://playground.sun.com/1275/practice/imap/imap0_9d.pdf Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add Fixed PHY support for ucc_geth
On Tue, 18 Mar 2008 10:46:55 +0100
Joakim Tjernlund wrote:
The new Fixed PHY method, fixed-link property, isn't
impl. for ucc_geth which makes fixed PHYs non functional.
Add support for the new method to restore the Fixed PHY
functionality.
Makes sense to me, but let's cc linuxppc-devel
Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED]
Acked-by: Vitaly Bordug [EMAIL PROTECTED]
---
This is a regression as fixed PHYs works in 2.6.23 and I am
using it.
drivers/net/ucc_geth.c | 53
+++ 1 files changed, 30
insertions(+), 23 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index ecc5712..18c8b39 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3836,6 +3836,7 @@ static int ucc_geth_probe(struct of_device*
ofdev, const struct of_device_id *ma struct device_node *phy;
int err, ucc_num, max_speed = 0;
const phandle *ph;
+ const u32 *fixed_link;
const unsigned int *prop;
const char *sprop;
const void *mac_addr;
@@ -3926,18 +3927,38 @@ static int ucc_geth_probe(struct of_device*
ofdev, const struct of_device_id *ma
ug_info-uf_info.regs = res.start;
ug_info-uf_info.irq = irq_of_parse_and_map(np, 0);
+ fixed_link = of_get_property(np, fixed-link, NULL);
+ if (fixed_link) {
+ ug_info-mdio_bus = 0;
+ ug_info-phy_address = fixed_link[0];
+ phy = NULL;
+ } else {
+ ph = of_get_property(np, phy-handle, NULL);
+ phy = of_find_node_by_phandle(*ph);
- ph = of_get_property(np, phy-handle, NULL);
- phy = of_find_node_by_phandle(*ph);
+ if (phy == NULL)
+ return -ENODEV;
- if (phy == NULL)
- return -ENODEV;
+ /* set the PHY address */
+ prop = of_get_property(phy, reg, NULL);
+ if (prop == NULL)
+ return -1;
+ ug_info-phy_address = *prop;
+
+ /* Set the bus id */
+ mdio = of_get_parent(phy);
+
+ if (mdio == NULL)
+ return -1;
- /* set the PHY address */
- prop = of_get_property(phy, reg, NULL);
- if (prop == NULL)
- return -1;
- ug_info-phy_address = *prop;
+ err = of_address_to_resource(mdio, 0, res);
+ of_node_put(mdio);
+
+ if (err)
+ return -1;
+
+ ug_info-mdio_bus = res.start;
+ }
/* get the phy interface type, or default to MII */
prop = of_get_property(np, phy-connection-type, NULL);
@@ -3982,20 +4003,6 @@ static int ucc_geth_probe(struct of_device*
ofdev, const struct of_device_id *ma ug_info-numThreadsRx =
UCC_GETH_NUM_OF_THREADS_4; }
- /* Set the bus id */
- mdio = of_get_parent(phy);
-
- if (mdio == NULL)
- return -1;
-
- err = of_address_to_resource(mdio, 0, res);
- of_node_put(mdio);
-
- if (err)
- return -1;
-
- ug_info-mdio_bus = res.start;
-
if (netif_msg_probe(debug))
printk(KERN_INFO ucc_geth: UCC%1d at 0x%8x (irq =
%d) \n, ug_info-uf_info.ucc_num + 1, ug_info-uf_info.regs,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: On Tue, Mar 18, 2008 at 2:29 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote: Grant, Yes, the Motion-PRO LED driver has been reworked and posted: http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-proid=16617 Okay, I've taken another look at the driver and I've figured out what has been bothering me about it. It seems to me that the motion pro led driver is just the first of many that we will see (seeing as some many people find the blinking lights rather soothing) and it's a non trivial amount of code. (Note: I'm not actually opposed to this driver if Richard is okay with it; but I do think that in the long term we should move towards a more generic approach) In essence, this driver sets up two GPIO pins to drive LEDs. A pretty common approach for putting LEDs on a board. In this case each GPIO bank only contains 1 pin; but I imagine that on other boards there will be multiple pins in a GPIO bank, only some of which actually used for blinking LEDs. I've started thinking that it would be better to split things up in the device tree to have one node for each GPIO block and a single LED node that maps LEDs to gpio pins. That would allow a common driver to be written for all GPIO driven LEDs with a single block of device tree parsing code. Plus, it allows other devices to use GPIO pins within the same block (not an issue for the motion pro board; but when other boards start coming on-line it would allow us to reduce the amount of board specific code). Finally, it means that the timer pin GPIO driver can be used for more than just flashing an attached LED. I don't mind having a specific driver but I don't know anything about the hardware its creating the interface for so I need the community's help with that part. There is drivers/leds/leds-gpio.c if that would work better. Regards, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: simple MPC5200B system
Grant Likely schrieb: On Tue, Mar 18, 2008 at 9:14 AM, Andre Schwarz [EMAIL PROTECTED] wrote: I've read some discussions about the interrupt-map attribute of the pci node. I tried to follow Ben and David in their explanations - obviously I didn't really get it. Looks like there are a lot of people outside who need some enlightenment ... including me, of course. Maybe you can clarify this ? Taken from motionpro.dts ... First, you also need to look at interrupt-map-mask to interpret these values; from motionpro.dts: interrupt-map-mask = f800 0 0 7; which is applied to the unit interrupt specifier to figure out how to map onto the interrupt controller. The /size/ of this field is obtained by adding #address-cells with #interrupt-cells. (3+1=4). 'f8' refers to the upper 5 bits of the interrupt identifier which is a number from 0-31 which relates to the IDSEL line as you guessed. The '7' covers the lower 3 bits of the interrupt specifier which can be 1, 2, 3 or 4. The 120 bits in the middle are irrelevant, so interrupt-map-mask leaves them as zeros. ok. 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; First parameter seems to be the slot number, i.e. IDSEL line of the PCI device. How is this value coded ? Are these the bits 15..11 of the configuration address ? I don't remember how this is encoded. On the lite5200, idsel is wired to d0 and d1 for slots 1 and 2 respectively, yet these values suggest slots 24 and 25. I'll need to look at this again later. pci info from u-boot shows both devices (e1000 NIC + FPGA) 00 0a 4d56 1000 ff00 03- bus 0 , slot 0a, irq 3 00 0b 8086 1078 0200 02 - bus 0 , slot 0b, irq 2 IDSEL mapping of MPC5200 is 0b0_1011 for slot 0xb and 0b0_1010 for slot 0xa. Using those 5 bits = 3 for the first cell gives 5800 and 5000 2nd + 3rd paramter : no clue ! can you explain ? first 3 cells are the unit address and is #address-cells large. Only the first cell contains real data. ok. 4th : seem to be INT_A ... _D of a PCI device. Usually a device uses only INT_A. Do we need 4 entries in any case ? you only need entries for irq lines that are wired up. If your board does not wire up _B, _C and _D, then don't have an entry for them. However, if they are wired up then you should describe them. ok. I only have INT_A. 5th : ok - parent pic Correct. 6th ... 8th : IRQ representation of the parent pic, which gives : 6th : 0=CRIT for irq0 pin, 1=MAIN for irq1..3 pins 7th : irq number. 1 for the irq0 pin inside CRIT level. irq1..3 have number 1..3 inside MAIN level. 8th : should be 3 = level low which is default for PCI. Correct. There is also some good information here: http://playground.sun.com/1275/practice/imap/imap0_9d.pdf Cheers, g. using the following interrupt-map give me two working PCI devices with working interrupts ... :-) interrupt-map = 5800 0 0 1 mpc5200_pic 1 2 3 // e1000 5000 0 0 1 mpc5200_pic 1 3 3;// FPGA Thanks for your explanations ! regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull linux-2.6-mpc52xx.git
On Tue, Mar 18, 2008 at 10:41 AM, Richard Purdie [EMAIL PROTECTED] wrote: On Tue, 2008-03-18 at 08:47 -0600, Grant Likely wrote: I don't mind having a specific driver but I don't know anything about the hardware its creating the interface for so I need the community's help with that part. There is drivers/leds/leds-gpio.c if that would work better. Yes, I think that would be the right approach. We would need to add the binding code to translate from the OF device tree to the leds-gpio driver. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] 8xx: Add support for the MPC852 based board from keymile.
Wolfgang Denk wrote: Dear Scott, in message [EMAIL PROTECTED] you wrote: Well, the device tree is a mechanism for communicating from the firmware to the kernel, and if we could control the firmware better we'd just make it set the pins properly to begin with. :-) Is this just a comment, or do you oppose Heiko's suggestion? It was intended more as a gentle nudge to set up the pins in firmware when not constrained by existing firmwares in the field that must be supported. Other uses of the device tree seem possible and reasonable, too. For example, we can use the device tree to configure the firmware (U-Boot in this case). Using the device tree to describe the pin configuration of the hardware sounds easier to me than hard-coding it in some source (or header) file - no matter if this is in the kernel and/or in the firmware. What do you think? I'm fine with putting it in the device tree for firmware's benefit, though I'm not sure I fully agree with the easier bit until we get support for expressions and named constants in dts, so that the flags would be less opaque. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Make 83xx perfmon support selectable
On Fri, Mar 07, 2008 at 05:59:03PM -0600, Andy Fleming wrote: Not all e300 cores support the performance monitors, and the ones that don't will be confused by the mf/mtpmr instructions. This allows the support to be optional, so the 8349 can turn it off while the 8379 can turn it on. Sadly, those aren't config options, so it will be left to the defconfigs and the users to make that determination. So does this mean we can't do multiplatform of something with perfmon and something without perfmon? Seems like this should come from the device tree, or PVR, or some other runtime check. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely [EMAIL PROTECTED]
This target produces a flat binary rather than an ELF file,
fixes the entry point at the beginning of the image, and takes
a complete device tree with no fixups needed.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
This has been tested on a Xilinx Virtex 4 target with the image loaded into
RAM via JTAG.
arch/powerpc/boot/Makefile |9 +++-
arch/powerpc/boot/simpleboot.c | 84
arch/powerpc/boot/virtex405-head.S | 30 +
arch/powerpc/boot/wrapper |4 ++
4 files changed, 126 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 4974d9e..f6605fe 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,7 @@ $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
+$(obj)/virtex405-head.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
@@ -64,7 +65,7 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c
+ cuboot-warp.c cuboot-85xx-cpm2.c simpleboot.c virtex405-head.S
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -305,6 +306,12 @@ $(obj)/uImage: vmlinux $(wrapperbits)
$(obj)/cuImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,$(dtstree)/$*.dts)
+$(obj)/simpleImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call
if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
+
+$(obj)/simpleImage.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
+ $(call if_changed,wrap,simpleboot-$*,$(dtstree)/$*.dts)
+
$(obj)/treeImage.initrd.%: vmlinux $(dtstree)/%.dts $(wrapperbits)
$(call
if_changed,wrap,treeboot-$*,$(dtstree)/$*.dts,,$(obj)/ramdisk.image.gz)
diff --git a/arch/powerpc/boot/simpleboot.c b/arch/powerpc/boot/simpleboot.c
new file mode 100644
index 000..86cd285
--- /dev/null
+++ b/arch/powerpc/boot/simpleboot.c
@@ -0,0 +1,84 @@
+/*
+ * The simple platform -- for booting when firmware doesn't supply a device
+ *tree or any platform configuration information.
+ *All data is extracted from an embedded device tree
+ *blob.
+ *
+ * Authors: Scott Wood [EMAIL PROTECTED]
+ * Grant Likely [EMAIL PROTECTED]
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008 Secret Lab Technologies Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include types.h
+#include io.h
+#include stdio.h
+#include libfdt/libfdt.h
+
+BSS_STACK(4*1024);
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ const u32 *na, *ns, *reg, *timebase;
+ u64 memsize64;
+ int node, size, i;
+
+ /* Make sure FDT blob is sane */
+ if (fdt_check_header(_dtb_start) != 0)
+ fatal(Invalid device tree blob\n);
+
+ /* Find the #address-cells and #size-cells properties */
+ node = fdt_path_offset(_dtb_start, /);
+ if (node 0)
+ fatal(Cannot find root node\n);
+ na = fdt_getprop(_dtb_start, node, #address-cells, size);
+ if (!na || (size != 4))
+ fatal(Cannot find #address-cells property);
+ ns = fdt_getprop(_dtb_start, node, #size-cells, size);
+ if (!ns || (size != 4))
+ fatal(Cannot find #size-cells property);
+
+ /* Find the memory range */
+ node = fdt_node_offset_by_prop_value(_dtb_start, -1, device_type,
+memory, sizeof(memory));
+ if (node 0)
+ fatal(Cannot find memory node\n);
+ reg = fdt_getprop(_dtb_start, node, reg, size);
+ if (size (*na+*ns) * sizeof(u32))
+ fatal(cannot get memory range\n);
+
+ /* Only interested in memory based at 0 */
+ for (i = 0; i *na; i++)
+ if (*reg++ != 0)
+ fatal(Memory range is not based at address 0\n);
+
+ /* get the memsize and trucate it to under 4G on 32 bit machines */
+ memsize64 = 0;
+ for (i = 0; i *ns; i++)
+ memsize64 = (memsize64 32) | *reg++;
+ if (sizeof(void *) == 4 memsize64 = 0x1ULL)
+ memsize64 = 0x;
+
+ /* finally, setup
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for QE
+ GTMs).
+ - reg : should contain gtm registers location and length (0x40).
+ - interrupts : should contain four interrupts.
+ - interrupt-parent : interrupt source phandle.
interrupt-parent isn't required; it's perfectly valid to specify that in the
parent node instead.
+Example:
+
+[EMAIL PROTECTED] {
+ compatible = fsl,gtm;
+ reg = 0x500 0x40;
+ interrupts = 90 8 78 8 84 8 72 8;
+ interrupt-parent = ipic;
+};
+
+[EMAIL PROTECTED] {
+ compatible = fsl,qe-gtm, fsl,gtm;
+ reg = 0x440 0x40;
+ interrupts = 12 13 14 15;
+ interrupt-parent = qeic;
+};
timer would be a better node name than gtm.
+static int __init gtm_init_gtm(void)
Name seems rather redundant... what's wrong with gtm_init()?
+/*
+ * For now we just fixing up the clock -- it's brg-frequency for QE
+ * chips, generic code does not and should not know these details.
+ *
+ * Later we might want to set up BRGs, when QE will actually use
+ * them (there are TIMERCS bits in the CMXGCR register, but today
+ * these bits seem to be no-ops.
+ */
+static int __init qe_init_gtm(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, fsl,qe-gtm) {
+ struct gtm *gtm = np-data;
+
+ if (!gtm) {
+ /* fsl,qe-gtm without fsl,gtm compatible? */
+ WARN_ON(1);
+ continue;
+ }
+
+ gtm-clock = qe_get_brg_clk();
+ }
+
+ return 0;
+}
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(), then np-data will not be set.
If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
do we need qe_init_gtm() at all?
+/**
+ * gtm_get_timer - request GTM timer for use with the rest of GTM API
+ * @width: timer width (only 16 bits wide timers implemented so far)
+ *
+ * This function reserves GTM timer for later use. It returns gtm_timer
+ * structure to use with the rest of GTM API, you should use timer-irq
+ * to manage timer interrupt.
+ */
+extern struct gtm_timer *gtm_get_timer(int width);
To support using the GTM as a wakeup from deep sleep on 831x (which I've had
a patch pending for quite a while now), we'll need some way of reserving a
specific timer (only GTM1, timer 4 is supported).
+/**
+ * gtm_put_timer - release GTM timer
+ * @width: timer width (only 16 bits wide timers implemented so far)
+ *
+ * This function releases GTM timer sp others might request it.
+ */
+extern void gtm_put_timer(struct gtm_timer *tmr);
+
+/**
+ * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference mode
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ * @hz: timer rate in Hz
+ * @ref: refernce value
How about period or expiry? And it'd be better to let the caller
request a time in some real unit (e.g. microseconds), and let the gtm driver
figure out how to divide that between prescaler and reference value,
especially in the absence of a way to ask for the allowable hz ranges.
+ * @ffr: free run flag
Could we call it something more intuitive such as freerun?
+ * Thus function (re)sets GTM timer so it counts up to the reference value
and
+ * fires the interrupt when the value is reached. If ffr flag is set, timer
+ * will also reset itself upon reference value, otherwise it continues to
+ * increment.
+ */
+extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
+ u16 ref, bool ffr);
+
+/**
+ * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ *
+ * Thus function used to acknowledge timer interrupt event, use it inside the
+ * interrupt handler.
+ */
+static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
What does the ref mean in these names?
How about gtm_arm_timer16 and gtm_ack_timer16?
+{
+ out_be16(tmr-gtevr, 0x);
+}
You need to include asm/io.h for this.
Don't blindly clear all events, just the events that have been acted upon.
Either take the events as an argument, or make the ack function specific to
REF, and only set that bit.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] [POWERPC] qe_lib: implement qe_muram_offset
On Tue, Mar 11, 2008 at 08:24:13PM +0300, Anton Vorontsov wrote: qe_muram_offset is the reverse of the qe_muram_addr, will be used for the Freescale QE USB Host Controller driver. This patch also moves qe_muram_addr into the qe.h header, plus adds __iomem hints to use with sparse. We should really switch QE over to using the muram code in cpm_common.c... -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tue, Mar 18, 2008 at 12:43:29PM -0500, Scott Wood wrote:
On Tue, Mar 11, 2008 at 08:24:29PM +0300, Anton Vorontsov wrote:
+Required properties:
+ - compatible : should be fsl,gtm (fsl,qe-gtm in addition for QE
+ GTMs).
+ - reg : should contain gtm registers location and length (0x40).
+ - interrupts : should contain four interrupts.
+ - interrupt-parent : interrupt source phandle.
interrupt-parent isn't required; it's perfectly valid to specify that in the
parent node instead.
Ok
+Example:
+
+[EMAIL PROTECTED] {
+ compatible = fsl,gtm;
+ reg = 0x500 0x40;
+ interrupts = 90 8 78 8 84 8 72 8;
+ interrupt-parent = ipic;
+};
+
+[EMAIL PROTECTED] {
+ compatible = fsl,qe-gtm, fsl,gtm;
+ reg = 0x440 0x40;
+ interrupts = 12 13 14 15;
+ interrupt-parent = qeic;
+};
timer would be a better node name than gtm.
Ok
+static int __init gtm_init_gtm(void)
Name seems rather redundant... what's wrong with gtm_init()?
Probably :%s/// effect. Will fix.
+/*
+ * For now we just fixing up the clock -- it's brg-frequency for QE
+ * chips, generic code does not and should not know these details.
+ *
+ * Later we might want to set up BRGs, when QE will actually use
+ * them (there are TIMERCS bits in the CMXGCR register, but today
+ * these bits seem to be no-ops.
+ */
+static int __init qe_init_gtm(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, fsl,qe-gtm) {
+ struct gtm *gtm = np-data;
+
+ if (!gtm) {
+ /* fsl,qe-gtm without fsl,gtm compatible? */
+ WARN_ON(1);
+ continue;
+ }
+
+ gtm-clock = qe_get_brg_clk();
+ }
+
+ return 0;
+}
+arch_initcall(qe_init_gtm);
If this happens before the gtm_init_gtm(),
If isn't possible, order is guaranteed.
then np-data will not be set.
It's a bug in the device tree or in the Linux code then.
If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in
gtm_get_clock(), if there's no clock-frequency -- and if there is, then why
do we need qe_init_gtm() at all?
Because for the QE clock-frequency != brg-frequency.
+/**
+ * gtm_get_timer - request GTM timer for use with the rest of GTM API
+ * @width: timer width (only 16 bits wide timers implemented so far)
+ *
+ * This function reserves GTM timer for later use. It returns gtm_timer
+ * structure to use with the rest of GTM API, you should use timer-irq
+ * to manage timer interrupt.
+ */
+extern struct gtm_timer *gtm_get_timer(int width);
To support using the GTM as a wakeup from deep sleep on 831x (which I've had
a patch pending for quite a while now), we'll need some way of reserving a
specific timer (only GTM1, timer 4 is supported).
You can add reserve function either in the PM driver (if any), or
you can do something in the device tree (wakeup-timer = ..). I don't
see any problems if you want to implement it.
+/**
+ * gtm_put_timer - release GTM timer
+ * @width: timer width (only 16 bits wide timers implemented so far)
+ *
+ * This function releases GTM timer sp others might request it.
+ */
+extern void gtm_put_timer(struct gtm_timer *tmr);
+
+/**
+ * gtm_reset_ref_timer_16 - (re)set single (16 bits) timer in reference
mode
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ * @hz:timer rate in Hz
+ * @ref: refernce value
How about period or expiry? And it'd be better to let the caller
request a time in some real unit (e.g. microseconds), and let the gtm driver
figure out how to divide that between prescaler and reference value,
especially in the absence of a way to ask for the allowable hz ranges.
Will think about it.
+ * @ffr: free run flag
Could we call it something more intuitive such as freerun?
Easy.
+ * Thus function (re)sets GTM timer so it counts up to the reference value
and
+ * fires the interrupt when the value is reached. If ffr flag is set, timer
+ * will also reset itself upon reference value, otherwise it continues to
+ * increment.
+ */
+extern int gtm_reset_ref_timer_16(struct gtm_timer *tmr, unsigned int hz,
+ u16 ref, bool ffr);
+
+/**
+ * gtm_ack_ref_timer_16 - acknowledge timer event (free-run timers only)
+ * @tmr: pointer to the gtm_timer structure obtained from gtm_get_timer
+ *
+ * Thus function used to acknowledge timer interrupt event, use it inside
the
+ * interrupt handler.
+ */
+static inline void gtm_ack_ref_timer_16(struct gtm_timer *tmr)
What does the ref mean in these names?
How about gtm_arm_timer16 and gtm_ack_timer16?
Ok.
+{
+ out_be16(tmr-gtevr, 0x);
+}
You need to include asm/io.h for this.
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
Anton Vorontsov wrote: +arch_initcall(qe_init_gtm); If this happens before the gtm_init_gtm(), If isn't possible, order is guaranteed. You use arch_initcall for both, so you're relying on link order. I think this at least merits a comment. then np-data will not be set. It's a bug in the device tree or in the Linux code then. Hmm? It's set by gtm_init_gtm(). If this code runs before gtm_init_gtm(), what are you expecting to initialize np-data? If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in gtm_get_clock(), if there's no clock-frequency -- and if there is, then why do we need qe_init_gtm() at all? Because for the QE clock-frequency != brg-frequency. Sorry, I missed that you were getting clock-frequency from the parent, rather than the gtm node. If you do the latter, then you can just stick the relevant frequency in the gtm node and not worry about where it comes from. This would be analogous to how UART clocks are specified. Also, what if some arch_initcall runs between gtm_init_gtm and qe_init_gtm, that registers itself as a client of the gtm driver, and uses the wrong clock value? +extern struct gtm_timer *gtm_get_timer(int width); To support using the GTM as a wakeup from deep sleep on 831x (which I've had a patch pending for quite a while now), we'll need some way of reserving a specific timer (only GTM1, timer 4 is supported). You can add reserve function either in the PM driver (if any), or What I meant was that there needs to be some way of telling this driver not to hand the reserved timer out to some other client. you can do something in the device tree (wakeup-timer = ..). I don't see any problems if you want to implement it. How about simply having optional arguments to gtm_get_timer() to specify the GTM device and timer number, which will fail if it's already in use? Then, the PM driver simply needs to run early enough to grab the timer it needs. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote: Anton Vorontsov wrote: +arch_initcall(qe_init_gtm); If this happens before the gtm_init_gtm(), If isn't possible, order is guaranteed. You use arch_initcall for both, so you're relying on link order. I think this at least merits a comment. then np-data will not be set. It's a bug in the device tree or in the Linux code then. Hmm? It's set by gtm_init_gtm(). If this code runs before gtm_init_gtm(), what are you expecting to initialize np-data? What code exactly? If this happens after gtm_init_gtm(), then gtm_init_gtm() will fail in gtm_get_clock(), if there's no clock-frequency -- and if there is, then why do we need qe_init_gtm() at all? Because for the QE clock-frequency != brg-frequency. Sorry, I missed that you were getting clock-frequency from the parent, rather than the gtm node. If you do the latter, then you can just stick the relevant frequency in the gtm node and not worry about where it comes from. This would be analogous to how UART clocks are specified. Ok. Also, what if some arch_initcall runs between gtm_init_gtm and qe_init_gtm, that registers itself as a client of the gtm driver, and uses the wrong clock value? Again, what code exactly? If it is a driver (for what this API is created for), it hardly will run earlier than arch/ code. If this is platform code (arch/powerpc/platform/), then it is hardly will run earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem? Since I'll implement clock-frequency inside the timer node, this isn't relevant anymore... +extern struct gtm_timer *gtm_get_timer(int width); To support using the GTM as a wakeup from deep sleep on 831x (which I've had a patch pending for quite a while now), we'll need some way of reserving a specific timer (only GTM1, timer 4 is supported). You can add reserve function either in the PM driver (if any), or What I meant was that there needs to be some way of telling this driver not to hand the reserved timer out to some other client. you can do something in the device tree (wakeup-timer = ..). I don't see any problems if you want to implement it. How about simply having optional arguments to gtm_get_timer() to specify the GTM device and timer number, which will fail if it's already in use? Then, the PM driver simply needs to run early enough to grab the timer it needs. Ah. You need specific timer. No problem. I don't like idea of new arguments to the gtm_get_timer() function (complicates things), but we can just implement another one. gtm_get_timer_name, choice the name please. _specific, _2, _for, __gtm_get_timer, ... -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Force 4K pages for IO addresses.
On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote: Benjamin Herrenschmidt wrote: On Mon, 2008-03-17 at 19:34 -0500, Olof Johansson wrote: On Mon, Mar 17, 2008 at 02:54:19PM +1100, Tony Breeds wrote: Currently HEA requires 4K pages for IO resources. Just set the pages size to IO to 4K. Well, that's too bad. Why penalize all platforms for it? I.e.: Nack, we use 64K iopages on pa6t and it works well. No need to waste tlb and erat space. We would have to make that pSeries specific for now I suppose... We don't have a way to know that there can be an EHEA right ? It may not be in the device-tree at boot and dynamically added to the partition... The ibm,drc-names property of the root node should have HEA strings in it on systems where EHEA can potentially be present. Ah good, I didn't know. That will force us to stick an ugly wart somewhere to test it though, maybe we can just force mmu_ci_restrictions to 1 ? Paul what do you think ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
Anton Vorontsov wrote: On Tue, Mar 18, 2008 at 02:55:14PM -0500, Scott Wood wrote: Anton Vorontsov wrote: +arch_initcall(qe_init_gtm); If this happens before the gtm_init_gtm(), If isn't possible, order is guaranteed. You use arch_initcall for both, so you're relying on link order. I think this at least merits a comment. then np-data will not be set. It's a bug in the device tree or in the Linux code then. Hmm? It's set by gtm_init_gtm(). If this code runs before gtm_init_gtm(), what are you expecting to initialize np-data? What code exactly? Sorry, this code == qe_init_gtm(). Obviously, if you assume that gtm_init_gtm() will always be linked earlier, then it's not an issue. Also, what if some arch_initcall runs between gtm_init_gtm and qe_init_gtm, that registers itself as a client of the gtm driver, and uses the wrong clock value? Again, what code exactly? If it is a driver (for what this API is created for), it hardly will run earlier than arch/ code. If this is platform code (arch/powerpc/platform/), then it is hardly will run earlier than arch/sysdev/. Inside the arch/sysdev/ fsl_gtm.c is guaranteed to run earlier than qe_lib/gtm.c. So, where is the problem? That's a lot of implicit, undocumented dependency on link order... Things can be moved around, and driver-ish code can pop up in surprising places. All I meant was that having the gtm driver present itself as ready when it isn't, in a way which isn't readily apparent if it happens, is worrysome. Since I'll implement clock-frequency inside the timer node, this isn't relevant anymore... OK, good. Ah. You need specific timer. No problem. I don't like idea of new arguments to the gtm_get_timer() function (complicates things), but we can just implement another one. gtm_get_timer_name, choice the name please. _specific, _2, _for, __gtm_get_timer, ... How about: struct gtm_timer *gtm_get_specific_timer(struct gtm *gtm, int timer, int width); ...with np-data used by the caller to figure out which gtm pointer to pass in. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] Force 4K pages for IO addresses.
On Wed, Mar 19, 2008 at 07:31:25AM +1100, Benjamin Herrenschmidt wrote: On Tue, 2008-03-18 at 09:45 -0500, Nathan Lynch wrote: The ibm,drc-names property of the root node should have HEA strings in it on systems where EHEA can potentially be present. Ah good, I didn't know. That will force us to stick an ugly wart somewhere to test it though, maybe we can just force mmu_ci_restrictions to 1 ? Paul what do you think ? That's not enough, mmu_io_psize also needs to be 4K. I'll poke at doing something platform specific today. Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
+ L2C0: [EMAIL PROTECTED] {
+ compatible = ibm,l2-cache-440gx, ibm,l2-cache;
+ dcr-reg = 20 8 /* Internal SRAM DCR's */
+ 30 8;/* L2 cache DCR's */
The unit address is based on the _first_ entry in reg. No2 this
is dcr-reg, but you don't really want to be more incompatible than
necessary...
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] Add L2 cache node to AMCC Taishan dts file
On Tue, Mar 18, 2008 at 02:37:46PM +0100, Stefan Roese wrote:
This patch adds the L2 cache node to the Taishan 440GX dts file.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
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: [EMAIL PROTECTED] {
A node with no reg property shouldn't have a unit address.
+ 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 = 4; /* L2, 256K */
+ interrupt-parent = UIC2;
+ interrupts = 17 1;
+ };
Now.. usually cache nodes are given as descendents of the CPU node.
In this case you have the DCR control registers though, so I guess
this is representing a control interface rather than the cache
itself. Hrm.. not really sure how to do this.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer [EMAIL PROTECTED] wrote: In the future, this will be used to provide similar configuration for PowerPC and Microblaze. It may also be convenient for those using Xilinx cores as peripherals for external processors, rather than explicitly having a dependance on the processor architecture. Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED] --- Grant, This is the patch, updated for all of the drivers that I think are in the tree. I think the problematic parts may be the ppc part, which is required for backward compatibility. If this has to wait until ppc dies, then that's fine with me, I guess. It may also be better to clean up the Kconfig lines for Sysace and framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS. My understanding is that those config options are there because of people using external PPCs with those devices in the FPGA. Hey Steve; I haven't forgotten about this patch, but I've been thinking about it some more and I'm coming to the conclusion that it might just be better to eliminate driver dependence on XILINX_DRIVERS and XILINX_VIRTEX entirely and instead just make each of them depends on PPC32 || MICROBLAZE. There's no reason to restrict compiling these drivers to platforms that are known to have xilinx parts on them. I know that in most cases they will not be used, but by relaxing the dependencies they will get compile tested on more platforms than they are now and they'll get picked up for make allyesconfigs builds. In my mind this means greater chances of compile bugs getting found and reported. In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency too; but I think the drivers are using io primitives at the moment that are not portable to x86. Thoughts? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could be a more broadly configurable option, with some of these ideas in mind. Currently, it's hidden by default, but we could easily change this to be visible by default, or selected by a broader number of architectures. I tend to think about them as a group: What if x86 *did* support the primitives needed by these drivers, then if the individual drivers depend on XILINX_DRIVERS, then the modification could be made in one spot. By your suggestion, we would have to modify each one independantly. I do dislike the hodgepodge of different configuration dependencies (such as Sysace)... It makes sense to me to have them be uniformly available. If they are all going to be PPC32 || microblaze, then it seems to me like there should be an intermediate configuration option that expresses exactly that set. Would you feel differently if we flipped the dependencies around, like XILINX_DRIVERS depends on PPC32 || MICROBLAZE? Steve -Original Message- From: [EMAIL PROTECTED] on behalf of Grant Likely Sent: Tue 3/18/2008 9:15 PM To: Stephen Neuendorffer Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Subject: Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers. On Tue, Feb 12, 2008 at 3:31 PM, Stephen Neuendorffer [EMAIL PROTECTED] wrote: In the future, this will be used to provide similar configuration for PowerPC and Microblaze. It may also be convenient for those using Xilinx cores as peripherals for external processors, rather than explicitly having a dependance on the processor architecture. Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED] --- Grant, This is the patch, updated for all of the drivers that I think are in the tree. I think the problematic parts may be the ppc part, which is required for backward compatibility. If this has to wait until ppc dies, then that's fine with me, I guess. It may also be better to clean up the Kconfig lines for Sysace and framebuffer drivers by having PPC32 or PPC4xx select XILINX_DRIVERS. My understanding is that those config options are there because of people using external PPCs with those devices in the FPGA. Hey Steve; I haven't forgotten about this patch, but I've been thinking about it some more and I'm coming to the conclusion that it might just be better to eliminate driver dependence on XILINX_DRIVERS and XILINX_VIRTEX entirely and instead just make each of them depends on PPC32 || MICROBLAZE. There's no reason to restrict compiling these drivers to platforms that are known to have xilinx parts on them. I know that in most cases they will not be used, but by relaxing the dependencies they will get compile tested on more platforms than they are now and they'll get picked up for make allyesconfigs builds. In my mind this means greater chances of compile bugs getting found and reported. In fact, it would be nice to drop the PPC32 || MICROBLAZE dependency too; but I think the drivers are using io primitives at the moment that are not portable to x86. Thoughts? Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Xilinx: Add generic configuration option to enable all xilinx drivers.
On Tue, Mar 18, 2008 at 10:32 PM, Stephen Neuendorffer [EMAIL PROTECTED] wrote: Hmm... interesting points. I guess my feeling was that XILINX_DRIVERS could be a more broadly configurable option, with some of these ideas in mind. Currently, it's hidden by default, but we could easily change this to be visible by default, or selected by a broader number of architectures. I tend to think about them as a group: What if x86 *did* support the primitives needed by these drivers, then if the individual drivers depend on XILINX_DRIVERS, then the modification could be made in one spot. By your suggestion, we would have to modify each one independantly. Heh; it's not *that* many drivers and it's just Kconfig stuff which is real easy to change. My preference would be to eliminate XILINX_DRIVERS entirely, but I'm not going to fight about it. :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG]2.6.25-rc6:Unable to handle kernel paging request
Sudhir Kumar writes: Unable to handle kernel paging request for data at address 0xd82e Looks like some driver tried to access I/O port 0x2e without checking whether there was possibly anything there first. Faulting instruction address: 0xc074ded8 cpu 0x0: Vector: 300 (Data Access) at [c0003e073aa0] pc: c074ded8: .f71805f_find+0x44/0x32c lr: c074e1f8: .f71805f_init+0x38/0x194 sp: c0003e073d20 msr: 80009032 dar: d82e dsisr: 4200 current = 0xc000220851c0 paca= 0xc07c2700 pid = 1, comm = swapper enter ? for help [c0003e073dc0] c074e1f8 .f71805f_init+0x38/0x194 Looks like it might be the f71805f driver, whatever that is... Hmmm, drivers/hwmon/f71805f.c looks like it, and indeed it does go poking around in PCI I/O space with no checks whatever. I suggest you turn off CONFIG_SENSORS_F71805F. It doesn't help, of course, that CONFIG_HWMON defaults to y. :( Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
