Re: [PATCH 2/2] powerpc: Move mpc83xx_add_bridge to fsl_pci.c [rev2]
On Thu, Jun 26, 2008 at 11:07:57AM -0600, John Rigby wrote: This allows other platforms with the same pci block like MPC5121 to use it. Signed-off-by: John Rigby [EMAIL PROTECTED] Acked-by: Grant Likely [EMAIL PROTECTED] --- arch/powerpc/platforms/83xx/Kconfig |2 +- arch/powerpc/platforms/83xx/Makefile |1 - arch/powerpc/platforms/83xx/mpc831x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc832x_mds.c |1 + arch/powerpc/platforms/83xx/mpc832x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc834x_itx.c |1 + arch/powerpc/platforms/83xx/mpc834x_mds.c |1 + arch/powerpc/platforms/83xx/mpc836x_mds.c |1 + arch/powerpc/platforms/83xx/mpc837x_mds.c |1 + arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc83xx.h |1 - arch/powerpc/platforms/83xx/pci.c | 91 - arch/powerpc/platforms/83xx/sbc834x.c |1 + arch/powerpc/sysdev/fsl_pci.c | 61 +++ arch/powerpc/sysdev/fsl_pci.h |1 + 15 files changed, 72 insertions(+), 94 deletions(-) delete mode 100644 arch/powerpc/platforms/83xx/pci.c diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig index 0a306eb..ca2c149 100644 --- a/arch/powerpc/platforms/83xx/Kconfig +++ b/arch/powerpc/platforms/83xx/Kconfig @@ -3,7 +3,7 @@ menuconfig MPC83xx depends on PPC_83xx select PPC_UDBG_16550 select PPC_PCI_CHOICE - select PPC_INDIRECT_PCI + select FSL_PCI if PCI if MPC83xx diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile index 76494be..59c413c 100644 --- a/arch/powerpc/platforms/83xx/Makefile +++ b/arch/powerpc/platforms/83xx/Makefile @@ -2,7 +2,6 @@ # Makefile for the PowerPC 83xx linux kernel. # obj-y:= misc.o usb.o -obj-$(CONFIG_PCI)+= pci.o obj-$(CONFIG_MPC831x_RDB)+= mpc831x_rdb.o obj-$(CONFIG_MPC832x_RDB)+= mpc832x_rdb.o obj-$(CONFIG_MPC834x_MDS)+= mpc834x_mds.o diff --git a/arch/powerpc/platforms/83xx/mpc831x_rdb.c b/arch/powerpc/platforms/83xx/mpc831x_rdb.c index c4db517..a428f8d 100644 --- a/arch/powerpc/platforms/83xx/mpc831x_rdb.c +++ b/arch/powerpc/platforms/83xx/mpc831x_rdb.c @@ -19,6 +19,7 @@ #include asm/time.h #include asm/ipic.h #include asm/udbg.h +#include sysdev/fsl_pci.h #include mpc83xx.h diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c index 6dbc6ea..dd4be4a 100644 --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c @@ -36,6 +36,7 @@ #include asm/prom.h #include asm/udbg.h #include sysdev/fsl_soc.h +#include sysdev/fsl_pci.h #include asm/qe.h #include asm/qe_ic.h diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c index e7f706b..f049d69 100644 --- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c +++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c @@ -27,6 +27,7 @@ #include asm/qe.h #include asm/qe_ic.h #include sysdev/fsl_soc.h +#include sysdev/fsl_pci.h #include mpc83xx.h diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c index 50e8f63..7301d77 100644 --- a/arch/powerpc/platforms/83xx/mpc834x_itx.c +++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c @@ -35,6 +35,7 @@ #include asm/prom.h #include asm/udbg.h #include sysdev/fsl_soc.h +#include sysdev/fsl_pci.h #include mpc83xx.h diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c index 2b8a0a3..30d509a 100644 --- a/arch/powerpc/platforms/83xx/mpc834x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c @@ -35,6 +35,7 @@ #include asm/prom.h #include asm/udbg.h #include sysdev/fsl_soc.h +#include sysdev/fsl_pci.h #include mpc83xx.h diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c index c2e5de6..75b80e8 100644 --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c @@ -42,6 +42,7 @@ #include asm/prom.h #include asm/udbg.h #include sysdev/fsl_soc.h +#include sysdev/fsl_pci.h #include asm/qe.h #include asm/qe_ic.h diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c index 64d17b0..be62de2 100644 --- a/arch/powerpc/platforms/83xx/mpc837x_mds.c +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c @@ -19,6 +19,7 @@ #include asm/ipic.h #include asm/udbg.h #include asm/prom.h +#include sysdev/fsl_pci.h #include mpc83xx.h diff --git a/arch/powerpc/platforms/83xx/mpc837x_rdb.c b/arch/powerpc/platforms/83xx/mpc837x_rdb.c index c00356b..da030af 100644 --- a/arch/powerpc/platforms/83xx/mpc837x_rdb.c +++
Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree
On Wed, Jun 18, 2008 at 02:24:46PM -0600, John Rigby wrote:
Updated device tree for MPC5121ADS
Really should be more detailed in the commit message.
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc5121ads.dts | 309 -
1 files changed, 299 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index 94ad7b2..67dc920 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -1,7 +1,7 @@
/*
- * MPC5121E MDS Device Tree Source
+ * MPC5121E ADS Device Tree Source
*
- * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2007,2008 Freescale Semiconductor Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -17,6 +17,10 @@
#address-cells = 1;
#size-cells = 1;
+ aliases {
+ pci = pci;
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -39,6 +43,39 @@
reg = 0x 0x1000; // 256MB at 0
};
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5121-mbx;
+ reg = 0x2000 0x4000;
+ interrupts = 66 0x8;
+ interrupt-parent = ipic ;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5121-sram;
+ reg = 0x3000 0x2; // 128K at 0x3000
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5121-nfc;
+ reg = 0x4000 0x10;// 1M at 0x4000
+ interrupts = 6 8;
+ interrupt-parent = ipic ;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ // ADS has two Hynix 512MB Nand flash chips in a single
+ // stacked package .
+ chips = 2;
+ [EMAIL PROTECTED] {
+ label = nand0;
+ reg = 0x 0x0200; // first 32 MB of chip 0
+ };
+ [EMAIL PROTECTED] {
+ label = nand1;
+ reg = 0x2000 0x0200; // first 32 MB of chip 1
+ };
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc5121ads-localbus;
#address-cells = 2;
@@ -51,18 +88,56 @@
[EMAIL PROTECTED],0 {
compatible = cfi-flash;
reg = 0 0x0 0x400;
+ #address-cells = 1;
+ #size-cells = 1;
bank-width = 4;
- device-width = 1;
+ device-width = 2;
+ [EMAIL PROTECTED] {
+ label = protected;
+ reg = 0x 0x0004; // first sector
is protected
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = filesystem;
+ reg = 0x0004 0x03c0; // 60M for
filesystem
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x03c4 0x0028; // 2.5M for
kernel
+ };
+ [EMAIL PROTECTED] {
+ label = device-tree;
+ reg = 0x03ec 0x0004; // one sector
for device tree
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0x03f0 0x0010; // 1M for u-boot
+ read-only;
+ };
};
[EMAIL PROTECTED],0 {
compatible = fsl,mpc5121ads-cpld;
reg = 0x2 0x0 0x8000;
};
+
+ cpld_pic: [EMAIL PROTECTED],a {
+ compatible = fsl,mpc5121ads-cpld-pic;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0x2 0xa 0x5;
+ interrupt-parent = ipic ;
+ // irq routing
+ // all irqs but touch screen are routed to irq0
(ipic 48)
+ // touch screen is statically routed to irq1 (ipic
17)
+ // so don't use it here
+ interrupts = 48 0x8;
+ };
};
[EMAIL PROTECTED] {
compatible = fsl,mpc5121-immr;
+ device_type = soc;
Don't do this. I know it exists on older board ports, but it is bad
practice. Depend entirely on the compatible value instead.
Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree
On Thu, Jun 26, 2008 at 09:40:57PM -0600, John Rigby wrote:
On Thu, Jun 26, 2008 at 7:42 PM, David Gibson [EMAIL PROTECTED] wrote:
On Wed, Jun 18, 2008 at 02:24:46PM -0600, John Rigby wrote:
[EMAIL PROTECTED] {
compatible = fsl,mpc5121-immr;
+ device_type = soc;
I realise we still need the unwanted device_type value on the soc in
some cases for backwards compatibility, but why are you adding it
where it wasn't before..?
Because get_immrbase in fsl_soc.c does not work without it.
I think I'd rather see get_immrbase() instead then.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
Hi Jon, Grant,
On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote:
On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote:
On 6/25/08, Jean Delvare [EMAIL PROTECTED] wrote:
i2c-adap = mpc_ops;
- i2c-adap.nr = pdev-id;
i2c_set_adapdata(i2c-adap, i2c);
- i2c-adap.dev.parent = pdev-dev;
- if ((result = i2c_add_numbered_adapter(i2c-adap)) 0) {
+ i2c-adap.dev.parent = op-dev;
+
+ result = i2c_add_adapter(i2c-adap);
The driver was previously using i2c_add_numbered_adapter(), giving MPC
platform the possibility to use new-style i2c drivers:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44
You're breaking this, I doubt it's on purpose?
Grant, what do you want here? You're the one who converted it to
i2c_add_numbered_adapter. But in other posts you've said that the
device tree should have nothing to do with bus numbering.
Yes, I did make that change, but that was when it was a platform bus
driver. Converting it to an of_platform bus driver entirely changes the
situation and it should go back to using i2c_add_adapter() with a parse
of the device tree for child nodes.
I am surprised and disappointed, as this sounds like a regression.
Registering the i2c buses with random numbers and parsing the device
tree later to figure out which devices are where, is what everybody was
doing before the new i2c device/driver matching model was implemented,
because there was no other way. I'm curious why you are going back to
this approach when i2c-core now offers something way cleaner and more
efficient.
But well, you'll know better. I'm not familiar with the platform, and
don't have the time to look into it anyway.
Once this driver is converted to an OF one it shouldn't need bus ids
since all of the i2c devices will be children of the bus node. We can
just let the i2c subsystem assign a bus number.
Exactly.
Timur has some issues with the i2c bus number in his ALSA driver. The
problem is locating the i2c device when the i2s driver loads. Parsing
the device tree to extract an i2c bus and device number is not a good
solution.
The trick here is to store the pointer to the device node inside the
i2c device. I do this with SPI devices like this:
/* Store a pointer to the node in the device structure */
of_node_get(nc);
spi-dev.archdata.of_node = nc;
Then, when you've got a device_node pointer, you can parse through the
set of registered SPI devices and match against the one that has the
same device node pointer.
codec-handle should give you the i2c device node. But then we can't
use of_find_device_by_node because the i2c device is not an of_device,
it's a cross platform i2c_device. Should of_find_device_by_node()
return a 'struct device' instead of a 'struct of_device' and leave it
as a user exercise to cast up? It is used nine times in the kernel,
mostly sparc.
No, this doesn't work because I2C and SPI devices are not of_platform
devices. They aren't even platform devices. of_find_device_by_node()
only works for the of_platform bus.
Using archdata.of_node is part of the device structure and works for
every bus type (platform, of_platform, SPI, I2C, PCI, etc.)
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Sun, Jun 29, 2008 at 08:31:43AM +0200, Jean Delvare wrote: Hi Jon, Grant, On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote: On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote: The driver was previously using i2c_add_numbered_adapter(), giving MPC platform the possibility to use new-style i2c drivers: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44 You're breaking this, I doubt it's on purpose? Grant, what do you want here? You're the one who converted it to i2c_add_numbered_adapter. But in other posts you've said that the device tree should have nothing to do with bus numbering. Yes, I did make that change, but that was when it was a platform bus driver. Converting it to an of_platform bus driver entirely changes the situation and it should go back to using i2c_add_adapter() with a parse of the device tree for child nodes. I am surprised and disappointed, as this sounds like a regression. Registering the i2c buses with random numbers and parsing the device tree later to figure out which devices are where, is what everybody was doing before the new i2c device/driver matching model was implemented, because there was no other way. I'm curious why you are going back to this approach when i2c-core now offers something way cleaner and more efficient. Ah, but the whole random number parsing thing is no longer necessary because we ensure that registration of i2c devices always occurs after the i2c adapter is created (for device tree aware i2c adapter drivers. adapters that aren't device tree aware still need to assign a number). After the i2c adapter registers itself, of_register_i2c_devices() is called which walks through the child nodes of the i2c adapter node in the device tree. Each child node is an i2c device, and it immediately get registered with the adapter. Because this ensures that i2c device registration always happens after adapter registration, and since the pointer to the i2c_adapter is known, then i2c_new_device() can be used directly without ever needing to know the bus number. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Resend][PATCH 1/8][Version 2] MPC5121 Update MPC5121ADS device tree
On Sun, Jun 29, 2008 at 12:15 AM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 09:40:57PM -0600, John Rigby wrote: Because get_immrbase in fsl_soc.c does not work without it. I think I'd rather see get_immrbase() instead then. er, I think I'd rather see get_immrbase() *fixed* instead then. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Sun, 29 Jun 2008 00:58:12 -0600, Grant Likely wrote: On Sun, Jun 29, 2008 at 08:31:43AM +0200, Jean Delvare wrote: Hi Jon, Grant, On Sat, 28 Jun 2008 22:49:40 -0600, Grant Likely wrote: On Sat, Jun 28, 2008 at 10:05:28PM -0400, Jon Smirl wrote: The driver was previously using i2c_add_numbered_adapter(), giving MPC platform the possibility to use new-style i2c drivers: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1469fa263870acd890a4b9f6ef557acc5d673b44 You're breaking this, I doubt it's on purpose? Grant, what do you want here? You're the one who converted it to i2c_add_numbered_adapter. But in other posts you've said that the device tree should have nothing to do with bus numbering. Yes, I did make that change, but that was when it was a platform bus driver. Converting it to an of_platform bus driver entirely changes the situation and it should go back to using i2c_add_adapter() with a parse of the device tree for child nodes. I am surprised and disappointed, as this sounds like a regression. Registering the i2c buses with random numbers and parsing the device tree later to figure out which devices are where, is what everybody was doing before the new i2c device/driver matching model was implemented, because there was no other way. I'm curious why you are going back to this approach when i2c-core now offers something way cleaner and more efficient. Ah, but the whole random number parsing thing is no longer necessary because we ensure that registration of i2c devices always occurs after the i2c adapter is created (for device tree aware i2c adapter drivers. adapters that aren't device tree aware still need to assign a number). After the i2c adapter registers itself, of_register_i2c_devices() is called which walks through the child nodes of the i2c adapter node in the device tree. Each child node is an i2c device, and it immediately get registered with the adapter. Because this ensures that i2c device registration always happens after adapter registration, and since the pointer to the i2c_adapter is known, then i2c_new_device() can be used directly without ever needing to know the bus number. Ah, OK. If you use i2c_new_device() then it's alright. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8][Version 2] MPC5121 Add generic board support
On Tue, Jun 24, 2008 at 3:24 PM, John Rigby [EMAIL PROTECTED] wrote:
Move shared code from mpc5121_ads.c to mpc512x_shared.c.
Add new generic board setup mpc5121_generic.c
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
+void __init mpc512x_init_IRQ(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, fsl,ipic);
Along with all my other device-tree conventions comments; you should
really be testing for fsl,mpc5121-ipic here. fsl,ipic is not a good
value for compatible.
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Sun, 29 Jun 2008 09:17:25 +0200
Jean Delvare [EMAIL PROTECTED] wrote:
Ah, OK. If you use i2c_new_device() then it's alright.
Correct.
I have done the same thing for the i2c-ibm_iic.c driver. Jean, I think
you will like this. It gets rid of the index and the numbered drivers.
And the walking of the device tree is very clean because the dts knows
all the devices.
For example here is the relevant portion of the dts for the Warp:
IIC0: [EMAIL PROTECTED] {
compatible = ibm,iic-440ep, ibm,iic-440gp, ibm,iic;
reg = ef600700 14;
interrupt-parent = UIC0;
interrupts = 2 4;
#address-cells = 1;
#size-cells = 0;
[EMAIL PROTECTED] {
compatible = adi,ad7414;
reg = 4a;
interrupts = 19 8;
interrupt-parent = UIC0;
};
};
It clearly shows that first i2c controller (IIC0) contains one ad7414 device at
address 4A.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Sun, 29 Jun 2008 12:24:39 -0400, Sean MacLennan wrote:
On Sun, 29 Jun 2008 09:17:25 +0200
Jean Delvare [EMAIL PROTECTED] wrote:
Ah, OK. If you use i2c_new_device() then it's alright.
Correct.
I have done the same thing for the i2c-ibm_iic.c driver. Jean, I think
you will like this. It gets rid of the index and the numbered drivers.
And the walking of the device tree is very clean because the dts knows
all the devices.
For example here is the relevant portion of the dts for the Warp:
IIC0: [EMAIL PROTECTED] {
compatible = ibm,iic-440ep, ibm,iic-440gp, ibm,iic;
reg = ef600700 14;
interrupt-parent = UIC0;
interrupts = 2 4;
#address-cells = 1;
#size-cells = 0;
[EMAIL PROTECTED] {
compatible = adi,ad7414;
reg = 4a;
interrupts = 19 8;
interrupt-parent = UIC0;
};
};
It clearly shows that first i2c controller (IIC0) contains one ad7414 device
at address 4A.
That's fine with me. I expected the dts to be converted to platform
initialization data (i2c_board_info structures) being registered with
i2c_register_board_info() and numbered adapters. But if you prefer
unnumbered adapters and the platform code or the bus driver itself
calls i2c_new_device() based on the dts, that should work too.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Convert i2c-mpc from a platform driver into a of_platform driver, V2
This version adds of_find_i2c_device_by_node() which is needed by ASOC drivers.
To make it work I had to make the i2c bus struct visible. It also picks up a
couple of other minor fixes that have been posted to the lists.
Signed-off-by: Jon Smirl [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 122 -
drivers/i2c/busses/i2c-mpc.c | 104 ---
drivers/i2c/i2c-core.c|2 -
drivers/of/of_i2c.c | 37 +---
include/linux/i2c.h |3 +
include/linux/of_i2c.h|2 +
6 files changed, 92 insertions(+), 178 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 019657c..ebcec73 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -414,128 +414,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include linux/i2c.h
-struct i2c_driver_device {
- char*of_device;
- char*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {ricoh,rs5c372a, rs5c372a},
- {ricoh,rs5c372b, rs5c372b},
- {ricoh,rv5c386, rv5c386},
- {ricoh,rv5c387a, rv5c387a},
- {dallas,ds1307, ds1307},
- {dallas,ds1337, ds1337},
- {dallas,ds1338, ds1338},
- {dallas,ds1339, ds1339},
- {dallas,ds1340, ds1340},
- {stm,m41t00, m41t00},
- {dallas,ds1374, ds1374},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
-struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info-type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) = I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, reg, len);
- if (!addr || len sizeof(int) || *addr (1 10) - 1) {
- printk(KERN_WARNING fsl_soc.c: invalid i2c device
entry\n);
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- if (of_find_i2c_driver(node, info) 0)
- continue;
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i = 0;
- struct platform_device *i2c_dev;
- int ret;
-
- for_each_compatible_node(np, NULL, fsl-i2c) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(r, 0, sizeof(r));
- memset(i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, r[1]);
-
- i2c_dev = platform_device_register_simple(fsl-i2c, i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, dfsrr, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, fsl5200-clocking, NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, i2c_data,
-sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i++);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index a076129..36bea49 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,8 @@
#include linux/module.h
#include
Re: [RFC] Non-numbered ibm iic driver
Sean MacLennan wrote: P.S. Do I need a signed-off-by for an RFC? Signed-off-by: Sean MacLennan [EMAIL PROTECTED] --- Not usually. Some intentionally leave the S-o-b: off of and RFC specifically to ensure that it stays RFC-ish and doesn't slip into patchness. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Convert i2c-mpc from a platform driver into a of_platform driver, V2
Hi Jon, This version adds of_find_i2c_device_by_node() which is needed by ASOC drivers. Cool. I was about to do something similar (of_get_adapter_nr_by_node). IMHO, the patch should be splitted into the addition of of_find_i2c_device_by_node() and the actual patch of i2c-mpc. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets
simpleImage should also create an .elf (for xmd or systemAce loading) If dtbImage and simpleImage could be merged, I'd be all for it... At some point of course, I need to figure merge the Device Tree in BRAM code that I've been using, which would be a simpleImage which wouldn't need a device tree. However, I don't see this happening before August. Steve -Original Message- From: [EMAIL PROTECTED] on behalf of Grant Likely Sent: Fri 6/27/2008 9:22 PM To: Stephen Neuendorffer Cc: Josh Boyer; John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Scott Wood; Geoff Levand Subject: Re: [PATCH] powerpc/bootwrapper: Add documentation of boot wrappertargets On Thu, Jun 26, 2008 at 1:16 PM, Stephen Neuendorffer [EMAIL PROTECTED] wrote: Forgive my ignorance here, but what specifically does this imply? As far as I can tell, generally speaking, some of the board-specific information is passed into the boot wrapper, which then stuffs it into the device tree. Yes, you are correct. I'll fill out the documentation more here. uImage is for device-tree aware U-Boot versions And this differs from above because it gets a device tree passed in, which uboot has already stuffed correctly. Correct. dtbImage is used for boards that can take an ELF zImage, but still need a dtb provided. simpleImage, not sure here. So both of these are elfs... but how do they differ? Is it only in how the right head.s file gets picked up? simpleImage is not an elf. Its a raw position-independent binary which can be loaded anywhere in RAM. Some dtbImages are elfs; but there are a flat binaries. The main difference is that all simpleImages assume that firmware provides nothing interesting; but the flat dtbImages have custom code for extracting a little bit of data out of the boards firmware. It's all a bit of a confusing mess. It might be a good idea to rework all the image names to stuff not so non-obvious, but I'm not sure the best way to go about it. There is a lot of historical stuff in there where the various 'zImage.*' targets grew and morphed over time in ways that are hard to follow. It may make more sense to change the flat-binary dtbImages to be simpleImages instead with overrides for specific boards (just like is done for virtex405-*). ps3 is the other major user of dtbImage. I created the whole dtbImage stuff in the first place to eliminate overloaded makefile targets where some zImage% target were providing a device tree and other zImage% targets were not. Splitting dtb-provided from dtb-not-provided targets clarified the Makefile quite a bit. dtbImage is not a fantastic name, but I needed something different from zImage for images with an embedded device tree. Looking at the Makefile, dtbImage and simpleImage targets are virtually identical. Perhaps it would be best to merge the targets and deal with all the differences in the wrapper script (with the default to just use simpleboot.S as the init code). Thoughts? Cheers, g. -- 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
Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:29 AM, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] arch/microblaze/platform/generic/system.dts | 300 +++ Since this is a generated file, and entirely bitstream specific, does it make sense to include it in the kernel tree? If it does, then is it produced from one of the Xilinx reference designs? Can you add documentation to the header that specifies exactly which design version this .dts is for? I think there's value in having a generic DTS as an example or template, even if it doesn't correspond to any specific machine. Agreed a comment block explaining this is valuable. I'd almost oppose any attempt to include a standard DTS for things like ML401 boards etc - they are just misleading. Unless we do MD5 hashes on MHS files, and use them as the filenames, any attempt to define a standard platform will just fail and confuse people. Better to show them how to generate the DTS for their system. +/* + * (C) Copyright 2007-2008 Xilinx, Inc. + * (C) Copyright 2007-2008 Michal Simek + * + * Michal SIMEK [EMAIL PROTECTED] If this is a generated file, then is this copyright notice even appropriate? I agree. I think Michal is just copying Xilinx's habit of putting copyright headers in generated files, and it's one that we should stop now. Regards, John ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [i2c] [PATCH] Convert i2c-mpc from a platform driver to an of_platform one
On Sunday 29 June 2008, Jean Delvare wrote: After the i2c adapter registers itself, of_register_i2c_devices() is called which walks through the child nodes of the i2c adapter node in the device tree. Each child node is an i2c device, and it immediately get registered with the adapter. Because this ensures that i2c device registration always happens after adapter registration, and since the pointer to the i2c_adapter is known, then i2c_new_device() can be used directly without ever needing to know the bus number. Ah, OK. If you use i2c_new_device() then it's alright. Right. Conceptually the way that the i2c core uses numbered adapters and registered board_info could be viewed as a way to let platforms avoid tracking that stuff themselves. Since the of_* framework is already tracking that, there's no big win in trying to have i2c-core track that too, on its behalf. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
Is there really much of a chance of that, given the differences with the bootwrappers? Does anyone care enough about legacy_serial for this to matter? My impression was that legacy serial was not preferred anyway... Steve -Original Message- From: [EMAIL PROTECTED] on behalf of Grant Likely Sent: Sat 6/28/2008 1:33 PM To: Stephen Neuendorffer Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; git Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'. On Fri, Jun 6, 2008 at 10:16 AM, Stephen Neuendorffer [EMAIL PROTECTED] wrote: 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. This is an easy solution, but it is not a good one. Doing so would break UDBG on other 405 boards when building multiplatform kernels. It would be better to teach legacy serial about the shift and offset. Alternately, add code to add_legacy_soc_port() to skip it if the shift/offset properties are present. Cheers, g. -- 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
Re: Please pull from 'powerpc-next' branch
On Fri, 2008-06-27 at 08:00 -0500, Kumar Gala wrote: On Jun 27, 2008, at 6:27 AM, Paul Mackerras wrote: Kumar Gala writes: Paul, any update on when we might see some of the various patches pulled into powerpc-next? I've got some work I'd like to see in .27 but it needs Michael's code patching patches. I thought you had some concerns about patches 5/14 and 12/14 of his series? 5/14 needs some better comments but nothing that should hold up the acceptance and 12/14 or should be merged with 11/14 if he reposts the patch set. But again, nothing to hold things up. I guess it would be easier for you Kumar if I do a fixup patch to add comments, rather than rebasing and you having to rebase as well? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] MPC5121 Add PCI support
Yes, Kumar made the same comment. The newer patch that moves the 83xx add bridge routine to fsl_soc obsoletes this patch. On Sat, Jun 28, 2008 at 11:38 PM, Grant Likely [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 10:58:38AM -0600, John Rigby wrote: Copied from 83xx minus support for two busses. If this is a copy, then can it be shared? g. ___ 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 12/60] microblaze_v4: Generic dts file for platforms
Hi Steve, In my opionion, we should only include dts files for reference designs, and it must be documented how to get the design that the dts corresponds to. I'm not sure you (or Xilinx) are quite ready for the pain this implies - have you tried browsing reference designs on Xilinx.com recently? It's a total mishmash of tool versions, boards, you name it. If Xilinx is ready to declare a gold standard ML401 design, and commit to maintaining it tool version after tool version, lots of people will be very happy, but I don't see it just yet! I'm not having a go at you here, just questioning the notion that there is really any such thing as a persistent 'reference design' for these platforms. These are not physical boards that get manufactured and persist as real objects. MD5 hashing might be one way to prevent people from getting the dts file wrong, however without some way of checking it automatically, I don't think anyone will have the patience to checksum the design they have (even worse, with whitespace changes, the md5 sum will change, so this is pretty fragile. Actually I was only joking about the md5 hashing - just to prove my point :) Having a device tree in the kernel for documentation *shouldn't* be necessary, Well, yes and no. A vanilla DTS that shows what a valid one might look like - oh, here's where I declare my main memory parameters, ... has some value IMO. since noone should ever write their dts by hand. (right?) I'm not certain you can guarantee that. Hence, I'd prefer to not put the dts file in the kernel at all, and but to automatically generate the dts and store it in the blockram of the design. This inextricably associates the dts with the design. Whether the DTS lives in block ram or is pulled over the net by uboot or whatever is not our call to make in the kernel - that's a deployment issue. As for the copyright, I haven't been able to find much information on whether or not generated files are even copyrightable. One might argue that they don't have sufficient 'creative value' to be copyrightable. Or arguably, they are as copyrightable by the generator author as by the author or the .mhs file. The DTS is a mechanical translation from one file format to another (more or less). Auto-inserting a copyright Xilinx (or anyone else) in there would be unenforceable, and therefore should probably just go away. How would you feel if the FSF claimed copyright over object code derived from your source files simply because you ran them through gcc? :) I believe there's a special clause in the GCC license to explicitly cover this kind of situation. Cheers, John ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 12/60] microblaze_v4: Generic dts file for platforms
In my opionion, we should only include dts files for reference designs, and it must be documented how to get the design that the dts corresponds to. MD5 hashing might be one way to prevent people from getting the dts file wrong, however without some way of checking it automatically, I don't think anyone will have the patience to checksum the design they have (even worse, with whitespace changes, the md5 sum will change, so this is pretty fragile. Having a device tree in the kernel for documentation *shouldn't* be necessary, since noone should ever write their dts by hand. (right?) Hence, I'd prefer to not put the dts file in the kernel at all, and but to automatically generate the dts and store it in the blockram of the design. This inextricably associates the dts with the design. As for the copyright, I haven't been able to find much information on whether or not generated files are even copyrightable. One might argue that they don't have sufficient 'creative value' to be copyrightable. Or arguably, they are as copyrightable by the generator author as by the author or the .mhs file. I admit in this case, I've followed the safe route by claiming a copyright, which at least at Xilinx has significant precedent. Steve -Original Message- From: John Williams [mailto:[EMAIL PROTECTED] Sent: Sun 6/29/2008 5:02 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer; John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Michal Simek Subject: Re: [PATCH 12/60] microblaze_v4: Generic dts file for platforms On Sat, Jun 28, 2008 at 3:49 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Jun 26, 2008 at 5:29 AM, [EMAIL PROTECTED] wrote: From: Michal Simek [EMAIL PROTECTED] arch/microblaze/platform/generic/system.dts | 300 +++ Since this is a generated file, and entirely bitstream specific, does it make sense to include it in the kernel tree? If it does, then is it produced from one of the Xilinx reference designs? Can you add documentation to the header that specifies exactly which design version this .dts is for? I think there's value in having a generic DTS as an example or template, even if it doesn't correspond to any specific machine. Agreed a comment block explaining this is valuable. I'd almost oppose any attempt to include a standard DTS for things like ML401 boards etc - they are just misleading. Unless we do MD5 hashes on MHS files, and use them as the filenames, any attempt to define a standard platform will just fail and confuse people. Better to show them how to generate the DTS for their system. +/* + * (C) Copyright 2007-2008 Xilinx, Inc. + * (C) Copyright 2007-2008 Michal Simek + * + * Michal SIMEK [EMAIL PROTECTED] If this is a generated file, then is this copyright notice even appropriate? I agree. I think Michal is just copying Xilinx's habit of putting copyright headers in generated files, and it's one that we should stop now. Regards, John 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
Re: [PATCH 4/6] MPC5121 Add MPC5121ADS cpld support
On Sat, Jun 28, 2008 at 11:36 PM, Grant Likely
[EMAIL PROTECTED] wrote:
Minor comments below.
On Fri, Jun 20, 2008 at 10:58:37AM -0600, John Rigby wrote:
Add a interrupt host for the interrupt
controller in the mpc5121ads cpld.
PCI interrupts are 0-7 the rest are 8-15
Touchscreen pendown irq is hardwired to irq1
All other irqs are chainged to irq0
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/platforms/512x/Kconfig|1 +
arch/powerpc/platforms/512x/Makefile |2 +-
arch/powerpc/platforms/512x/mpc5121_ads.c | 14 ++-
arch/powerpc/platforms/512x/mpc5121_ads.h | 14 ++
arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 204
5 files changed, 233 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads.h
create mode 100644 arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
diff --git a/arch/powerpc/platforms/512x/Kconfig
b/arch/powerpc/platforms/512x/Kconfig
index f9a04da..0fd3b00 100644
--- a/arch/powerpc/platforms/512x/Kconfig
+++ b/arch/powerpc/platforms/512x/Kconfig
@@ -12,6 +12,7 @@ config MPC5121_ADS
depends on PPC_MULTIPLATFORM PPC32
select DEFAULT_UIMAGE
select PPC_MPC5121
+ select MPC5121_ADS_CPLD
What is this for? I don't see it used anywhere.
Yes you are right, the Makefile just uses MPC5121_ADS to include the cpld code.
help
This option enables support for the MPC5121E ADS board.
diff --git a/arch/powerpc/platforms/512x/mpc5121_ads.c
b/arch/powerpc/platforms/512x/mpc5121_ads.c
index 45bb2ef..36805fd 100644
--- a/arch/powerpc/platforms/512x/mpc5121_ads.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2007, 2008 Freescale Semiconductor, Inc. All rights
reserved.
*
* Author: John Rigby, [EMAIL PROTECTED], Thur Mar 29 2007
*
@@ -23,6 +23,16 @@
#include asm/time.h
#include mpc512x.h
+#include mpc5121_ads.h
+
+static void __init mpc5121_ads_setup_arch(void)
+{
+ printk(KERN_INFO MPC5121 ADS board from Freescale Semiconductor\n);
+ /*
+ * cpld regs are needed early
+ */
+ mpc5121_ads_cpld_map();
+}
static struct of_device_id __initdata of_bus_ids[] = {
{ .name = soc, },
@@ -41,6 +51,7 @@ static void __init
mpc5121_ads_declare_of_platform_devices(void)
static void __init mpc5121_ads_init_IRQ(void)
{
mpc512x_init_IRQ();
+ mpc5121_ads_cpld_pic_init();
Ah, I understand now. Ignore my related comment in the previous patch.
}
/*
___
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 2/4] spi: split up spi_new_device() to allow two stage registration.
On Friday 23 May 2008, Grant Likely wrote: Question: spi_alloc_device() (and the original code) does a spi_master_get() on the spi_master device. Doesn't spi_master_put() need to be called when the device is discarded? spi_dev_put() doesn't do that explicitly; is it an implicit operation after a device has been deregistered from the spi_master? Depends whether or not the add() has been done to hook things into the driver model tree, as I recall. The add() presumes things are properly refcounted. When you make a driver model tree node vanish, its associated refcounts get updated too. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] spi: split up spi_new_device() to allow two stage registration.
On Tuesday 17 June 2008, Grant Likely wrote: This patch splits the allocation and registration portions of code out of spi_new_device() and creates three new functions; spi_alloc_device(), spi_register_device(), and spi_device_release(). I have no problem with the first two, but why the last? If the devices are always allocated by spi_alloc_device() as they should be -- probably through an intermediary -- the only public function necessary for that cleanup should be the existing spi_dev_put(). Ah, okay. I'm still a bit fuzzy on the device model conventions. I'll remove that then. I've dug into this some more. spi_alloc_device only allocates the memory. It doesn't call device_initialize() to initialize the kref. Well, the driver model idiom is initialize() then add(), with register() calls combining the two. An alloc() is just a bit outside those core idioms ... But one alloc() example is platform_device_alloc(), which does the device_initialize() call ... followed by platform_device_add(). The spi_new_device() call does a bunch of stuff beyond a register(), but it also calls device_register(). All of that behaviour is handled within device_register(). Therefore if a driver uses spi_alloc_device() and then if a later part of the initialization fails before spi_register_device() is called, then the alloc'd memory needs to be freed, but spi_dev_put() won't work because the kobj isn't set up so I need another function to handle freeing it in on a failure path. I see ... Should I switch things around to do device_initialize() in the alloc function Yes. and call device_add() instead of device_register() in the spi_register_device() function? You should also rename it to spi_add_device(), since register() calls always do the initialize() rather than having it done for them in advance. People rely on those names supporting that pattern (as they should). Is that sufficient to make put_device() work? Looks like it to me. Calling device_initialize() will do a kobject_init(), which is documented as requiring a kobject_put() to clean up ... that's all put_device() will ever do. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Add dma nodes to 83xx, 85xx and 86xx boards
On Fri, Jun 27, 2008 at 04:10:17PM -0500, Kumar Gala wrote:
Added DMA nodes for the elo/elo-plus DMA engines.
Renamed the interrupt controller alias in mpc832x_rdb.dts to ipic so that
its the same as all the other boards.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
[snip]
diff --git a/arch/powerpc/boot/dts/asp834x-redboot.dts
b/arch/powerpc/boot/dts/asp834x-redboot.dts
index 972cf78..8b1bb0e 100644
--- a/arch/powerpc/boot/dts/asp834x-redboot.dts
+++ b/arch/powerpc/boot/dts/asp834x-redboot.dts
@@ -118,6 +118,41 @@
mode = cpu;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8347-dma, fsl,elo-dma;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a8;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ cell-index = 0;
What's the cell-index in these nodes used to index? Given the
confusion there's been about the proper use of this property, a
comment indicating which shared registers this is used to index is
probably a good idea.
--
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 08/18 v2] powerpc: Do not probe PCI buses or eBus devices if CMO is enabled
Robert Jennings writes: From: Brian King [EMAIL PROTECTED] The Cooperative Memory Overcommit (CMO) on System p does not currently support native PCI devices or eBus devices when enabled. Then why would we get any native PCI or eBus devices in the device tree? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/bootwrapper: Add documentation of boot wrapper targets
Grant Likely writes: From: Grant Likely [EMAIL PROTECTED] There have been many questions on and off the mailing list about how exactly the bootwrapper is used for embedded targets. Add some documentation and help text to try and clarify the system. Signed-off-by: Grant Likely [EMAIL PROTECTED] ... diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index d6c96d9..7cd4182 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -203,6 +203,10 @@ simpleboot-virtex405-*) platformo=$object/virtex405-head.o $object/simpleboot.o binary=y ;; +simpleboot-*) +platformo=$object/simpleboot.o +binary=y +;; esac Evidently your patch does more than just Add documentation... Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[POWERPC] mpc7448hpc2.dts: remove chosen node from dts
Modern versions of u-boot create a chosen node automatically. So if
we set the chosen node in the dts file, there will be 2 chosen nodes
passed in to the kernel, and the kernel command line will be taken from
the wrong node. So, remove the extra chosen node from the dts file.
Signed-off-by: Chunbo Luo [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc7448hpc2.dts |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc7448hpc2.dts
b/arch/powerpc/boot/dts/mpc7448hpc2.dts
index 4936349..d74727f 100644
--- a/arch/powerpc/boot/dts/mpc7448hpc2.dts
+++ b/arch/powerpc/boot/dts/mpc7448hpc2.dts
@@ -186,8 +186,5 @@
};
};
};
- chosen {
- linux,stdout-path = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
- };
};
---
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
