Re: cell-index vs. index vs. no index in I2C device nodes
Hi Ben, On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote: On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote: As far as I am concerned, it's really up to the maintainers and users of this platform. All I am asking for is that you do not call i2c_add_numbered_adapter() on an adapter with an automatically generated number. This function must only be used for adapter's those number is well defined. If an adapter doesn't have a well-defined number then use i2c_add_adapter() (but then you can no longer declare your I2C devices as part of the platform data.) Can't we just give those things -names- instead of numbers ? Good question. These i2c adapters already have names (i2c_adapter.name), which are set by their respective drivers with more or less grace depending on the driver [1]. What we don't have though is the possibility to instantiate i2c devices by adapter name. We could certainly add a busname field to struct i2c_devinfo and implement i2c_register_board_info_by_name() if it seems to be worth the extra code and memory. I am open to the idea if it solves a problem with no other clean solution. [1] radeonfb is notoriously bad at that ;) -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 2/4] [POWERPC] 85xx: add board support for the TQM8548 modules
Kumar Gala wrote:
On Jun 5, 2008, at 3:39 PM, Wolfgang Grandegger wrote:
Kumar Gala wrote:
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
+memory {
+device_type = memory;
+reg = 0x 0x2000;
+};
is memory fixed on this board to 256M?
Ah, no, actually I have a module with 512 MB but it can be ordered with
less or more memory like the other TQM85xx modules as well. Does U-Boot
fixup this value? Is it used by Linux?
if u-boot determines the memory it will update this properly. Linux
expects this to be set to know how much mem is in the system.
if you can try setting the 2nd value to 0x0 and see if it boots that
will let me know if its safe for me to change.
It works with
memory {
device_type = memory;
reg = 0x 0x; // size filled by U-Boot
};
as well. With my previous definition Linux came up with 512 MB of memory
as well and it was already obvious, that U-Boot fills in the right size
value.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Fri, Jun 6, 2008 at 12:21 AM, Jean Delvare [EMAIL PROTECTED] wrote: Hi Ben, On Fri, 06 Jun 2008 14:16:23 +1000, Benjamin Herrenschmidt wrote: On Thu, 2008-06-05 at 09:48 +0200, Jean Delvare wrote: As far as I am concerned, it's really up to the maintainers and users of this platform. All I am asking for is that you do not call i2c_add_numbered_adapter() on an adapter with an automatically generated number. This function must only be used for adapter's those number is well defined. If an adapter doesn't have a well-defined number then use i2c_add_adapter() (but then you can no longer declare your I2C devices as part of the platform data.) Can't we just give those things -names- instead of numbers ? Good question. These i2c adapters already have names (i2c_adapter.name), which are set by their respective drivers with more or less grace depending on the driver [1]. What we don't have though is the possibility to instantiate i2c devices by adapter name. We could certainly add a busname field to struct i2c_devinfo and implement i2c_register_board_info_by_name() if it seems to be worth the extra code and memory. I am open to the idea if it solves a problem with no other clean solution. Even this isn't necessary. In arch/powerpc we don't really need to register the board info separately from the bus driver so we don't need to jump through hoops to match a board_info with an i2c bus. The device tree data structure already links the i2c devices with the bus they are on, so an OF-aware i2c bus driver will match against a node in the device tree and then use all the child nodes to register i2c devices against itself. This, of course, only applies to platform level i2c busses described in the device tree. Plugin devices like PCI cards still can create their own i2c busses in the usual way. 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: Using GPIO
Hi,
I am also trying to use Xilinx GPIO driver on my board but I encounter some
problems. I thought they will be resolved with this information but it
doesn't.
I use GPIO driver as built-in but during kernel boot but I don't see log
about it contrary to Xemac driver for instance. First I wanted to create my
gpio driver normally without using Xilinx one, with ioremap and writel/readl
but I didn't write anything in the register, I don't know why. Then I tried
to use Xilinx GPIO driver but I don't know why I don't hit xgpio_probe,
xgpio_init returns 0 so it's OK.
Do you have any idea ?
Thanks
Ludovic Desroches
arch/ppc/syslib/virtex_devices.c:
* // 0 is LEDS_4BIT, 1 is LEDS_POSITIONS, 2 is PUSH_BUTTONS_POSITION
** #define XPAR_GPIO(num) { \
**.name = xilinx_gpio, \
**.id = num, \
**.num_resources = 2, \
*That was a 2.
If anybody wants to make a patch out of those few lines of code, I couldn't
figure out how to do this with git... But I will use a more general GPIO
approach as soon as I can put my hands on our custom card.
*.resource = (struct resource[]) { \
**{ \
**.start = XPAR_GPIO_##num##_BASEADDR, \
**.end = XPAR_GPIO_##num##_HIGHADDR, \
**.flags = IORESOURCE_MEM, \
**}, \
**{ \
**.start = XPAR_INTC_0_GPIO_##num##_VEC_ID, \
**.flags = IORESOURCE_IRQ, \
**}, \
**}, \
** }
** [...]
** /* GPIO instances */
** #if defined(XPAR_GPIO_0_BASEADDR)
** XPAR_GPIO(0),
** #endif
** #if defined(XPAR_GPIO_1_BASEADDR)
** XPAR_GPIO(1),
** #endif
** #if defined(XPAR_GPIO_2_BASEADDR)
** XPAR_GPIO(2),
** #endif
*
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3 1/4] [POWERPC] 85xx: correct vendor prefix in DTS files for TQM85xx modules
David Gibson wrote:
On Thu, Jun 05, 2008 at 07:10:22PM +0200, Wolfgang Grandegger wrote:
Like for the TQM5200, the vendor prefix tqc, is now used for all
TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
corresponding DTS files.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++--
arch/powerpc/boot/dts/tqm8541.dts |4 ++--
arch/powerpc/boot/dts/tqm8555.dts |4 ++--
arch/powerpc/boot/dts/tqm8560.dts |4 ++--
arch/powerpc/platforms/85xx/tqm85xx.c |8
5 files changed, 12 insertions(+), 12 deletions(-)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8540.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
-model = tqm,8540;
-compatible = tqm,8540, tqm,85xx;
+model = tqc,8540;
+compatible = tqc,8540, tqc,85xx;
Hrm. compatible strings with xx type wildcards in them should be
avoided. Keeping them for compatibility with existing code or trees
is fine, but given that you're changing the name anyway, you should
get rid of the 85xx reference. Either just dropping it, if it's not
actually used, or replacing with a defined name or the specific model
of the earliest board this series is compatible with.
$ grep 85xx *.dts
mpc8540ads.dts: compatible = MPC8540ADS, MPC85xxADS;
mpc8541cds.dts: compatible = MPC8541CDS, MPC85xxCDS;
mpc8544ds.dts: compatible = MPC8544DS, MPC85xxDS;
mpc8548cds.dts: compatible = MPC8548CDS, MPC85xxCDS;
mpc8555cds.dts: compatible = MPC8555CDS, MPC85xxCDS;
mpc8560ads.dts: compatible = MPC8560ADS, MPC85xxADS;
mpc8568mds.dts: compatible = MPC8568EMDS, MPC85xxMDS;
tqm8540.dts:compatible = tqc,8540, tqc,85xx;
tqm8541.dts:compatible = tqc,8541, tqc,85xx;
tqm8548-bigflash.dts: compatible = tqc,8548, tqc,85xx;
tqm8555.dts:compatible = tqc,8555, tqc,85xx;
tqm8560.dts:compatible = tqc,8560, tqc,85xx;
The 85xx wildcard seems to be used for other devices as well. It's fine
for me removing tqc,85xx. Furthermore I just realize, that the tqm
prefix is missing in the board names. The correct properties should then
look like:
model = tqc,tqm8540;
compatible = tqc,tqm8540;
Going to prepare new patches now.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26-rc5 DOA on mac g5
On Thu, 5 Jun 2008 21:55:11 -0700 Andrew Morton [EMAIL PROTECTED] wrote: Might be a platform thing, might be an ATA thing: OK, I found Hugh's fix. Please let's not release 2.6.27 with a 1000-patch bisect-breaking hole in it. From: Hugh Dickins [EMAIL PROTECTED] Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering: fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Signed-off-by: Hugh Dickins [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] Tested-by: Olaf Hering [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/libata-sff.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/ata/libata-sff.c~libata-fix-g5-sata-broken-on-rc5 drivers/ata/libata-sff.c --- a/drivers/ata/libata-sff.c~libata-fix-g5-sata-broken-on-rc5 +++ a/drivers/ata/libata-sff.c @@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_ return status; } /* Clear INTRQ latch */ - status = ata_sff_check_status(ap); + status = ap-ops-sff_check_status(ap); return status; } _ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Friday 06 June 2008, Kumar Gala wrote: On Jun 5, 2008, at 11:32 PM, Benjamin Herrenschmidt wrote: On Thu, 2008-06-05 at 22:12 +0200, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Acked-by: Kumar Gala [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Fri, 2008-06-06 at 08:21 +0200, Jean Delvare wrote: We could certainly add a busname field to struct i2c_devinfo and implement i2c_register_board_info_by_name() if it seems to be worth the extra code and memory. I am open to the idea if it solves a problem with no other clean solution. [1] radeonfb is notoriously bad at that ;) radeonfb is notoriously bad at many things :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
David Gibson wrote: On Thu, Jun 05, 2008 at 08:43:51AM -0500, Kumar Gala wrote: On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote: [snip] + timebase-frequency = 0; // from U-Boot + bus-frequency = 0;// from U-Boot + clock-frequency = 0; // from U-Boot u-boot will add this for us so no need for them. I think it's worth including them (with the comments) for documentation purposes though. Plus allowing the bootloader and bootwrapper to just replace property values without resizing or inserting is somewhat worthwhile of itself. I understand your point and while testing the new blob, I realized that the DTB image created with $ make ARCH=powerpc tqm8548.dtb does not work because work space is missing: ## Flattened Device Tree blob at 0090 Booting using the fdt blob at 0x90 Loading Device Tree to 007fe000, end 007ff8e0 ... OK WARNING: could not create /chosen FDT_ERR_NOSPACE. ERROR: /chosen node create failed - must RESET the board to recover. As I see it, I have to define DTS_FLAGS manually $ export DTS_FLAGS=-R4 -S0x3000 $ make ARCH=powerpc tqm8548.dtb to get a working blob. Is that the intended behavior? Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cntlzw
It's in the Compiler Writer's Guide with explanation; section 5-10. http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6 There are lots of clever examples in there, it's definitely recommended reading (I should make a cheat sheet of chapter 5 though so I can pin it to my wall) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Scott Wood wrote: Kevin Diggs wrote: Hi, x86 has bsf and bsr. PPC has cntlzw which I think is equivalent to bsr. Anyone know of a sneaky algorithm to do bsf? wordsize - 1 - cntlzw(x ~(x - 1)); -Scott ___ 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: arch/ppc is going away Real Soon Now
In message [EMAIL PROTECTED] Becky Bruce wrote: On Jun 5, 2008, at 3:30 PM, Scott Wood wrote: Olof Johansson wrote: On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Wolfgang Denk [EMAIL PROTECTED] -- 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] The only solution is ... a balance of power. We arm our side with exactly that much more. A balance of power -- the trickiest, most difficult, dirtiest game of them all. But the only one that preserves both sides. -- Kirk, A Private Little War, stardate 4211.8 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 0/4] [POWERPC] 85xx: Add suport for TQM8548 and some TQM85xx fixes
Hello, here is v4 of the patches adding suport for TQM8548 and fixing some TQM85xx issues. Hope that's the final patch now. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 1/4] [POWERPC] 85xx: correct vendor prefix in DTS files for TQM85xx modules
Like for the TQM5200, the vendor prefix tqc, is now used for all
TQM85xx modules from TQ-Components GmbH (http://www.tqc.de) in the
corresponding DTS files.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++--
arch/powerpc/boot/dts/tqm8541.dts |4 ++--
arch/powerpc/boot/dts/tqm8555.dts |4 ++--
arch/powerpc/boot/dts/tqm8560.dts |4 ++--
arch/powerpc/platforms/85xx/tqm85xx.c |8
5 files changed, 12 insertions(+), 12 deletions(-)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8540.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8540.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8540;
- compatible = tqm,8540, tqm,85xx;
+ model = tqc,tqm8540;
+ compatible = tqc,tqm8540;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8541.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8541.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8541.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8541;
- compatible = tqm,8541, tqm,85xx;
+ model = tqc,tqm8541;
+ compatible = tqc,tqm8541;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8555.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8555.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8555.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8555;
- compatible = tqm,8555, tqm,85xx;
+ model = tqc,tqm8555;
+ compatible = tqc,tqm8555;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
@@ -12,8 +12,8 @@
/dts-v1/;
/ {
- model = tqm,8560;
- compatible = tqm,8560, tqm,85xx;
+ model = tqc,tqm8560;
+ compatible = tqc,tqm8560;
#address-cells = 1;
#size-cells = 1;
Index: linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
===
--- linux-2.6-galak.orig/arch/powerpc/platforms/85xx/tqm85xx.c
+++ linux-2.6-galak/arch/powerpc/platforms/85xx/tqm85xx.c
@@ -165,10 +165,10 @@ static int __init tqm85xx_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if ((of_flat_dt_is_compatible(root, tqm,8540)) ||
- (of_flat_dt_is_compatible(root, tqm,8541)) ||
- (of_flat_dt_is_compatible(root, tqm,8555)) ||
- (of_flat_dt_is_compatible(root, tqm,8560)))
+ if ((of_flat_dt_is_compatible(root, tqc,tqm8540)) ||
+ (of_flat_dt_is_compatible(root, tqc,tqm8541)) ||
+ (of_flat_dt_is_compatible(root, tqc,tqm8555)) ||
+ (of_flat_dt_is_compatible(root, tqc,tqm8560)))
return 1;
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4 2/4] [POWERPC] 85xx: add board support for the TQM8548 modules
This patch adds support for the TQM8548 modules from TQ-Components
GmbH (http://www.tqc.de).
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/Makefile |1
arch/powerpc/boot/dts/tqm8548.dts | 365 +
arch/powerpc/boot/wrapper |2
arch/powerpc/configs/85xx/tqm8548_defconfig | 1094
arch/powerpc/platforms/85xx/Kconfig |8
arch/powerpc/platforms/85xx/tqm85xx.c | 15
6 files changed, 1482 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8548.dts
create mode 100644 arch/powerpc/configs/85xx/tqm8548_defconfig
Index: linux-2.6-galak/arch/powerpc/boot/Makefile
===
--- linux-2.6-galak.orig/arch/powerpc/boot/Makefile
+++ linux-2.6-galak/arch/powerpc/boot/Makefile
@@ -255,6 +255,7 @@ image-$(CONFIG_MPC85xx_DS) += cuImage.m
cuImage.mpc8572ds
image-$(CONFIG_TQM8540)+= cuImage.tqm8540
image-$(CONFIG_TQM8541)+= cuImage.tqm8541
+image-$(CONFIG_TQM8548)+= cuImage.tqm8548
image-$(CONFIG_TQM8555)+= cuImage.tqm8555
image-$(CONFIG_TQM8560)+= cuImage.tqm8560
image-$(CONFIG_SBC8548)+= cuImage.sbc8548
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548.dts
@@ -0,0 +1,365 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqc,tqm8548;
+ compatible = tqc,tqm8548;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x; // Filled in by U-Boot
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xe000 0x10;
+ reg = 0xe000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+
[PATCH v4 3/4] [POWERPC] 85xx: support for the TQM8548 module using the big Flash
Some TQM85xx boards could be equipped with up to 1 GiB (NOR) flash
memory and therefore a modified memory map is required and setup by
the board loader. This patch adds an appropriate DTS file.
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 365 +
1 file changed, 365 insertions(+)
create mode 100644 arch/powerpc/boot/dts/tqm8548-bigflash.dts
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8548-bigflash.dts
===
--- /dev/null
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -0,0 +1,365 @@
+/*
+ * TQM8548 Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [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.
+ */
+
+/dts-v1/;
+
+/ {
+ model = tqc,tqm8548;
+ compatible = tqc,tqm8548;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ ethernet3 = enet3;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x; // Filled in by U-Boot
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xa000 0x10;
+ reg = 0xa000 0x1000; // CCSRBAR
+ bus-frequency = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-memory-controller;
+ reg = 0x2000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 18 2;
+ };
+
+ L2: [EMAIL PROTECTED] {
+ compatible = fsl,mpc8548-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x8; // L2, 512K
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 1;
+ compatible = fsl-i2c;
+ reg = 0x3100 0x100;
+ interrupts = 43 2;
+ interrupt-parent = mpic;
+ dfsrr;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+
+ phy1: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 1;
+ device_type = ethernet-phy;
+ };
+ phy2: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 2;
+ device_type = ethernet-phy;
+ };
+ phy3: [EMAIL PROTECTED] {
+ interrupt-parent = mpic;
+ interrupts = 8 1;
+ reg = 3;
+ device_type = ethernet-phy;
+ };
+
[PATCH v4 4/4] [POWERPC] 85xx: add local bus nodes for Flash and CAN to tqm8560.dts
This patch adds local bus nodes for Flash and CAN to the DTS file
of the TQM8560 module (tqm8560.dts).
Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/tqm8560.dts | 65 ++
1 file changed, 65 insertions(+)
Index: linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
===
--- linux-2.6-galak.orig/arch/powerpc/boot/dts/tqm8560.dts
+++ linux-2.6-galak/arch/powerpc/boot/dts/tqm8560.dts
@@ -2,6 +2,7 @@
* TQM 8560 Device Tree Source
*
* Copyright 2008 Freescale Semiconductor Inc.
+ * Copyright 2008 Wolfgang Grandegger [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
@@ -223,6 +224,70 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8560-localbus, fsl,pq3-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xe0005000 0x100; // BRx, ORx, etc.
+
+ ranges =
+ 0 0x0 0xfc00 0x0400 // NOR FLASH bank 1
+ 1 0x0 0xf800 0x0800 // NOR FLASH bank 0
+ 2 0x0 0xe300 0x8000 // CAN (2 x i82527)
+ ;
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 1 0x0 0x800;
+ bank-width = 4;
+ device-width = 1;
+
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x 0x0020;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 0x0020 0x0030;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x0050 0x07a0;
+ };
+ [EMAIL PROTECTED] {
+ label = env1;
+ reg = 0x07f0 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = env2;
+ reg = 0x07f4 0x0004;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ /* Note: CAN support needs be enabled in U-Boot */
+ [EMAIL PROTECTED],0 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x0 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+
+ [EMAIL PROTECTED],100 {
+ compatible = intel,82527; // Bosch CC770
+ reg = 2 0x100 0x100;
+ interrupts = 4 0;
+ interrupt-parent = mpic;
+ };
+ };
+
pci0: [EMAIL PROTECTED] {
cell-index = 0;
#interrupt-cells = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
Adrian Bunk writes: BTW: I remember Paul wanted to get PReP under arch/powerpc/ working - should this be done before the big ppc removal? I have a PReP port for arch/powerpc that works for one machine, at least. :) The key part is the residual to device-tree converter that I posted some time back with a request for people to test it on their PReP machines, but I haven't heard back from anybody. I'm going to post the patch shortly anyway. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
David Gibson wrote: Aliases aren't trivially reversible, but it shouldn't be too hard to write a helper function which will do the scan and parse you describe. How about I submit a patch adding a function called of_get_aliased_index()? -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Fri, 6 Jun 2008 14:53:47 +0300 Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 09:11:48AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Paulus, Can we just kill all of arch/ppc for .27 right now? Is anyone already working on doing this and the cleanups that will then be possible? Otherwise I'll be glad to contribute to it. :) I think we can handle it. Thanks though. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
On Jun 6, 2008, at 5:09 AM, Wolfgang Grandegger wrote: David Gibson wrote: On Thu, Jun 05, 2008 at 08:43:51AM -0500, Kumar Gala wrote: On Jun 5, 2008, at 4:05 AM, Wolfgang Grandegger wrote: [snip] + timebase-frequency = 0; // from U-Boot + bus-frequency = 0; // from U-Boot + clock-frequency = 0;// from U-Boot u-boot will add this for us so no need for them. I think it's worth including them (with the comments) for documentation purposes though. Plus allowing the bootloader and bootwrapper to just replace property values without resizing or inserting is somewhat worthwhile of itself. I understand your point and while testing the new blob, I realized that the DTB image created with $ make ARCH=powerpc tqm8548.dtb does not work because work space is missing: ## Flattened Device Tree blob at 0090 Booting using the fdt blob at 0x90 Loading Device Tree to 007fe000, end 007ff8e0 ... OK WARNING: could not create /chosen FDT_ERR_NOSPACE. ERROR: /chosen node create failed - must RESET the board to recover. As I see it, I have to define DTS_FLAGS manually $ export DTS_FLAGS=-R4 -S0x3000 $ make ARCH=powerpc tqm8548.dtb to get a working blob. Is that the intended behavior? this is normal. Andy Fleming has posted a patch to u-boot to help improve the situation. I'm not sure if WD has picked it up for 1.3.4 yet. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
On Friday 06 June 2008, Timur Tabi wrote: David Gibson wrote: Aliases aren't trivially reversible, but it shouldn't be too hard to write a helper function which will do the scan and parse you describe. How about I submit a patch adding a function called of_get_aliased_index()? Would be very welcome. :) Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] MTD support for the AMCC Taishan
On Monday 17 March 2008, Imre Kaloz wrote: Signed-off-by: Imre Kaloz [EMAIL PROTECTED] Acked-by: Stefan Roese [EMAIL PROTECTED] Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] [POWERPC] 85xx: add board support for the TQM8548 modules
In message [EMAIL PROTECTED] you wrote: As I see it, I have to define DTS_FLAGS manually $ export DTS_FLAGS=-R4 -S0x3000 $ make ARCH=powerpc tqm8548.dtb to get a working blob. Is that the intended behavior? this is normal. Andy Fleming has posted a patch to u-boot to help improve the situation. I'm not sure if WD has picked it up for 1.3.4 yet. I will. But wouldn't it make sense to allow at least for some level of compatibility with older versions of U-Boot? Adding these options as default would probably not hurt? 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] Anarchy may not be the best form of government, but it's better than no government at all. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Default flats for running dtc from kernel build
On Jun 6, 2008, at 9:33 AM, Wolfgang Denk wrote: In message [EMAIL PROTECTED] you wrote: As I see it, I have to define DTS_FLAGS manually $ export DTS_FLAGS=-R4 -S0x3000 $ make ARCH=powerpc tqm8548.dtb to get a working blob. Is that the intended behavior? this is normal. Andy Fleming has posted a patch to u-boot to help improve the situation. I'm not sure if WD has picked it up for 1.3.4 yet. I will. But wouldn't it make sense to allow at least for some level of compatibility with older versions of U-Boot? Adding these options as default would probably not hurt? Agreed. I didn't realize we could actually do this from the kernel build system. I'm sure others will have their two cents to add. But something like: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index c40fb82..52db85a 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -29,6 +29,8 @@ ifdef CONFIG_DEBUG_INFO BOOTCFLAGS += -g endif +DTS_FLAGS ?= -R4 -S 0x3000 + ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Fri, Jun 6, 2008 at 7:56 AM, Josh Boyer [EMAIL PROTECTED] wrote: On Fri, 6 Jun 2008 14:53:47 +0300 Adrian Bunk [EMAIL PROTECTED] wrote: On Thu, Jun 05, 2008 at 09:11:48AM -0600, Grant Likely wrote: On Thu, Jun 5, 2008 at 8:52 AM, Josh Boyer [EMAIL PROTECTED] wrote: This commit (patch omitted due to size) is sitting in my local tree: commit 0d7efc1e80fc262bcc507a605482c5681e3f082a Author: Josh Boyer [EMAIL PROTECTED] Date: Thu Jun 5 09:46:17 2008 -0500 ppc/4xx: Remove 4xx support from arch/ppc Remove support for PPC 403, 405, and 440 processors from arch/ppc. The arch/powerpc equivalents should be used. Boards that are not ported yet will need to be ported to arch/powerpc to have continued support. This looks like unneeded churn. Paulus, Can we just kill all of arch/ppc for .27 right now? Is anyone already working on doing this and the cleanups that will then be possible? Otherwise I'll be glad to contribute to it. :) I think we can handle it. Thanks though. BTW Paul, we agreed in your absence on IRC that you should take the honors of committing the kill arch/ppc patch and the associated top spot in LWN's top committers list... but there's a price. You may very well get mailed the bar tab from the ding-dong-arch-ppc-is-dead party at OLS this year. :-} Oh, and we're going try to create the longest acked-by chain in Linux history. 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] phylib: Don't allow core of phylib to build as a module
On Mon, Jun 2, 2008 at 5:20 PM, Scott Wood [EMAIL PROTECTED] wrote: Kumar Gala wrote: I think we'd be better off with a small stub that is always built into the kernel for phy_read/phy_write, etc or the function pointer indirection mechanism. And then instead of build failures, you'd get a silent runtime failure to apply the workaround if phylib is built as a module. Indeed; I vote for the build failure over the silent runtime failure. If a platform needs it and does not select it, then the platform is broken and it is a bug. 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] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
On Tue, Jun 3, 2008 at 3:41 PM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
It appears that this turns out to interact badly with the probing of
PPC_UDBG_16550, which is always enabled on PPC405 (and apparently
found!) even though Virtex devices don't have them.
What is the symptom?
g.
Steve
-Original Message-
From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 08, 2008 11:25 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Stephen Neuendorffer
Subject: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
ePAPR drafts propose 'simple-bus' as a generic compatibility type for
busses which cannot be probed for devices. In addition, the Xilinx
versions of these IPs seem to be proliferating. Hence, in the future
let's prefer to use the standard names. I've left the old names in
for short term backward compatibility for existing device trees.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
arch/powerpc/platforms/40x/virtex.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
index 6c72994..b1ab7b8 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -16,6 +16,7 @@
#include asm/xilinx_intc.h
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = simple-bus, },
{ .compatible = xlnx,plb-v46-1.00.a, },
{ .compatible = xlnx,plb-v46-1.02.a, },
{ .compatible = xlnx,plb-v34-1.01.a, },
--
1.5.3.4
--
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: Default flats for running dtc from kernel build
On Fri, 2008-06-06 at 09:51 -0500, Kumar Gala wrote: I will. But wouldn't it make sense to allow at least for some level of compatibility with older versions of U-Boot? Adding these options as default would probably not hurt? Agreed. I didn't realize we could actually do this from the kernel build system. I'm sure others will have their two cents to add. But something like: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index c40fb82..52db85a 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -29,6 +29,8 @@ ifdef CONFIG_DEBUG_INFO BOOTCFLAGS += -g endif +DTS_FLAGS ?= -R4 -S 0x3000 + ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif Hrm. Should we use -p extra_space instead of -S total_space? Seems someone added this DTC commit last November: commit 2b7dc8dce549ad72ad437b254bf756d7ba4c2a5a Author: Kumar Gala [EMAIL PROTECTED] Date: Wed Nov 28 10:21:12 2007 -0600 Add an option to pad the blob that is generated There are times when we need extra space in the blob and just want to have it added on w/o know the exact size to make it. The padding and min size options are mutually exclusive. Signed-off-by: Kumar Gala [EMAIL PROTECTED] A thought, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Fri, 2008-06-06 at 13:19 +0200, Wolfgang Denk wrote: In message [EMAIL PROTECTED] Becky Bruce wrote: On Jun 5, 2008, at 3:30 PM, Scott Wood wrote: Olof Johansson wrote: On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Wolfgang Denk [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 85xx: MPC8548CDS - Fix size of PCIe IO space
Andrew Klossner pointed out the IO space size was in violation of the alignment requirements for windows on the 85xx. The size should have been 1M (to match u-boot). Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc8548cds.dts |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts index fa298a8..4811b81 100644 --- a/arch/powerpc/boot/dts/mpc8548cds.dts +++ b/arch/powerpc/boot/dts/mpc8548cds.dts @@ -409,7 +409,7 @@ interrupts = 26 2; bus-range = 0 255; ranges = 0x200 0x0 0xa000 0xa000 0x0 0x2000 - 0x100 0x0 0x0 0xe300 0x0 0x800; + 0x100 0x0 0x0 0xe300 0x0 0x10; clock-frequency = ; #interrupt-cells = 1; #size-cells = 2; @@ -428,7 +428,7 @@ 0x100 0x0 0x0 0x100 0x0 0x0 - 0x0 0x800; + 0x0 0x10; }; }; }; -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 85xx: MPC85xx MDS - Unconditionally select PHYLIB for board fixups
The MPC85xx MDS board requires some board level tweaks of the PHYs that either the eTSEC (gianfar) or UCC ethernet controllers are connected to. Its possible to build the phylib as a module, however this breaks the board level fix ups because phy_read and phy_write are not available if we build as a module. So we unconditionally select PHYLIB to ensure its built into the kernel if we are building in MPC85xx MDS support. This was determined to be the easiest soultion even though it prevents the user from removing PHYLIB support if they decide they don't want it. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- will go via the powerpc.git tree for 2.6.26. - k arch/powerpc/platforms/85xx/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 7ff29d5..ecbe580 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -34,6 +34,7 @@ config MPC85xx_MDS bool Freescale MPC85xx MDS select DEFAULT_UIMAGE select QUICC_ENGINE + select PHYLIB help This option enables support for the MPC85xx MDS board -- 1.5.5.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Default flats for running dtc from kernel build
On Jun 6, 2008, at 10:31 AM, Jon Loeliger wrote: On Fri, 2008-06-06 at 09:51 -0500, Kumar Gala wrote: I will. But wouldn't it make sense to allow at least for some level of compatibility with older versions of U-Boot? Adding these options as default would probably not hurt? Agreed. I didn't realize we could actually do this from the kernel build system. I'm sure others will have their two cents to add. But something like: diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index c40fb82..52db85a 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -29,6 +29,8 @@ ifdef CONFIG_DEBUG_INFO BOOTCFLAGS += -g endif +DTS_FLAGS ?= -R4 -S 0x3000 + ifeq ($(call cc-option-yn, -fstack-protector),y) BOOTCFLAGS += -fno-stack-protector endif Hrm. Should we use -p extra_space instead of -S total_space? Seems someone added this DTC commit last November: commit 2b7dc8dce549ad72ad437b254bf756d7ba4c2a5a Author: Kumar Gala [EMAIL PROTECTED] Date: Wed Nov 28 10:21:12 2007 -0600 Add an option to pad the blob that is generated There are times when we need extra space in the blob and just want to have it added on w/o know the exact size to make it. The padding and min size options are mutually exclusive. Signed-off-by: Kumar Gala [EMAIL PROTECTED] A thought, jdl Yeah, I think the -R isn't need either. So maybe: DTS_FLAGS ?= -P 0x1000 1k seems like more than enough default padding. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Default flats for running dtc from kernel build
On Fri, Jun 6, 2008 at 9:42 AM, Kumar Gala [EMAIL PROTECTED] wrote: Yeah, I think the -R isn't need either. So maybe: DTS_FLAGS ?= -P 0x1000 1k seems like more than enough default padding. Good by me. 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: Default flats for running dtc from kernel build
On Fri, 2008-06-06 at 10:42 -0500, Kumar Gala wrote: So maybe: DTS_FLAGS ?= -P 0x1000 Lowercase p. 1k seems like more than enough default padding. I would think so. - k jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using GPIO
I think there are some more details in my notes: https://lpsc-secure.in2p3.fr/trac/akido/wiki/CrossCompile#GettingGPIOtoworkinuserspace I am also trying to use Xilinx GPIO driver on my board but I encounter some problems. I thought they will be resolved with this information but it doesn't. -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
legacy_serial identifies a valid ns16550 on a simple-bus, but the
legacy_serial driver doesn't understand the shift and offset flags
necessary to get it to work, which results in no console.
I think the easiest solution is to change the Kconfig so that
PPC_UDBG_16550 is only selected based on !XILINX_VIRTEX. I've done this
in my tree, but I've been swamped with other things at the moment, so I
haven't verified it.
Or is legacy_serial just legacy at this point and can go away entirely?
I got the impression from some of the earlier discussion that it wasn't
preferred, at least
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Friday, June 06, 2008 8:29 AM
To: Stephen Neuendorffer
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; git
Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for
'simple-bus'.
On Tue, Jun 3, 2008 at 3:41 PM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
It appears that this turns out to interact badly with the probing of
PPC_UDBG_16550, which is always enabled on PPC405 (and apparently
found!) even though Virtex devices don't have them.
What is the symptom?
g.
Steve
-Original Message-
From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 08, 2008 11:25 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linuxppc-dev@ozlabs.org
Cc: Stephen Neuendorffer
Subject: [PATCH] [POWERPC] Xilinx: add compatibility for
'simple-bus'.
ePAPR drafts propose 'simple-bus' as a generic compatibility type
for
busses which cannot be probed for devices. In addition, the Xilinx
versions of these IPs seem to be proliferating. Hence, in the
future
let's prefer to use the standard names. I've left the old names in
for short term backward compatibility for existing device trees.
Signed-off-by: Stephen Neuendorffer
[EMAIL PROTECTED]
---
arch/powerpc/platforms/40x/virtex.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
index 6c72994..b1ab7b8 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -16,6 +16,7 @@
#include asm/xilinx_intc.h
static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = simple-bus, },
{ .compatible = xlnx,plb-v46-1.00.a, },
{ .compatible = xlnx,plb-v46-1.02.a, },
{ .compatible = xlnx,plb-v34-1.01.a, },
--
1.5.3.4
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
IB/ehca: Reject send WRs only for RESET, INIT and RTR state
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_reqs.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index bbe0436..f093b00 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -421,8 +421,10 @@ int ehca_post_send(struct ib_qp *qp,
int ret = 0;
unsigned long flags;
- if (unlikely(my_qp-state != IB_QPS_RTS)) {
- ehca_err(qp-device, QP not in RTS state qpn=%x, qp-qp_num);
+ /* Reject WR if QP is in RESET, INIT or RTR state */
+ if (unlikely(my_qp-state IB_QPS_RTS)) {
+ ehca_err(qp-device, Invalid QP state qp_state=%d qpn=%x,
+my_qp-state, qp-qp_num);
return -EINVAL;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[v3] Fix definitions for dbcr0, dbcr1, dbcr2 register for bookE processors
Updates: Made names match BookeE names in BookeE spec, Added comment that DBCR0_RST* was not followed in fsl. * Did not get a chance to add missing entries for other cases with DBCR1 DBCR0 .. but if anyone would like to add them, that would be awsome! Taken from the PowerPC ISA BookIII-E specifies that DBCR0 is different for all others that are not ppc405 chips. So I have now chnaged the conditional to reflect this. Also added definitions needed for DBCR1 DBCR2. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h --- a/include/asm-powerpc/reg_booke.h +++ b/include/asm-powerpc/reg_booke.h @@ -253,6 +253,7 @@ #define ESR_BO 0x0002 /* Byte Ordering */ /* Bit definitions related to the DBCR0. */ +#if defined(CONFIG_40x) #define DBCR0_EDM 0x8000 /* External Debug Mode */ #define DBCR0_IDM 0x4000 /* Internal Debug Mode */ #define DBCR0_RST 0x3000 /* all the bits in the RST field */ @@ -275,6 +276,52 @@ #define DBCR0_IA12T0x8000 /* Instr Addr 1-2 range Toggle */ #define DBCR0_IA34T0x4000 /* Instr Addr 3-4 range Toggle */ #define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#elif defined(CONFIG_BOOKE) +#define DBCR0_EDM 0x8000 /* External Debug Mode */ +#define DBCR0_IDM 0x4000 /* Internal Debug Mode */ +/* DBCR0_RST* is 44x specific and not followed in fsl booke */ +#define DBCR0_RST 0x3000 /* all the bits in the RST field */ +#define DBCR0_RST_SYSTEM 0x3000/* System Reset */ +#define DBCR0_RST_CHIP 0x2000 /* Chip Reset */ +#define DBCR0_RST_CORE 0x1000 /* Core Reset */ +#define DBCR0_RST_NONE 0x /* No Reset */ +#define DBCR0_ICMP 0x0800 /* Instruction Completion */ +#define DBCR0_IC DBCR0_ICMP +#define DBCR0_BRT 0x0400 /* Branch Taken */ +#define DBCR0_BR DBCR0_BRT +#define DBCR0_IRPT 0x0200 /* Exception Debug Event */ +#define DBCR0_EDE DBCR0_IRPT +#define DBCR0_TDE 0x0100 /* TRAP Debug Event */ +#define DBCR0_IAC1 0x0080 /* Instr Addr compare 1 enable */ +#define DBCR0_IA1 DBCR0_IAC1 +#define DBCR0_IAC2 0x0040 /* Instr Addr compare 2 enable */ +#define DBCR0_IA2 DBCR0_IAC2 +#define DBCR0_IAC3 0x0020 /* Instr Addr compare 3 enable */ +#define DBCR0_IA3 DBCR0_IAC3 +#define DBCR0_IAC4 0x0010 /* Instr Addr compare 4 enable */ +#define DBCR0_IA4 DBCR0_IAC4 +#define DBCR0_DAC1R0x0008 /* DAC 1 Read enable */ +#define DBCR0_DAC1W0x0004 /* DAC 1 Write enable */ +#define DBCR0_DAC2R0x0002 /* DAC 2 Read enable */ +#define DBCR0_DAC2W0x0001 /* DAC 2 Write enable */ +#define DBCR0_RET 0x8000 /* Return Debug Event */ +#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#endif + +#if defined(CONFIG_BOOKE) +/* Bit definitions related to the DBCR1. */ +#define DBCR1_IAC12M 0x0080 /* Instr Addr 1-2 range enable */ +#define DBCR1_IAC12MX 0x00C0 /* Instr Addr 1-2 range eXclusive */ +#define DBCR1_IAC12AT 0x0001 /* Instr Addr 1-2 range Toggle */ +#define DBCR1_IAC34M 0x0080 /* Instr Addr 3-4 range enable */ +#define DBCR1_IAC34MX 0x00C0 /* Instr Addr 3-4 range eXclusive */ +#define DBCR1_IAC34AT 0x0001 /* Instr Addr 3-4 range Toggle */ + +/* Bit definitions related to the DBCR2. */ +#define DBCR2_DAC12M 0x0080 /* DAC 1-2 range enable */ +#define DBCR2_DAC12MX 0x00C0 /* DAC 1-2 range eXclusive */ +#define DBCR2_DAC12A 0x0020 /* DAC 1-2 Asynchronous */ +#endif /* Bit definitions related to the TCR. */ #define TCR_WP(x) (((x)0x3)30) /* WDT Period */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 85xx: MPC85xx MDS - Unconditionally select PHYLIB for board fixups
Kumar Gala wrote: The MPC85xx MDS board requires some board level tweaks of the PHYs that either the eTSEC (gianfar) or UCC ethernet controllers are connected to. Its possible to build the phylib as a module, however this breaks the board level fix ups because phy_read and phy_write are not available if we build as a module. So we unconditionally select PHYLIB to ensure its built into the kernel if we are building in MPC85xx MDS support. This was determined to be the easiest soultion even though it prevents the user from removing PHYLIB support if they decide they don't want it. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- will go via the powerpc.git tree for 2.6.26. - k arch/powerpc/platforms/85xx/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig index 7ff29d5..ecbe580 100644 --- a/arch/powerpc/platforms/85xx/Kconfig +++ b/arch/powerpc/platforms/85xx/Kconfig @@ -34,6 +34,7 @@ config MPC85xx_MDS bool Freescale MPC85xx MDS select DEFAULT_UIMAGE select QUICC_ENGINE + select PHYLIB help ACK ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx support in arch/ppc is going away Real Soon Now
On Fri, Jun 06, 2008 at 10:09:54PM +1000, Paul Mackerras wrote: Adrian Bunk writes: BTW: I remember Paul wanted to get PReP under arch/powerpc/ working - should this be done before the big ppc removal? I have a PReP port for arch/powerpc that works for one machine, at least. :) The key part is the residual to device-tree converter that I posted some time back with a request for people to test it on their PReP machines, but I haven't heard back from anybody. I'm going to post the patch shortly anyway. Meelis Roos [EMAIL PROTECTED] has a Motorola Powerstack II Pro4000 and recently reported (now fixed) 2.6.26-rc build problems with the rusty ppc code. You might have luck asking him for testing, thereby doubling the number of known-working machines. :) Paul. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IB/ehca: Reject send WRs only for RESET, INIT and RTR state
thanks, applied. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
750GX
Hi, In the 750GX data sheet (750GX_ds2-17-05.pdf), page 45 has Table 5-1 that describes the PLL range field. It goes something like this: PLL_RNGrange 00600 - 900 01900 - 1000 10500 - 600 Anyone have any thoughts as to what the correct values are for 600 and 900? I think I have this working. I was setting the range to 1 for all frequencies because I did: if(freq600) instead of if(freq60) when building my frequency table. This cpufreq stuff definitely messes up the repeatability of my bogomazes value. kevin P.S.: I'd be interested in various theories as to what this does? P.P.S.: On page 341 of the 750GX user manual It says: Turning the non selected PLL off results in a modest power savings ... Regarding what goes on in idle_6xx.S, wouldn't this likely save more power than switching to a lower frequency (to clock mostly nothing since the processor is going into doze or nap)? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[v4] Fix definitions for dbcr0, dbcr1, dbcr2 register for bookE processors
Updates: Placed everything in one conditional. Updated commit message. This takes values from the PowerPC ISA BookIII-E specifications that are for DBCR0. Many of these values are different from those currently specified, which are for the ppc405. Also added some bookE definitions for DBCR1 DBCR2. Signed-off-by: Jerone Young [EMAIL PROTECTED] diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h --- a/include/asm-powerpc/reg_booke.h +++ b/include/asm-powerpc/reg_booke.h @@ -253,6 +253,7 @@ #define ESR_BO 0x0002 /* Byte Ordering */ /* Bit definitions related to the DBCR0. */ +#if defined(CONFIG_40x) #define DBCR0_EDM 0x8000 /* External Debug Mode */ #define DBCR0_IDM 0x4000 /* Internal Debug Mode */ #define DBCR0_RST 0x3000 /* all the bits in the RST field */ @@ -275,6 +276,50 @@ #define DBCR0_IA12T0x8000 /* Instr Addr 1-2 range Toggle */ #define DBCR0_IA34T0x4000 /* Instr Addr 3-4 range Toggle */ #define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ +#elif defined(CONFIG_BOOKE) +#define DBCR0_EDM 0x8000 /* External Debug Mode */ +#define DBCR0_IDM 0x4000 /* Internal Debug Mode */ +/* DBCR0_RST* is 44x specific and not followed in fsl booke */ +#define DBCR0_RST 0x3000 /* all the bits in the RST field */ +#define DBCR0_RST_SYSTEM 0x3000/* System Reset */ +#define DBCR0_RST_CHIP 0x2000 /* Chip Reset */ +#define DBCR0_RST_CORE 0x1000 /* Core Reset */ +#define DBCR0_RST_NONE 0x /* No Reset */ +#define DBCR0_ICMP 0x0800 /* Instruction Completion */ +#define DBCR0_IC DBCR0_ICMP +#define DBCR0_BRT 0x0400 /* Branch Taken */ +#define DBCR0_BR DBCR0_BRT +#define DBCR0_IRPT 0x0200 /* Exception Debug Event */ +#define DBCR0_EDE DBCR0_IRPT +#define DBCR0_TDE 0x0100 /* TRAP Debug Event */ +#define DBCR0_IAC1 0x0080 /* Instr Addr compare 1 enable */ +#define DBCR0_IA1 DBCR0_IAC1 +#define DBCR0_IAC2 0x0040 /* Instr Addr compare 2 enable */ +#define DBCR0_IA2 DBCR0_IAC2 +#define DBCR0_IAC3 0x0020 /* Instr Addr compare 3 enable */ +#define DBCR0_IA3 DBCR0_IAC3 +#define DBCR0_IAC4 0x0010 /* Instr Addr compare 4 enable */ +#define DBCR0_IA4 DBCR0_IAC4 +#define DBCR0_DAC1R0x0008 /* DAC 1 Read enable */ +#define DBCR0_DAC1W0x0004 /* DAC 1 Write enable */ +#define DBCR0_DAC2R0x0002 /* DAC 2 Read enable */ +#define DBCR0_DAC2W0x0001 /* DAC 2 Write enable */ +#define DBCR0_RET 0x8000 /* Return Debug Event */ +#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */ + +/* Bit definitions related to the DBCR1. */ +#define DBCR1_IAC12M 0x0080 /* Instr Addr 1-2 range enable */ +#define DBCR1_IAC12MX 0x00C0 /* Instr Addr 1-2 range eXclusive */ +#define DBCR1_IAC12AT 0x0001 /* Instr Addr 1-2 range Toggle */ +#define DBCR1_IAC34M 0x0080 /* Instr Addr 3-4 range enable */ +#define DBCR1_IAC34MX 0x00C0 /* Instr Addr 3-4 range eXclusive */ +#define DBCR1_IAC34AT 0x0001 /* Instr Addr 3-4 range Toggle */ + +/* Bit definitions related to the DBCR2. */ +#define DBCR2_DAC12M 0x0080 /* DAC 1-2 range enable */ +#define DBCR2_DAC12MX 0x00C0 /* DAC 1-2 range eXclusive */ +#define DBCR2_DAC12A 0x0020 /* DAC 1-2 Asynchronous */ +#endif /* Bit definitions related to the TCR. */ #define TCR_WP(x) (((x)0x3)30) /* WDT Period */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] [POWERPC] 86xx: suspend support
This patch adds suspend (standby, not suspend-to-ram) support for MPC86xx
processors.
In standby mode MPC86xx is able to wakeup only upon external interrupts
(including sreset).
Signed-off-by: Scott Wood [EMAIL PROTECTED]
Signed-off-by: Jason Jin [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/platforms/86xx/Makefile |1 +
arch/powerpc/platforms/86xx/mpc86xx_suspend.c | 92 +
3 files changed, 94 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2cde4e3..c45c71e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -192,7 +192,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_86xx
config PPC_DCR_NATIVE
bool
diff --git a/arch/powerpc/platforms/86xx/Makefile
b/arch/powerpc/platforms/86xx/Makefile
index 1b9b4a9..a8557df 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_SMP) += mpc86xx_smp.o
+obj-$(CONFIG_SUSPEND) += mpc86xx_suspend.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
b/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
new file mode 100644
index 000..ce13e4c
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
@@ -0,0 +1,92 @@
+/*
+ * MPC86xx suspend (standby) support
+ *
+ * Copyright (C) 2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Jason Jin [EMAIL PROTECTED]
+ *
+ * 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 linux/init.h
+#include linux/types.h
+#include linux/suspend.h
+#include linux/of.h
+#include linux/io.h
+#include asm/prom.h
+#include asm/reg.h
+#include asm/mpc6xx.h
+
+#define PMCSR_DEVSLEEP 0x0002
+
+struct mpc86xx_pmc {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 reserve1;
+ __be32 reserve2;
+ __be32 powmgtcsr;
+};
+
+static struct mpc86xx_pmc __iomem *pmc_regs_86xx;
+
+static int mpc86xx_suspend_enter(suspend_state_t state)
+{
+ u32 tmp;
+
+ /* Disable power management. */
+ tmp = mfmsr();
+ mtmsr(tmp ~MSR_POW);
+
+ /* Enable sleep mode, disable others. */
+ tmp = mfspr(SPRN_HID0);
+ mtspr(SPRN_HID0, (tmp ~(HID0_DOZE | HID0_NAP)) | HID0_SLEEP);
+ asm(sync);
+
+ /* Device power down. */
+ setbits32(pmc_regs_86xx-powmgtcsr, PMCSR_DEVSLEEP);
+
+ /* 86xx did not support deep sleep, let it enter standby mode. */
+ mpc6xx_enter_standby();
+
+ clrbits32(pmc_regs_86xx-powmgtcsr, PMCSR_DEVSLEEP);
+
+ return 0;
+}
+
+static int mpc86xx_suspend_valid(suspend_state_t state)
+{
+ if (state == PM_SUSPEND_STANDBY)
+ return 1;
+ return 0;
+}
+
+static struct platform_suspend_ops mpc86xx_suspend_ops = {
+ .valid = mpc86xx_suspend_valid,
+ .enter = mpc86xx_suspend_enter,
+};
+
+static int __init mpc86xx_pmc_init(void)
+{
+ void __iomem *guts;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc8610-guts);
+ if (!np) {
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc8641-guts);
+ if (!np)
+ return -ENODEV;
+ }
+
+ guts = of_iomap(np, 0);
+ of_node_put(np);
+ if (!guts)
+ return -ENOMEM;
+
+ pmc_regs_86xx = guts + 0x70;
+
+ suspend_set_ops(mpc86xx_suspend_ops);
+ return 0;
+}
+module_init(mpc86xx_pmc_init);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support
On MPC8610HPCD there is a dedicated switch to wake up the board.
The SW9 button is routed to IRQ8, but could be re-routed (via PIXIS)
to sreset. Luckily, default is IRQ8.
With 'no_console_suspend' kernel command line argument specified, the
board is also able to wakeup upon the serial input.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |4 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 +
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 45 +++--
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 6c55f3f..8fd0500 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2896,11 +2896,15 @@ platforms are moved over to use the
flattened-device-tree model.
- compatible : should be fsl,fpga-pixis.
- reg : should contain the address and the lenght of the FPPGA register
set.
+- interrupt-parent: the phandle for the interrupt controller.
+- interrupts : should specify event IRQ.
Example (MPC8610HPCD)
[EMAIL PROTECTED] {
compatible = fsl,fpga-pixis;
reg = 0xe800 32;
+ interrupt-parent = mpic;
+ interrupts = 8 8;
};
t) Freescale MSI interrupt controller
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 8dd8350..5952aa0 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -105,6 +105,8 @@
compatible = fsl,fpga-pixis;
ranges = 0 3 0 0x20;
reg = 3 0 0x20;
+ interrupt-parent = mpic;
+ interrupts = 8 8;
sdcsr_pio: [EMAIL PROTECTED] {
#gpio-cells = 2;
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 83e8ffd..12612fa 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -24,6 +24,7 @@
#include linux/seq_file.h
#include linux/fsl_ir.h
#include linux/gpio.h
+#include linux/interrupt.h
#include linux/of.h
#include linux/of_gpio.h
@@ -43,11 +44,14 @@
#include sysdev/fsl_pci.h
#include sysdev/fsl_soc.h
+#define PX_CSR_EVES(1 2)
#define PX_BRDCFG0_DVISEL (1 3)
#define PX_BRDCFG0_DLINK (1 4)
#define PX_BRDCFG0_DIU_MASK(PX_BRDCFG0_DVISEL | PX_BRDCFG0_DLINK)
#define PX_BRDCFG0_IRDAEN (1 5)
+static struct device_node *pixis_node;
+static u8 __iomem *pixis_csr;
static u8 __iomem *pixis_bdcfg0;
static u8 __iomem *pixis_arch;
static u32 __iomem *clkdvdr;
@@ -182,6 +186,37 @@ err:
of_node_put(irda);
}
+#ifdef CONFIG_SUSPEND
+static irqreturn_t sw9_irq(int irq, void *data)
+{
+ pr_debug(%s: PIXIS' event (sw9/wakeup) IRQ handled\n, __func__);
+ return IRQ_HANDLED;
+}
+
+static void __init mpc8610_suspend_init(void)
+{
+ int irq;
+
+ if (!pixis_node)
+ return;
+
+ irq = irq_of_parse_and_map(pixis_node, 0);
+ if (irq 0 || irq == NO_IRQ) {
+ pr_err(%s: can't map pixis event IRQ.\n, __func__);
+ return;
+ }
+
+ if (request_irq(irq, sw9_irq, 0, sw9, NULL)) {
+ pr_err(%s: can't request pixis event IRQ.\n, __func__);
+ irq_dispose_mapping(irq);
+ }
+
+ enable_irq_wake(irq);
+}
+#else
+static inline void mpc8610_suspend_init(void) { }
+#endif /* CONFIG_SUSPEND */
+
static struct of_device_id __initdata mpc8610_ids[] = {
{ .compatible = fsl,mpc8610-immr, },
{ .compatible = simple-bus, },
@@ -191,6 +226,7 @@ static struct of_device_id __initdata mpc8610_ids[] = {
static int __init mpc8610_declare_of_platform_devices(void)
{
mpc8610_ir_init();
+ mpc8610_suspend_init();
/* Without this call, the SSI device driver won't get probed. */
of_platform_bus_probe(NULL, mpc8610_ids, NULL);
@@ -418,16 +454,17 @@ static void __init mpc86xx_hpcd_setup_arch(void)
return;
}
- np = of_find_compatible_node(NULL, NULL, fsl,fpga-pixis);
- if (np) {
- of_address_to_resource(np, 0, r);
- of_node_put(np);
+ pixis_node = of_find_compatible_node(NULL, NULL, fsl,fpga-pixis);
+ if (pixis_node) {
+ of_address_to_resource(pixis_node, 0, r);
+ of_node_put(pixis_node);
pixis = ioremap(r.start, 32);
if (!pixis) {
printk(KERN_ERR Err: can't map FPGA cfg register!\n);
return;
}
pixis_bdcfg0 = pixis + 8;
+ pixis_csr = pixis + 3;
pixis_arch = pixis
Re: [ofa-general] IB/ehca: Reject send WRs only for RESET, INIT and RTR state
Hi.
I checked the code in the ehca driver and noticed that
post RR to a QP is being accepted in any state (including the RESET state).
thanks
Dotan
Joachim Fenkes wrote:
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
drivers/infiniband/hw/ehca/ehca_reqs.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index bbe0436..f093b00 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -421,8 +421,10 @@ int ehca_post_send(struct ib_qp *qp,
int ret = 0;
unsigned long flags;
- if (unlikely(my_qp-state != IB_QPS_RTS)) {
- ehca_err(qp-device, QP not in RTS state qpn=%x, qp-qp_num);
+ /* Reject WR if QP is in RESET, INIT or RTR state */
+ if (unlikely(my_qp-state IB_QPS_RTS)) {
+ ehca_err(qp-device, Invalid QP state qp_state=%d qpn=%x,
+my_qp-state, qp-qp_num);
return -EINVAL;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] 86xx: suspend support
Ugh...
This should be From: Jason Jin [EMAIL PROTECTED], since
I've made only few small cleanups, the code itself is almost intact.
On Fri, Jun 06, 2008 at 11:24:43PM +0400, Anton Vorontsov wrote:
This patch adds suspend (standby, not suspend-to-ram) support for MPC86xx
processors.
In standby mode MPC86xx is able to wakeup only upon external interrupts
(including sreset).
Signed-off-by: Scott Wood [EMAIL PROTECTED]
Signed-off-by: Jason Jin [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |2 +-
arch/powerpc/platforms/86xx/Makefile |1 +
arch/powerpc/platforms/86xx/mpc86xx_suspend.c | 92
+
3 files changed, 94 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2cde4e3..c45c71e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -192,7 +192,7 @@ config ARCH_HIBERNATION_POSSIBLE
config ARCH_SUSPEND_POSSIBLE
def_bool y
- depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200
+ depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_86xx
config PPC_DCR_NATIVE
bool
diff --git a/arch/powerpc/platforms/86xx/Makefile
b/arch/powerpc/platforms/86xx/Makefile
index 1b9b4a9..a8557df 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_SMP)+= mpc86xx_smp.o
+obj-$(CONFIG_SUSPEND)+= mpc86xx_suspend.o
obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
obj-$(CONFIG_SBC8641D) += sbc8641d.o
obj-$(CONFIG_MPC8610_HPCD) += mpc8610_hpcd.o
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
b/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
new file mode 100644
index 000..ce13e4c
--- /dev/null
+++ b/arch/powerpc/platforms/86xx/mpc86xx_suspend.c
@@ -0,0 +1,92 @@
+/*
+ * MPC86xx suspend (standby) support
+ *
+ * Copyright (C) 2008 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author: Jason Jin [EMAIL PROTECTED]
+ *
+ * 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 linux/init.h
+#include linux/types.h
+#include linux/suspend.h
+#include linux/of.h
+#include linux/io.h
+#include asm/prom.h
+#include asm/reg.h
+#include asm/mpc6xx.h
+
+#define PMCSR_DEVSLEEP 0x0002
+
+struct mpc86xx_pmc {
+ __be32 devdisr;
+ __be32 devdisr2;
+ __be32 reserve1;
+ __be32 reserve2;
+ __be32 powmgtcsr;
+};
+
+static struct mpc86xx_pmc __iomem *pmc_regs_86xx;
+
+static int mpc86xx_suspend_enter(suspend_state_t state)
+{
+ u32 tmp;
+
+ /* Disable power management. */
+ tmp = mfmsr();
+ mtmsr(tmp ~MSR_POW);
+
+ /* Enable sleep mode, disable others. */
+ tmp = mfspr(SPRN_HID0);
+ mtspr(SPRN_HID0, (tmp ~(HID0_DOZE | HID0_NAP)) | HID0_SLEEP);
+ asm(sync);
+
+ /* Device power down. */
+ setbits32(pmc_regs_86xx-powmgtcsr, PMCSR_DEVSLEEP);
+
+ /* 86xx did not support deep sleep, let it enter standby mode. */
+ mpc6xx_enter_standby();
+
+ clrbits32(pmc_regs_86xx-powmgtcsr, PMCSR_DEVSLEEP);
+
+ return 0;
+}
+
+static int mpc86xx_suspend_valid(suspend_state_t state)
+{
+ if (state == PM_SUSPEND_STANDBY)
+ return 1;
+ return 0;
+}
+
+static struct platform_suspend_ops mpc86xx_suspend_ops = {
+ .valid = mpc86xx_suspend_valid,
+ .enter = mpc86xx_suspend_enter,
+};
+
+static int __init mpc86xx_pmc_init(void)
+{
+ void __iomem *guts;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc8610-guts);
+ if (!np) {
+ np = of_find_compatible_node(NULL, NULL, fsl,mpc8641-guts);
+ if (!np)
+ return -ENODEV;
+ }
+
+ guts = of_iomap(np, 0);
+ of_node_put(np);
+ if (!guts)
+ return -ENOMEM;
+
+ pmc_regs_86xx = guts + 0x70;
+
+ suspend_set_ops(mpc86xx_suspend_ops);
+ return 0;
+}
+module_init(mpc86xx_pmc_init);
--
1.5.5.1
--
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 1/2] make walk_memory_resource available with MEMORY_HOTPLUG=n
On Tue, 2008-06-03 at 17:30 -0500, Nathan Lynch wrote:
The ehea driver was recently changed[1] to use walk_memory_resource() to
detect the system's memory layout. However, walk_memory_resource() is
available only when memory hotplug is enabled. So CONFIG_EHEA was
made to depend on MEMORY_HOTPLUG [2], but it is inappropriate for a
network driver to have such a dependency.
Make the declaration of walk_memory_resource() and its powerpc
implementation (ehea is powerpc-specific) unconditionally available.
[1] 48cfb14f8b89d4d5b3df6c16f08b258686fb12ad
ehea: Add DLPAR memory remove support
[2] fb7b6ca2b6b7c23b52be143bdd5f55a23b9780c8
ehea: Add dependency to Kconfig
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/mm/mem.c |3 +--
include/linux/memory_hotplug.h | 16
2 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f67e118..51f82d8 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -151,6 +151,7 @@ out:
return ret;
}
#endif /* CONFIG_MEMORY_HOTREMOVE */
+#endif /* CONFIG_MEMORY_HOTPLUG */
/*
* walk_memory_resource() needs to make sure there is no holes in a given
@@ -184,8 +185,6 @@ walk_memory_resource(unsigned long start_pfn, unsigned
long nr_pages, void *arg,
}
EXPORT_SYMBOL_GPL(walk_memory_resource);
-#endif /* CONFIG_MEMORY_HOTPLUG */
-
void show_mem(void)
{
unsigned long total = 0, reserved = 0;
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 73e3586..ea9f5ad 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -77,14 +77,6 @@ extern int __add_pages(struct zone *zone, unsigned long
start_pfn,
extern int __remove_pages(struct zone *zone, unsigned long start_pfn,
unsigned long nr_pages);
-/*
- * Walk through all memory which is registered as resource.
- * arg is (start_pfn, nr_pages, private_arg_pointer)
- */
-extern int walk_memory_resource(unsigned long start_pfn,
- unsigned long nr_pages, void *arg,
- int (*func)(unsigned long, unsigned long, void *));
-
#ifdef CONFIG_NUMA
extern int memory_add_physaddr_to_nid(u64 start);
#else
@@ -199,6 +191,14 @@ static inline void
register_page_bootmem_info_node(struct pglist_data *pgdat)
#endif /* ! CONFIG_MEMORY_HOTPLUG */
+/*
+ * Walk through all memory which is registered as resource.
+ * arg is (start_pfn, nr_pages, private_arg_pointer)
+ */
+extern int walk_memory_resource(unsigned long start_pfn,
+ unsigned long nr_pages, void *arg,
+ int (*func)(unsigned long, unsigned long, void *));
+
extern int add_memory(int nid, u64 start, u64 size);
extern int arch_add_memory(int nid, u64 start, u64 size);
extern int remove_memory(u64 start, u64 size);
Sorry. I couldn't get back earlier.
Acked-by: Badari Pulavarty [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: arch/ppc is going away Real Soon Now
On Fri, 06 Jun 2008 10:34:28 -0500 Jon Loeliger [EMAIL PROTECTED] wrote: On Fri, 2008-06-06 at 13:19 +0200, Wolfgang Denk wrote: In message [EMAIL PROTECTED] Becky Bruce wrote: On Jun 5, 2008, at 3:30 PM, Scott Wood wrote: Olof Johansson wrote: On Jun 5, 2008, at 3:12 PM, Arnd Bergmann wrote: On Thursday 05 June 2008, Stephen Neuendorffer wrote: Grant Likely [EMAIL PROTECTED] wrote: Paulus, Can we just kill all of arch/ppc for .27 right now? Acked-by: Josh Boyer [EMAIL PROTECTED] Acked-by: Stephen Neuendorffer [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Olof Johansson [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] Acked-by: Becky Bruce [EMAIL PROTECTED] Acked-by: Wolfgang Denk [EMAIL PROTECTED] Acked-by: Jon Loeliger [EMAIL PROTECTED] Acked-by: Sean MacLennan [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Default flats for running dtc from kernel build
DTS_FLAGS ?= -P 0x1000 1k seems like more than enough default padding. Yes. So why specify 4kB? /me hides Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
patch usb-ohci-ppc-of-use-linux-of_platform.h-instead-of-asm.patch added to gregkh-2.6 tree
This is a note to let you know that I've just added the patch titled Subject: USB: ohci-ppc-of: use linux/of_platform.h instead of asm to my gregkh-2.6 tree. Its filename is usb-ohci-ppc-of-use-linux-of_platform.h-instead-of-asm.patch This tree can be found at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/ From [EMAIL PROTECTED] Fri Jun 6 15:16:28 2008 From: Stephen Rothwell [EMAIL PROTECTED] Date: Fri, 23 May 2008 16:37:58 +1000 Subject: USB: ohci-ppc-of: use linux/of_platform.h instead of asm To: Sylvain Munaut [EMAIL PROTECTED] Cc: ppc-dev linuxppc-dev@ozlabs.org, Greg KH [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- drivers/usb/host/ohci-ppc-of.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/host/ohci-ppc-of.c +++ b/drivers/usb/host/ohci-ppc-of.c @@ -14,8 +14,8 @@ */ #include linux/signal.h +#include linux/of_platform.h -#include asm/of_platform.h #include asm/prom.h Patches currently in gregkh-2.6 which might be from [EMAIL PROTECTED] are bad/battery-class-driver.patch usb/usb-ohci-ppc-of-use-linux-of_platform.h-instead-of-asm.patch ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] make walk_memory_resource available with MEMORY_HOTPLUG=n
Nathan Lynch wrote: The ehea driver was recently changed[1] to use walk_memory_resource() to detect the system's memory layout. However, walk_memory_resource() is available only when memory hotplug is enabled. So CONFIG_EHEA was made to depend on MEMORY_HOTPLUG [2], but it is inappropriate for a network driver to have such a dependency. Make the declaration of walk_memory_resource() and its powerpc implementation (ehea is powerpc-specific) unconditionally available. Paul, can you take these two patches, or should I send them to akpm? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Well, I just don't see the point of having two different properties that say the same thing. I'm not an IEE 1275 purist, so I don't think we should be hampered by old node definitions. I especially don't like having a property specifically for indexing I2C nodes that can't be used to enumerate other nodes. It's not about purity. It's about overloading something that has existing semantics just because you have one usecase that you _think_ needs it. If everyone did that, this whole device tree concept is going to just be one big cluster f*ck. One important way of preventing this overloading and death-by-complexity is to make most properties specific to a particular binding. It is good if other bindings that need similar functionality can use similar properties, or sometimes even identical ones; but there are only a few properties that are defined for *every* node. Trying to make stuff too generic just doesn't work. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cell-index vs. index vs. no index in I2C device nodes
Aliases can also provide a reasonable way of enumerating devices, if reg isn't suitable on its own. Yes. In almost all cases, drivers and subsystems do not need this at all though. In OF, one device points to another by putting the phandle of that pointed-to device in some property (and buses are represented by their parent bridge). If the Linux subsystem wants to use an integer for distinguishing between its various buses, that's fine, but it can just make up these numbers -- the numbers themselves have no actual meaning, only the relationships expressed via those numbers do. That's true. However if all the system documentation uses a particular numbering of the devices, it's convenient if we can use the same numbering in Linux. Sure, it's convenient, and you can use aliases to get the naming you want accessible to the user. The drivers shouldn't depend on this naming internally though, esp. since it doesn't really help anything. Incidentally, another word on cell-index. Even for its intended purpose, this was always a compromise. The strictly correct way to handle shared registers like this is for the node representing the shared resource to have a table of phandles pointing back to the devices controlled by the shared registers from which the appropriate indices can derived. IMO, there is no really good (let alone correct) way of handling this. On at least some 4xx chips, however, the shared resources are scattered around various places, but all use the same device numbering. Therefore it seemed expedient to encode that numbering in a single place - 'cell-index' - rather than having several such tables. Yeah, it seems to work out for those 4xx. Other platforms would be well advised to consider the tradeoff for themselves though, many SoCs have an even more wild design than 4xx does ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] make walk_memory_resource available with MEMORY_HOTPLUG=n
Nathan Lynch writes: Paul, can you take these two patches, or should I send them to akpm? I'll take them. I assume we want this in 2.6.26. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
