* [PATCH 1/3] ppc32: Make platform devices being able to assign functions
From: Vitaly Bordug @ 2005-12-19 13:21 UTC (permalink / raw)
To: Kumar Gala, Marcelo Tosatti; +Cc: linuxppc-embedded list
Implemented by modification of the .name field of the platform device,
when PDs with the
same names are to be used within different drivers, as
<device_name> -> <device_name>:<function>
Corresponding drivers should change the .name in struct device_driver to
reflect upper of course.
Also helper platform_notify_map function added, making assignment of
board-specific platform_info more consistent and generic.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
---
arch/ppc/syslib/ppc_sys.c | 136 ++++++++++++++++++++++++++++++++++++++++++++-
include/asm-ppc/mpc10x.h | 1
include/asm-ppc/mpc52xx.h | 1
include/asm-ppc/mpc8260.h | 1
include/asm-ppc/mpc83xx.h | 1
include/asm-ppc/mpc85xx.h | 1
include/asm-ppc/mpc8xx.h | 1
include/asm-ppc/ppc_sys.h | 24 ++++++++
8 files changed, 164 insertions(+), 2 deletions(-)
applies-to: 4ce1b1890dc687cb1cf77f98e7a95b94c7ef3a93
a8450a334dc930d7284800c457d91ed55a1a3dd7
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
index c0b93c4..26d2658 100644
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -15,11 +15,23 @@
*/
#include <linux/string.h>
+#include <linux/bootmem.h>
#include <asm/ppc_sys.h>
int (*ppc_sys_device_fixup) (struct platform_device * pdev);
static int ppc_sys_inited;
+static int ppc_sys_func_inited;
+
+static const char *ppc_sys_func_names[] = {
+ [FUNC_ENABLED] = "dummy",
+ [FUNC_ETH] = "eth",
+ [FUNC_UART] = "uart",
+ [FUNC_HLDC] = "hldc",
+ [FUNC_USB] = "usb",
+ [FUNC_IRDA] = "irda",
+ [FUNC_DISABLED] = "off",
+};
void __init identify_ppc_sys_by_id(u32 id)
{
@@ -38,13 +50,13 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
unsigned int i = 0;
- while (ppc_sys_specs[i].ppc_sys_name[0])
- {
+ while (ppc_sys_specs[i].ppc_sys_name[0]) {
if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
break;
i++;
}
cur_ppc_sys_spec = &ppc_sys_specs[i];
+
return;
}
@@ -128,6 +140,126 @@ void ppc_sys_device_remove(enum ppc_sys_
}
}
+/* Platform-notify mapping
+ * Helper function for BSP code to assign board-specific platfom-divice bits
+ */
+
+void platform_notify_map(const struct platform_notify_dev_map *map,
+ struct device *dev)
+{
+ struct platform_device *pdev;
+ int len, idx;
+ const char *s;
+
+ /* do nothing if no device or no bus_id */
+ if (!dev || !dev->bus_id)
+ return;
+
+ /* call per device map */
+ while (map->bus_id != NULL) {
+ idx = -1;
+ s = strrchr(dev->bus_id, '.');
+ if (s != NULL)
+ idx = (int)simple_strtol(s + 1, NULL, 10);
+ else
+ s = dev->bus_id + strlen(s);
+
+ len = s - dev->bus_id;
+
+ if (!strncmp(dev->bus_id, map->bus_id, len)) {
+ pdev = container_of(dev, struct platform_device, dev);
+ map->rtn(pdev, idx);
+ }
+ map++;
+ }
+}
+
+/*
+ Function assignment stuff.
+ Intended to work as follows:
+ the device name defined in foo_devices.c will be concatenated with :"func",
+ where func is string map of respective function from platfom_device_func enum
+
+ The FUNC_ENABLED function is intended to remove all assignments, making the device to appear
+ in platform bus with unmodified name.
+ */
+
+/*
+ Here we'll replace .name pointers with fixed-lenght strings
+ Hereby, this should be called *before* any func stuff triggeded.
+ */
+void ppc_sys_device_initfunc(void)
+{
+ int i;
+ const char *name;
+ static char new_names[NUM_PPC_SYS_DEVS][BUS_ID_SIZE];
+ enum ppc_sys_devices cur_dev;
+
+ /* If inited yet, do nothing */
+ if (ppc_sys_func_inited)
+ return;
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ if ((cur_dev = cur_ppc_sys_spec->device_list[i]) < 0)
+ continue;
+
+ if (ppc_sys_platform_devices[cur_dev].name) {
+ /*backup name */
+ name = ppc_sys_platform_devices[cur_dev].name;
+ strlcpy(new_names[i], name, BUS_ID_SIZE);
+ ppc_sys_platform_devices[cur_dev].name = new_names[i];
+ }
+ }
+
+ ppc_sys_func_inited = 1;
+}
+
+/*The "engine" of the func stuff. Here we either concat specified function string description
+ to the name, or remove it if FUNC_ENABLED parameter is passed here*/
+void ppc_sys_device_setfunc(enum ppc_sys_devices dev,
+ enum platform_device_func func)
+{
+ char *s;
+ char *name = (char *)ppc_sys_platform_devices[dev].name;
+ char tmp[BUS_ID_SIZE];
+
+ if (!ppc_sys_func_inited) {
+ printk(KERN_ERR "Unable to alter function - not inited!\n");
+ return;
+ }
+
+ if (ppc_sys_inited) {
+ platform_device_unregister(&ppc_sys_platform_devices[dev]);
+ }
+
+ if ((s = (char *)strchr(name, ':')) != NULL) { /* reassign */
+ /* Either change the name after ':' or remove func modifications */
+ if (func != FUNC_ENABLED)
+ strlcpy(s + 1, ppc_sys_func_names[func], BUS_ID_SIZE);
+ else
+ *s = 0;
+ } else if (func != FUNC_ENABLED) {
+ /* do assignment if it is not just "enable" request */
+ sprintf(tmp, "%s:%s", name, ppc_sys_func_names[func]);
+ strlcpy(name, tmp, BUS_ID_SIZE);
+ }
+
+ if (ppc_sys_inited) {
+ platform_device_register(&ppc_sys_platform_devices[dev]);
+ }
+}
+
+void ppc_sys_device_set_func_all(enum platform_device_func func)
+{
+ enum ppc_sys_devices cur_dev;
+ int i;
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ cur_dev = cur_ppc_sys_spec->device_list[i];
+ ppc_sys_device_setfunc(cur_dev, func);
+ }
+}
+
static int __init ppc_sys_init(void)
{
unsigned int i, dev_id, ret = 0;
diff --git a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
index 77b1e09..976ad3d 100644
--- a/include/asm-ppc/mpc10x.h
+++ b/include/asm-ppc/mpc10x.h
@@ -165,6 +165,7 @@ enum ppc_sys_devices {
MPC10X_DMA1,
MPC10X_UART0,
MPC10X_UART1,
+ NUM_PPC_SYS_DEVS,
};
int mpc10x_bridge_init(struct pci_controller *hose,
diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
index e5f80c2..b2cb44f 100644
--- a/include/asm-ppc/mpc52xx.h
+++ b/include/asm-ppc/mpc52xx.h
@@ -49,6 +49,7 @@ enum ppc_sys_devices {
MPC52xx_ATA,
MPC52xx_I2C1,
MPC52xx_I2C2,
+ NUM_PPC_SYS_DEVS,
};
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
index 3214526..6ba69a8 100644
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -83,6 +83,7 @@ enum ppc_sys_devices {
MPC82xx_CPM_SMC2,
MPC82xx_CPM_USB,
MPC82xx_SEC1,
+ NUM_PPC_SYS_DEVS,
};
#ifndef __ASSEMBLY__
diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
index 7cdf60f..3c23fc4 100644
--- a/include/asm-ppc/mpc83xx.h
+++ b/include/asm-ppc/mpc83xx.h
@@ -108,6 +108,7 @@ enum ppc_sys_devices {
MPC83xx_USB2_DR,
MPC83xx_USB2_MPH,
MPC83xx_MDIO,
+ NUM_PPC_SYS_DEVS,
};
#endif /* CONFIG_83xx */
diff --git a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
index 9d14bae..2a77884 100644
--- a/include/asm-ppc/mpc85xx.h
+++ b/include/asm-ppc/mpc85xx.h
@@ -135,6 +135,7 @@ enum ppc_sys_devices {
MPC85xx_eTSEC4,
MPC85xx_IIC2,
MPC85xx_MDIO,
+ NUM_PPC_SYS_DEVS,
};
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
index 46f159c..90e3d59 100644
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -111,6 +111,7 @@ enum ppc_sys_devices {
MPC8xx_CPM_SMC1,
MPC8xx_CPM_SMC2,
MPC8xx_CPM_USB,
+ NUM_PPC_SYS_DEVS,
};
#ifndef BOARD_CHIP_NAME
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
index 83d8c77..76f259f 100644
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -47,6 +47,21 @@ struct ppc_sys_spec {
enum ppc_sys_devices *device_list;
};
+struct platform_notify_dev_map {
+ const char *bus_id;
+ void (*rtn)(struct platform_device * pdev, int idx);
+};
+
+enum platform_device_func {
+ FUNC_ENABLED = 0,
+ FUNC_ETH = 1,
+ FUNC_UART = 2,
+ FUNC_HLDC = 3,
+ FUNC_USB = 4,
+ FUNC_IRDA = 5,
+ FUNC_DISABLED = 6,
+};
+
/* describes all specific chips and which devices they have on them */
extern struct ppc_sys_spec ppc_sys_specs[];
extern struct ppc_sys_spec *cur_ppc_sys_spec;
@@ -72,5 +87,14 @@ extern void *ppc_sys_get_pdata(enum ppc_
/* remove a device from the system */
extern void ppc_sys_device_remove(enum ppc_sys_devices dev);
+/*Function assignment stuff*/
+void ppc_sys_device_initfunc(void);
+void ppc_sys_device_setfunc(enum ppc_sys_devices dev,
+ enum platform_device_func func);
+void ppc_sys_device_set_func_all(enum platform_device_func func);
+
+void platform_notify_map(const struct platform_notify_dev_map *map,
+ struct device *dev);
+
#endif /* __ASM_PPC_SYS_H */
#endif /* __KERNEL__ */
---
Sincerely,
Vitaly
^ permalink raw reply related
* Re: Howto submit drivers/patches ?
From: John Carlson @ 2005-12-19 13:10 UTC (permalink / raw)
To: David H. Lynch Jr., linuxppc-embedded
In-Reply-To: <43A64446.8080109@comcast.net>
--- "David H. Lynch Jr." <dhlii@comcast.net> wrote:
>
> I am just polishing off bringup a Xilinx Virtex
> IV/ppc405 system with
> minimal hardware under 2.6.14.4.
> I have a collection of patches that I can submit
> for the specific,
> board, for the Virtex IV, for board specific
> hardware, ...
> Additionally I have 2 complete boot loader through
> full serial driver
> implementations of a pseudo serial console driver
> for this board when it
> is in a HOST development system - it is a compact
> flash card normally
> plugged into a PC during development and using the
> PC as the console,
> and a complete serial driver chain for the Xilinx
> UartLite as a console
> when not in a Host, or as a general serial driver.
> The Xilinx Driver is
> based heavily on other 2.6 driver/serial drivers and
> not the 2.4
> implementation from Xilinx.
>
> Is this list the right place to submit this ?
> Is there a HOWTO addressing the rules/procedures to
> do so.
Look in the Documentation directory, specificly the
two files
SubmittingDrivers and SubmittingPatches where the
correct
procedure is explained.
>
> I have not looked at the kernel style guides, but
> the style of this
> code is pretty much identical to other Kernel code.
> The UartLite driver
> is virtually indistinguishable from other
> driver/serial drivers except
> the few places where hardware differences require
> changes, and that
> there is a full tree of end-end support similar to
> what exists for the
> 8250's.
>
> David H. Lynch Jr.
> DLA Systems
> 354 Rudy Dam Rd.
> Lititz, PA 17543
> 717.627.3770
>
>
>
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
John Carlson
<carlsj@yahoo.com>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] CPM initial console on ttyS instead of ttyCPM
From: Pantelis Antoniou @ 2005-12-19 13:08 UTC (permalink / raw)
To: Nathael Pajani; +Cc: linuxppc-embedded
In-Reply-To: <20051219140927.55259cea.nathael.pajani@cpe.fr>
Nathael Pajani wrote:
> Hi!
>
> here is a patch to have the CPM consoles on /dev/ttyS* instead of /dev/ttyCPM*
> Of course, it depends on not already having a 8250 like uart configured, in which case it falls back to ttyCPM.
>
> Signed-off-by: Nathael Pajani <nathael.pajani at cpe.fr>
>
[snip]
>
>
>
WTF is that? There was a reason why both the device number & name changed.
And misusing the 8250 config option, that's nice.
Try to come up with something less intrusive please.
Pantelis
^ permalink raw reply
* [PATCH] CPM initial console on ttyS instead of ttyCPM
From: Nathael Pajani @ 2005-12-19 13:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
here is a patch to have the CPM consoles on /dev/ttyS* instead of /dev/ttyC=
PM*
Of course, it depends on not already having a 8250 like uart configured, in=
which case it falls back to ttyCPM.
Signed-off-by: Nathael Pajani <nathael.pajani at cpe.fr>
diff -urpN linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_core.c ecr=
in-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_core.c
--- linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-16=
12:08:48.867092000 +0100
+++ ecrin-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-16=
11:53:13.140613000 +0100
@@ -70,10 +70,11 @@ static void cpm_uart_init_scc(struct uar
static void cpm_uart_initbd(struct uart_cpm_port *pinfo);
=20
/**************************************************************/
+/*cpm2_immr =3D (cpm2_map_t *)ioremap(CPM_MAP_ADDR, CPM_MAP_SIZE)*/
=20
static inline unsigned long cpu2cpm_addr(void *addr)
{
- if ((unsigned long)addr >=3D CPM_ADDR)
+ if( (unsigned long)addr >=3D CPM_ADDR )
return (unsigned long)addr;
return virt_to_bus(addr);
}
@@ -1072,13 +1073,13 @@ static void cpm_uart_console_write(struc
}
=20
/*
- * Setup console. Be careful is called early !
+ * Setup console. Be careful this is called early !
*/
static int __init cpm_uart_console_setup(struct console *co, char *options)
{
struct uart_port *port;
struct uart_cpm_port *pinfo;
- int baud =3D 38400;
+ int baud =3D 9600; /* NATH: was 38400 */
int bits =3D 8;
int parity =3D 'n';
int flow =3D 'n';
@@ -1136,7 +1137,11 @@ static int __init cpm_uart_console_setup
=20
static struct uart_driver cpm_reg;
static struct console cpm_scc_uart_console =3D {
+#ifndef CONFIG_SERIAL_8250
+ .name =3D "ttyS",
+#else
.name =3D "ttyCPM",
+#endif
.write =3D cpm_uart_console_write,
.device =3D uart_console_device,
.setup =3D cpm_uart_console_setup,
@@ -1163,8 +1168,14 @@ console_initcall(cpm_uart_console_init);
=20
static struct uart_driver cpm_reg =3D {
.owner =3D THIS_MODULE,
+#ifndef CONFIG_SERIAL_8250
+ .driver_name =3D "serial",
+/* .devfs_name =3D "tts/", */
+ .dev_name =3D "ttyS",
+#else
.driver_name =3D "ttyCPM",
.dev_name =3D "ttyCPM",
+#endif
.major =3D SERIAL_CPM_MAJOR,
.minor =3D SERIAL_CPM_MINOR,
.cons =3D CPM_UART_CONSOLE,
@@ -1174,7 +1185,7 @@ static int __init cpm_uart_init(void)
{
int ret, i;
=20
- printk(KERN_INFO "Serial: CPM driver $Revision: 0.01 $\n");
+ printk(KERN_INFO "Serial: CPM driver $Revision: 0.01b $\n");
=20
#ifndef CONFIG_SERIAL_CPM_CONSOLE
ret =3D cpm_uart_init_portdesc();
diff -urpN linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_cpm2.h ecr=
in-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_cpm2.h
--- linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_cpm2.h 2005-12-16=
12:08:48.883093000 +0100
+++ ecrin-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart_cpm2.h 2005-12-16=
11:53:13.144613000 +0100
@@ -20,9 +20,6 @@
#define SCC3_IRQ SIU_INT_SCC3
#define SCC4_IRQ SIU_INT_SCC4
=20
-/* the CPM address */
-#define CPM_ADDR CPM_MAP_ADDR
-
static inline void cpm_set_brg(int brg, int baud)
{
cpm_setbrg(brg, baud);
diff -urpN linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart.h ecrin-2.=
6.13.2_light/drivers/serial/cpm_uart/cpm_uart.h
--- linux-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart.h 2005-12-16 12:0=
8:48.863092000 +0100
+++ ecrin-2.6.13.2_light/drivers/serial/cpm_uart/cpm_uart.h 2005-12-16 11:5=
3:13.140613000 +0100
@@ -17,8 +17,13 @@
#include "cpm_uart_cpm1.h"
#endif
=20
-#define SERIAL_CPM_MAJOR 204
-#define SERIAL_CPM_MINOR 46
+#ifndef CONFIG_SERIAL_8250
+#define SERIAL_CPM_MAJOR TTY_MAJOR
+#define SERIAL_CPM_MINOR 64
+#else
+#define SERIAL_CPM_MAJOR 204
+#define SERIAL_CPM_MINOR 46
+#endif
=20
#define IS_SMC(pinfo) (pinfo->flags & FLAG_SMC)
#define IS_DISCARDING(pinfo) (pinfo->flags & FLAG_DISCARDING)
diff -urpN linux-2.6.13.2_light/drivers/serial/cpm_uart/Makefile ecrin-2.6.=
13.2_light/drivers/serial/cpm_uart/Makefile
--- linux-2.6.13.2_light/drivers/serial/cpm_uart/Makefile 2005-12-16 12:08:=
48.859091000 +0100
+++ ecrin-2.6.13.2_light/drivers/serial/cpm_uart/Makefile 2005-12-16 11:53:=
13.140613000 +0100
@@ -1,5 +1,5 @@
#
-# Makefile for the Motorola 8xx FEC ethernet controller
+# Makefile for the CPM ethernet controllers
#
=20
obj-$(CONFIG_SERIAL_CPM) +=3D cpm_uart.o
----=20
Nathael PAJANI
Ing=E9nieur CPE Lyon
nathael.pajani@cpe.fr
^ permalink raw reply
* Problem loading modules
From: Nathael Pajani @ 2005-12-19 13:09 UTC (permalink / raw)
To: linuxppc-embedded
Hi!=20
>I'm working with a ml403 board, porting Linux 2.4.devel on it. I got the OS
>running, but I cannot load modules.
>When I try "modprobe /lib/modules/<version>/kernel/net/<module.o>, I obtain
>the error messages:
>Note: /etc/modules.conf is more recent than
>/lib/modules/<version>/modules.dep
>modprobe: Can't locate module lib/modules/<version>/kernel/net/<module.o>
did you try with insmod ?
then try running depmod.
----=20
Nathael PAJANI
Ing=E9nieur CPE Lyon
nathael.pajani@cpe.fr
^ permalink raw reply
* Re: Ramdisk images for test
From: Wolfgang Denk @ 2005-12-19 12:39 UTC (permalink / raw)
To: HappyPhot; +Cc: linuxppc-embedded
In-Reply-To: <000501c6046b$f1abd5a0$0760120a@photon>
In message <000501c6046b$f1abd5a0$0760120a@photon> you wrote:
>
> I followed setion 7.6 of DULG and found got two Ramdisk images
> for test for ppc_82xx. One is pRamdisk, another is ramdisk_image.gz.
> Who can tell what the difference is between them ?
The former is a U-Boot/PPCBoot image, the later one a raw compressed
ramdisk image. They contain the same data, just packaged differently.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I'm a programmer: I don't buy software, I write it.
-- Tom Christiansen
^ permalink raw reply
* Re: Unable to open an initial console
From: Addison Baldwin @ 2005-12-19 12:17 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <43A31EE1.3030101@ru.mvista.com>
Thank you!
I had to create the /dev/ttyCPM0 and had to point /dev/console to it.
Now the console is working fine!
Best Regards,
Addison Baldwin
On 12/16/05, Vitaly Bordug <vbordug@ru.mvista.com> wrote:
> Addison Baldwin wrote:
> > I was sucessful to port U-Boot to our 8272 board. Now I'm experiencing
> > a problem:
> >
> > Our Kernel hangs with the message that says it was trasnferring
> > control to linux. A post morten analyzes indicated that it stopped at
> > "Unable to open an initial console" in the memory sapce where console
> > output should be out (in the sdram, like I had found somewhere in this
> > list, how to do it).
> >
> > I have checked the bootargs values, it is ok:
> > bootargs root=3D/dev/ram console=3DttyS0,115200
> >
> Only for 2.4, 2.6 is different for this.
> console=3DttyCPM0 should be there, and that device does have different ma=
jor/minor comparing to ttyS0.
> Note that the UART has to be enabled explicitly in kernel config, for mor=
e info, search this list archives.
>
> > We also checked our "/dev" and there was a link to console, pointing
> > ttyS0. Also, ttyS0 was there too.
> >
> > Does anyone have any idea how to fix it?
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
> --
> Sincerely,
> Vitaly
>
^ permalink raw reply
* Re: Howto submit drivers/patches ?
From: Vitaly Bordug @ 2005-12-19 10:09 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: Andrei Konovalov, linuxppc-embedded
In-Reply-To: <43A64446.8080109@comcast.net>
David H. Lynch Jr. wrote:
> I am just polishing off bringup a Xilinx Virtex IV/ppc405 system with
> minimal hardware under 2.6.14.4.
> I have a collection of patches that I can submit for the specific,
> board, for the Virtex IV, for board specific hardware, ...
> Additionally I have 2 complete boot loader through full serial driver
> implementations of a pseudo serial console driver for this board when it
> is in a HOST development system - it is a compact flash card normally
> plugged into a PC during development and using the PC as the console,
> and a complete serial driver chain for the Xilinx UartLite as a console
> when not in a Host, or as a general serial driver. The Xilinx Driver is
> based heavily on other 2.6 driver/serial drivers and not the 2.4
> implementation from Xilinx.
>
> Is this list the right place to submit this ?
Yes, this is the right place.
> Is there a HOWTO addressing the rules/procedures to do so.
>
Dunno actually, but that is not that tricky. Just send patches here, splitted if
possible to understand better what each one does, don't forget detailed description of a change
and the Signed-off-by: line.
> I have not looked at the kernel style guides, but the style of this
> code is pretty much identical to other Kernel code. The UartLite driver
> is virtually indistinguishable from other driver/serial drivers except
> the few places where hardware differences require changes, and that
> there is a full tree of end-end support similar to what exists for the
> 8250's.
>
> David H. Lynch Jr.
> DLA Systems
> 354 Rudy Dam Rd.
> Lititz, PA 17543
> 717.627.3770
>
>
>
>
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: POSIX High Resolution Timers in LinuxPPC 2.4
From: David Jander @ 2005-12-19 9:39 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Martin, Tim
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE4871022BB9A9@VCAEXCH01.hq.corp.viasat.com>
Hi Tim,
On Friday 16 December 2005 23:34, Martin, Tim wrote:
> Could someone give me a brief history lesson on POSIX high resolution
> timers (e.g. timer_create() function) implemented in the Linux kernel on
> the PowerPC 405 architecture? Specifically:
>
> Confirm they are in the mainline 2.6 kernel now (e.g. kernel.org)?
>
> Were they ever a part of the "mainline" 2.4 linuxppc kernel (e.g
> ppc.bkbits.net)?
>
> If no, were they ever available as a patch? The stuff at
> sourceforge.net/projects/high-res-timers stops at 2.4.20 and looks like it
> was only ever working for i386, not ppc.
I asked a related question a while back, and got no answer (yet).
I did find this though, which you might have overlooked:
http://prdownloads.sourceforge.net/high-res-timers/ppc-hrt-2.6.10.patch?download
I am equally puzzled about whether this has made it into mainstream, is about
to, or never will. I don't even know if it actually works.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Problem loading modules
From: Paula Saameño @ 2005-12-19 9:25 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hi all,
First of all, Merry Xmas!!
I'm working with a ml403 board, porting Linux 2.4.devel on it. I got the OS
running, but I cannot load modules.
When I try "modprobe /lib/modules/<version>/kernel/net/<module.o>, I obtain
the error messages:
Note: /etc/modules.conf is more recent than
/lib/modules/<version>/modules.dep
modprobe: Can't locate module lib/modules/<version>/kernel/net/<module.o>
Do you know what is going on?
Thanks!!
Paula Saameno
[-- Attachment #2: Type: text/html, Size: 561 bytes --]
^ permalink raw reply
* [PATCH] powerpc: CPM2 interrupt handler failure after 100,000
From: Nathael Pajani @ 2005-12-19 9:00 UTC (permalink / raw)
To: linuxppc-embedded
interrupts
Message-Id: <20051219100059.5a95533f.nathael.pajani@cpe.fr>
X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.9; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi!
Hum.. in the patch you moved from "void" to "int":
>-static void cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
>+static int cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
But should'nt it be "irqreturn_t" ?
static irqreturn_t cpm2_cascade(int irq, void *dev_id, struct pt_regs *regs)
+++
Have fun :)
----=20
Nathael PAJANI
Ing=E9nieur CPE Lyon
nathael.pajani@cpe.fr
^ permalink raw reply
* RE: SMP on MV64460
From: Sam Song @ 2005-12-19 7:27 UTC (permalink / raw)
To: wilhardt; +Cc: 'Lance Ware', linuxppc-embedded
In-Reply-To: <200512190413.jBJ4D9nd031244@ylpvm01.prodigy.net>
wilhardt@wilhardts.com wrote:
>
> There are a few of examples of SMP using the
> MV64460 from Curtiss Wright,
> but I don't know of a 7447A SMP (you really
> need a backside external cache
> to take advantage of SMP). The CWCEC boards
> support 2.4 or 2.6.
>
>
http://www.cwembedded.com/products/0/2/151.html/
The above linkage is broken to me. With google,
I got some other info as well. I will report
back if some improvement.
Thanks,
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* Ramdisk images for test
From: HappyPhot @ 2005-12-19 7:15 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to use ramdisk for my board. (not success yet)
I followed setion 7.6 of DULG and found got two Ramdisk images
for test for ppc_82xx. One is pRamdisk, another is ramdisk_image.gz.
Who can tell what the difference is between them ?
thank you,
/HappyPhot
^ permalink raw reply
* Mac OpenFirmware 3.x questions.
From: Andrei Warkentin @ 2005-12-19 7:11 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I was just wondering if I clearly understand the process of using the
client interface if I ever (in my kernel) decide to set up my own
virtual memory (or for that matter pretty much do anything that
involves modifying CPU state) -
1) Load saved OF-era SDR1, MSR, SPRGs, BATs, segment registers, SRR0,
SRR1, restore OF exception vectors.
2) Flush i/d caches.
3) Call client interface.
4) Load kernel SDR1, MSR, SPRGs, BATs, segment registers, SRR0, SRR1,
restore kernel exception vectors.
5) Flush i/d caches.
Does this seem reasonable? Do I need to save/restore anything else? I
understand that OF (3.x) lives in flash ROM, and only copies the
exception vectors from 0xfff----- down to 0x000----- - but where does
it store the page tables (as used by claim/release) and where is OF
physically/virtually? It would be pretty bad to wipe out OF's .bss or
whatever, or even worse... overwrite the flash itself. :)
Thanks and have a great day.
Andrei Warkentin
andrey.warkentin@gmail.com
Cell: (+1) (847) 321-15-55
Office: (+1) (312) 756-15-00 x614
^ permalink raw reply
* Howto submit drivers/patches ?
From: David H. Lynch Jr. @ 2005-12-19 5:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF22452781.22D7B3D3-ON652570D9.0019E468-652570D9.001A1298@tcs.com>
I am just polishing off bringup a Xilinx Virtex IV/ppc405 system with
minimal hardware under 2.6.14.4.
I have a collection of patches that I can submit for the specific,
board, for the Virtex IV, for board specific hardware, ...
Additionally I have 2 complete boot loader through full serial driver
implementations of a pseudo serial console driver for this board when it
is in a HOST development system - it is a compact flash card normally
plugged into a PC during development and using the PC as the console,
and a complete serial driver chain for the Xilinx UartLite as a console
when not in a Host, or as a general serial driver. The Xilinx Driver is
based heavily on other 2.6 driver/serial drivers and not the 2.4
implementation from Xilinx.
Is this list the right place to submit this ?
Is there a HOWTO addressing the rules/procedures to do so.
I have not looked at the kernel style guides, but the style of this
code is pretty much identical to other Kernel code. The UartLite driver
is virtually indistinguishable from other driver/serial drivers except
the few places where hardware differences require changes, and that
there is a full tree of end-end support similar to what exists for the
8250's.
David H. Lynch Jr.
DLA Systems
354 Rudy Dam Rd.
Lititz, PA 17543
717.627.3770
^ permalink raw reply
* RE: SMP on MV64460
From: wilhardt @ 2005-12-19 4:09 UTC (permalink / raw)
To: 'Sam Song', 'Lance Ware'; +Cc: linuxppc-embedded
In-Reply-To: <20051219025133.54341.qmail@web15807.mail.cnb.yahoo.com>
There are a few of examples of SMP using the MV64460 from Curtiss =
Wright,
but I don't know of a 7447A SMP (you really need a backside external =
cache
to take advantage of SMP). The CWCEC boards support 2.4 or 2.6.
http://www.cwembedded.com/products/0/2/151.html/
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Sam Song
Sent: Sunday, December 18, 2005 6:52 PM
To: Lance Ware
Cc: linuxppc-embedded@ozlabs.org
Subject: Re : SMP on MV64460
Lance Ware <lware@datadesigncorp.net> wrote:
> I am currently working on a board which has
> MV64460 linked between two 7447a processors. I
> wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx
> bridge.
I happen to have such a board, DB64460-BP, on
hand.=20
But even 2.4 kernel has some problems with
MV64460
PCI part. I wonder whether there is a 2.4 version
support that with PCI device like VGA card.=20
Thanks,
Sam
__________________________________________________
=B8=CF=BF=EC=D7=A2=B2=E1=D1=C5=BB=A2=B3=AC=B4=F3=C8=DD=C1=BF=C3=E2=B7=D1=D3=
=CA=CF=E4?
http://cn.mail.yahoo.com
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re : SMP on MV64460
From: Sam Song @ 2005-12-19 2:51 UTC (permalink / raw)
To: Lance Ware; +Cc: linuxppc-embedded
In-Reply-To: <000601c6028c$85eaea80$2d01a8c0@jalexander>
Lance Ware <lware@datadesigncorp.net> wrote:
> I am currently working on a board which has
> MV64460 linked between two 7447a processors. I
> wanted to know if someone has been able to get
> the Linux 2.6 kernel working with any MV64xxx
> bridge.
I happen to have such a board, DB64460-BP, on
hand.
But even 2.4 kernel has some problems with
MV64460
PCI part. I wonder whether there is a 2.4 version
support that with PCI device like VGA card.
Thanks,
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* MPC8272ADS stability issues
From: Laurie, Ian @ 2005-12-18 23:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Does anyone have any news regarding any resolution of this issue?
We have a board exhibiting crashes even at the U-boot level (memory
test for example).
Very interested in hearing if anyone has had some luck resolving
the problem.
Ian
ian at avnet dot com
^ permalink raw reply
* Re: x86 gdb with ppc8xx gdbserver
From: White @ 2005-12-18 20:56 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com>
Am Sun, 18 Dec 2005 20:44:27 +0530 schrieb Robin Mathew
<robbinmathew@gmail.com> :
> Hi,
> We are trying to setup gdbserver and gdb for target debugging. We were able
> to connect and debug with eldk's ppc8xx/gdb and ppc8xx gdbserver without any
> issues.
>
> But I am not able to compile gdb in x86 for ppc8xx target. Can you please
> point to some source tree of gdb that can be compiled for x86 platform for
> ppc8xx target? I tried with gdb version 6.4 but it does not take
> --target=ppc8xx option. I think the option that I am using to compile for
> target is not right.
>
> Any help in this regard is greatly appreciated.
>
> Thanks,
> Robin
Please Look at the Docu, i get this work some month ago, but it was a
different host,build,target config....
i dont know anymore, but perhaps it helps to try to adjust this
settings.
(I can remember some options like "supported archs" or so...)
soory, that I can't provide exact infos, but I hope this helps a little
bit.
Good Luck,
Bye.
^ permalink raw reply
* Re: x86 gdb with ppc8xx gdbserver
From: Wolfgang Denk @ 2005-12-18 20:55 UTC (permalink / raw)
To: Robin Mathew; +Cc: linuxppc-embedded
In-Reply-To: <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com>
Dear Robin,
in message <5b74ec4d0512180714r178223f6ub60df08a7ef78fc9@mail.gmail.com> you wrote:
>
> But I am not able to compile gdb in x86 for ppc8xx target. Can you please
> point to some source tree of gdb that can be compiled for x86 platform for
> ppc8xx target? I tried with gdb version 6.4 but it does not take
Since you've been successful with the ELDK binaries, why not using
the ELDK sources? Either the SRPM from the ELDK source distribution
(which gives you 5.2.1), or from the CVS, which has the (not yet
released) ELDK 4.0 code (= 6.3.0)
> --target=ppc8xx option. I think the option that I am using to compile for
> target is not right.
Indeed, it is wrong. There is no such target architecture as "ppc8xx".
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
For every complex problem, there is a solution that is simple, neat,
and wrong. -- H. L. Mencken
^ permalink raw reply
* x86 gdb with ppc8xx gdbserver
From: Robin Mathew @ 2005-12-18 15:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
Hi,
We are trying to setup gdbserver and gdb for target debugging. We were able
to connect and debug with eldk's ppc8xx/gdb and ppc8xx gdbserver without any
issues.
But I am not able to compile gdb in x86 for ppc8xx target. Can you please
point to some source tree of gdb that can be compiled for x86 platform for
ppc8xx target? I tried with gdb version 6.4 but it does not take
--target=ppc8xx option. I think the option that I am using to compile for
target is not right.
Any help in this regard is greatly appreciated.
Thanks,
Robin
[-- Attachment #2: Type: text/html, Size: 590 bytes --]
^ permalink raw reply
* Re: eldk bug?how to fix
From: Wolfgang Denk @ 2005-12-18 14:44 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <4440987.1134894054475.JavaMail.postfix@mx3.mail.sohu.com>
In message <4440987.1134894054475.JavaMail.postfix@mx3.mail.sohu.com> you wrote:
> [root@localhost atmlz]# ppc_6xx-gcc -c -o temp atm_aalx.c
> atm_aalx.c: In function `main':
> atm_aalx.c:201: warning: return type of `main' is not `int'
> /tmp/cciJlehe.s: Assembler messages:
> /tmp/cciJlehe.s:916: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:917: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:917: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:918: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:918: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:919: Error: unsupported relocation against r3
> /tmp/cciJlehe.s:3655: Error: unsupported relocation against r3
Are you by any chance using inline assembler code in your source
file? This is the only explanation I have, since GCC does not
generate "r3" references in it's assembler code.
It would have been a good idea if you had included your source code
so we could see what you are doing...
> [root@localhost atmlz]# ppc_6xx-gcc -S -o temp.s atm_aalx.c
> [root@localhost atmlz]# vi temp.s
> ...................
> stw 0,4(9)
> .L36:
> #APP
> mfmsr r3
> ori r3,r3,0x8000
> andi. r3,r3,0xffbf
> mtmsr r3
> #NO_APP
> lwz 11,0(1)
> ..............................
I see. This is your own assembler code, not something generated from
C source code.
> I must change those "r3" to "3" manually.
> How to fix?
Don't write incorrect assembler code, or use the required header
files (like ppc_asm.tmpl).
And while we are at it: be careful not to try privileged instructions
in user space.
This is your own error, not a problem with ELDK.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
^ permalink raw reply
* eldk bug?how to fix
From: zengshuai @ 2005-12-18 8:20 UTC (permalink / raw)
To: ppc
[root@localhost atmlz]# ppc_6xx-gcc -c -o temp atm_aalx.c
atm_aalx.c: In function `main':
atm_aalx.c:201: warning: return type of `main' is not `int'
/tmp/cciJlehe.s: Assembler messages:
/tmp/cciJlehe.s:916: Error: unsupported relocation against r3
/tmp/cciJlehe.s:917: Error: unsupported relocation against r3
/tmp/cciJlehe.s:917: Error: unsupported relocation against r3
/tmp/cciJlehe.s:918: Error: unsupported relocation against r3
/tmp/cciJlehe.s:918: Error: unsupported relocation against r3
/tmp/cciJlehe.s:919: Error: unsupported relocation against r3
/tmp/cciJlehe.s:3655: Error: unsupported relocation against r3
[root@localhost atmlz]# ppc_6xx-gcc -S -o temp.s atm_aalx.c
[root@localhost atmlz]# vi temp.s
...................
stw 0,4(9)
.L36:
#APP
mfmsr r3
ori r3,r3,0x8000
andi. r3,r3,0xffbf
mtmsr r3
#NO_APP
lwz 11,0(1)
..............................
I must change those "r3" to "3" manually.
How to fix?
------------------------------
我现在使用Sogou.com的2G邮箱了,你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Benjamin Herrenschmidt @ 2005-12-18 7:18 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <3a8648f28b591dee596d6cb195f1cad1@kernel.crashing.org>
> No. Their name can be whatever is required. The "device_type" should
> be "pci", for conventional PCI busses; and it should be whatever is
> defined by the appropriate OF binding for newer, mostly PCI-comnpatible,
> busses (like HT, PCIe, PCI-X, etc.)
Yes, but the recommended practice is still to call them "pci" :) The
device_type of "pci" defines the fact that it's providing a PCI bus, but
is not unique to PCI hosts, p2p bridges share it. It's a convention for
a pci host bridge however to be named "pci" while a p2p bridge is named
"pci-bridge".
As for HT, PCI-X, PCI-E etc... I don't think there are much bindings
around, but I would recommend sticking strictly to the PCI one, only
adding something to either model or compatible. We may want to
standardize some additional things that aren't in the binding, like a
pci-family (pci, pci-e, pci-x, ht) property, or a extended-config-space
to advertise support for config space > 4096, etc.
At this point, I would really like to find out the remains of the OF
working group an kick that back into life to properly define those
things.
> It is up to a device's parent bus to find the correct driver; for
> the parent bus, device_type and/or compatible are normally enough
> to do the matching. "model" is useful to disambiguate sometimes,
> but it normally is _too_ exact to do useful driver matching.
Except that OF platform devices don't really have a parent bus, they
expose a bus_type structure that can be used to match any device node in
the OF tree. There is no and there will not be a 1:1 relationship
between the OF device-tree and the linux one, so we must do compromises.
> Interrupts are evil evil evil as always ;-)
Yah, and I need to design something smart on the linux side to backup my
promise of not requiring device-nodes per PCI devices, since that means
not requiring nodes for p2p bridges neither, and thus impementing a
generic interrupt mapping algorithm that works both with full of
parsing, but also with partial one, doing standard swizzling for bridges
without a node (and with a platform hook to override that optionally).
On my todo list but not done yet.
> Yes, almost every SoC has at least two busses; e.g., you often see
> a high-speed coherent "system" bus, and a lower-speed non-coherent
> I/O bus connected to it. But there are lots of variations to this
> theme.
That shouldn't be a problem anyway. Just cascade them and don't forget
the "ranges" property :)
> SMT threads should not be represented as separate CPUs. But some
> CPU resources that are described in a CPU node are non-shared between
> SMT threads; we need to find a way to describe those.
>
> The biggest problem is interrupts (as always); the unit-id for a
> "cpu" node in OF is the IPI number of that CPU, but on SMT, IPIs
> are per thread.
Yes, that's a problem
Ben.
^ permalink raw reply
* Re: RFC: Rev 0.5 Booting the Linux/ppc kernel without Open Firmware
From: Segher Boessenkool @ 2005-12-18 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Arnd Bergmann, linuxppc64-dev
In-Reply-To: <1134856762.6102.54.camel@gaston>
>> - Do we need a way to identify the type of soc bus? There are
>> different
>> standards for this, e.g. PLB4 on PPC440 or the EIB on the Cell BE.
>> My initial idea was to have different device-type properties for
>> these,
>> but I now think that device_type = "soc" makes sense for all of
>> them.
>> Maybe we could add a model or compatible property for them.
>
> That would be a good idea.
"device_type" is what defines the (OF) programming interface. As not
all SoC busses are identical for this, they should not have the same
device_type.
If you do want all of those semi-transparent SoC busses to be found
by one wildcard, you can add it to the "compatible" property.
> Also, it might be useful to ass a "clock-frequency" to it for
> processors
> where it makes sense.
Certainly.
> One of the things we are passing from uboot
> currently is the list of clock frequencies for PLB/OPB/PCI/... we need
> to replace this with appropriate nodes and their respective
> "clock-frequency" properties
>
>> - It does not really belong into this document, but is related anyway:
>> how do you want to represent this in Linux? Currently, most of these
>> would be of_platform_device, but I think it would be good to have
>> a new bus_type for it. The advantage would be that you can see the
>> devices in /sys/devices/soc@xxx/ even if the driver is not loaded
>> and the driver can even be autoloaded by udev.
>> Also, which properties should show up in sysfs? All of them or just
>> those specified in this document or a subset of them?
All that make sense.
> If we go that way, we also need to have the SOC type take optionally
> part in the matching. That is, the driver matching infos should be
> based
> on model & compatible like OF does, thus we could recommend something
> like:
>
> - Define a unique SOC name per SOC bus type/family, for example,
> ppc4xxPLB, etc... This goes into /soc/model.
"model" should be a string that is the "official" vendor name for
the device.
> - Optionally, use compatible for similar busses. For example, if you
> have a new rev of that PLB that is similar but has extensions called
> PLB2, you can have model be ppc4xxPLB2 and compatible containing
> ppc4xxPLB.
"compatible" does not contain alternatives for "model"; it contains
alternatives for "name".
> - Define that the "model" property of a device under /soc is of the
> form "socname,devicename"... For example, EMAC would be
> ppc4xxPLB,emac",
> Same rule applies with compatible (this one could be compatible, among
> others, with "ppc4xxPLB,emac" and model "ppc4xxPLB2,emac".
>
>> - What do we do with pci root devices? They are often physically
>> connected
>> to the internal CPU bus, so it would make sense to represent them
>> this way in the device tree. Should we add them to the specification
>> here? Would it even work the expected way in Linux?
>
> They are generally below the root of the tree, they don't have to
> though. Linux shouldn't care as there is no generic code to instanciate
> them, it's platform specific. I may change that in the future though
> but
> this isn't the case yet. The only rule is their name should be "pci"
No. Their name can be whatever is required. The "device_type" should
be "pci", for conventional PCI busses; and it should be whatever is
defined by the appropriate OF binding for newer, mostly PCI-comnpatible,
busses (like HT, PCIe, PCI-X, etc.)
>> - For some devices, you mandate a model property, for others you
>> don't.
>> Is this intentional? It might be easier to find the right device
>> driver if the match string always contains a model name.
It is up to a device's parent bus to find the correct driver; for
the parent bus, device_type and/or compatible are normally enough
to do the matching. "model" is useful to disambiguate sometimes,
but it normally is _too_ exact to do useful driver matching.
>> - How would I represent nested interrupt controllers? E.g. suppose I
>> have a Cell internal interrupt controller on one SOC bus and
>> and an external interrupt controller on another SOC bus but have
>> that deliver interrupts to the first one.
>
> Read OF interrupt binding :) Typically, nodes contain either an
> interrupt-parent or a parent device with interrupt routing info (like a
> PCI bridge) which points to their actual parent controller. If it's a
> nested controller, it will itself have an interrupt parent and
> "interrupts" property to link it to its parent controller.
Interrupts are evil evil evil as always ;-)
>> - Should it mention nested SOC buses, e.g. a PLB4 bus connected to a
>> PLB5 bus?
>>
> Do we have many of these horrors in real life ?
Yes, almost every SoC has at least two busses; e.g., you often see
a high-speed coherent "system" bus, and a lower-speed non-coherent
I/O bus connected to it. But there are lots of variations to this
theme.
>> - The title says 'without Open Firmware', but it should also be
>> allowed
>> to use the same SOC bus layout when using SLOF or some other OF
>> implementation, right?
>
> Yes, in fact, this document does cover open firmware as well. It
> defines
> the flattened tree format, but doesn't exclude open firmware, and then
> defines the subset of OF required by the kernel.
>
>> - Also not new in this version, but still: Should there be support for
>> specifying CPUs with multiple SMT threads?
>
> We need to think about this...
SMT threads should not be represented as separate CPUs. But some
CPU resources that are described in a CPU node are non-shared between
SMT threads; we need to find a way to describe those.
The biggest problem is interrupts (as always); the unit-id for a
"cpu" node in OF is the IPI number of that CPU, but on SMT, IPIs
are per thread.
Segher
^ 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