* [PATCH] [POWERPC] iSeries: fix ref counting in vio setup.
From: Stephen Rothwell @ 2007-11-06 6:26 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/vio.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/vio.c b/arch/powerpc/platforms/iseries/vio.c
index d6435b0..be06cfd 100644
--- a/arch/powerpc/platforms/iseries/vio.c
+++ b/arch/powerpc/platforms/iseries/vio.c
@@ -523,15 +523,16 @@ static void __init get_viotape_info(struct device_node *vio_root)
static int __init iseries_vio_init(void)
{
struct device_node *vio_root;
+ int ret = -ENODEV;
if (!firmware_has_feature(FW_FEATURE_ISERIES))
- return -ENODEV;
+ goto out;
iommu_vio_init();
vio_root = of_find_node_by_path("/vdevice");
if (!vio_root)
- return -ENODEV;
+ goto out;
if (viopath_hostLp == HvLpIndexInvalid) {
vio_set_hostlp();
@@ -544,10 +545,11 @@ static int __init iseries_vio_init(void)
get_viocd_info(vio_root);
get_viotape_info(vio_root);
- return 0;
+ ret = 0;
put_node:
of_node_put(vio_root);
- return -ENODEV;
+ out:
+ return ret;
}
arch_initcall(iseries_vio_init);
--
1.5.3.5
^ permalink raw reply related
* [RFC/PATCH] Fix rtas_ibm_suspend_me bugs
From: Nathan Lynch @ 2007-11-06 4:43 UTC (permalink / raw)
To: linuxppc-dev
(very rfc for now, no sign-off, needs more testing)
There are a couple of bugs in the rtas_ibm_suspend_me() and
rtas_percpu_suspend_me() functions:
1. rtas_ibm_suspend_me() uses on_each_cpu() to invoke
rtas_percpu_suspend_me() via IPI:
if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
...
'data' is on the stack, and rtas_ibm_suspend_me() takes no measures to
ensure that all instances of rtas_percpu_suspend_me() are finished
accessing 'data' before returning. This can result in the IPI'd cpus
accessing random stack data and getting stuck in H_JOIN.
Fix this by moving rtas_suspend_me_data off the stack, and protect it
with a mutex. Use a completion to ensure that all cpus are done
accessing the data before unlocking.
2. rtas_percpu_suspend_me passes the Linux logical cpu id to the
H_PROD hypervisor method, when it should be using the platform
interrupt server value for that cpu (hard_smp_processor_id). In
practice, this probably causes problems only on partitions where
processors have been removed and added in a particular order.
---
arch/powerpc/kernel/rtas.c | 64 ++++++++++++++++++++++++++++++++-----------
1 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 2147807..24faaea 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -19,6 +19,9 @@
#include <linux/init.h>
#include <linux/capability.h>
#include <linux/delay.h>
+#include <linux/mutex.h>
+#include <linux/completion.h>
+#include <linux/smp.h>
#include <asm/prom.h>
#include <asm/rtas.h>
@@ -34,6 +37,7 @@
#include <asm/lmb.h>
#include <asm/udbg.h>
#include <asm/syscalls.h>
+#include <asm/atomic.h>
struct rtas_t rtas = {
.lock = SPIN_LOCK_UNLOCKED
@@ -41,10 +45,21 @@ struct rtas_t rtas = {
EXPORT_SYMBOL(rtas);
struct rtas_suspend_me_data {
+ atomic_t working; /* number of cpus accessing rtas_suspend_me_data */
long waiting;
struct rtas_args *args;
+ struct completion done; /* wait on this until working == 0 */
};
+static void rtas_suspend_me_data_init(struct rtas_suspend_me_data *rsmd,
+ struct rtas_args *args)
+{
+ atomic_set(&rsmd->working, 0);
+ rsmd->waiting = 1;
+ rsmd->args = args;
+ init_completion(&rsmd->done);
+}
+
DEFINE_SPINLOCK(rtas_data_buf_lock);
EXPORT_SYMBOL(rtas_data_buf_lock);
@@ -671,36 +686,49 @@ static void rtas_percpu_suspend_me(void *info)
* we set it to <0.
*/
local_irq_save(flags);
+ atomic_inc(&data->working);
do {
rc = plpar_hcall_norets(H_JOIN);
smp_rmb();
} while (rc == H_SUCCESS && data->waiting > 0);
if (rc == H_SUCCESS)
+ /* join is complete (or there was an error) and this
+ * cpu was prodded
+ */
goto out;
if (rc == H_CONTINUE) {
+ /* this cpu does the join */
data->waiting = 0;
data->args->args[data->args->nargs] =
rtas_call(ibm_suspend_me_token, 0, 1, NULL);
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD,i);
} else {
data->waiting = -EBUSY;
printk(KERN_ERR "Error on H_JOIN hypervisor call\n");
}
+ /* This cpu did the join or got an error, so we need to prod
+ * everyone else. Extra prods are harmless.
+ */
+ for_each_online_cpu(i)
+ plpar_hcall_norets(H_PROD, get_hard_smp_processor_id(i));
+
out:
+ if (atomic_dec_return(&data->working) == 0)
+ complete(&data->done);
local_irq_restore(flags);
return;
}
+static DEFINE_MUTEX(rsm_lock); /* protects rsm_data */
+static struct rtas_suspend_me_data rsm_data;
+
static int rtas_ibm_suspend_me(struct rtas_args *args)
{
- int i;
+ int err;
long state;
long rc;
unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
- struct rtas_suspend_me_data data;
/* Make sure the state is valid */
rc = plpar_hcall(H_VASI_STATE, retbuf,
@@ -721,25 +749,27 @@ static int rtas_ibm_suspend_me(struct rtas_args *args)
return 0;
}
- data.waiting = 1;
- data.args = args;
+ mutex_lock(&rsm_lock);
+
+ rtas_suspend_me_data_init(&rsm_data, args);
- /* Call function on all CPUs. One of us will make the
- * rtas call
+ /* Call function on all CPUs. One of us (but not necessarily
+ * this one) will make the ibm,suspend-me call.
*/
- if (on_each_cpu(rtas_percpu_suspend_me, &data, 1, 0))
- data.waiting = -EINVAL;
+ if (on_each_cpu(rtas_percpu_suspend_me, &rsm_data, 1, 0))
+ rsm_data.waiting = -EINVAL;
+
+ /* Must wait for all IPIs to complete before unlocking */
+ wait_for_completion(&rsm_data.done);
- if (data.waiting != 0)
+ if (rsm_data.waiting != 0)
printk(KERN_ERR "Error doing global join\n");
- /* Prod each CPU. This won't hurt, and will wake
- * anyone we successfully put to sleep with H_JOIN.
- */
- for_each_possible_cpu(i)
- plpar_hcall_norets(H_PROD, i);
+ err = rsm_data.waiting;
+
+ mutex_unlock(&rsm_lock);
- return data.waiting;
+ return err;
}
#else /* CONFIG_PPC_PSERIES */
static int rtas_ibm_suspend_me(struct rtas_args *args)
--
1.5.3.4.56.ge720
^ permalink raw reply related
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Stephen Rothwell @ 2007-11-06 4:40 UTC (permalink / raw)
To: Jon Smirl; +Cc: Tjernlund, Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <9e4733910711052025m7905efb6ja3e4b6a022e6aa81@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
Hi Jon,
On Mon, 5 Nov 2007 23:25:35 -0500 "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> + compatible = of_get_property(node, "compatible", &len);
> + strlcpy(info.driver_name, compatible, len);
Of course, you will check len against sizeof(info.driver_name), right?
> -/* With some changes from Kyösti Mälkki <kmalkki@cc.hut.fi>.
> +/* With some changes from Kyï¿œsti Mï¿œlkki <kmalkki@cc.hut.fi>.
Did you mean to change this?
> + char **alias;
const char ** would be nicer.
> struct i2c_driver {
> int id;
> unsigned int class;
> +
> + /* Alias name for the driver. Used to support device trees on
> + * the PowerPC architecture. Device tree names take the form of
> + * vendor,chip. For example "epson,pcf8564". Alias is a list of
> + * strings terminated by a zero entry.
> + */
> + char **alias;
const char ** would be nicer;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] reduce load time for modules with lots of relocs
From: Stephen Rothwell @ 2007-11-06 4:29 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev
In-Reply-To: <20071106023355.GJ9695@localdomain>
[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]
On Mon, 5 Nov 2007 20:33:55 -0600 Nathan Lynch <ntl@pobox.com> wrote:
>
> static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
> {
> - unsigned int i, j, ret = 0;
> + unsigned int i, sorted_count = 0;
> + Elf32_Word last_info;
> + Elf32_Sword last_addend;
> + Elf32_Rela **sortbuf = NULL;
You don't need to initialise sortbuf and f you make it a "const
Elf32_Rela **" ...
> + sortbuf = vmalloc(num * sizeof(*sortbuf));
> + if (!sortbuf)
> + return -ENOMEM;
> +
> + for (i = 0; i < num; i++)
> + sortbuf[i] = (Elf32_Rela *)&rela[i];
You shouldn't need that cast.
> -static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num)
> +static int count_relocs(const Elf64_Rela *rela, unsigned int num)
> {
> unsigned int i, j, ret = 0;
> + Elf64_Xword last_info;
> + Elf64_Sxword last_addend;
> + Elf64_Rela **sortbuf = NULL;
Same here.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jon Smirl @ 2007-11-06 4:25 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F8267.8070106@freescale.com>
On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> >>> Or push these strings into the chip drivers and modify
> >>> i2c-core to also match on the device tree style names.
> >> That would be ideal; it just hasn't been done yet.
> >
> > This is not hard to do but the i2c people will have to agree. I need
> > to change the i2c_driver structure to include the additional names.
>
> I got a fair bit of resistance from them on the topic of multiple match
> names for i2c clients.
Here's a first pass at pushing the strings back into the i2c drivers.
If this looks reasonable it can be optimized a lot more. A more
advanced version of this code would combine the alias, name, and
driver_name fields. The existing pairing of driver_name/name could be
merged into the concept of alias names for the driver.
Extend i2c-core to support lists of device tree compatible names when
matching drivers
From: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/busses/i2c-mpc.c | 35 ++++-------------------------------
drivers/i2c/i2c-core.c | 17 +++++++++++++++--
drivers/rtc/rtc-pcf8563.c | 1 +
drivers/rtc/rtc-rs5c372.c | 1 +
include/linux/i2c.h | 11 +++++++++--
5 files changed, 30 insertions(+), 35 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4ddebe4..6313631 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -312,34 +312,6 @@ static struct i2c_adapter mpc_ops =3D {
=09.retries =3D 1
};
-struct i2c_driver_device {
-=09char=09*of_device;
-=09char=09*i2c_driver;
-=09char=09*i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] =3D {
-=09{"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
-=09{"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
-=09{"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
-=09{"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
-=09{"epson,pcf8564", "rtc-pcf8563", "pcf8564",},
-};
-
-static int of_find_i2c_driver(struct device_node *node, struct
i2c_board_info *info)
-{
-=09int i;
-
-=09for (i =3D 0; i < ARRAY_SIZE(i2c_devices); i++) {
-=09=09if (!of_device_is_compatible(node, i2c_devices[i].of_device))
-=09=09=09continue;
-=09=09strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN)=
;
-=09=09strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
-=09=09return 0;
-=09}
-=09return -ENODEV;
-}
-
static void of_register_i2c_devices(struct i2c_adapter *adap, struct
device_node *adap_node)
{
=09struct device_node *node =3D NULL;
@@ -347,6 +319,7 @@ static void of_register_i2c_devices(struct
i2c_adapter *adap, struct device_node
=09while ((node =3D of_get_next_child(adap_node, node))) {
=09=09struct i2c_board_info info;
=09=09const u32 *addr;
+=09=09const char *compatible;
=09=09int len;
=09=09addr =3D of_get_property(node, "reg", &len);
@@ -359,9 +332,9 @@ static void of_register_i2c_devices(struct
i2c_adapter *adap, struct device_node
=09=09if (info.irq =3D=3D NO_IRQ)
=09=09=09info.irq =3D -1;
-=09=09if (of_find_i2c_driver(node, &info) < 0)
-=09=09=09continue;
-
+=09=09compatible =3D of_get_property(node, "compatible", &len);
+=09=09strlcpy(info.driver_name, compatible, len);
+=09=09info.type[0] =3D '\0';
=09=09info.platform_data =3D NULL;
=09=09info.addr =3D *addr;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index d663e69..4128cd1 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -17,7 +17,7 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=09=09 */
/* -----------------------------------------------------------------------=
-- */
-/* With some changes from Ky=F6sti M=E4lkki <kmalkki@cc.hut.fi>.
+/* With some changes from Ky=EF=BF=9Csti M=EF=BF=9Clkki <kmalkki@cc.hut.fi=
>.
All SMBus-related things are written by Frodo Looijaard <frodol@dds.nl>
SMBus 2.0 support by Mark Studebaker <mdsxyz123@yahoo.com> and
Jean Delvare <khali@linux-fr.org> */
@@ -51,6 +51,7 @@ static int i2c_device_match(struct device *dev,
struct device_driver *drv)
{
=09struct i2c_client=09*client =3D to_i2c_client(dev);
=09struct i2c_driver=09*driver =3D to_i2c_driver(drv);
+=09char **alias;
=09/* make legacy i2c drivers bypass driver model probing entirely;
=09 * such drivers scan each i2c adapter/bus themselves.
@@ -61,7 +62,19 @@ static int i2c_device_match(struct device *dev,
struct device_driver *drv)
=09/* new style drivers use the same kind of driver matching policy
=09 * as platform devices or SPI: compare device and driver IDs.
=09 */
-=09return strcmp(client->driver_name, drv->name) =3D=3D 0;
+=09if (strcmp(client->driver_name, drv->name) =3D=3D 0)
+=09=09return true;
+
+=09/* Match against alias device tree names */
+=09if (!driver->alias)
+=09=09return 0;
+=09alias =3D driver->alias;
+=09while (*alias) {
+=09=09if (strcmp(client->driver_name, *alias) =3D=3D 0)
+=09=09=09return true;
+=09=09alias++;
+=09}
+=09return 0;
}
#ifdef=09CONFIG_HOTPLUG
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index b778d35..7c8caf5 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -266,6 +266,7 @@ static struct i2c_driver pcf8563_driver =3D {
=09.driver=09=09=3D {
=09=09.name=09=3D "rtc-pcf8563",
=09},
+=09.alias=09=3D (char *[]){"epson,pcf8564", 0},
=09.id=09=09=3D I2C_DRIVERID_PCF8563,
=09.probe =3D &pcf8563_probe,
=09.remove =3D &pcf8563_remove,
diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 6b67b50..0f37d04 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -649,6 +649,7 @@ static struct i2c_driver rs5c372_driver =3D {
=09.driver=09=09=3D {
=09=09.name=09=3D "rtc-rs5c372",
=09},
+=09.alias=09=3D (char
*[]){"ricoh,rs5c372a","ricoh,rs5c372b","ricoh,rv5c386","ricoh,rv5c387a",0},
=09.probe=09=09=3D rs5c372_probe,
=09.remove=09=09=3D rs5c372_remove,
};
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 2a32f2f..d55748c 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -107,6 +107,13 @@ extern s32 i2c_smbus_write_i2c_block_data(struct
i2c_client * client,
struct i2c_driver {
=09int id;
=09unsigned int class;
+=09
+=09/* Alias name for the driver. Used to support device trees on
+=09 * the PowerPC architecture. Device tree names take the form of
+=09 * vendor,chip. For example "epson,pcf8564". Alias is a list of
+=09 * strings terminated by a zero entry.
+=09 */
+=09char **alias;
=09/* Notifies the driver that a new bus has appeared. This routine
=09 * can be used by the driver to test if the bus meets its conditions
@@ -146,7 +153,7 @@ struct i2c_driver {
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
-#define I2C_NAME_SIZE=0920
+#define I2C_NAME_SIZE=0940
/**
* struct i2c_client - represent an I2C slave device
@@ -225,7 +232,7 @@ static inline void i2c_set_clientdata (struct
i2c_client *dev, void *data)
* with the adapter already known.
*/
struct i2c_board_info {
-=09char=09=09driver_name[KOBJ_NAME_LEN];
+=09char=09=09driver_name[I2C_NAME_SIZE];
=09char=09=09type[I2C_NAME_SIZE];
=09unsigned short=09flags;
=09unsigned short=09addr;
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* No ip addr on the Xilinx ML403
From: usysinc @ 2007-11-06 3:38 UTC (permalink / raw)
To: linuxppc-embedded
I have successfully booted the Linux 2.6.23 vertex kernel branch on the ML403
board. The hard_temac 3.00_a was implemented in the MHS file. The kernel was
configured with no Marvel PHY drivers; just the generic 10/100 Ethernet MII,
and 10/100/1000 Ethernet. The Temac configures correctly and I have verified
that DHCP is indeed functional, but no 'ip addr=' is visible with ifconfig
and can't ping anything other than localhost. Can anyone suggest a solution
to this configuration problem?
XTemac: using sgDMA mode.
[ 3.079060] XTemac: using TxDRE mode
[ 3.121940] XTemac: using RxDRE mode
[ 3.164839] XTemac: buffer descriptor size: 32768 (0x8000)
[ 3.231800] XTemac: (buffer_descriptor_init) phy: 0x3cb0000, virt:
0xff100000, size: 0x8000
[ 3.339873] eth%d: XTemac: PHY detected at address 0.
[ 3.400611] eth0: Dropping NETIF_F_SG since no checksum feature.
[ 3.475138] eth0: Xilinx TEMAC #0 at 0x81200000 mapped to 0xC5060000,
irq=0
[ 3.558779] eth0: XTemac id 1.0f, block id 5, type 8
.
.
.
# ifdown eth0
# ifup eth0
[ 20.004852] eth0: XTemac: Options: 0xb8f2
[ 32.012102] eth0: XTemac: Not able to set the speed to 1000 (status:
0x7949)
[ 34.089874] eth0: XTemac: We renegotiated the speed to: 100
[ 34.156549] eth0: XTemac: speed set to 100Mb/s
[ 34.209718] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2
[ 34.285693] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1
udhcpc (v1.7.2) started
udhcpc: script /usr/share/udhcpc/default.script failed: No such file or
directory
Sending discover...
Sending select for 192.168.0.2...
Lease of 192.168.0.2 obtained, lease time 86400
udhcpc: script /usr/share/udhcpc/default.script failed: No such file or
directory
# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:3E:26:15:59
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1240 (1.2 KiB) TX bytes:1180 (1.1 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
- Brendan
--
View this message in context: http://www.nabble.com/No-ip-addr-on-the-Xilinx-ML403-tf4755897.html#a13600333
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [RFC/PATCH] reduce load time for modules with lots of relocs
From: Nathan Lynch @ 2007-11-06 2:33 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: linuxppc-dev
In-Reply-To: <20071101235728.GE9695@localdomain>
Nathan Lynch wrote:
> Medve Emilian-EMMEDVE1 wrote:
> >
> > I have module with 36K relocation entries (I know, I know, how could
> > that be...) and the count_relocs() function takes ~17 seconds to crunch
> > through the relocation table from the .rela.text section. I don't think
> > I can reduce the number of entries in the relocation table (can I?) so
> > I'm thinking at improving the performance of count_relocs() (currently
> > O(n^2)). Does anybody have a simpler idea? Does anyone have any
> > constructive suggestion on how to improve the situation?
>
> This seems to come up every few months. There was a patch submitted
> here:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
I think this comes up often enough for us to fix it (IIRC unionfs
people complained about it long ago too), and it's kind of lame to
spend 17 seconds in the kernel without scheduling. So I dug up some
old patches that should reduce the complexity to O(n logn), using the
sort() function, which IMO is preferable to doing our own hash thing
as that patch from June does. Only the 64-bit code is tested. Does
this help your situation?
arch/powerpc/kernel/module_32.c | 85 +++++++++++++++++++++++++++++++---------
arch/powerpc/kernel/module_64.c | 80 ++++++++++++++++++++++++++++++-------
2 files changed, 132 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 07a89a3..001b941 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -24,6 +24,7 @@
#include <linux/kernel.h>
#include <linux/cache.h>
#include <linux/bug.h>
+#include <linux/sort.h>
#include "setup.h"
@@ -50,26 +51,64 @@ void module_free(struct module *mod, void *module_region)
table entries. */
}
+static int reloc_cmp(const void *_a, const void *_b)
+{
+ const Elf32_Rela *a = *(Elf32_Rela **)_a, *b = *(Elf32_Rela **)_b;
+
+ if (a->r_info < b->r_info)
+ return -1;
+ else if (a->r_info > b->r_info)
+ return 1;
+ else if (a->r_addend < b->r_addend)
+ return -1;
+ else if (a->r_addend > b->r_addend)
+ return 1;
+
+ return 0;
+}
+
+
/* Count how many different relocations (different symbol, different
addend) */
static unsigned int count_relocs(const Elf32_Rela *rela, unsigned int num)
{
- unsigned int i, j, ret = 0;
+ unsigned int i, sorted_count = 0;
+ Elf32_Word last_info;
+ Elf32_Sword last_addend;
+ Elf32_Rela **sortbuf = NULL;
+
+ if (num == 0)
+ return 0;
+
+ sortbuf = vmalloc(num * sizeof(*sortbuf));
+
+ if (!sortbuf)
+ return -ENOMEM;
+
+ for (i = 0; i < num; i++)
+ sortbuf[i] = (Elf32_Rela *)&rela[i];
+
+ sort(sortbuf, i, sizeof(sortbuf[0]), reloc_cmp, NULL);
+
+ last_info = sortbuf[0]->r_info;
+ last_addend = sortbuf[0]->r_addend;
+ sorted_count = 1;
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
for (i = 0; i < num; i++) {
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (ELF32_R_SYM(rela[i].r_info)
- == ELF32_R_SYM(rela[j].r_info)
- && rela[i].r_addend == rela[j].r_addend)
- break;
- }
- if (j == i) ret++;
+ /* If this r_info,r_addend tuple matches the previous
+ * entry, don't count it again
+ */
+ if (sortbuf[i]->r_info == last_info &&
+ sortbuf[i]->r_addend == last_addend)
+ continue;
+
+ last_info = sortbuf[i]->r_info;
+ last_addend = sortbuf[i]->r_addend;
+ sorted_count++;
}
- return ret;
+
+ vfree(sortbuf);
+ return sorted_count;
}
/* Get the potential trampolines size required of the init and
@@ -96,15 +135,19 @@ static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
continue;
if (sechdrs[i].sh_type == SHT_RELA) {
+ int count;
DEBUGP("Found relocations in section %u\n", i);
DEBUGP("Ptr: %p. Number: %u\n",
(void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela));
- ret += count_relocs((void *)hdr
+ count = count_relocs((void *)hdr
+ sechdrs[i].sh_offset,
sechdrs[i].sh_size
/ sizeof(Elf32_Rela))
* sizeof(struct ppc_plt_entry);
+ if (count < 0)
+ return count;
+ ret += count;
}
}
@@ -117,6 +160,7 @@ int module_frob_arch_sections(Elf32_Ehdr *hdr,
struct module *me)
{
unsigned int i;
+ int ret;
/* Find .plt and .init.plt sections */
for (i = 0; i < hdr->e_shnum; i++) {
@@ -131,10 +175,15 @@ int module_frob_arch_sections(Elf32_Ehdr *hdr,
}
/* Override their sizes */
- sechdrs[me->arch.core_plt_section].sh_size
- = get_plt_size(hdr, sechdrs, secstrings, 0);
- sechdrs[me->arch.init_plt_section].sh_size
- = get_plt_size(hdr, sechdrs, secstrings, 1);
+ ret = get_plt_size(hdr, sechdrs, secstrings, 0);
+ if (ret < 0)
+ return ret;
+ sechdrs[me->arch.core_plt_section].sh_size = ret;
+
+ ret = get_plt_size(hdr, sechdrs, secstrings, 1);
+ if (ret < 0)
+ return ret;
+ sechdrs[me->arch.init_plt_section].sh_size = ret;
return 0;
}
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 75c7c4f..bfc5b98 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -21,6 +21,7 @@
#include <linux/err.h>
#include <linux/vmalloc.h>
#include <linux/bug.h>
+#include <linux/sort.h>
#include <asm/module.h>
#include <asm/uaccess.h>
#include <asm/firmware.h>
@@ -77,28 +78,68 @@ static struct ppc64_stub_entry ppc64_stub =
0x4e, 0x80, 0x04, 0x20 /* bctr */
} };
+static int reloc_cmp(const void *_a, const void *_b)
+{
+ const Elf64_Rela *a = *(Elf64_Rela **)_a, *b = *(Elf64_Rela **)_b;
+
+ if (a->r_info < b->r_info)
+ return -1;
+ else if (a->r_info > b->r_info)
+ return 1;
+ else if (a->r_addend < b->r_addend)
+ return -1;
+ else if (a->r_addend > b->r_addend)
+ return 1;
+
+ return 0;
+}
+
/* Count how many different 24-bit relocations (different symbol,
different addend) */
-static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num)
+static int count_relocs(const Elf64_Rela *rela, unsigned int num)
{
unsigned int i, j, ret = 0;
+ Elf64_Xword last_info;
+ Elf64_Sxword last_addend;
+ Elf64_Rela **sortbuf = NULL;
+
+ if (num == 0)
+ return 0;
+
+ sortbuf = vmalloc(num * sizeof(*sortbuf));
- /* FIXME: Only count external ones --RR */
- /* Sure, this is order(n^2), but it's usually short, and not
- time critical */
- for (i = 0; i < num; i++) {
+ if (!sortbuf)
+ return -ENOMEM;
+
+ for (j = 0, i = 0; i < num; i++) {
/* Only count 24-bit relocs, others don't need stubs */
if (ELF64_R_TYPE(rela[i].r_info) != R_PPC_REL24)
continue;
- for (j = 0; j < i; j++) {
- /* If this addend appeared before, it's
- already been counted */
- if (rela[i].r_info == rela[j].r_info
- && rela[i].r_addend == rela[j].r_addend)
- break;
- }
- if (j == i) ret++;
+ sortbuf[j++] = (Elf64_Rela *)&rela[i];
}
+
+ if (j == 0)
+ goto out;
+
+ sort(sortbuf, j, sizeof(sortbuf[0]), reloc_cmp, NULL);
+
+ last_info = sortbuf[0]->r_info;
+ last_addend = sortbuf[0]->r_addend;
+ ret = 1;
+ for (i = 0; i < j; i++) {
+ /* If this r_info,r_addend tuple matches the previous
+ * entry, don't count it again
+ */
+ if (sortbuf[i]->r_info == last_info &&
+ sortbuf[i]->r_addend == last_addend)
+ continue;
+
+ last_info = sortbuf[i]->r_info;
+ last_addend = sortbuf[i]->r_addend;
+ ret++;
+ }
+out:
+ vfree(sortbuf);
return ret;
}
@@ -129,13 +170,17 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
/* Every relocated section... */
for (i = 1; i < hdr->e_shnum; i++) {
if (sechdrs[i].sh_type == SHT_RELA) {
+ int count;
DEBUGP("Found relocations in section %u\n", i);
DEBUGP("Ptr: %p. Number: %lu\n",
(void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size / sizeof(Elf64_Rela));
- relocs += count_relocs((void *)sechdrs[i].sh_addr,
+ count = count_relocs((void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size
/ sizeof(Elf64_Rela));
+ if (count < 0)
+ return count;
+ relocs += count;
}
}
@@ -173,6 +218,7 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
struct module *me)
{
unsigned int i;
+ int stubs_size;
/* Find .toc and .stubs sections, symtab and strtab */
for (i = 1; i < hdr->e_shnum; i++) {
@@ -209,7 +255,11 @@ int module_frob_arch_sections(Elf64_Ehdr *hdr,
me->arch.toc_section = me->arch.stubs_section;
/* Override the stubs size */
- sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs);
+ stubs_size = get_stubs_size(hdr, sechdrs);
+ if (stubs_size < 0)
+ return stubs_size;
+
+ sechdrs[me->arch.stubs_section].sh_size = stubs_size;
return 0;
}
^ permalink raw reply related
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Stephen Rothwell @ 2007-11-06 2:28 UTC (permalink / raw)
To: Jon Smirl; +Cc: Tjernlund, Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <9e4733910711051734m7cf1fac0y5fb39feb37bad548@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
On Mon, 5 Nov 2007 20:34:51 -0500 "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> > > +static struct of_platform_driver mpc_i2c_driver = {
> > > + .owner = THIS_MODULE,
> > > + .name = DRV_NAME,
> > > + .match_table = mpc_i2c_of_match,
> > > + .probe = mpc_i2c_probe,
> > > + .remove = __devexit_p(mpc_i2c_remove),
> > > + .driver = {
> > > + .name = DRV_NAME,
> > > },
> > > };
> >
> > Do we still need .name if we have .driver.name?
>
> This is a general question, if of_platform_driver doesn't need .name
> it should be removed from the structure.
I am in the process of doing that. However there a quite a few drivers
that need to be fixed first. In the meantime,
of_register_platform_driver will copy which ever of the name and owner
fields you fill in to the others, so we can convert over time. For new
drivers (and changing), please use the name and owner fields in the
embedded device_driver struct. (this is the same as done by the platform
drivers currently ...)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] pasemi: Don't reset mpic at boot
From: Olof Johansson @ 2007-11-06 2:21 UTC (permalink / raw)
To: linuxppc-dev
[POWERPC] pasemi: Don't reset mpic at boot
Due to an erratum, we don't want to reset the mpic at boot time. It can
sometimes cause problems with lost interrupts later on while running.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 857d238..bd85853 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -214,7 +214,7 @@ static __init void pas_init_IRQ(void)
printk(KERN_DEBUG "OpenPIC addr: %lx\n", openpic_addr);
mpic = mpic_alloc(mpic_node, openpic_addr,
- MPIC_PRIMARY|MPIC_LARGE_VECTORS|MPIC_WANTS_RESET,
+ MPIC_PRIMARY|MPIC_LARGE_VECTORS,
0, 0, " PAS-OPIC ");
BUG_ON(!mpic);
^ permalink raw reply related
* Re: [PATCH] powerpc: prpmc2800 - Don't trust documented memory size
From: Mark A. Greer @ 2007-11-06 1:59 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071106012805.GA20909@mag.az.mvista.com>
On Mon, Nov 05, 2007 at 06:28:05PM -0700, Mark A. Greer wrote:
> It turns out that the firmware on some PrPMC2800 processor modules
> initializes the memory controller for 512 MB even when there is more
> memory. As a simple work around, set the amount of memory in the
> device tree passed to the kernel to the lesser of what the memory
> controller is set up for and the actual amount of memory.
>
> Signed-off-by: Mark A. Greer <mgreer@mvista.com>
> ---
Paul, please ignore this patch. There is still something wrong.
Sorry for the noise.
Mark
^ permalink raw reply
* Re: [PATCH] [POWERPC] pasemi: Broaden specific references to 1682M
From: Olof Johansson @ 2007-11-06 2:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Doug Thompson
In-Reply-To: <cd9a9e67893406e486d2ffc7599e28b7@kernel.crashing.org>
On Tue, Nov 06, 2007 at 02:42:08AM +0100, Segher Boessenkool wrote:
> Hi Olof,
>
> Nice cleanup! One minor thing...
>
>> static struct of_device_id pasemi_bus_ids[] = {
>> + /* Unfortunately needed for legacy firmwares */
>> { .type = "localbus", },
>> { .type = "sdc", },
>> + { .compatible = "pasemi,localbus", },
>> + { .compatible = "pasemi,sdc", },
>
> The new comment is for the device_type entries only, right? You
> might want to make that more clear.
Good point. I'll clarify it with a new comment above the compatible
entries. I won't repost the patch since the change is minor, but include
it for the upstream push.
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] pasemi: Broaden specific references to 1682M
From: Segher Boessenkool @ 2007-11-06 1:42 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Doug Thompson
In-Reply-To: <20071105032802.GA16613@lixom.net>
Hi Olof,
Nice cleanup! One minor thing...
> static struct of_device_id pasemi_bus_ids[] = {
> + /* Unfortunately needed for legacy firmwares */
> { .type = "localbus", },
> { .type = "sdc", },
> + { .compatible = "pasemi,localbus", },
> + { .compatible = "pasemi,sdc", },
The new comment is for the device_type entries only, right? You
might want to make that more clear.
Segher
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jon Smirl @ 2007-11-06 1:34 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F7247.9070106@freescale.com>
On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> > +static struct of_platform_driver mpc_i2c_driver = {
> > + .owner = THIS_MODULE,
> > + .name = DRV_NAME,
> > + .match_table = mpc_i2c_of_match,
> > + .probe = mpc_i2c_probe,
> > + .remove = __devexit_p(mpc_i2c_remove),
> > + .driver = {
> > + .name = DRV_NAME,
> > },
> > };
>
> Do we still need .name if we have .driver.name?
This is a general question, if of_platform_driver doesn't need .name
it should be removed from the structure.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] powerpc: prpmc2800 - Don't trust documented memory size
From: Mark A. Greer @ 2007-11-06 1:28 UTC (permalink / raw)
To: linuxppc-dev
It turns out that the firmware on some PrPMC2800 processor modules
initializes the memory controller for 512 MB even when there is more
memory. As a simple work around, set the amount of memory in the
device tree passed to the kernel to the lesser of what the memory
controller is set up for and the actual amount of memory.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/prpmc2800.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..559c45e 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -405,7 +405,10 @@ static void prpmc2800_fixups(void)
bip = prpmc2800_get_bip(); /* Get board info based on VPD */
- mem_size = (bip) ? bip->mem_size : mv64x60_get_mem_size(bridge_base);
+ mem_size = mv64x60_get_mem_size(bridge_base);
+ if (bip)
+ mem_size = min(mem_size, bip->mem_size);
+
prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */
/* If the VPD doesn't match what we know about, just use the
^ permalink raw reply related
* Re: [PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
From: Stephen Rothwell @ 2007-11-06 1:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071105175341.6ee15106@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 455 bytes --]
On Mon, 5 Nov 2007 17:53:41 -0600 Josh Boyer <jwboyer@gmail.com> wrote:
>
> Yeah, this is fine with me too. But why haven't we put a #warning in
> asm/of_platform.h and asm/prom.h?
Because thee are way to many places to be fixed yet. And asm/prom.h needs to be explicitly included if you want to use the flattened device tree accessors.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jon Smirl @ 2007-11-06 0:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F8267.8070106@freescale.com>
On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> >>> One side effect is that legacy style i2c drivers won't work anymore.
> >> If you mean legacy-style client drivers, why not?
> >
> > i2c_new_device() doesn't work with legacy-style client drivers.
>
> No, but they should still work the old way.
I'm not in favor trying to support both legacy and new style i2c
drivers. It took me all of five minutes to convert an existing legacy
driver to the new style. Pretty much all you need to do is delete code
(about 100 lines). So I'd recommend converting the drivers we are
interest in instead of trying to support both types.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Jon Smirl @ 2007-11-06 0:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Tjernlund, Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <fa686aa40711051446q1abe886dh6225fa1ec675ef9b@mail.gmail.com>
On 11/5/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> > Jon Smirl wrote:
> > > On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> > >> Jon Smirl wrote:
> > >>> This is my first pass at reworking the Freescale i2c driver. It
> > >>> switches the driver from being a platform driver to an open firmware
> > >>> one. I've checked it out on my hardware and it is working.
> > >> We may want to hold off on this until arch/ppc goes away (or at least
> > >> all users of this driver in arch/ppc).
> > >
> > > How about renaming the old driver file and leaving it hooked to ppc?
> > > Then it would get deleted when ppc goes away. That would let work
> > > progress on the powerpc version.
> >
> > Or we could have one driver that has two probe methods. I don't like
> > forking the driver.
>
> I agree. This driver can and should have multiple bus bindings.
What non-of platform uses this driver?
I believe this is the last struct platform driver left for the
mpc5200. Fixing this one allows the platform bus to be removed. With a
device tree there isn't any reason to keep a platform bus, everything
should be on the of_platform bus.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
From: Josh Boyer @ 2007-11-05 23:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20071106094014.cd429711.sfr@canb.auug.org.au>
On Tue, 6 Nov 2007 09:40:14 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Mon, 05 Nov 2007 15:43:43 -0600 Jon Loeliger <jdl@freescale.com> wrote:
> >
> > From: Jon Loeliger <jdl@freescale.com>
> >
> > Signed-off-by: Jon Loeliger <jdl@freescale.com>
>
> Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
Yeah, this is fine with me too. But why haven't we put a #warning in
asm/of_platform.h and asm/prom.h?
josh
^ permalink raw reply
* Re: libfdt: Fix sw_tree1 testcase
From: David Gibson @ 2007-11-05 23:42 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Ip3bp-000260-Of@jdl.com>
On Mon, Nov 05, 2007 at 09:11:25AM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > There is a bug in the sw_tree1 testcase / utility which puts two
> > "compatible" properties in one node in the output tree. This patch
> > fixes the bug, and also adds a new test checking that the sw_tree1
> > output is equal to test_tree1.dtb as its supposed to be, which should
> > catch future errors of this type.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> This change appears to cause a test to fail.
> I've not looked into it beyond "make check failed":
Crud, I screwed up and gave you an intermediate version of the patch
which tried to do the same thing for rw_tree1. For that to work, I'll
need to write a dtbs_equal_notordered test.
Corrected version below.
libfdt: Fix sw_tree1 testcase
There is a bug in the sw_tree1 testcase / utility which puts two
"compatible" properties in one node in the output tree. This patch
fixes the bug, and also adds a new test checking that the sw_tree1
output is equal to test_tree1.dtb as its supposed to be, which should
catch future errors of this type.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-11-06 10:38:21.000000000 +1100
+++ dtc/tests/run_tests.sh 2007-11-06 10:39:37.000000000 +1100
@@ -71,6 +71,7 @@
run_test sw_tree1
tree1_tests sw_tree1.test.dtb
tree1_tests unfinished_tree1.test.dtb
+ run_test dtbs_equal_ordered test_tree1.dtb sw_tree1.test.dtb
# fdt_move tests
for tree in test_tree1.dtb sw_tree1.test.dtb unfinished_tree1.test.dtb; do
Index: dtc/tests/sw_tree1.c
===================================================================
--- dtc.orig/tests/sw_tree1.c 2007-11-05 16:59:13.000000000 +1100
+++ dtc/tests/sw_tree1.c 2007-11-06 10:39:37.000000000 +1100
@@ -64,7 +64,6 @@
CHECK(fdt_begin_node(fdt, "subsubnode"));
CHECK(fdt_property(fdt, "compatible", "subsubnode1\0subsubnode",
23));
- CHECK(fdt_property_string(fdt, "compatible", "subsubnode1\0"));
CHECK(fdt_property_typed(fdt, "prop-int", TEST_VALUE_1));
CHECK(fdt_end_node(fdt));
CHECK(fdt_end_node(fdt));
--
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
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Grant Likely @ 2007-11-05 23:03 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <472F915F.9010400@freescale.com>
On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> Matt Sealey wrote:
> > Scott Wood wrote:
> >> Jon Smirl wrote:
> >
> >>>>> cell-index = <1>;
> >>>> What is cell-index for?
> >>> I was using it to control the bus number, is that the wrong
> >>> attribute?
> >>
> >> It shouldn't be specified at all -- the hardware has no concept of
> >> a device number.
> >
> > Well, all i2c devices have a chip id you can probe for,
>
> I meant a controller device number (a.k.a. bus number), which (outside
> of documentation) is purely a Linux invention, and which is what
> cell-index was being used for above.
>
> > as for buses I think cell-index is a holdover from the way the PSC
> > code is organised on the MPC5200 for example - if you have multiple
> > buses which use the same registers, for example. It's redundant on
> > the PSC's for programming because they all use different register
> > offsets but if you move to other devices like the GPTs, then it is
> > then useful for debugging (it is far more interesting to say GPT1
> > than GPT @ offset to match the)
Actually, it is not intended for this. cell-index is not intended to
be able to say GPT1 instead of GPT@xxx (while that may be possible, it
is not the intent). Nor is it a holdover from the PSC code design.
It is designed to describe the internal structure of the SoC. The
5200 has 6 PSCs, and there are some chip registers which are shared
between all the PSCs (for clocking, IO mode, etc). It is not
sufficient to simply plop down a device tree node for each PSC because
it doesn't give enough information about which bits to use in the
shared regs. (For example, the port_config register)
> > and in general for tweaking OTHER
> > parts of the chip (for instance the CDM - very relevant!) which use
> > single registers to control entire swathes of units.
>
> Right, that's what cell-index is for. This is different. :-)
Yes, this is correct.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Grant Likely @ 2007-11-05 22:46 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F8267.8070106@freescale.com>
On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> Jon Smirl wrote:
> > On 11/5/07, Scott Wood <scottwood@freescale.com> wrote:
> >> Jon Smirl wrote:
> >>> This is my first pass at reworking the Freescale i2c driver. It
> >>> switches the driver from being a platform driver to an open firmware
> >>> one. I've checked it out on my hardware and it is working.
> >> We may want to hold off on this until arch/ppc goes away (or at least
> >> all users of this driver in arch/ppc).
> >
> > How about renaming the old driver file and leaving it hooked to ppc?
> > Then it would get deleted when ppc goes away. That would let work
> > progress on the powerpc version.
>
> Or we could have one driver that has two probe methods. I don't like
> forking the driver.
I agree. This driver can and should have multiple bus bindings.
> >>> cell-index = <1>;
> >> What is cell-index for?
> >
> > I was using it to control the bus number, is that the wrong attribute?
>
> It shouldn't be specified at all -- the hardware has no concept of a
> device number.
cell-index is important. It describes the hardware, or more
specifically the layout of the SoC. The SoC has 2 i2c busses which
are numbered 0 and 1. This property should stay for the 5200.
However, that is the only purpose of it. cell-index does *not*
describe the system level bus number.
> > I was allowing control of the bus number with "cell-index" and
> > i2c_add_numbered_adapter().
> > Should I get rid of this and switch to i2c_add_adapter()?
>
> Yes.
Yes, the purpose of cell-index is not to give an i2c bus number enumeration.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] 4xx; Replace #includes of asm/of_platform.h with linux/of_platform.h.
From: Stephen Rothwell @ 2007-11-05 22:40 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1194299023.7158.59.camel@ld0161-tx32>
[-- Attachment #1: Type: text/plain, Size: 338 bytes --]
On Mon, 05 Nov 2007 15:43:43 -0600 Jon Loeliger <jdl@freescale.com> wrote:
>
> From: Jon Loeliger <jdl@freescale.com>
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Replace some #includes of asm/of_platform.h with linux/of_platform.h.
From: Stephen Rothwell @ 2007-11-05 22:36 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1194296705.7158.45.camel@ld0161-tx32>
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Hi Jon,
Thanks for starting this.
On Mon, 05 Nov 2007 15:05:06 -0600 Jon Loeliger <jdl@freescale.com> wrote:
>
> From: Jon Loeliger <jdl@freescale.com>
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
> #include <asm/of_device.h>
asm/of_device.h -> linux/of_device.h as well? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Scott Wood @ 2007-11-05 21:55 UTC (permalink / raw)
To: Matt Sealey; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F9086.2060606@genesi-usa.com>
Matt Sealey wrote:
> Scott Wood wrote:
>> Jon Smirl wrote:
>
>>>>> cell-index = <1>;
>>>> What is cell-index for?
>>> I was using it to control the bus number, is that the wrong
>>> attribute?
>>
>> It shouldn't be specified at all -- the hardware has no concept of
>> a device number.
>
> Well, all i2c devices have a chip id you can probe for,
I meant a controller device number (a.k.a. bus number), which (outside
of documentation) is purely a Linux invention, and which is what
cell-index was being used for above.
> as for buses I think cell-index is a holdover from the way the PSC
> code is organised on the MPC5200 for example - if you have multiple
> buses which use the same registers, for example. It's redundant on
> the PSC's for programming because they all use different register
> offsets but if you move to other devices like the GPTs, then it is
> then useful for debugging (it is far more interesting to say GPT1
> than GPT @ offset to match the) and in general for tweaking OTHER
> parts of the chip (for instance the CDM - very relevant!) which use
> single registers to control entire swathes of units.
Right, that's what cell-index is for. This is different. :-)
-Scott
^ permalink raw reply
* Re: [RFC] Rework of i2c-mpc.c - Freescale i2c driver
From: Matt Sealey @ 2007-11-05 21:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Tjernlund, linuxppc-dev, Jean Delvare, i2c
In-Reply-To: <472F8267.8070106@freescale.com>
Scott Wood wrote:
> Jon Smirl wrote:
>>>> cell-index = <1>;
>>> What is cell-index for?
>> I was using it to control the bus number, is that the wrong attribute?
>
> It shouldn't be specified at all -- the hardware has no concept of a
> device number.
Well, all i2c devices have a chip id you can probe for, as for buses I
think cell-index is a holdover from the way the PSC code is organised
on the MPC5200 for example - if you have multiple buses which use the
same registers, for example. It's redundant on the PSC's for programming
because they all use different register offsets but if you move to
other devices like the GPTs, then it is then useful for debugging (it
is far more interesting to say GPT1 than GPT @ offset to match the)
and in general for tweaking OTHER parts of the chip (for instance
the CDM - very relevant!) which use single registers to control entire
swathes of units.
This way if you are in any doubt you can tell which one you should
be futzing with in other parts of the chip without complicated logic
based on MBAR offsets from the manual (magic numbers hinder the
maintainability and portability of the code). It's not relevant for
i2c but like I said, still valid, useful information..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox