* Re: [RFC/PATCH] Add a device_initcall to machdep_calls
From: Grant Likely @ 2007-11-30 23:30 UTC (permalink / raw)
To: benh; +Cc: olof, linuxppc-dev
In-Reply-To: <1196463486.13230.116.camel@pasglop>
On 11/30/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2007-11-30 at 15:51 -0700, Grant Likely wrote:
> >
> > Add a device_initcall hook to machdep_calls so that platform code
> > doesn't
> > need to register device_initcalls that must first check what platform
> > it is running on.
> >
> > This should (slightly) speed boot time on kernels that support a lot
> > of
> > boards and make device_initcall hooks slightly simpler to implement
> > because the platform doesn't need to be tested when called.
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> > ---
> >
> > Please comment; I think this is a good change, but I'd like some
> > feedback.
>
> Hrm... I'm not too sure about it...
>
> My initial idea for dealing with that issue was more along the lines of
> defining a set of
>
> machine_xxx_initcall(mach, function)
>
> Where xxx is (arch,core,subsys,fs,device, whatever...)
>
> Those could, at first be implemented as a simple macro wrapper that
> expands to a function that tests machine_is() and calls the function,
> and later one, we can do more fancy things, such as ELF sections with
> function pointers in them.
Is that level of sophistication really warranted for this scenario?
When I'm writing platform code (and granted I'm focused on the
embedded cases) then I've already tested for the board type and I
already know if I want to run that code. Typically that code is all
contained within a single board file anyway.
I'd rather start with the initcall unregistered and register it when
the board is probed instead of registering by default and testing for
exclusion.
In other words it sound like an O(1) problem being solved with an O(n) solution.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: CPM2 USB host driver
From: David Brownell @ 2007-11-30 23:18 UTC (permalink / raw)
To: Arnd Bergmann, avorontsov; +Cc: linuxppc-dev, gregkh, linux-usb-devel, mike
In-Reply-To: <200711302332.21864.arnd@arndb.de>
On Friday 30 November 2007, Arnd Bergmann wrote:
> 6100 lines means it's still the second-largest hcd driver in the kernel,
> only drivers/usb/host/u132-hcd.c has even more.
~/kernel/g26/drivers/usb/host$ wc -l ohci*[hc] |grep total
9485 total
~/kernel/g26/drivers/usb/host$ wc -l ehci*[hc] |grep total
8709 total
~/kernel/g26/drivers/usb/host$ wc -l uhci*[hc] |grep total
4211 total
~/kernel/g26/drivers/usb/host$ wc -l sl811*[hc] |grep total
2472 total
~/kernel/g26/drivers/usb/host$
Of course a lot of the OHCI stuff is various flavors of bus glue
(with more in the queue). And for one nyet-merged driver:
~/kernel/omap-2.6/drivers/usb/musb$ wc -l *[hc] | grep total
15223 total
~/kernel/omap-2.6/drivers/usb/musb$
That's an OTG driver so it includes both host and peripheral
sides, plus currently bus glue for three different chunks of
silicon (DaVinci, OMAP, TUSB6010 ... Blackfin on the way)
with three different DMA engines (sigh).
So it's not that big; larger than UHCI or sl811-hcd though. ;)
> My experience with other drivers moved into the kernel is that you
> end up rewriting it completely anyway. I can also recommend starting
> from scratch, and taking one of the in-kernel drivers as an example.
Start-from-scratch vs Incremental-rewrite ... there are advantages
to each approach.
> Maybe Greg or David can give you a suggestion which one of them
> serves as the best example for a new host driver.
I don't even know what a CPM2 is, or what kind of host it has.
(Wasn't CPM the predecessor of MS-DOS?)
Suggestions would be futile.
- Dave
^ permalink raw reply
* Cannot login via tinylogin on sequoia
From: Leonid @ 2007-11-30 23:10 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <821B2170E9E7F04FA38DF7EC21DE48710BA65802@VCAEXCH01.hq.corp.viasat.com>
Hi:
I have built u-boot, kernel and filesystem using ELDK 4.1 for AMCC
PPC440EPx sequoia board. When I boot linux using NFS filesystem,
supplied with ELDK itself, I can login (usrr root, no password). However
I couldn't login while used ramdisk, built by myself or taken from AMCC
resource CD. Combinations root/root or root/nothing don't work.=20
Sequoia login: root
Password:
Login incorrect
Please press Enter to activate this console. Dec 31 18:00:26 Sequoia
auth.warn login[37]: invalid password for `UNKNOWN' on `ttyS0'
Dec 31 18:00:26 Sequoia daemon.info init: Process '/bin/tinylogin login
-f root' (pid 37) exited. Scheduling it for restart.
How I can learn what user/password combination are configured and how do
I change them? This is static/etc/passwd from my SIMPLE filesystem:
root::0:0:root:/root:/bin/sh
bin:*:1:1:bin:/bin:
daemon:*:2:2:daemon:/sbin:
halt:*:7:0:halt:/sbin:/sbin/halt
ftp:*:14:50:FTP User:/
nobody:*:99:99:Nobody:/:
target:$1$x4Rc1j78$n5FVlLwarSyMYoZaMlijU1:200:100:Test
User:/home:/bin/sh
Thanks,
Leonid.
^ permalink raw reply
* Re: [RFC/PATCH] Add a device_initcall to machdep_calls
From: Benjamin Herrenschmidt @ 2007-11-30 22:58 UTC (permalink / raw)
To: Grant Likely; +Cc: olof, linuxppc-dev
In-Reply-To: <20071130225043.12499.86364.stgit@trillian.secretlab.ca>
On Fri, 2007-11-30 at 15:51 -0700, Grant Likely wrote:
>
> Add a device_initcall hook to machdep_calls so that platform code
> doesn't
> need to register device_initcalls that must first check what platform
> it is running on.
>
> This should (slightly) speed boot time on kernels that support a lot
> of
> boards and make device_initcall hooks slightly simpler to implement
> because the platform doesn't need to be tested when called.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Please comment; I think this is a good change, but I'd like some
> feedback.
Hrm... I'm not too sure about it...
My initial idea for dealing with that issue was more along the lines of
defining a set of
machine_xxx_initcall(mach, function)
Where xxx is (arch,core,subsys,fs,device, whatever...)
Those could, at first be implemented as a simple macro wrapper that
expands to a function that tests machine_is() and calls the function,
and later one, we can do more fancy things, such as ELF sections with
function pointers in them.
Ben.
^ permalink raw reply
* [RFC/PATCH] Add a device_initcall to machdep_calls
From: Grant Likely @ 2007-11-30 22:51 UTC (permalink / raw)
To: linuxppc-dev, vitb, galak, olof, jwboyer, benh
From: Grant Likely <grant.likely@secretlab.ca>
Add a device_initcall hook to machdep_calls so that platform code doesn't
need to register device_initcalls that must first check what platform
it is running on.
This should (slightly) speed boot time on kernels that support a lot of
boards and make device_initcall hooks slightly simpler to implement
because the platform doesn't need to be tested when called.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Please comment; I think this is a good change, but I'd like some feedback.
Cheers,
g.
arch/powerpc/kernel/setup-common.c | 11 +++++++++++
arch/powerpc/platforms/40x/kilauea.c | 5 +----
arch/powerpc/platforms/40x/virtex.c | 5 +----
arch/powerpc/platforms/40x/walnut.c | 5 +----
arch/powerpc/platforms/44x/bamboo.c | 5 +----
arch/powerpc/platforms/44x/ebony.c | 5 +----
arch/powerpc/platforms/44x/sequoia.c | 5 +----
arch/powerpc/platforms/82xx/mpc8272_ads.c | 6 ++----
arch/powerpc/platforms/82xx/pq2fads.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_mds.c | 5 +----
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 14 +++-----------
arch/powerpc/platforms/83xx/mpc834x_itx.c | 5 +----
arch/powerpc/platforms/83xx/mpc836x_mds.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 5 +----
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 9 +++------
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 5 +----
arch/powerpc/platforms/8xx/ep88xc.c | 5 ++---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 5 ++---
arch/powerpc/platforms/cell/setup.c | 5 +----
arch/powerpc/platforms/celleb/setup.c | 5 +----
arch/powerpc/platforms/pasemi/setup.c | 11 ++---------
arch/powerpc/platforms/powermac/setup.c | 9 +--------
include/asm-powerpc/machdep.h | 1 +
23 files changed, 41 insertions(+), 100 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 2de00f8..6fef005 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -610,3 +610,14 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+/* device init hook. Allow platforms to provide a device init function */
+static int __init ppc_init_device(void)
+{
+ /* call platform device init */
+ if (ppc_md.init_device)
+ return ppc_md.init_device();
+ return 0;
+}
+device_initcall(ppc_init_device);
+
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index 1bffdbd..f2bb028 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -29,14 +29,10 @@ static struct of_device_id kilauea_of_bus[] = {
static int __init kilauea_device_probe(void)
{
- if (!machine_is(kilauea))
- return 0;
-
of_platform_bus_probe(NULL, kilauea_of_bus, NULL);
return 0;
}
-device_initcall(kilauea_device_probe);
static int __init kilauea_probe(void)
{
@@ -52,6 +48,7 @@ define_machine(kilauea) {
.name = "Kilauea",
.probe = kilauea_probe,
.progress = udbg_progress,
+ .init_device = kilauea_device_probe,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/40x/virtex.c b/arch/powerpc/platforms/40x/virtex.c
index 14bbc32..76403f8 100644
--- a/arch/powerpc/platforms/40x/virtex.c
+++ b/arch/powerpc/platforms/40x/virtex.c
@@ -17,14 +17,10 @@
static int __init virtex_device_probe(void)
{
- if (!machine_is(virtex))
- return 0;
-
of_platform_bus_probe(NULL, NULL, NULL);
return 0;
}
-device_initcall(virtex_device_probe);
static int __init virtex_probe(void)
{
@@ -39,6 +35,7 @@ static int __init virtex_probe(void)
define_machine(virtex) {
.name = "Xilinx Virtex",
.probe = virtex_probe,
+ .init_device = virtex_device_probe,
.init_IRQ = xilinx_intc_init_tree,
.get_irq = xilinx_intc_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/40x/walnut.c b/arch/powerpc/platforms/40x/walnut.c
index ff6db24..3786aeb 100644
--- a/arch/powerpc/platforms/40x/walnut.c
+++ b/arch/powerpc/platforms/40x/walnut.c
@@ -34,15 +34,11 @@ static struct of_device_id walnut_of_bus[] = {
static int __init walnut_device_probe(void)
{
- if (!machine_is(walnut))
- return 0;
-
/* FIXME: do bus probe here */
of_platform_bus_probe(NULL, walnut_of_bus, NULL);
return 0;
}
-device_initcall(walnut_device_probe);
static int __init walnut_probe(void)
{
@@ -58,6 +54,7 @@ define_machine(walnut) {
.name = "Walnut",
.probe = walnut_probe,
.progress = udbg_progress,
+ .init_device = walnut_device_probe,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/44x/bamboo.c b/arch/powerpc/platforms/44x/bamboo.c
index be23f11..1aa3c3f 100644
--- a/arch/powerpc/platforms/44x/bamboo.c
+++ b/arch/powerpc/platforms/44x/bamboo.c
@@ -32,14 +32,10 @@ static struct of_device_id bamboo_of_bus[] = {
static int __init bamboo_device_probe(void)
{
- if (!machine_is(bamboo))
- return 0;
-
of_platform_bus_probe(NULL, bamboo_of_bus, NULL);
return 0;
}
-device_initcall(bamboo_device_probe);
static int __init bamboo_probe(void)
{
@@ -55,6 +51,7 @@ define_machine(bamboo) {
.name = "Bamboo",
.probe = bamboo_probe,
.progress = udbg_progress,
+ .init_device = bamboo_device_probe,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.restart = ppc44x_reset_system,
diff --git a/arch/powerpc/platforms/44x/ebony.c b/arch/powerpc/platforms/44x/ebony.c
index 6cd3476..d32065a 100644
--- a/arch/powerpc/platforms/44x/ebony.c
+++ b/arch/powerpc/platforms/44x/ebony.c
@@ -36,14 +36,10 @@ static struct of_device_id ebony_of_bus[] = {
static int __init ebony_device_probe(void)
{
- if (!machine_is(ebony))
- return 0;
-
of_platform_bus_probe(NULL, ebony_of_bus, NULL);
return 0;
}
-device_initcall(ebony_device_probe);
/*
* Called very early, MMU is off, device-tree isn't unflattened
@@ -62,6 +58,7 @@ define_machine(ebony) {
.name = "Ebony",
.probe = ebony_probe,
.progress = udbg_progress,
+ .init_device = ebony_device_probe,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.restart = ppc44x_reset_system,
diff --git a/arch/powerpc/platforms/44x/sequoia.c b/arch/powerpc/platforms/44x/sequoia.c
index 21a9dd1..9166a3d 100644
--- a/arch/powerpc/platforms/44x/sequoia.c
+++ b/arch/powerpc/platforms/44x/sequoia.c
@@ -32,14 +32,10 @@ static struct of_device_id sequoia_of_bus[] = {
static int __init sequoia_device_probe(void)
{
- if (!machine_is(sequoia))
- return 0;
-
of_platform_bus_probe(NULL, sequoia_of_bus, NULL);
return 0;
}
-device_initcall(sequoia_device_probe);
static int __init sequoia_probe(void)
{
@@ -55,6 +51,7 @@ define_machine(sequoia) {
.name = "Sequoia",
.probe = sequoia_probe,
.progress = udbg_progress,
+ .init_device = sequioa_device_probe,
.init_IRQ = uic_init_tree,
.get_irq = uic_get_irq,
.restart = ppc44x_reset_system,
diff --git a/arch/powerpc/platforms/82xx/mpc8272_ads.c b/arch/powerpc/platforms/82xx/mpc8272_ads.c
index fd83440..044a215 100644
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c
+++ b/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -165,14 +165,11 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc8272_ads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
return 0;
}
-device_initcall(declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -188,6 +185,7 @@ define_machine(mpc8272_ads)
.name = "Freescale MPC8272 ADS",
.probe = mpc8272_ads_probe,
.setup_arch = mpc8272_ads_setup_arch,
+ .init_device = declare_of_platform_devices,
.init_IRQ = mpc8272_ads_pic_init,
.get_irq = cpm2_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/82xx/pq2fads.c b/arch/powerpc/platforms/82xx/pq2fads.c
index 4f457a9..9535a37 100644
--- a/arch/powerpc/platforms/82xx/pq2fads.c
+++ b/arch/powerpc/platforms/82xx/pq2fads.c
@@ -176,20 +176,17 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(pq2fads))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
define_machine(pq2fads)
{
.name = "Freescale PQ2FADS",
.probe = pq2fads_probe,
.setup_arch = pq2fads_setup_arch,
+ .init_device = declare_of_platform_devices,
.init_IRQ = pq2fads_pic_init,
.get_irq = cpm2_get_irq,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index a19d9b6..f45046a 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -110,15 +110,11 @@ static struct of_device_id mpc832x_ids[] = {
static int __init mpc832x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc832x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
return 0;
}
-device_initcall(mpc832x_declare_of_platform_devices);
static void __init mpc832x_sys_init_IRQ(void)
{
@@ -150,6 +146,7 @@ define_machine(mpc832x_mds) {
.name = "MPC832x MDS",
.probe = mpc832x_sys_probe,
.setup_arch = mpc832x_sys_setup_arch,
+ .init_device = mpc832x_declare_of_platform_devices,
.init_IRQ = mpc832x_sys_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index 8e7492e..0f30372 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -63,9 +63,6 @@ static struct spi_board_info mpc832x_spi_boardinfo = {
static int __init mpc832x_spi_init(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
@@ -80,8 +77,6 @@ static int __init mpc832x_spi_init(void)
mpc83xx_spi_deactivate_cs);
}
-device_initcall(mpc832x_spi_init);
-
/* ************************************************************************
*
* Setup the architecture
@@ -121,17 +116,13 @@ static struct of_device_id mpc832x_ids[] = {
{},
};
-static int __init mpc832x_declare_of_platform_devices(void)
+static int __init mpc832x_rdb_init_device(void)
{
- if (!machine_is(mpc832x_rdb))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc832x_ids, NULL);
- return 0;
+ return mpc832x_spi_init();
}
-device_initcall(mpc832x_declare_of_platform_devices);
void __init mpc832x_rdb_init_IRQ(void)
{
@@ -163,6 +154,7 @@ define_machine(mpc832x_rdb) {
.name = "MPC832x RDB",
.probe = mpc832x_rdb_probe,
.setup_arch = mpc832x_rdb_setup_arch,
+ .init_device = mpc832x_rdb_init_device,
.init_IRQ = mpc832x_rdb_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 909f9a9..4312240 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -64,14 +64,10 @@ static void __init mpc834x_itx_setup_arch(void)
static int __init mpc834x_itx_declare_of_platform_devices(void)
{
- if (!machine_is(mpc834x_itx))
- return 0;
-
of_platform_bus_probe(NULL, NULL, NULL);
return 0;
}
-device_initcall(mpc834x_itx_declare_of_platform_devices);
/*
* Called very early, MMU is off, device-tree isn't unflattened
@@ -87,6 +83,7 @@ define_machine(mpc834x_itx) {
.name = "MPC834x ITX",
.probe = mpc834x_itx_probe,
.setup_arch = mpc834x_itx_setup_arch,
+ .init_device = mpc834x_itx_declare_of_platform_devices,
.init_IRQ = mpc83xx_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 67a61ac..2fd7d6a 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -141,15 +141,11 @@ static struct of_device_id mpc836x_ids[] = {
static int __init mpc836x_declare_of_platform_devices(void)
{
- if (!machine_is(mpc836x_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL, mpc836x_ids, NULL);
return 0;
}
-device_initcall(mpc836x_declare_of_platform_devices);
static void __init mpc836x_mds_init_IRQ(void)
{
@@ -181,6 +177,7 @@ define_machine(mpc836x_mds) {
.name = "MPC836x MDS",
.probe = mpc836x_mds_probe,
.setup_arch = mpc836x_mds_setup_arch,
+ .init_device = mpc836x_declare_of_platform_devices,
.init_IRQ = mpc836x_mds_init_IRQ,
.get_irq = ipic_get_irq,
.restart = mpc83xx_restart,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ads.c b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
index bccdc25..9fdfed5 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ads.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ads.c
@@ -233,13 +233,9 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
- if (!machine_is(mpc85xx_ads))
- return 0;
-
of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -255,6 +251,7 @@ define_machine(mpc85xx_ads) {
.name = "MPC85xx ADS",
.probe = mpc85xx_ads_probe,
.setup_arch = mpc85xx_ads_setup_arch,
+ .init_device = declare_of_platform_device,
.init_IRQ = mpc85xx_ads_pic_init,
.show_cpuinfo = mpc85xx_ads_show_cpuinfo,
.get_irq = mpic_get_irq,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 4d063ee..35a2ec4 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -222,9 +222,6 @@ static int mpc85xx_cds_8259_attach(void)
struct device_node *cascade_node = NULL;
int cascade_irq;
- if (!machine_is(mpc85xx_cds))
- return 0;
-
/* Initialize the i8259 controller */
for_each_node_by_type(np, "interrupt-controller")
if (of_device_is_compatible(np, "chrp,iic")) {
@@ -262,9 +259,6 @@ static int mpc85xx_cds_8259_attach(void)
return 0;
}
-
-device_initcall(mpc85xx_cds_8259_attach);
-
#endif /* CONFIG_PPC_I8259 */
/*
@@ -343,6 +337,9 @@ define_machine(mpc85xx_cds) {
.name = "MPC85xx CDS",
.probe = mpc85xx_cds_probe,
.setup_arch = mpc85xx_cds_setup_arch,
+#if defined(CONFIG_PPC_I8259) && defined(CONFIG_PCI)
+ .init_device = mpc85xx_cds_8259_attach,
+#endif
.init_IRQ = mpc85xx_cds_pic_init,
.show_cpuinfo = mpc85xx_cds_show_cpuinfo,
.get_irq = mpic_get_irq,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 61b3eed..b759387 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -144,15 +144,11 @@ static struct of_device_id mpc85xx_ids[] = {
static int __init mpc85xx_publish_devices(void)
{
- if (!machine_is(mpc85xx_mds))
- return 0;
-
/* Publish the QE devices */
of_platform_bus_probe(NULL,mpc85xx_ids,NULL);
return 0;
}
-device_initcall(mpc85xx_publish_devices);
static void __init mpc85xx_mds_pic_init(void)
{
@@ -199,6 +195,7 @@ define_machine(mpc85xx_mds) {
.name = "MPC85xx MDS",
.probe = mpc85xx_mds_probe,
.setup_arch = mpc85xx_mds_setup_arch,
+ .init_device = mpc85xx_publish_devices,
.init_IRQ = mpc85xx_mds_pic_init,
.get_irq = mpic_get_irq,
.restart = fsl_rstcr_restart,
diff --git a/arch/powerpc/platforms/8xx/ep88xc.c b/arch/powerpc/platforms/8xx/ep88xc.c
index c518b6c..0d49e1c 100644
--- a/arch/powerpc/platforms/8xx/ep88xc.c
+++ b/arch/powerpc/platforms/8xx/ep88xc.c
@@ -155,17 +155,16 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(ep88xc))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
define_machine(ep88xc) {
.name = "Embedded Planet EP88xC",
.probe = ep88xc_probe,
.setup_arch = ep88xc_setup_arch,
+ .init_device = declare_of_platform_devices,
.init_IRQ = m8xx_pic_init,
.get_irq = mpc8xx_get_irq,
.restart = mpc8xx_restart,
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index 2cf1b6a..9f88fe6 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -264,17 +264,16 @@ static struct of_device_id __initdata of_bus_ids[] = {
static int __init declare_of_platform_devices(void)
{
/* Publish the QE devices */
- if (machine_is(mpc885_ads))
- of_platform_bus_probe(NULL, of_bus_ids, NULL);
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
return 0;
}
-device_initcall(declare_of_platform_devices);
define_machine(mpc885_ads) {
.name = "Freescale MPC885 ADS",
.probe = mpc885ads_probe,
.setup_arch = mpc885ads_setup_arch,
+ .init_device = declare_of_platform_devices,
.init_IRQ = m8xx_pic_init,
.get_irq = mpc8xx_get_irq,
.restart = mpc8xx_restart,
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index 98e7ef8..b0579c8 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -85,9 +85,6 @@ static int __init cell_publish_devices(void)
{
int node;
- if (!machine_is(cell))
- return 0;
-
/* Publish OF platform devices for southbridge IOs */
of_platform_bus_probe(NULL, NULL, NULL);
@@ -101,7 +98,6 @@ static int __init cell_publish_devices(void)
}
return 0;
}
-device_initcall(cell_publish_devices);
static void cell_mpic_cascade(unsigned int irq, struct irq_desc *desc)
{
@@ -208,6 +204,7 @@ define_machine(cell) {
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
.progress = cell_progress,
+ .init_device = cell_publish_devices,
.init_IRQ = cell_init_irq,
.pci_setup_phb = rtas_setup_phb,
#ifdef CONFIG_KEXEC
diff --git a/arch/powerpc/platforms/celleb/setup.c b/arch/powerpc/platforms/celleb/setup.c
index ddfb35a..9d7a993 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -127,9 +127,6 @@ static struct of_device_id celleb_bus_ids[] __initdata = {
static int __init celleb_publish_devices(void)
{
- if (!machine_is(celleb))
- return 0;
-
/* Publish OF platform devices for southbridge IOs */
of_platform_bus_probe(NULL, celleb_bus_ids, NULL);
@@ -137,7 +134,6 @@ static int __init celleb_publish_devices(void)
return 0;
}
-device_initcall(celleb_publish_devices);
define_machine(celleb) {
.name = "Cell Reference Set",
@@ -156,6 +152,7 @@ define_machine(celleb) {
.nvram_read = beat_nvram_read,
.nvram_write = beat_nvram_write,
.set_dabr = beat_set_xdabr,
+ .init_device = celleb_publish_devices,
.init_IRQ = beatic_init_IRQ,
.get_irq = beatic_get_irq,
.pci_probe_mode = celleb_pci_probe_mode,
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 3d62060..5bd2325 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -126,9 +126,6 @@ static int __init pas_setup_mce_regs(void)
struct pci_dev *dev;
int reg;
- if (!machine_is(pasemi))
- return -ENODEV;
-
/* Remap various SoC status registers for use by the MCE handler */
reg = 0;
@@ -172,7 +169,6 @@ static int __init pas_setup_mce_regs(void)
return 0;
}
-device_initcall(pas_setup_mce_regs);
static __init void pas_init_IRQ(void)
{
@@ -369,9 +365,7 @@ static struct of_device_id pasemi_bus_ids[] = {
static int __init pasemi_publish_devices(void)
{
- if (!machine_is(pasemi))
- return 0;
-
+ pas_setup_mce_regs();
pasemi_pcmcia_init();
/* Publish OF platform devices for SDC and other non-PCI devices */
@@ -379,8 +373,6 @@ static int __init pasemi_publish_devices(void)
return 0;
}
-device_initcall(pasemi_publish_devices);
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
@@ -404,6 +396,7 @@ define_machine(pasemi) {
.probe = pas_probe,
.setup_arch = pas_setup_arch,
.init_early = pas_init_early,
+ .init_device = pasemi_publish_devices,
.init_IRQ = pas_init_IRQ,
.get_irq = mpic_get_irq,
.restart = pas_restart,
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 02c5330..a0c5a6c 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -532,12 +532,6 @@ static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
- if (machine_is(chrp))
- return -1;
-
- if (!machine_is(powermac))
- return 0;
-
np = of_find_node_by_name(NULL, "valkyrie");
if (np)
of_platform_device_create(np, "valkyrie", NULL);
@@ -553,8 +547,6 @@ static int __init pmac_declare_of_platform_devices(void)
return 0;
}
-device_initcall(pmac_declare_of_platform_devices);
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
@@ -672,6 +664,7 @@ define_machine(powermac) {
.setup_arch = pmac_setup_arch,
.init_early = pmac_init_early,
.show_cpuinfo = pmac_show_cpuinfo,
+ .init_device = pmac_declare_of_platform_devices,
.init_IRQ = pmac_pic_init,
.get_irq = NULL, /* changed later */
.pci_irq_fixup = pmac_pci_irq_fixup,
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 6968f43..39532c0 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -101,6 +101,7 @@ struct machdep_calls {
int (*probe)(void);
void (*setup_arch)(void); /* Optional, may be NULL */
void (*init_early)(void);
+ int (*init_device)(void); /* Optional, may be NULL */
/* Optional, may be NULL. */
void (*show_cpuinfo)(struct seq_file *m);
void (*show_percpuinfo)(struct seq_file *m, int i);
^ permalink raw reply related
* Re: CPM2 USB host driver
From: Arnd Bergmann @ 2007-11-30 22:32 UTC (permalink / raw)
To: avorontsov; +Cc: dbrownell, linux-usb-devel, gregkh, linuxppc-dev, mike
In-Reply-To: <20071130161136.GA27760@localhost.localdomain>
(Cc:'ing linux-usb-devel)
On Friday 30 November 2007, Anton Vorontsov wrote:
> As for FHCI driver, it's not that big (6100 lines host patch + 3516
> lines usbgadget patch), but since usb subsystem changed: you have to
> know all the changes (or to look them up) and blindly follow them. Or
> start from scratch with FHCI/cpm2usb as the reference, thus evolve
> into Linux USB expert one day.
6100 lines means it's still the second-largest hcd driver in the kernel,
only drivers/usb/host/u132-hcd.c has even more.
> Today, I think I would choose the second option. Definitely more
> fun, and most probably quicker to progress. Though, I repeat,
> I didn't look into cpm2usb project.
My experience with other drivers moved into the kernel is that you
end up rewriting it completely anyway. I can also recommend starting
from scratch, and taking one of the in-kernel drivers as an example.
Maybe Greg or David can give you a suggestion which one of them
serves as the best example for a new host driver.
Arnd <><
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: T Ziomek @ 2007-11-30 22:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, T Ziomek
In-Reply-To: <1196460928.13230.111.camel@pasglop>
On Sat, 1 Dec 2007, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 16:11 -0600, T Ziomek wrote:
>>> Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
>>> once you are done debugging :-)
>>
>> I'm probably not the only person that would turn it on when needed,
>> think
>> "well, no harm in leaving it on for the rest of my development, and it
>> might be handy; just turn it off when we're done".
>>
>> It's these kind of non-obvious but undocumented things that make a lot
>> of
>> OSS code a pain to work with for non-experts [1]. What's the harm in
>> giving folks a heads-up?
>
> There is no harm, I didn't say I wasn't going to document it, you do
> have a point there, I was just mentioning by the way, that leaving
> EARLY_DEBUG is generally not a good idea in production.
>
> One of the things that arhc/powerpc provides is the ability for you to
> have a single kernel image boot boards with different 4xx processors for
> example, or different fsl booke processors. You lose that if you leave
> early debug on as it usually contain hard coded addresses for a given
> board.
>
> This is typically useful if you have several revisions / versions of
> your product, which could use different processor revisions or even
> model, and want a single kernel image to support them.
Makes sense (my last PPC work was with arch/ppc, when arch/powerpc was
just getting started, and I'm not using PPCs at the moment).
Maybe the better comment to add for EARLY_DEBUG is to turn it off when
not of immediate concern?
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: Semaphores in eldk4.1
From: Wolfgang Denk @ 2007-11-30 22:27 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: linuxppc-embedded
In-Reply-To: <47503B5A.6090604@quadrics.com>
In message <47503B5A.6090604@quadrics.com> you wrote:
>
> I have been suing the eldk4.1 tool chain for a few months now and have
Please post ELDK related questions on the ELDK mailing list instead,
see http://lists.denx.de/mailman/listinfo/eldk
> The problem I have come up against is related to some of the semaphore
> functions in semaphore.h, namely sem_wait, sem_post. This was originally
> noticed in a third party driver I am porting from one board to another
--------------------------^^^^^^^^
> but a small test program has shown the same results.
What exactly are you talking about? Device driver (i. e. kernel)
code, or application (i. e. user space) code ?
> Calls to these functions on the ppc_82xx platform return -1 with an
> error code of 38, in this case meaning ENOSYS (not implemented). On the
Did you enable the CONFIG_SYSVIPC option in your Linux kernel
configuration?
> ppc_85xx the same program executes fine, thus I conclude that it is
> specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across
> this problem, I did find one thread but there was no conclusion listed.
There is absolutley no difference between ppc_85xx and ppc_82xx as
far as library sources or configuration are concerned. The problem is
most probably in your Linux kernel, I guess.
> I also can not find anything stating that these functions are not
> implemented for the 82xx arch compared with others for the eldk4.1
Provide a test program that fails for yuou, and we can provide much
better comments.
But please post followups on the ELDK mailing list.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Old programmers never die, they just become managers.
^ permalink raw reply
* RE: ppcboot and powerpc branch question
From: Pagnotta, Chris @ 2007-11-30 22:25 UTC (permalink / raw)
To: Wolfgang Denk, fabien; +Cc: linuxppc-embedded
In-Reply-To: <20071130221554.3AA0124075@gemini.denx.de>
Wolgang,
This question does pertain to the thread in question, but..
I am currently using your ELDK 4.1 Uclibc and have written various
scripts that allow it to be used with buildroot makefiles. Are you going
to releasing a newer version anytime soon?
Thanks,
Chris P.
-----Original Message-----
From: linuxppc-embedded-bounces+chris.pagnotta=3Dviasat.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+chris.pagnotta=3Dviasat.com@ozlabs.org]=
On Behalf Of Wolfgang Denk
Sent: Friday, November 30, 2007 2:16 PM
To: fabien
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: ppcboot and powerpc branch question
In message <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com>
you wrote:
>=20
> instead of bd_t struct. I'm a bit disappointed because i also see that
> older u-boot (in my case
> ppcboot 1.1.5) aren't capable to pass dts to kernel.
PPCBoot was a in a distant past before U-Boot. Actually, PPCBoot
1.1.5 is more than 5 and a half years old. You cannot really expect a
Neanderthal man to drive a space shuttle.
> Is there a way to keep my old bootloader to boot a powerpc branch
kernel ?
No. Please use a current U-Boot (i. e. at least U-Boot 1.3.0).
Best regards,
Wolfgang Denk
--=20
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
As in certain cults it is possible to kill a process if you know its
true name. -- Ken Thompson and Dennis M. Ritchie
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* current ARCH=powerpc for v2pro.
From: Stephen Neuendorffer @ 2007-11-30 22:21 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
Grant,
I'm trying to bring up your arch/powerpc work, using a compiled in
device tree. I added this:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..48f745d 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -53,7 +53,7 @@ src-wlib :=3D string.S crt0.S stdio.c main.c
flatdevtree.c flatd
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c
uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
src-plat :=3D of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+ virtex.c cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c
cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c
cuboot-bamboo.c=20
fixed-head.S ep88xc.c cuboot-hpc2.c
@@ -159,6 +159,7 @@ image-$(CONFIG_EBONY) +=3D
treeImage.ebo
image-$(CONFIG_BAMBOO) +=3D treeImage.bamboo
cuImage.bamboo
image-$(CONFIG_SEQUOIA) +=3D cuImage.sequoia
image-$(CONFIG_WALNUT) +=3D treeImage.walnut
+image-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) +=3D
zImage.virtex
endif
=20
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/virtex.c b/arch/powerpc/boot/virtex.c
new file mode 100644
index 0000000..32cebc1
--- /dev/null
+++ b/arch/powerpc/boot/virtex.c
@@ -0,0 +1,20 @@
+
+
+#include "ops.h"
+#include "stdio.h"
+#include "dcr.h"
+#include "4xx.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(void)
+{
+ unsigned long end_of_ram =3D 0xfffffff;
+ unsigned long avail_ram =3D end_of_ram - (unsigned long) _end;
+
+ simple_alloc_init(_end, avail_ram, 32, 32);
+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ serial_console_init();
+ printf("booting virtex\n");
+}
and got as far as:
---
booting virtex
zImage starting: loaded at 0x00400000 (sp: 0x00551f14)
Allocating 0x2d7324 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040b000:0x00550d74)...done 0x2b35ec bytes
Linux/PowerPC load: root=3D/dev/xsysace/disc0/part2
Finalizing device tree... flat tree at 0x409870
---
Tracing through the code, it appears that there is a machine check in
memset_io in early_init():
unsigned long __init early_init(unsigned long dt_ptr)
{
unsigned long offset =3D reloc_offset();
struct cpu_spec *spec;
/* First zero the BSS -- use memset_io, some platforms don't
have
* caches on yet */
memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
__bss_stop - __bss_start);
/*
* Identify the CPU type and fix up code sections
* that depend on which cpu we have.
*/
spec =3D identify_cpu(offset, mfspr(SPRN_PVR));
do_feature_fixups(spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
return KERNELBASE + offset;
}
Which seems bizarre, because that code is very simple. I'm guessing
that something in the memory configuration is wierd (or maybe
zImage.virtex is not the right way to do this?) but I'm a little lost
where to look from here. I also tried it with both paulus_master and
your virtex-for-2.6.24 branch.
Any ideas?
Steve
^ permalink raw reply related
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Benjamin Herrenschmidt @ 2007-11-30 22:15 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301605540.5450@gauley.ddna.labs.mot.com>
On Fri, 2007-11-30 at 16:11 -0600, T Ziomek wrote:
> > Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
> > once you are done debugging :-)
>
> I'm probably not the only person that would turn it on when needed,
> think
> "well, no harm in leaving it on for the rest of my development, and it
> might be handy; just turn it off when we're done".
>
> It's these kind of non-obvious but undocumented things that make a lot
> of
> OSS code a pain to work with for non-experts [1]. What's the harm in
> giving folks a heads-up?
There is no harm, I didn't say I wasn't going to document it, you do
have a point there, I was just mentioning by the way, that leaving
EARLY_DEBUG is generally not a good idea in production.
One of the things that arhc/powerpc provides is the ability for you to
have a single kernel image boot boards with different 4xx processors for
example, or different fsl booke processors. You lose that if you leave
early debug on as it usually contain hard coded addresses for a given
board.
This is typically useful if you have several revisions / versions of
your product, which could use different processor revisions or even
model, and want a single kernel image to support them.
Ben.
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: Wolfgang Denk @ 2007-11-30 22:15 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com>
In message <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com> you wrote:
>
> instead of bd_t struct. I'm a bit disappointed because i also see that
> older u-boot (in my case
> ppcboot 1.1.5) aren't capable to pass dts to kernel.
PPCBoot was a in a distant past before U-Boot. Actually, PPCBoot
1.1.5 is more than 5 and a half years old. You cannot really expect a
Neanderthal man to drive a space shuttle.
> Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
No. Please use a current U-Boot (i. e. at least U-Boot 1.3.0).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
As in certain cults it is possible to kill a process if you know its
true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Scott Wood @ 2007-11-30 22:14 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301605540.5450@gauley.ddna.labs.mot.com>
T Ziomek wrote:
> On Sat, 1 Dec 2007, Benjamin Herrenschmidt wrote:
>> Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
>> once you are done debugging :-)
>
> I'm probably not the only person that would turn it on when needed, think
> "well, no harm in leaving it on for the rest of my development, and it
> might be handy; just turn it off when we're done".
>
> It's these kind of non-obvious but undocumented things that make a lot of
> OSS code a pain to work with for non-experts [1]. What's the harm in
> giving folks a heads-up?
Well, the config text does say "(dangerous)"...
-Scott
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: T Ziomek @ 2007-11-30 22:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196456185.13230.100.camel@pasglop>
On Sat, 1 Dec 2007, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 13:10 -0600, T Ziomek wrote:
>>> This patch makes the early debug option force the console loglevel
>>> to the max. The early debug option is meant to catch messages very
>>> early in the kernel boot process, in many cases, before the kernel
>>> has a chance to parse the "debug" command line argument. Thus it
>>> makes sense when CONFIG_PPC_EARLY_DEBUG is set, to force the console
>>> log level to the max at boot time.
>> . . .
>>> +#ifdef CONFIG_PPC_EARLY_DEBUG
>>> + console_loglevel = 10;
>>> +#endif
>>> }
>>
>> The change makes sense, but wouldn't it also make sense to note it in
>> arch/powerpc/Kconfig.debug? Otherwise it's really hard to figure out
>> why,
>> after bringing up a new board, removing "debug" from the kernel cmd
>> line
>> does, well, nothing.
>
> Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
> once you are done debugging :-)
I'm probably not the only person that would turn it on when needed, think
"well, no harm in leaving it on for the rest of my development, and it
might be handy; just turn it off when we're done".
It's these kind of non-obvious but undocumented things that make a lot of
OSS code a pain to work with for non-experts [1]. What's the harm in
giving folks a heads-up?
[1] : And I don't just mean newbies...I mean anybody who doesn't live in
the code on a daily basis year-round.
--
/"\ ASCII Ribbon Campaign |
\ / | Email to user 'CTZ001'
X Against HTML | at 'email.mot.com'
/ \ in e-mail & news |
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Kumar Gala @ 2007-11-30 21:56 UTC (permalink / raw)
To: benh; +Cc: Olof Johansson, netdev, jgarzik, linuxppc-dev
In-Reply-To: <1196456356.13230.104.camel@pasglop>
On Nov 30, 2007, at 2:59 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
>> Hi,
>>
>> On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt
>> wrote:
>>
>>> This adds support for the Agere ET1011c PHY as found on the AMCC
>>> Taishan
>>> board.
>>
>> The whole patch has whitespace messed up (tabs vs spaces).
>
> Thanks for noticing it on the ...3rd time those are sent to the
> list...
Clearly if you used checkpatch.pl you'd have noticed this by now. :)
- k
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-11-30 21:44 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071130153242.6ea7e5ae@zod.rchland.ibm.com>
On Fri, 2007-11-30 at 15:32 -0600, Josh Boyer wrote:
> On Sat, 01 Dec 2007 07:57:09 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> > > On Fri, 30 Nov 2007 17:11:01 +1100
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > > From: Hugh Blemings <hugh@blemings.org>
> > > >
> > > >
> > > > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > > ---
> > > >
> > > > This needs a bit of cleanup still, probably not to be merged as-is
> > > > just yet (like using mtdcri/mfdcri for CPR access).
> > > >
> > > > arch/powerpc/Kconfig.debug | 6
> > > > arch/powerpc/boot/44x.h | 1
> > > > arch/powerpc/boot/Makefile | 7
> > >
> > > Small conflict in the Makefile keeps this from applying cleanly.
> >
> > Can you tell me more ? doesn't conflict here.
>
> You have cuImage.bamboo with a comment in front of it.
Oh... yeah, ok, my bad, I see where that comes from. I'll fix it up.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Josh Boyer @ 2007-11-30 21:32 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196456229.13230.102.camel@pasglop>
On Sat, 01 Dec 2007 07:57:09 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> > On Fri, 30 Nov 2007 17:11:01 +1100
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > From: Hugh Blemings <hugh@blemings.org>
> > >
> > >
> > > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > > ---
> > >
> > > This needs a bit of cleanup still, probably not to be merged as-is
> > > just yet (like using mtdcri/mfdcri for CPR access).
> > >
> > > arch/powerpc/Kconfig.debug | 6
> > > arch/powerpc/boot/44x.h | 1
> > > arch/powerpc/boot/Makefile | 7
> >
> > Small conflict in the Makefile keeps this from applying cleanly.
>
> Can you tell me more ? doesn't conflict here.
You have cuImage.bamboo with a comment in front of it.
josh
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Olof Johansson @ 2007-11-30 21:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <1196456356.13230.104.camel@pasglop>
On Sat, Dec 01, 2007 at 07:59:16AM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
> > Hi,
> >
> > On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
> > > board.
> >
> > The whole patch has whitespace messed up (tabs vs spaces).
>
> Thanks for noticing it on the ...3rd time those are sent to the list...
Yeah, sorry about that. Should have caught it sooner.
Anyway, can be fixed up with incremental patch, doesn't need to hold up
the whole series.
-Olof
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Olof Johansson @ 2007-11-30 21:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196456043.13230.96.camel@pasglop>
On Sat, Dec 01, 2007 at 07:54:03AM +1100, Benjamin Herrenschmidt wrote:
>
> On Fri, 2007-11-30 at 08:15 -0600, Olof Johansson wrote:
> > On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt wrote:
> >
> > > There will be further cleanups and fixes before 2.6.25 opens
> >
> > May I suggest running them through checkpatch.pl? It finds stuff in over
> > half of the ones I tried it on :)
>
> and I don't give a shit about checkpatch.pl
That's up to you, but I've found that it saves a handful of nitpicky
comments about whitespace, etc, after posting. It doesn't mean every
single warning from it has to be followed.
Since you said you'd post this series again I figured it could be useful
to fix the whitespace it finds, instead of having people find it by hand
when reading the patches.
That's all.
-Olof
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Benjamin Herrenschmidt @ 2007-11-30 20:54 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130141540.GA3117@lixom.net>
On Fri, 2007-11-30 at 08:15 -0600, Olof Johansson wrote:
> On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt wrote:
>
> > There will be further cleanups and fixes before 2.6.25 opens
>
> May I suggest running them through checkpatch.pl? It finds stuff in over
> half of the ones I tried it on :)
and I don't give a shit about checkpatch.pl
Ben.
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Benjamin Herrenschmidt @ 2007-11-30 20:59 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130142904.GC3117@lixom.net>
On Fri, 2007-11-30 at 08:29 -0600, Olof Johansson wrote:
> Hi,
>
> On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt wrote:
>
> > This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
> > board.
>
> The whole patch has whitespace messed up (tabs vs spaces).
Thanks for noticing it on the ...3rd time those are sent to the list...
Ben.
^ permalink raw reply
* Re: [PATCH 18/24] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-11-30 20:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071130140825.67721825@zod.rchland.ibm.com>
On Fri, 2007-11-30 at 14:08 -0600, Josh Boyer wrote:
> On Fri, 30 Nov 2007 17:11:01 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > From: Hugh Blemings <hugh@blemings.org>
> >
> >
> > Signed-off-by: Hugh Blemings <hugh@blemings.org>
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> >
> > This needs a bit of cleanup still, probably not to be merged as-is
> > just yet (like using mtdcri/mfdcri for CPR access).
> >
> > arch/powerpc/Kconfig.debug | 6
> > arch/powerpc/boot/44x.h | 1
> > arch/powerpc/boot/Makefile | 7
>
> Small conflict in the Makefile keeps this from applying cleanly.
Can you tell me more ? doesn't conflict here.
Ben.
^ permalink raw reply
* Re: [PATCH 15/24] powerpc: early debug forces console log level to max
From: Benjamin Herrenschmidt @ 2007-11-30 20:56 UTC (permalink / raw)
To: T Ziomek; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711301306520.5450@gauley.ddna.labs.mot.com>
On Fri, 2007-11-30 at 13:10 -0600, T Ziomek wrote:
> > This patch makes the early debug option force the console loglevel
> > to the max. The early debug option is meant to catch messages very
> > early in the kernel boot process, in many cases, before the kernel
> > has a chance to parse the "debug" command line argument. Thus it
> > makes sense when CONFIG_PPC_EARLY_DEBUG is set, to force the console
> > log level to the max at boot time.
> . . .
> > +#ifdef CONFIG_PPC_EARLY_DEBUG
> > + console_loglevel = 10;
> > +#endif
> > }
>
> The change makes sense, but wouldn't it also make sense to note it in
> arch/powerpc/Kconfig.debug? Otherwise it's really hard to figure out
> why,
> after bringing up a new board, removing "debug" from the kernel cmd
> line
> does, well, nothing.
Possibly, though you aren't supposed to leave EARLY_DEBUG enabled
once you are done debugging :-)
Ben.
^ permalink raw reply
* Re: [RFC][PATCH] [POWERPC] Allow caching of kmap_atomic page
From: Benjamin Herrenschmidt @ 2007-11-30 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0711300311490.1799@blarg.am.freescale.net>
On Fri, 2007-11-30 at 03:14 -0600, Kumar Gala wrote:
> Skip updating the kmap_pte and flushing the TLB if the pte we
> are about to write is the same as the one we wrote last time we
> called kmap_atomic for this km_type.
>
> Also expose the flags to allow a caller to specify their own
> flags for things like non-cacheable IO memory.
>
> ---
>
> This is the starts of some work Ben and I were discussion to allow us to
> use kmap_atomic to access a page size region of PCI CFG space when its
> provided as direct MMIO.
>
> We also intend to provide a means to preload the TLB for SW managed TLB
> machines.
We probably need to move that outside of highmem though...
Cheers,
Ben.
> - k
>
> include/asm-powerpc/highmem.h | 16 +++++++++++++---
> 1 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
> index f7b21ee..a50bb00 100644
> --- a/include/asm-powerpc/highmem.h
> +++ b/include/asm-powerpc/highmem.h
> @@ -73,10 +73,12 @@ static inline void kunmap(struct page *page)
> * be used in IRQ contexts, so in some (very limited) cases we need
> * it.
> */
> -static inline void *kmap_atomic(struct page *page, enum km_type type)
> +static inline void *__kmap_atomic(struct page *page,
> + enum km_type type, unsigned long flags)
> {
> unsigned int idx;
> unsigned long vaddr;
> + pte_t pte;
>
> /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
> pagefault_disable();
> @@ -88,12 +90,20 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
> #ifdef HIGHMEM_DEBUG
> BUG_ON(!pte_none(*(kmap_pte+idx)));
> #endif
> - set_pte_at(&init_mm, vaddr, kmap_pte+idx, mk_pte(page, kmap_prot));
> - flush_tlb_page(NULL, vaddr);
> + pte = mk_pte(page, flags);
> + if (!pte_same(kmap_pte[idx], pte)) {
> + set_pte_at(&init_mm, vaddr, kmap_pte+idx, pte);
> + flush_tlb_page(NULL, vaddr);
> + }
>
> return (void*) vaddr;
> }
>
> +static inline void *kmap_atomic(struct page *page, enum km_type type)
> +{
> + return __kmap_atomic(page, type, kmap_prot);
> +}
> +
> static inline void kunmap_atomic(void *kvaddr, enum km_type type)
> {
> #ifdef HIGHMEM_DEBUG
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Josh Boyer @ 2007-11-30 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196403038.569525.367459803520.qpush@grosgo>
On Fri, 30 Nov 2007 17:10:38 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Here's a set of patches that bring PCI, PCI-X and PCI-Express
> support to 4xx on arch/powerpc. It also changes/fixed various
> bits and pieces, such as a bit of rework of arch/powerpc/boot
> 4xx code, adding a couple of new platforms along the way.
>
> There are some issues with the SCSI stack vs. non-coherent
> DMA that I'm working on fixing separately, and there's a
> problem I noticed with the e1000 driver vs. 64 bits resources
> on 32 bits architectures for which I also have a patch that
> I posted separately. Appart from that, I got it working fine
> with a USB2 card in an ebony and 2 USB storage devices.
>
> Some of these patches are _NOT_ yet candidate for merging
> (mostly the board support ones), but you can review them and
> Josh can put them in an experimental tree.
I've added these to the 2.6.25-candidates branch in my tree. Fixed up
the few conflicts manually. I'll expect refreshes before merging
anyway, but I'd like to get these out there for people to play with.
josh
^ 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