* RE: [PATCH 0/5 v3] Porting RapidIO driver from ppc to powerpc architecture and adding memory mapped RapidIO driver.
From: Zhang Wei-r63237 @ 2007-11-12 2:18 UTC (permalink / raw)
To: Randy Vinson; +Cc: linuxppc-dev
In-Reply-To: <4734E089.8070800@mvista.com>
Hi, Randy,
I'll post it soon and hope to get much feedback from you.
Thanks!
Wei.=20
> -----Original Message-----
> From: Randy Vinson [mailto:rvinson@mvista.com]=20
>=20
> Zhang Wei-r63237 wrote:
> > Yes, I'm working on it. Do not worry about it.
> How's this going? I've been working on this a bit myself, but=20
> if you are
> close to posting your stuff, I'll stop and wait for your version
> instead. It doesn't make sense for us to duplicate the same work.
>=20
> Randy Vinson
>=20
^ permalink raw reply
* [PATCH] Demote clockevent printk to KERN_DEBUG.
From: Tony Breeds @ 2007-11-12 3:25 UTC (permalink / raw)
To: LinuxPPC-dev
These don't need to be seen by eveyone on every boot.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/kernel/time.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 4beb632..c0d7772 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -829,7 +829,7 @@ static void register_decrementer_clockevent(int cpu)
*dec = decrementer_clockevent;
dec->cpumask = cpumask_of_cpu(cpu);
- printk(KERN_INFO "clockevent: %s mult[%lx] shift[%d] cpu[%d]\n",
+ printk(KERN_DEBUG "clockevent: %s mult[%lx] shift[%d] cpu[%d]\n",
dec->name, dec->mult, dec->shift, cpu);
clockevents_register_device(dec);
--
1.5.3.5
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: David Gibson @ 2007-11-12 3:04 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IqUun-00063a-7g@jdl.com>
On Fri, Nov 09, 2007 at 08:32:57AM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> >
> > But you do take a hit w.r.t. *minimum* representation size - there's
> > no form amongst all the possibilities here more compact than pure hex.
> > Especially since spaces are optional in the old form. The fact that
> > [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
> > original form.
> >
> > The point of [] is for random binary data which is neither strings
> > (even with the odd strange character) nor sensibly organized into
> > 32-bit (or larger) integers. Wanting something other than hex here is
> > much rarer than in the < > case.
> >
> > You're seeing < > and [ ] as basically the same thing - a list of
> > values - with the only difference being the size of those values.
> > That's not wrong, but it's not the only way to look at it - and it's
> > not the way I was thinking of [ ] when I invented it. Your proposal
> > makes perfect sense while you think of [] as a list of values - but
> > not so much when it's thought of as a direct binary representation.
> >
> > So I'm thinking perhaps we need two different things here: a "list of
> > values" representation, which can accomodate expressions and can also
> > have multiple sizes (because expressions which are evaluated to a
> > 16-bit or 64-bit value could also be useful under the right
> > circumstances), and the [ ] "bytestring
> > literal" representation. Perhaps something like:
> >
> > (32-bit values)
> > <0xdeadbeef (1+1)>
> > or <.32 0xdeadbeef (1+1)>
> >
> > (64-bit values)
> > <.64 (0xdeadbeef << 32) (-1)>
> > (8-bit values)
> > <.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
> >
> > i.e. < > is list of values form, with size of each value as a sort of
> > parameter (defaulting to 32-bit, of course). I'm not sure I like that
> > particular syntax, it's just the first thing I came up with to
> > demonstrate the idea.
>
>
> Ah ha! I see. You want this, then:
>
> x = <.srec 0000 C001C0DEGE75BABE F1>
>
> OK. That was entirely joking. We all know that
> the cool code does NOT get the babe.
Hrm.. I think I'm not getting all the allusions here.
> Seriously though, I see your point, and I don't really
> have a strong opinion here, so in the interest of making
> some headway, we can just leave it as is for now.
>
> If it turns out to be a bad decision later, we'll fix it. :-)
Works for me. And we even have some ideas on how to fix it, if we
have to, without too much horror, so that seems like a reasonable
position to me.
> And with that issue behind us....
>
> I'm going to post these patches to introduce the new DTS format!
> Any last straggler comments?
Hurrah. Let's do it!
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] [POWERPC] Silence an annoying boot message
From: Stephen Rothwell @ 2007-11-12 2:53 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
vmemmap_populate will printk (with KERN_WARNING) for a lot of pages
if CONFIG_SPARSEMEM_VMEMMAP is enabled (at least it does on iSeries).
Turn it into a DEBUG message.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/init_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Without this patch, all the messages before this one are purged from the
console buffer. Is this really a warning?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index d9c82d3..ee0e0cc 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -239,7 +239,7 @@ int __meminit vmemmap_populate(struct page *start_page,
if (!p)
return -ENOMEM;
- printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
+ DBG(KERN_DEBUG "vmemmap %08lx allocated at %p, "
"physical %08lx.\n", start, p, __pa(p));
mapped = htab_bolt_mapping(start, start + page_size,
--
1.5.3.5
^ permalink raw reply related
* Re: Do not depend on MAX_ORDER when grouping pages by mobility
From: Stephen Rothwell @ 2007-11-12 2:21 UTC (permalink / raw)
To: Mel Gorman; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Hi Mel,
I discovered recently that a kernel built with ppc64_defconfig no longer
boots on legacy iSeries. It did in 2.6.23. I bisected down the commit
d9c2340052278d8eb2ffb16b0484f8f794def4de ("Do not depend on MAX_ORDER
when grouping pages by mobility") which fails while its parent is ok.
Also, an iseries_defconfig kernel will boot. The reason it seem is
because on PowerPC 64 with CONFIG_HUGETLB_PAGE, HPAGE_SHIFT is not
constant and its value is determined at runtime early.
For legacy iSeries HPAGE_SHIFT remains 0 which means that
HUGETLB_PAGE_ORDER becomes -PAGE_SHIFT and things degenerate badly.
I can enable CONFIG_HUGETLB_PAGE_SIZE_VARIABLE for PowerPC 64, but I
still need to know a good value for HPAGE_SHIFT. Do you have a
suggestion? Is there a better way to fix this problem? There are places
in the PowerPC code that assume that HPAGE_SHIFT == 0 means that we have
no huge pages.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Gianfar ethernet device
From: Benjamin Herrenschmidt @ 2007-11-12 2:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111716oea3572fq9bc42221f805e11@mail.gmail.com>
On Sun, 2007-11-11 at 20:16 -0500, Jon Smirl wrote:
>
> Are there powerpc platforms without device trees?
Not in arch/powerpc.
Ben.
^ permalink raw reply
* [RFC] Disabling platform bus and using only of_platform bus
From: Jon Smirl @ 2007-11-12 1:45 UTC (permalink / raw)
To: PowerPC dev list
Disabling platform bus and using only of_platform bus works for my
mpc5200 system. Attached is a first pass at a patch implementing
of_platform bus only. Suggestions on the correct ways to do the things
needed?
alsa soc in kernel uses platform bus, asoc v2 is under development and
it removes asoc from the platform bus. I tested these patches with
asoc v2.
root@phyCORE-MPC5200B-tiny:/sys/bus ls
asoc mdio_bus of_platform scsi spi
i2c mmc pci sdio usb
BTW, turning off platform bus exposed some general problems (driver
core fixing up parent pointer to point at platform bus when the device
lives on of_platform bus). This is a useful thing to check out on all
of the powerpc platforms. The patch only fixes things up for mpc5200.
There is another patch that was already posted for review that moves
fsl_i2c out of fsl_soc and into mpc_i2c.c.
-----------------------------------------------------------------------------------------------------------
Make the platform bus optional on PowerPC
From: Jon Smirl <jonsmirl@gmail.com>
---
drivers/base/Kconfig | 8 ++++++++
drivers/base/Makefile | 3 ++-
drivers/base/init.c | 2 ++
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d7da109..b05f4a2 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -26,6 +26,14 @@ config PREVENT_FIRMWARE_BUILD
should be made.
If unsure say Y here.
+config PLATFORM_BUS
+ bool "Create the platform bus"
+ default y
+ help
+ The platform bus is used to access hardware built into the CPU or
on the motherboard.
+ On the PowerPC architecture the of_platform bus replaces platform bus.
+ If unsure say Y here.
+
config FW_LOADER
tristate "Userspace firmware loading support"
depends on HOTPLUG
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index b39ea3f..60a15eb 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -1,10 +1,11 @@
# Makefile for the Linux device tree
obj-y := core.o sys.o bus.o dd.o \
- driver.o class.o platform.o \
+ driver.o class.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o
obj-y += power/
+obj-$(PLATFORM_BUS) += platform.o
obj-$(CONFIG_HAS_DMA) += dma-mapping.o dmapool.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER) += firmware_class.o
diff --git a/drivers/base/init.c b/drivers/base/init.c
index 3713815..b8b276b 100644
--- a/drivers/base/init.c
+++ b/drivers/base/init.c
@@ -32,7 +32,9 @@ void __init driver_init(void)
/* These are also core pieces, but must come after the
* core core pieces.
*/
+#ifdef CONFIG_PLATFORM_BUS
platform_bus_init();
+#endif
system_bus_init();
cpu_dev_init();
memory_dev_init();
-----------------------------------------------------------------------------------------------
Ifdef out some MPC83xx code that is building on the MPC5200
From: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/kernel/setup-common.c | 2 ++
arch/powerpc/sysdev/fsl_soc.c | 7 ++++++-
drivers/i2c/i2c-core.c | 10 +++++-----
drivers/scsi/hosts.c | 6 ++++--
4 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 2de00f8..93afc97 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -439,6 +439,7 @@ void __init smp_setup_cpu_sibling_map(void)
}
#endif /* CONFIG_SMP */
+#if defined(CONFIG_AMIGA) || defined(CONFIG_MAC) || defined(CONFIG_ATARI)
static __init int add_pcspkr(void)
{
struct device_node *np;
@@ -461,6 +462,7 @@ static __init int add_pcspkr(void)
return ret;
}
device_initcall(add_pcspkr);
+#endif
void probe_machine(void)
{
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index d6ef264..7017510 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -130,6 +130,7 @@ u32 get_baudrate(void)
EXPORT_SYMBOL(get_baudrate);
#endif /* CONFIG_CPM2 */
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_85xx) ||
defined(CONFIG_PPC_86xx)
static int __init gfar_mdio_of_init(void)
{
struct device_node *np;
@@ -317,6 +318,7 @@ err:
}
arch_initcall(gfar_of_init);
+#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
@@ -379,7 +381,7 @@ nodev:
}
arch_initcall(mpc83xx_wdt_init);
-#endif
+
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
@@ -542,6 +544,7 @@ err:
}
arch_initcall(fsl_usb_of_init);
+#endif
#ifndef CONFIG_PPC_CPM_NEW_BINDING
#ifdef CONFIG_CPM2
@@ -1085,6 +1088,7 @@ arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
#endif /* CONFIG_PPC_CPM_NEW_BINDING */
+#if defined(CONFIG_PPC_83xx)
int __init fsl_spi_init(struct spi_board_info *board_infos,
unsigned int num_board_infos,
void (*activate_cs)(u8 cs, u8 polarity),
@@ -1174,6 +1178,7 @@ err:
return spi_register_board_info(board_infos, num_board_infos);
}
+#endif
#if defined(CONFIG_PPC_85xx) || defined(CONFIG_PPC_86xx)
static __be32 __iomem *rstcr;
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 8b49860..f99b909 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -340,6 +340,11 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
struct list_head *item;
struct i2c_driver *driver;
+ if (adap->dev.parent == NULL) {
+ printk(KERN_ERR "I2C adapter driver [%s] forgot to specify "
+ "physical device\n", adap->name);
+ return -ENODEV;
+ }
mutex_init(&adap->bus_lock);
mutex_init(&adap->clist_lock);
INIT_LIST_HEAD(&adap->clients);
@@ -351,11 +356,6 @@ static int i2c_register_adapter(struct i2c_adapter *adap)
* If the parent pointer is not set up,
* we add this adapter to the host bus.
*/
- if (adap->dev.parent == NULL) {
- adap->dev.parent = &platform_bus;
- pr_debug("I2C adapter driver [%s] forgot to specify "
- "physical device\n", adap->name);
- }
sprintf(adap->dev.bus_id, "i2c-%d", adap->nr);
adap->dev.release = &i2c_adapter_dev_release;
adap->dev.class = &i2c_adapter_class;
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 24271a8..377b66d 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -203,8 +203,10 @@ int scsi_add_host(struct Scsi_Host *shost, struct
device *dev)
goto out;
}
- if (!shost->shost_gendev.parent)
- shost->shost_gendev.parent = dev ? dev : &platform_bus;
+ if (!shost->shost_gendev.parent) {
+ printk(KERN_ERR "shost->shost_gendev.parent must not be NULL\n");
+ goto out;
+ }
error = device_add(&shost->shost_gendev);
if (error)
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: Gianfar ethernet device
From: Jon Smirl @ 2007-11-12 1:16 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <1194829680.18185.10.camel@pasglop>
On 11/11/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > The real solution is that gianfar support belongs in a device driver,
> > not in a common file. That whole fsl_soc.c file is a catch-all of
> > things that belong in device drivers. I haven't looked at every line
> > in it, but 90%+ of the code should be moved into device drivers.
> >
> > I'm preparing a patch that moves the i2c driver out of fsl_soc.c and
> > into i2c_mpc.c.
>
> The problem is how do you instantiate it. I'm working on some solution
> for that but it's not there yet.
Are there powerpc platforms without device trees?
Standard of_platform driver works fine to instantiate the i2c driver
on mpc5200.
static struct of_device_id mpc_i2c_of_match[] = {
{
.compatible = "fsl-i2c",
},
};
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
/* Structure for a device driver */
static struct of_platform_driver mpc_i2c_driver = {
.match_table = mpc_i2c_of_match,
.probe = mpc_i2c_probe,
.remove = __devexit_p(mpc_i2c_remove),
.driver = {
.owner = THIS_MODULE,
.name = DRV_NAME,
},
};
static int __init mpc_i2c_init(void)
{
int rv;
rv = of_register_platform_driver(&mpc_i2c_driver);
if (rv) {
printk(KERN_ERR DRV_NAME " of_register_platform_driver failed (%i)\n", rv);
return rv;
}
return 0;
}
module_init(mpc_i2c_init);
----------------------------------------------------------------------------------------------
i2c and alsa soc core instantiate like this, asoc v2 is not in tree
yet. These cores used to create platform drivers, but that was wrong,
they don't have any hardware associated with them.
static int __init i2c_init(void)
{
int retval;
retval = bus_register(&i2c_bus_type);
if (retval)
return retval;
return class_register(&i2c_adapter_class);
}
subsys_initcall(i2c_init);
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Gianfar ethernet device
From: Benjamin Herrenschmidt @ 2007-11-12 1:08 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111622v5ad6fdd2jd30989819d05615d@mail.gmail.com>
> The real solution is that gianfar support belongs in a device driver,
> not in a common file. That whole fsl_soc.c file is a catch-all of
> things that belong in device drivers. I haven't looked at every line
> in it, but 90%+ of the code should be moved into device drivers.
>
> I'm preparing a patch that moves the i2c driver out of fsl_soc.c and
> into i2c_mpc.c.
The problem is how do you instanciate it. I'm working on some solution
for that but it's not there yet.
Ben.
^ permalink raw reply
* Re: pcspkr device, pnpPNP,100
From: Benjamin Herrenschmidt @ 2007-11-12 1:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111618l5190dee3jd8e0aa8f9b78ebf4@mail.gmail.com>
On Sun, 2007-11-11 at 19:18 -0500, Jon Smirl wrote:
> Using this scheme, which platforms should select the pcspkr hardware?
Run a poll :-) I suppose at least chrp/prep/pegasos
Ben.
^ permalink raw reply
* Re: Gianfar ethernet device
From: Jon Smirl @ 2007-11-12 0:30 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111622v5ad6fdd2jd30989819d05615d@mail.gmail.com>
BTW, this exercise of disabling platform bus is turning up some real bugs.
There are several tests in the kernel like this:
if (!shost->shost_gendev.parent)
shost->shost_gendev.parent = dev ? dev : &platform_bus;
if (adap->dev.parent == NULL) {
adap->dev.parent = &platform_bus;
pr_debug("I2C adapter driver [%s] forgot to specify "
"physical device\n", adap->name);
}
This doesn't do the right thing when the device is on of_platform_bus
instead of platform_bus. What's the right fix for these? Shouldn't the
call error out instead of trying to fix up the parent? Then fix the
code to set the parent right when the device was created.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Gianfar ethernet device
From: Jon Smirl @ 2007-11-12 0:22 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <1194825876.18185.3.camel@pasglop>
On 11/11/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-11 at 18:30 -0500, Jon Smirl wrote:
> > Does this patch add the right ifdefs in fsl_soc.c to make these
> > drivers build on their proper platforms? As an experiment I have
> > disabled platform bus on the mpc5200 and I'm only using of_platform
> > bus. Turning off platform bus is exposing a lot of code that is
> > getting built into my mpc5200 kernel that is supporting devices not
> > available on the platform.
> >
> > A few more fixups in some other drivers and I should have mpc5200
> > working without platform bus.
>
> That sort of per-platform ifdefs is just WRONG.
>
> On the other hand, if you feel that such common code deserves not being
> built on all platforms, then what you can do is define a Kconfig option,
> such as CONFIG_PPC_CAN_HAVE_GIANFAR, that gets select'ed by the
> platforms that can have a Gianfar and use -that- for the ifdef.
The real solution is that gianfar support belongs in a device driver,
not in a common file. That whole fsl_soc.c file is a catch-all of
things that belong in device drivers. I haven't looked at every line
in it, but 90%+ of the code should be moved into device drivers.
I'm preparing a patch that moves the i2c driver out of fsl_soc.c and
into i2c_mpc.c.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: pcspkr device, pnpPNP,100
From: Jon Smirl @ 2007-11-12 0:18 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <1194826191.18185.6.camel@pasglop>
On 11/11/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-11 at 19:07 -0500, Jon Smirl wrote:
> >
> > This code should be in a device driver so that it can be selected with
> > Kconfig. Can we #ifdef it now as a hint? I could make it a device
> > driver but I don't have any hardware to test it on.
> >
> > I'm trying to get the mpc5200 kernel to build with platform bus turned
> > off (only of_platform bus). I'm almost there, just a couple more odd
> > places to patch up.
>
> Just don't do platform ifdef's, ever.
>
> What you can do however is Kconfig options that get selected by
> platforms that need a given service, and then use that as an ifdef for
> that service.
>
> A bit like how we select what interrupt controller drivers to built-in
> for example.
Using this scheme, which platforms should select the pcspkr hardware?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: pcspkr device, pnpPNP,100
From: Benjamin Herrenschmidt @ 2007-11-12 0:09 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111607i35294d3ja43e1c616a3427bd@mail.gmail.com>
On Sun, 2007-11-11 at 19:07 -0500, Jon Smirl wrote:
>
> This code should be in a device driver so that it can be selected with
> Kconfig. Can we #ifdef it now as a hint? I could make it a device
> driver but I don't have any hardware to test it on.
>
> I'm trying to get the mpc5200 kernel to build with platform bus turned
> off (only of_platform bus). I'm almost there, just a couple more odd
> places to patch up.
Just don't do platform ifdef's, ever.
What you can do however is Kconfig options that get selected by
platforms that need a given service, and then use that as an ifdef for
that service.
A bit like how we select what interrupt controller drivers to built-in
for example.
Ben.
^ permalink raw reply
* Re: pcspkr device, pnpPNP,100
From: Jon Smirl @ 2007-11-12 0:07 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <1194825784.18185.0.camel@pasglop>
On 11/11/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-11-11 at 18:35 -0500, Jon Smirl wrote:
> > Which platform does pcspkr device, pnpPNP,100 belong to, amiga? I'd
> > like to IFDEF add_pcspkr(void) in setup-common.c for the right
> > platform.
>
> #ifdef is evil. What about multiplatform kernels ? Just test for the
> presence of the device in the device-tree (use a platform driver maybe)
This code should be in a device driver so that it can be selected with
Kconfig. Can we #ifdef it now as a hint? I could make it a device
driver but I don't have any hardware to test it on.
I'm trying to get the mpc5200 kernel to build with platform bus turned
off (only of_platform bus). I'm almost there, just a couple more odd
places to patch up.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Gianfar ethernet device
From: Benjamin Herrenschmidt @ 2007-11-12 0:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111530g1f50d6e6hfaa76b4f051b5887@mail.gmail.com>
On Sun, 2007-11-11 at 18:30 -0500, Jon Smirl wrote:
> Does this patch add the right ifdefs in fsl_soc.c to make these
> drivers build on their proper platforms? As an experiment I have
> disabled platform bus on the mpc5200 and I'm only using of_platform
> bus. Turning off platform bus is exposing a lot of code that is
> getting built into my mpc5200 kernel that is supporting devices not
> available on the platform.
>
> A few more fixups in some other drivers and I should have mpc5200
> working without platform bus.
That sort of per-platform ifdefs is just WRONG.
On the other hand, if you feel that such common code deserves not being
built on all platforms, then what you can do is define a Kconfig option,
such as CONFIG_PPC_CAN_HAVE_GIANFAR, that gets select'ed by the
platforms that can have a Gianfar and use -that- for the ifdef.
Ben.
^ permalink raw reply
* Re: pcspkr device, pnpPNP,100
From: Benjamin Herrenschmidt @ 2007-11-12 0:03 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111535w6ffdfa97x4bed07eb84d4ab13@mail.gmail.com>
On Sun, 2007-11-11 at 18:35 -0500, Jon Smirl wrote:
> Which platform does pcspkr device, pnpPNP,100 belong to, amiga? I'd
> like to IFDEF add_pcspkr(void) in setup-common.c for the right
> platform.
#ifdef is evil. What about multiplatform kernels ? Just test for the
presence of the device in the device-tree (use a platform driver maybe)
Ben.
^ permalink raw reply
* pcspkr device, pnpPNP,100
From: Jon Smirl @ 2007-11-11 23:35 UTC (permalink / raw)
To: PowerPC dev list
Which platform does pcspkr device, pnpPNP,100 belong to, amiga? I'd
like to IFDEF add_pcspkr(void) in setup-common.c for the right
platform.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Gianfar ethernet device
From: Jon Smirl @ 2007-11-11 23:30 UTC (permalink / raw)
To: PowerPC dev list, Kumar Gala
In-Reply-To: <9e4733910711111511v36aa3504s3b55438698a4b4a8@mail.gmail.com>
Does this patch add the right ifdefs in fsl_soc.c to make these
drivers build on their proper platforms? As an experiment I have
disabled platform bus on the mpc5200 and I'm only using of_platform
bus. Turning off platform bus is exposing a lot of code that is
getting built into my mpc5200 kernel that is supporting devices not
available on the platform.
A few more fixups in some other drivers and I should have mpc5200
working without platform bus.
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index d6ef264..7017510 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -130,6 +130,7 @@ u32 get_baudrate(void)
EXPORT_SYMBOL(get_baudrate);
#endif /* CONFIG_CPM2 */
+#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_85xx) ||
defined(CONFIG_PPC_86xx)
static int __init gfar_mdio_of_init(void)
{
struct device_node *np;
@@ -317,6 +318,7 @@ err:
}
arch_initcall(gfar_of_init);
+#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
@@ -379,7 +381,7 @@ nodev:
}
arch_initcall(mpc83xx_wdt_init);
-#endif
+
static enum fsl_usb2_phy_modes determine_usb_phy(const char *phy_type)
{
@@ -542,6 +544,7 @@ err:
}
arch_initcall(fsl_usb_of_init);
+#endif
#ifndef CONFIG_PPC_CPM_NEW_BINDING
#ifdef CONFIG_CPM2
@@ -1085,6 +1088,7 @@ arch_initcall(cpm_smc_uart_of_init);
#endif /* CONFIG_8xx */
#endif /* CONFIG_PPC_CPM_NEW_BINDING */
+#if defined(CONFIG_PPC_83xx)
int __init fsl_spi_init(struct spi_board_info *board_infos,
unsigned int num_board_infos,
void (*activate_cs)(u8 cs, u8 polarity),
@@ -1174,6 +1178,7 @@ err:
return spi_register_board_info(board_infos, num_board_infos);
}
+#endif
#if defined(CONFIG_PPC_85xx) || defined(CONFIG_PPC_86xx)
static __be32 __iomem *rstcr;
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Gianfar ethernet device
From: Jon Smirl @ 2007-11-11 23:11 UTC (permalink / raw)
To: PowerPC dev list, Kumar Gala
Which platforms have the Gianfar ethernet device? The gfar code in
fsl_soc.c is getting built on the mpc5200 and it doesn't have the
device.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [RFC] powermac: proper sleep management
From: Benjamin Herrenschmidt @ 2007-11-11 20:59 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, linux-pm, David Woodhouse, Paul Mackerras
In-Reply-To: <1194523729.6294.18.camel@johannes.berg>
> Just thought I'd send out the patch again, it has changed quite a bit
> since last time because I cleaned up the code, made it depend on
> CONFIG_SUSPEND, made the ioctl backward compatibility optional and some
> other bits.
>
> The feared freezer vs. fuse sync deadlock is no longer present in 2.6.24
> because the sync is done before the freezer so maybe the patch stands a
> chance now.
>
> Scott: FYI, here's the use case for the ppc_md irq suspend/resume hooks.
Looks good to me, +/- a couple of things:
- We _REALLY_ want the freezer to be optional and not enabled by
default on PowerPC. Maybe make it a compile option ?
- Don't remove the pmu_polled_request() debug code. It's very useful
for debugging and I don't want to have to re-invent it.
Plus I also need to test it on some exotic hardware :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC] PMU: replace information ioctls and schedule for removal
From: Benjamin Herrenschmidt @ 2007-11-11 20:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1194523351.6294.11.camel@johannes.berg>
On Thu, 2007-11-08 at 13:02 +0100, Johannes Berg wrote:
> This patch adds sysfs attributes to the PMU to allow getting
> the information on the PMU type and whether adb is present from
> there instead of via the ioctl. The ioctl is made optional and
> scheduled for removal.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
While there, maybe also expose the PMU version ?
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> Documentation/feature-removal-schedule.txt | 8 ++++++
> drivers/macintosh/Kconfig | 11 ++++++++
> drivers/macintosh/via-pmu.c | 36 +++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+)
>
> --- everything.orig/drivers/macintosh/via-pmu.c 2007-11-08 11:48:48.292846681 +0100
> +++ everything/drivers/macintosh/via-pmu.c 2007-11-08 11:48:53.112861818 +0100
> @@ -2533,10 +2533,12 @@ pmu_ioctl(struct inode * inode, struct f
> #endif /* CONFIG_INPUT_ADBHID */
> #endif /* CONFIG_PMAC_BACKLIGHT_LEGACY */
>
> +#ifdef CONFIG_DEPRECATED_PMU_INFO_IOCTLS
> case PMU_IOC_GET_MODEL:
> return put_user(pmu_kind, argp);
> case PMU_IOC_HAS_ADB:
> return put_user(pmu_has_adb, argp);
> +#endif
> }
> return error;
> }
> @@ -2680,6 +2682,39 @@ static int pmu_sys_resume(struct sys_dev
>
> #endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
>
> +static ssize_t show_kind(struct sys_device *sysdev, char *buf)
> +{
> + return sprintf(buf, "%d\n", pmu_kind);
> +}
> +
> +static ssize_t show_has_adb(struct sys_device *sysdev, char *buf)
> +{
> + return sprintf(buf, "%d\n", pmu_has_adb);
> +}
> +
> +static SYSDEV_ATTR(kind, 0444, show_kind, NULL);
> +static SYSDEV_ATTR(has_adb, 0444, show_has_adb, NULL);
> +
> +int pmu_sys_add(struct sys_device *sysdev)
> +{
> + int err;
> +
> + err = sysdev_create_file(sysdev, &attr_kind);
> + if (err)
> + goto out;
> +
> + err = sysdev_create_file(sysdev, &attr_has_adb);
> + if (err)
> + goto out_remove_kind;
> +
> + return 0;
> +
> + out_remove_kind:
> + sysdev_remove_file(sysdev, &attr_kind);
> + out:
> + return err;
> +}
> +
> static struct sysdev_class pmu_sysclass = {
> set_kset_name("pmu"),
> };
> @@ -2693,6 +2728,7 @@ static struct sysdev_driver driver_pmu =
> .suspend = &pmu_sys_suspend,
> .resume = &pmu_sys_resume,
> #endif /* CONFIG_PM_SLEEP && CONFIG_PPC32 */
> + .add = &pmu_sys_add,
> };
>
> static int __init init_pmu_sysfs(void)
> --- everything.orig/Documentation/feature-removal-schedule.txt 2007-11-08 11:47:39.502844564 +0100
> +++ everything/Documentation/feature-removal-schedule.txt 2007-11-08 11:48:53.122870607 +0100
> @@ -342,3 +342,11 @@ Why: This driver has been marked obsolet
> Who: Stephen Hemminger <shemminger@linux-foundation.org>
>
> ---------------------------
> +
> +What: /dev/pmu information ioctls
> +When: January 2010
> +Files: drivers/macintosh/via-pmu.c
> +Why: The PMU information can be obtained from sysfs now.
> +Who: Johannes Berg <johannes@sipsolutions.net>
> +
> +---------------------------
> --- everything.orig/drivers/macintosh/Kconfig 2007-11-08 11:47:39.422844727 +0100
> +++ everything/drivers/macintosh/Kconfig 2007-11-08 11:48:53.122870607 +0100
> @@ -87,6 +87,17 @@ config ADB_PMU
> this device; you should do so if your machine is one of those
> mentioned above.
>
> +config DEPRECATED_PMU_INFO_IOCTLS
> + bool "Support deprecated PMU information ioctl"
> + depends on ADB_PMU
> + default y
> + help
> + The PMU ioctl supports getting information on the type of PMU and
> + whether an ADB is present. This information is also available in
> + sysfs so this ioctl is no longer needed.
> +
> + If in doubt, say Y even if you will not use the ioctl.
> +
> config ADB_PMU_LED
> bool "Support for the Power/iBook front LED"
> depends on ADB_PMU
>
^ permalink raw reply
* Re: [RFC] PMU: don't lock_kernel()
From: Benjamin Herrenschmidt @ 2007-11-11 20:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1194523283.6294.9.camel@johannes.berg>
On Thu, 2007-11-08 at 13:01 +0100, Johannes Berg wrote:
> I see nothing that this lock_kernel() actually protects against
> so remove it.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/macintosh/via-pmu.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> --- everything.orig/drivers/macintosh/via-pmu.c 2007-11-08 11:48:37.192845813 +0100
> +++ everything/drivers/macintosh/via-pmu.c 2007-11-08 11:48:48.292846681 +0100
> @@ -33,7 +33,6 @@
> #include <linux/adb.h>
> #include <linux/pmu.h>
> #include <linux/cuda.h>
> -#include <linux/smp_lock.h>
> #include <linux/module.h>
> #include <linux/spinlock.h>
> #include <linux/pm.h>
> @@ -2436,7 +2435,6 @@ pmu_release(struct inode *inode, struct
> struct pmu_private *pp = file->private_data;
> unsigned long flags;
>
> - lock_kernel();
> if (pp != 0) {
> file->private_data = NULL;
> spin_lock_irqsave(&all_pvt_lock, flags);
> @@ -2450,7 +2448,6 @@ pmu_release(struct inode *inode, struct
>
> kfree(pp);
> }
> - unlock_kernel();
> return 0;
> }
>
>
^ permalink raw reply
* Re: [RFC] PMU: remove dead code
From: Benjamin Herrenschmidt @ 2007-11-11 20:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1194523239.6294.7.camel@johannes.berg>
On Thu, 2007-11-08 at 13:00 +0100, Johannes Berg wrote:
> Some code in via-pmu.c is never compiled because of "compile options"
> within the file. Remove the code completely.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> drivers/macintosh/via-pmu.c | 42 +-----------------------------------------
> 1 file changed, 1 insertion(+), 41 deletions(-)
>
> --- everything.orig/drivers/macintosh/via-pmu.c 2007-11-08 11:47:42.332847765 +0100
> +++ everything/drivers/macintosh/via-pmu.c 2007-11-08 11:48:37.192845813 +0100
> @@ -65,9 +65,7 @@
> #include "via-pmu-event.h"
>
> /* Some compile options */
> -#undef SUSPEND_USES_PMU
> #define DEBUG_SLEEP
> -#undef HACKED_PCI_SAVE
>
> /* Misc minor number allocated for /dev/pmu */
> #define PMU_MINOR 154
> @@ -1255,9 +1253,7 @@ void
> pmu_suspend(void)
> {
> unsigned long flags;
> -#ifdef SUSPEND_USES_PMU
> - struct adb_request *req;
> -#endif
> +
> if (!via)
> return;
>
> @@ -1275,17 +1271,10 @@ pmu_suspend(void)
> via_pmu_interrupt(0, NULL);
> spin_lock_irqsave(&pmu_lock, flags);
> if (!adb_int_pending && pmu_state == idle && !req_awaiting_reply) {
> -#ifdef SUSPEND_USES_PMU
> - pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, 0);
> - spin_unlock_irqrestore(&pmu_lock, flags);
> - while(!req.complete)
> - pmu_poll();
> -#else /* SUSPEND_USES_PMU */
> if (gpio_irq >= 0)
> disable_irq_nosync(gpio_irq);
> out_8(&via[IER], CB1_INT | IER_CLR);
> spin_unlock_irqrestore(&pmu_lock, flags);
> -#endif /* SUSPEND_USES_PMU */
> break;
> }
> } while (1);
> @@ -1306,18 +1295,11 @@ pmu_resume(void)
> return;
> }
> adb_int_pending = 1;
> -#ifdef SUSPEND_USES_PMU
> - pmu_request(&req, NULL, 2, PMU_SET_INTR_MASK, pmu_intr_mask);
> - spin_unlock_irqrestore(&pmu_lock, flags);
> - while(!req.complete)
> - pmu_poll();
> -#else /* SUSPEND_USES_PMU */
> if (gpio_irq >= 0)
> enable_irq(gpio_irq);
> out_8(&via[IER], CB1_INT | IER_SET);
> spin_unlock_irqrestore(&pmu_lock, flags);
> pmu_poll();
> -#endif /* SUSPEND_USES_PMU */
> }
>
> /* Interrupt data could be the result data from an ADB cmd */
> @@ -1743,14 +1725,10 @@ pmu_present(void)
> * PCI devices which may get powered off when we sleep.
> */
> static struct pci_save {
> -#ifndef HACKED_PCI_SAVE
> u16 command;
> u16 cache_lat;
> u16 intr;
> u32 rom_address;
> -#else
> - u32 config[16];
> -#endif
> } *pbook_pci_saves;
> static int pbook_npci_saves;
>
> @@ -1796,16 +1774,10 @@ pbook_pci_save(void)
> pci_dev_put(pd);
> return;
> }
> -#ifndef HACKED_PCI_SAVE
> pci_read_config_word(pd, PCI_COMMAND, &ps->command);
> pci_read_config_word(pd, PCI_CACHE_LINE_SIZE, &ps->cache_lat);
> pci_read_config_word(pd, PCI_INTERRUPT_LINE, &ps->intr);
> pci_read_config_dword(pd, PCI_ROM_ADDRESS, &ps->rom_address);
> -#else
> - int i;
> - for (i=1;i<16;i++)
> - pci_read_config_dword(pd, i<<4, &ps->config[i]);
> -#endif
> ++ps;
> }
> }
> @@ -1824,17 +1796,6 @@ pbook_pci_restore(void)
> int j;
>
> while ((pd = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pd)) != NULL) {
> -#ifdef HACKED_PCI_SAVE
> - int i;
> - if (npci-- == 0) {
> - pci_dev_put(pd);
> - return;
> - }
> - ps++;
> - for (i=2;i<16;i++)
> - pci_write_config_dword(pd, i<<4, ps->config[i]);
> - pci_write_config_dword(pd, 4, ps->config[1]);
> -#else
> if (npci-- == 0)
> return;
> ps++;
> @@ -1858,7 +1819,6 @@ pbook_pci_restore(void)
> pci_write_config_word(pd, PCI_COMMAND, ps->command);
> break;
> }
> -#endif
> }
> }
>
>
^ permalink raw reply
* Re: IRQs in i2c-mpc.c
From: Benjamin Herrenschmidt @ 2007-11-11 20:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711110734m7d36a235t72f5112e59cbe0d5@mail.gmail.com>
> Is the only error return from irq_of_parse_and_map() NO_IRQ? or can we
> get standard negative returns? I started tracing out the returns from
> irq_of_parse_and_map() but there are a lot of them.
NP_IRQ is the only error return.
Ben.
^ 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