Re: powerpc.git merge status
On Tue, 2008-07-15 at 00:16 -0600, Grant Likely wrote: > On Tue, Jul 15, 2008 at 12:02 AM, Benjamin Herrenschmidt > <[EMAIL PROTECTED]> wrote: > > If you believe I've missed something, now is time to be vocal about > > it :-) > > I've also got some SPI stuff, but it depends on a commit in another > tree so I'll wait until it's in Linus' tree before I ask you to pull. Ok. Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
Hi
I have one query about this soc driver.
I want to know when u will merge it with kernel then
where and by which name this device will be available
in /dev directory of your file system.
As i am following the same structure for my driver so please help me. I
am ot able to recognise the device in the file system.
-Original Message-
From: Grant Likely <[EMAIL PROTECTED]>
To: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments
TLV320AIC26 codec driver
Date: Sat, 12 Jul 2008 02:39:39 -0600
From: Grant Likely <[EMAIL PROTECTED]>
ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
v1 API, so I don't expect it to get merged as-is, but I want to get it
out there for review.
---
sound/soc/codecs/Kconfig |4
sound/soc/codecs/Makefile |2
sound/soc/codecs/tlv320aic26.c | 546
sound/soc/codecs/tlv320aic26.h | 103
4 files changed, 655 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 3903ab7..96c7bfe 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -41,6 +41,10 @@ config SND_SOC_CS4270_VD33_ERRATA
bool
depends on SND_SOC_CS4270
+config SND_SOC_TLV320AIC26
+ tristate "TI TLB320AIC26 Codec support"
+ depends on SND_SOC && SPI
+
config SND_SOC_TLV320AIC3X
tristate
depends on SND_SOC && I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 4e1314c..ec0cd93 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -5,6 +5,7 @@ snd-soc-wm8753-objs := wm8753.o
snd-soc-wm9712-objs := wm9712.o
snd-soc-wm9713-objs := wm9713.o
snd-soc-cs4270-objs := cs4270.o
+snd-soc-tlv320aic26-objs := tlv320aic26.o
snd-soc-tlv320aic3x-objs := tlv320aic3x.o
obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
@@ -14,4 +15,5 @@ obj-$(CONFIG_SND_SOC_WM8753) += snd-soc-wm8753.o
obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
+obj-$(CONFIG_SND_SOC_TLV320AIC26) += snd-soc-tlv320aic26.o
obj-$(CONFIG_SND_SOC_TLV320AIC3X) += snd-soc-tlv320aic3x.o
diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
new file mode 100644
index 000..3ebfa23
--- /dev/null
+++ b/sound/soc/codecs/tlv320aic26.c
@@ -0,0 +1,546 @@
+/*
+ * Texas Instruments TLV320AIC26 low power audio CODEC
+ * ALSA SoC CODEC driver
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "tlv320aic26.h"
+
+MODULE_DESCRIPTION("ASoC TLV320AIC26 codec driver");
+MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>");
+MODULE_LICENSE("GPL");
+
+/* AIC26 driver private data */
+struct aic26 {
+ struct spi_device *spi;
+ struct snd_soc_codec codec;
+ u16 reg_cache[AIC26_REG_CACHE_SIZE];/* shadow registers */
+ int master;
+ int datfm;
+ int mclk;
+
+ /* Keyclick parameters */
+ int keyclick_amplitude;
+ int keyclick_freq;
+ int keyclick_len;
+};
+
+/* -
+ * Register access routines
+ */
+static unsigned int aic26_reg_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ struct aic26 *aic26 = codec->private_data;
+ u16 *cache = codec->reg_cache;
+ u16 cmd, value;
+ u8 buffer[2];
+ int rc;
+
+ if (reg >= AIC26_NUM_REGS) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ /* Do SPI transfer; first 16bits are command; remaining is
+* register contents */
+ cmd = AIC26_READ_COMMAND_WORD(reg);
+ buffer[0] = (cmd >> 8) & 0xff;
+ buffer[1] = cmd & 0xff;
+ rc = spi_write_then_read(aic26->spi, buffer, 2, buffer, 2);
+ if (rc) {
+ dev_err(&aic26->spi->dev, "AIC26 reg read error\n");
+ return -EIO;
+ }
+ value = (buffer[0] << 8) | buffer[1];
+
+ /* Update the cache before returning with the value */
+ if (AIC26_REG_IS_CACHED(reg))
+ cache[AIC26_REG_CACHE_ADDR(reg)] = value;
+ return value;
+}
+
+static unsigned int aic26_reg_read_cache(struct snd_soc_codec *codec,
+unsigned int reg)
+{
+ u16 *cache = codec->reg_cache;
+
+ if ((reg < 0) || (reg >= AIC26_NUM_REGS)) {
+ WARN_ON_ONCE(1);
+ return 0;
+ }
+
+ if (AIC26_REG_IS_CACHED(reg))
+ return cache[AIC26_REG_CACHE_ADDR(reg)];
+
+ return aic26_reg_read(codec, reg);
+}
+
+static int aic26_reg_write(struct snd_so
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Hi Milton, On Mon, 14 Jul 2008 12:09:03 -0500, Milton Miller wrote: > On Jul 14, 2008, at 2:59 AM, Jean Delvare wrote: > > Well, there are two approaches to the problem. The first approach > > (which I think Jim took in his patches? I don't really remember) is to > > simply solve the problem of concurrent I/O access to the Super-I/O > > configuration ports (typically 0x2e/0x2f or 0x4e/0x4f). That would be a > > simple driver requesting the ports in question and exporting an API for > > other drivers to access them in a safe way. > > > > The second approach is to make it a whole subsystem, as David is > > suggesting. The Super-I/O driver would then not only request the I/O > > ports, it would also identify which Super-I/O is there, and it would > > create devices (in the Linux device driver model sense of the term) for > > every logical device we are interested in (amongst which the hwmon > > ones.) The hwmon drivers would have to be converted from platform > > drivers to superio drivers. > > > > Each approach has its advantages. The first one is rather simple and > > also very generic in nature. It could be reused for other purposes. The > > second one offers automatic loading of hwmon drivers, which would be > > nice to have. > > > > There's probably a middle way which would keep the simplicity of the > > first approach while still allowing for driver auto-loading, without > > changing the bus type of all drivers. It would probably take some > > research though. > > I haven't done the research, but it might be keep superio as > a platform driver, and keep the clients as platform drivers. Only > have the superio driver probe and discover the subcomponent > addresses and then create the platform devices as children > instead of having each driver create its own platform device. > (This all assumes they are all platform devices in sysfs, I have > not looked). > > This is all because in the platform bus the bus driver does not > discover the addresses but relies on drivers or platform setup code. That's more or less what I had in mind, yes. > > (...) Milton, will you write a patch? > > Well, that is the second time you asked me, so I guess I should respond. > > While I it is possible for me to write this patch, my schedule and > priority list predict it would not be before the merge window closes. > In fact, I'm not sure when it would come out. It might be argued it > could go in early -rc, but I would fear somebody's chip will not be detected > with the additional check. For example, the port may reserved as mother > board resources or something. I really don't see this as something for kernel 2.6.27, it's too late already. It doesn't fix any actual problem anyway (none that can be fixed by not loading drivers you don't need, at least.) That would be for 2.6.28, so we have plenty of time to test the changes and ensure they do not break anything. As you are the one who reported the issue as something that was bothering you personally, I expected you to also spend some time trying to address it. > (...) Also, I have no hardware to test any > proposed patch, so it would be compile check only. If you write the patches and post them to the lm-sensors list, I am certain that you will find several volunteers for testing. Me, I can offer testing of the it87, f71805f and w83627ehf drivers. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
On Mon, 14 Jul 2008 11:55:01 -0600, David Hubbard wrote: > Hi Hans, > > On Mon, Jul 14, 2008 at 11:30 AM, Hans de Goede <[EMAIL PROTECTED]> wrote: > > Milton Miller wrote: > >> I haven't done the research, but it might be keep superio as > >> a platform driver, and keep the clients as platform drivers. Only > >> have the superio driver probe and discover the subcomponent > >> addresses and then create the platform devices as children > >> instead of having each driver create its own platform device. > >> (This all assumes they are all platform devices in sysfs, I have > >> not looked). > >> > >> This is all because in the platform bus the bus driver does not > >> discover the addresses but relies on drivers or platform setup code. > > > > This sounds like a good plan, rather then add a new bus type add a superio > > platform driver which does superio probing and registering of platform > > devices > > for discovered logical devices. > > > > This superio platform driver then needs to also export some functions of > > those > > few logical devices which need access to the superio registers for more then > > just finding out their own base address. > > > > I guess that it then would be best to load this superio driver by default on > > most systems. > > > > How does this all mix and match with isapnp, it feels to me we're doing > > somewhat the same as isapnp here. > > Is there any way to use lspci and start at the LPC bridge, then find > the SuperIO chip's IO address? What about ACPI tables? Perhaps probing > logic could look for an LPC bridge before probing certain IO addresses > even if the addresses are not in the LPC bridge config. I always assumed that there was no way to know in advance if a Super-I/O (LPC) chip was present or not, let alone the exact model of the chip. The I/O addresses are decoded by the Super-I/O chip itself, and in general it has no relation to PCI. And I've never seen ports 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports. But of course if there is a way to know, we should use it. Avoiding random access to I/O ports, even if they are relatively standard in this case, is always good. > A superio platform driver is a good way to go -- it fits with the way > the platform bus does things. Also, Jim's patches are almost there > already. Good. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote:
> > Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]>
>
> Can you send a cleanup patch against powerpc.git instead ?
>
Resending the patch against powerpc.git tree.
Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]>
---
include/asm-powerpc/processor.h |2 ++
1 file changed, 2 insertions(+)
Index: powerpc.git/include/asm-powerpc/processor.h
===
--- powerpc.git.orig/include/asm-powerpc/processor.h
+++ powerpc.git/include/asm-powerpc/processor.h
@@ -234,6 +234,8 @@ struct thread_struct {
#define thread_saved_pc(tsk)\
((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
+#define task_pt_regs(tsk) ((tsk)->thread.regs)
+
unsigned long get_wchan(struct task_struct *p);
#define KSTK_EIP(tsk) ((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Tue, 2008-07-15 at 14:36 +0530, Srinivasa D S wrote:
> On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote:
>
> > > Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]>
> >
> > Can you send a cleanup patch against powerpc.git instead ?
> >
>
> Resending the patch against powerpc.git tree.
Nah, your initial patch is there already :-) I'm just asking for a
cleanup one that removes the useless cast.
Cheers,
Ben.
>
> Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]>
>
>
> ---
> include/asm-powerpc/processor.h |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: powerpc.git/include/asm-powerpc/processor.h
> ===
> --- powerpc.git.orig/include/asm-powerpc/processor.h
> +++ powerpc.git/include/asm-powerpc/processor.h
> @@ -234,6 +234,8 @@ struct thread_struct {
> #define thread_saved_pc(tsk)\
> ((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
>
> +#define task_pt_regs(tsk)((tsk)->thread.regs)
> +
> unsigned long get_wchan(struct task_struct *p);
>
> #define KSTK_EIP(tsk) ((tsk)->thread.regs? (tsk)->thread.regs->nip: 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Monday 14 July 2008 11:06:47 pm Andreas Schwab wrote: > Timur Tabi <[EMAIL PROTECTED]> writes: > > Srinivasa D S wrote: > >> +#define task_pt_regs(tsk) (tsk)->thread.regs > > > > Shouldn't this be: > > > > #define task_pt_regs(tsk) ((tsk)->thread.regs) > > > > just to be safe? > > Both -> and . have already highest precedence as postfix operators. > Thanks for the comments, For safer side I have used "()" and sent the updated patch. Thanks Srinivasa DS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.26 does not boot on Pegasos
Hi, I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. The last message I have is: gunzip (0x <- some more hex digits) The configuration has been created from a working 2.6.25 one with make oldconfig and answering N to new config options. Anybody has seen this or do I have to start digging deeper? Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote: > Hi, > > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. > The last message I have is: > gunzip (0x <- some more hex digits) > > The configuration has been created from a working 2.6.25 one with > make oldconfig and answering N to new config options. > > Anybody has seen this or do I have to start digging deeper? Unfortunately, I don't have a pegasos anymore. David, did you get a chance to test anything recent on yours ? Matt ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote: > On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> wrote: > > Mark Brown wrote: > > > chassis - on Linux drivers can be automatically loaded based on these > > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > > that does this. > Allowing multiple binds at the root causes the problem of something > like compatible="lite5200b,mpc5200-simple". Both platforms would bind > and that's not what you want. Binding isn't the issue here - it's loading the driver in the first place. Once the drivers are loaded they can (hopefully) figure out if they are running on appropriate hardware. > Another scheme would be to add kernel code to always create virtual OF > devices like "lite5200b-fabric" that are derived off from the machine > name that achieved a bind. This is what I'm suggesting, modulo the fact that I'm suggesting *not* creating virtual devices but rather providing a mechanism for drivers to load without binding to anything. It strikes me that you're going to run into similar situations with other hardware at some point - either for undocumented extras that you happen to know exist on the system (like much of the DMI usage on x86) or for other things where you've got on-board hardware structured like sound hardware tends to be. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
Benjamin Herrenschmidt wrote: On Tue, 2008-07-15 at 14:36 +0530, Srinivasa D S wrote: On Monday 14 July 2008 02:36:57 pm Benjamin Herrenschmidt wrote: Signed-off-by: Srinivasa DS <[EMAIL PROTECTED]> Can you send a cleanup patch against powerpc.git instead ? Resending the patch against powerpc.git tree. Nah, your initial patch is there already :-) I'm just asking for a cleanup one that removes the useless cast. Sorry, I got it wrong, But I dont find my patch in your latest powerpc git tree(git.kernel.org/?p=linux/kernel/git/benh/powerpc.git). Thanks Srinivasa DS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Tue, Jul 15, 2008 at 01:27:52PM +0530, dinesh wrote: > I have one query about this soc driver. > I want to know when u will merge it with kernel then > where and by which name this device will be available > in /dev directory of your file system. > As i am following the same structure for my driver so please help me. I > am ot able to recognise the device in the file system. It will appear via the standard ALSA interfaces (and OSS interfaces if you enable OSS compatibility). The standard location for ALSA device files is under /dev/snd where you'll see several files per device. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
Hi Anton, > Since no sane driver will ever match specific devices, what we want is > to select most generic option (last). Then driver may call > of_device_is_compatible() if it is really interested in details. My original intention was to have alias entries for specific devices in the i2c device drivers. Later, Jean decided to only have the most generic names in there (like in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21) So your patch is correct. > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Acked-by: Jochen Friedrich <[EMAIL PROTECTED]> Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
On Tue, Jul 15, 2008 at 08:05:49PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote: > > Hi, > > > > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. > > The last message I have is: > > gunzip (0x <- some more hex digits) > > > > The configuration has been created from a working 2.6.25 one with > > make oldconfig and answering N to new config options. > > > > Anybody has seen this or do I have to start digging deeper? > > Unfortunately, I don't have a pegasos anymore. David, did you get a > chance to test anything recent on yours ? Matt ? I seem to remember that 2.6.26-rc5 booted fine. Compiling it right now before I start a bisection. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] task_pt_regs for powerpc systems
On Tue, 2008-07-15 at 16:00 +0530, Srinivasa DS wrote: > Sorry, I got it wrong, But I dont find my patch in your latest > powerpc > git tree(git.kernel.org/?p=linux/kernel/git/benh/powerpc.git). Hrm... I thought I merged it. I'll check that tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git merge status
On Tue, Jul 15, 2008 at 04:02:09PM +1000, Benjamin Herrenschmidt wrote: [...] > If you believe I've missed something, now is time to be vocal about > it :-) Yes, this one is lost: [OF] of_gpio: should use new header http://patchwork.ozlabs.org/linuxppc/patch?id=18750 Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git merge status
On Tue, 2008-07-15 at 16:02 +1000, Benjamin Herrenschmidt wrote: > Now, regarding the remaining bits, still on my todo for the next batch, > probably later this week, in this merge window: > - Kumar PTE bits... that's a bit "hot" for this merge window > but I suppose it can still make it. I'd argue that they should make it. It's parity with your PTE rework for 44x, and Kumar even found a bug (which you've pulled the fix for) in your implementation :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
Hello Stephen,
On Tue, Jul 15, 2008 at 01:10:04PM +1000, Stephen Rothwell wrote:
[...]
> > + led->np = np;
>
> You need to take a reference if you are keeping a pointer to a
> device_node, so:
> led->np = of_node_get(np);
>
> > + led->cdev.name = of_get_property(np, "label", NULL);
> > + if (!led->cdev.name)
> > + led->cdev.name = ofdev->dev.bus_id;
>
> Please use dev_name() in new code:
> led->cdev.name = dev_name(&ofdev->dev);
>
> > + led->cdev.brightness_set = gpio_led_set;
> > +
> > + ret = gpio_request(led->gpio, ofdev->dev.bus_id);
>
> dev_name() again.
>
> > +err_get_gpio:
>
> of_node_put(led->np);
>
> > + kfree(led);
> > + return ret;
> > +}
> > +
> > +static int __devexit of_gpio_leds_remove(struct of_device *ofdev)
> > +{
> > + struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
> > +
> > + led_classdev_unregister(&led->cdev);
> > + cancel_work_sync(&led->work);
> > + gpio_free(led->gpio);
> > + of_node_put(led->np);
>
> This was going to be unbalanced, but is now correct.
Thank you so much for the review, corrected version follows.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
thanks for your response but there is no /dev/snd directory in my file structure is there any special method to create it please tell in detail. -Original Message- From: Mark Brown <[EMAIL PROTECTED]> To: dinesh <[EMAIL PROTECTED]> Cc: Grant Likely <[EMAIL PROTECTED]>, linuxppc-dev@ozlabs.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver Date: Tue, 15 Jul 2008 11:33:34 +0100 On Tue, Jul 15, 2008 at 01:27:52PM +0530, dinesh wrote: > I have one query about this soc driver. > I want to know when u will merge it with kernel then > where and by which name this device will be available > in /dev directory of your file system. > As i am following the same structure for my driver so please help me. I > am ot able to recognise the device in the file system. It will appear via the standard ALSA interfaces (and OSS interfaces if you enable OSS compatibility). The standard location for ALSA device files is under /dev/snd where you'll see several files per device. ___ Alsa-devel mailing list [EMAIL PROTECTED] http://mailman.alsa-project.org/mailman/listinfo/alsa-devel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Tue, Jul 15, 2008 at 06:08:19PM +0530, dinesh wrote: > thanks for your response but there is no /dev/snd directory in my file > structure is there any special method to create it please tell in > detail. The devices appear via the standard kernel interfaces so if you are using udev or mdev they should be created automatically. Otherwise you'll need to create them statically using whatever method you usually use (eg, a MAKEDEV script supplied by your distribution or manually by reference to the device numbers exposed in /sys/class/sound/*/dev). The ALSA devices use the standard Linux mechanisms to create their devices so whatever you normally use to create devices should work for ALSA too. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc.git merge status
On Jul 15, 2008, at 1:02 AM, Benjamin Herrenschmidt wrote: I've pulled from Kumar, Josh and Grant, along with applying some patches hand picked from patchworks and build fixes. I've merged in Linus as of today (minus David Woodhouse firmware patches that have a build breakage) in order to fix a (fairly trivial) merge conflict. I've now pushed that to my powerpc.git "master" branch for overnight build-testing with kisskb at which point If all goes well, I'll put all of that in "merge" and "next" and ask Linus to pull it tomorrow. Now, regarding the remaining bits, still on my todo for the next batch, probably later this week, in this merge window: - The CMO stuff, I need to have a closer look but it should probably go in - Milton's serie. Mostly fixes, haven't had time to look too closely yet. - Kumar PTE bits... that's a bit "hot" for this merge window but I suppose it can still make it. - Some Cell stuff for which I'm waiting a new serie from Arnd If you believe I've missed something, now is time to be vocal about it :-) There are a number of patches I still need to pick up but I expect this to be a second round of pulling. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
On Wednesday 09 July 2008, Dave Jones wrote: > > diff --git a/arch/powerpc/platforms/cell/Kconfig > b/arch/powerpc/platforms/cell/Kconfig > index 3959fcf..19f4b4d 100644 > --- a/arch/powerpc/platforms/cell/Kconfig > +++ b/arch/powerpc/platforms/cell/Kconfig > @@ -91,6 +91,7 @@ config CBE_THERM > config CBE_CPUFREQ > tristate "CBE frequency scaling" > depends on CBE_RAS && CPU_FREQ > + select CPU_FREQ_TABLE > default m > help > This adds the cpufreq driver for Cell BE processors. I found the problem now, there was an incorrect 'select CBE_CPUFREQ' in the spudemand governor, but no 'depends on CPUFREQ', so it was possible to build CBE_CPUFREQ without the base CPUFREQ support. Fixed in the current version, will post later. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] leds: implement OpenFirmare GPIO LED driver
Despite leds-gpio and leds-of-gpio similar names and purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/gpio/led.txt | 15 ++
drivers/leds/Kconfig|8 +
drivers/leds/Makefile |1 +
drivers/leds/leds-of-gpio.c | 193 +++
4 files changed, 217 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/gpio/led.txt
create mode 100644 drivers/leds/leds-of-gpio.c
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt
b/Documentation/powerpc/dts-bindings/gpio/led.txt
new file mode 100644
index 000..7e9ce81
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/led.txt
@@ -0,0 +1,15 @@
+LED connected to GPIO
+
+Required properties:
+- compatible : should be "gpio-led".
+- label : (optional) the label for this LED. If omitted, the label is
+ taken from the node name (excluding the unit address).
+- gpios : should specify LED GPIO.
+
+Example:
+
[EMAIL PROTECTED] {
+ compatible = "gpio-led";
+ label = "hdd";
+ gpios = <&mcu_pio 0 0>;
+};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c35dfa..ad7eab3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -119,6 +119,14 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_OF_GPIO
+ tristate "LED Support for GPIO connected LEDs (OpenFirmware bindings)"
+ depends on LEDS_CLASS && OF_GPIO
+ help
+ This option enables support for the LEDs connected to GPIO
+ outputs. To be useful the particular board must have LEDs
+ and they must be connected to the GPIO lines.
+
config LEDS_CM_X270
tristate "LED Support for the CM-X270 LEDs"
depends on LEDS_CLASS && MACH_ARMCORE
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 7156f99..593775c 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
+obj-$(CONFIG_LEDS_OF_GPIO) += leds-of-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
diff --git a/drivers/leds/leds-of-gpio.c b/drivers/leds/leds-of-gpio.c
new file mode 100644
index 000..02c4290
--- /dev/null
+++ b/drivers/leds/leds-of-gpio.c
@@ -0,0 +1,193 @@
+/*
+ * LEDs driver for GPIOs (OpenFirmware bindings)
+ *
+ * Copyright (C) 2007 8D Technologies inc.
+ * Raphael Assenat <[EMAIL PROTECTED]>
+ * Copyright (C) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct of_gpio_led {
+ struct device_node *np;
+ struct led_classdev cdev;
+ unsigned int gpio;
+ struct work_struct work;
+ u8 new_level;
+ u8 can_sleep;
+};
+
+static void gpio_led_work(struct work_struct *work)
+{
+ struct of_gpio_led *led = container_of(work, struct of_gpio_led, work);
+
+ gpio_set_value_cansleep(led->gpio, led->new_level);
+}
+
+static void gpio_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ struct of_gpio_led *led = container_of(led_cdev, struct of_gpio_led,
+ cdev);
+ int level;
+
+ if (value == LED_OFF)
+ level = 0;
+ else
+ level = 1;
+
+ /* Setting GPIOs with I2C/etc requires a task context, and we don't
+* seem to have a reliable way to know if we're already in one; so
+* let's just assume the worst.
+*/
+ if (led->can_sleep) {
+ led->new_level = level;
+ schedule_work(&led->work);
+ } else {
+ gpio_set_value(led->gpio, level);
+ }
+}
+
+static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct of_gpio_led *led;
+ struct device_node *np = ofdev->node;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led->np = of_node_get(np);
+
+ ret = of_get_gpio(np, 0);
+ if (!gpio_is_valid
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On 7/15/08, Mark Brown <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote: > > On 7/14/08, Timur Tabi <[EMAIL PROTECTED]> wrote: > > > Mark Brown wrote: > > > > > > chassis - on Linux drivers can be automatically loaded based on these > > > > strings. See drivers/misc/thinkpad_acpi.c for an example of a driver > > > > that does this. > > > > Allowing multiple binds at the root causes the problem of something > > like compatible="lite5200b,mpc5200-simple". Both platforms would bind > > and that's not what you want. > > Binding isn't the issue here - it's loading the driver in the first > place. Once the drivers are loaded they can (hopefully) figure out if > they are running on appropriate hardware. In this case we would end up with two core PowerPC machine drivers bound, not ALSA ones. We have machine drivers in the PowerPC core, that's one reason why it is confusing to call the ALSA drivers machine drivers too. If we allow multiple bindings both lite5200b and mpc5200-simple would bind. The compatible list is a priority list from most specific to most general. First you check for the specific driver lite5200b, if it's not found then load the generic one mpc5200-simple. > > Another scheme would be to add kernel code to always create virtual OF > > devices like "lite5200b-fabric" that are derived off from the machine > > name that achieved a bind. > > > This is what I'm suggesting, modulo the fact that I'm suggesting *not* > creating virtual devices but rather providing a mechanism for drivers to > load without binding to anything. It strikes me that you're going to If you have drivers for four different hardware releases compiled into your kernel, the only kernel mechanism I know of to trigger only one of these to initialize is to create a device and then let the probe mechanism sort it out. This is even more true when the drivers are on initrd and need to be dynamically loaded. The module load code will search through the alias lists in the module .ko files. It has been pointed out that a lite5200b-fabric device isn't really a virtual devices. It's a device that represents the traces on the PCB wiring the generic chip drivers together. > run into similar situations with other hardware at some point - either > for undocumented extras that you happen to know exist on the system > (like much of the DMI usage on x86) or for other things where you've got > on-board hardware structured like sound hardware tends to be. This makes sense, it is possible that other areas we aren't familiar with will need fabric drivers too. The problem is easily exposed in audio hardware since we use external clock and amp chips. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
On Tue, 2008-07-15 at 16:40 +0400, Anton Vorontsov wrote: > Despite leds-gpio and leds-of-gpio similar names and purposes, there > is not much code can be shared between the two drivers (both are mostly > driver bindings anyway). I don't have any issue with the driver itself, just the name which is going to confuse people no end. Can we come up with a better name for this driver please? "dts-bind-gpio"? "openfirmware-led"? I'm mainly concerned with the more user visible bits like the name of the .c file, the wording of the Kconfig option and the module description. We need to play down the GPIO bit and play up the openfirmware bindings bit. As an example the Kconfig says "LED Support for GPIO connected LEDs" which its not, the bit about openfirmware bindings is in brackets and hence looks incidental. Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
On Jul 10, 2008, at 3:21 PM, Paul Gortmaker wrote: The mpc7448hpc2 board doesn't have an alias block like most of the other modern eval boards have. We need this block in order to have u-boot be able to make use of the CONFIG_OF_STDOUT_VIA_ALIAS (vs. having a hard coded node) in the future. Also remove the old, redundant chosen node. Of all the modern Freescale eval boards (incl. 83xx, 85xx, 86xx) this is the only one which still has it. Its presence also breaks with some older versions of u-boot, like 1.3.1 -- which try and insert a second chosen node. Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc7448hpc2.dts | 24 +++- 1 files changed, 15 insertions(+), 9 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/6] Add fsl, magic-packet to, and clean up, the gianfar binding.
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote: Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31 +-- 1 files changed, 12 insertions(+), 19 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/6] mpc83xx: Power Management support
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote: Basic PM support for 83xx. Standby is implemented as sleep. Suspend-to-RAM is implemented as "deep sleep" (with the processor turned off) on 831x. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig |2 +- arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/suspend-asm.S | 533 + arch/powerpc/platforms/83xx/suspend.c | 388 + arch/powerpc/sysdev/fsl_soc.h |1 + arch/powerpc/sysdev/ipic.c| 71 include/asm-powerpc/reg.h |4 + include/linux/fsl_devices.h |6 + 8 files changed, 1005 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/platforms/83xx/suspend-asm.S create mode 100644 arch/powerpc/platforms/83xx/suspend.c applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/6] mpc8313erdb: Add power management to the device tree.
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote: Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8313erdb.dts | 241 ++ +-- 1 files changed, 171 insertions(+), 70 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/83xx: fix ULPI setup for MPC8315 processors
On Jul 8, 2008, at 12:36 PM, Anton Vorontsov wrote: We must not use MPC831X_SICR[HL]_* definitions for the MPC8315 processors, because SICR USB bits locations are not compatible with MPC8313. This patch fixes ULPI workability on MPC8315E-RDB boards. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/platforms/83xx/mpc83xx.h |4 arch/powerpc/platforms/83xx/usb.c | 24 +++- 2 files changed, 19 insertions(+), 9 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/fsl_soc: gianfar: don't probe disabled devices
On Jul 8, 2008, at 12:36 PM, Anton Vorontsov wrote: Freescale ships MPC8315E-RDB boards in two variants: 1. With TSEC1 ethernet support and USB UTMI PHY; 2. Without TSEC1 support, but with USB ULPI PHY in addition. For the second case U-Boot will add status = "disabled"; property into the TSEC1 node, so Linux should not try to probe it. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/fsl_soc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
On Jul 4, 2008, at 11:53 AM, Anton Vorontsov wrote: This patch adds few bindings for the new drivers to be submitted through the appropriate maintainers. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Updated to decrypt MCU, and to split the bindings into appropriate files. .../powerpc/device-tree/fsl/mcu-mpc8349emitx.txt | 17 + Documentation/powerpc/device-tree/fsl/qe/usb.txt | 37 +++ + Documentation/powerpc/device-tree/fsl/upm-nand.txt | 28 +++ Documentation/powerpc/device-tree/gpio/led.txt | 15 4 files changed, 97 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/device-tree/fsl/mcu- mpc8349emitx.txt create mode 100644 Documentation/powerpc/device-tree/fsl/qe/usb.txt create mode 100644 Documentation/powerpc/device-tree/fsl/upm-nand.txt create mode 100644 Documentation/powerpc/device-tree/gpio/led.txt applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: pci config cleanup [rev2]
On Jun 26, 2008, at 12:07 PM, John Rigby wrote: Choosing PCI or not at config time is allowed on some platforms via an if expression in arch/powerpc/Kconfig. To add a new platform with PCI support selectable at config time, you must change the if expression. This patch makes this easier by changing: bool "PCI support" if to bool "PCI support" if PPC_PCI_CHOICE and adding select PPC_PCI_CHOICE to all the config nodes that were previously in the PCI if expression. Platforms with unconditional PCI support continue to just select PCI in their config nodes. Signed-off-by: John Rigby <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig | 12 arch/powerpc/platforms/52xx/Kconfig|1 + arch/powerpc/platforms/83xx/Kconfig|1 + arch/powerpc/platforms/85xx/Kconfig|2 +- arch/powerpc/platforms/86xx/Kconfig|2 ++ arch/powerpc/platforms/Kconfig |1 + arch/powerpc/platforms/Kconfig.cputype |2 ++ arch/powerpc/platforms/iseries/Kconfig |1 + arch/powerpc/platforms/ps3/Kconfig |1 + arch/powerpc/platforms/pseries/Kconfig |1 + 10 files changed, 19 insertions(+), 5 deletion applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Move mpc83xx_add_bridge to fsl_pci.c [rev2]
On Jun 26, 2008, at 12:07 PM, John Rigby wrote: This allows other platforms with the same pci block like MPC5121 to use it. Signed-off-by: John Rigby <[EMAIL PROTECTED]> --- arch/powerpc/platforms/83xx/Kconfig |2 +- arch/powerpc/platforms/83xx/Makefile |1 - arch/powerpc/platforms/83xx/mpc831x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc832x_mds.c |1 + arch/powerpc/platforms/83xx/mpc832x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc834x_itx.c |1 + arch/powerpc/platforms/83xx/mpc834x_mds.c |1 + arch/powerpc/platforms/83xx/mpc836x_mds.c |1 + arch/powerpc/platforms/83xx/mpc837x_mds.c |1 + arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 + arch/powerpc/platforms/83xx/mpc83xx.h |1 - arch/powerpc/platforms/83xx/pci.c | 91 - arch/powerpc/platforms/83xx/sbc834x.c |1 + arch/powerpc/sysdev/fsl_pci.c | 61 +++ arch/powerpc/sysdev/fsl_pci.h |1 + 15 files changed, 72 insertions(+), 94 deletions(-) delete mode 100644 arch/powerpc/platforms/83xx/pci.c applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
On Tue, Jul 15, 2008 at 01:54:30PM +0100, Richard Purdie wrote: > On Tue, 2008-07-15 at 16:40 +0400, Anton Vorontsov wrote: > > Despite leds-gpio and leds-of-gpio similar names and purposes, there > > is not much code can be shared between the two drivers (both are mostly > > driver bindings anyway). > > I don't have any issue with the driver itself, just the name which is > going to confuse people no end. > > Can we come up with a better name for this driver please? > "dts-bind-gpio"? Hm... I don't actually understand what this name implies. > "openfirmware-led"? And this would be wrong, since this driver is for GPIO LEDs only, not for all LEDs that OF can describe. In future there could be OF PWM LEDs or something like this. > I'm mainly concerned with the more user visible bits like the name of > the .c file, the wording of the Kconfig option and the module > description. We need to play down the GPIO bit and play up the > openfirmware bindings bit. Hm... file name is leds-of-gpio.c, how could I play up the "of" bit more than this? ;-) > As an example the Kconfig says "LED Support for GPIO connected LEDs" > which its not, the bit about openfirmware bindings is in brackets and > hence looks incidental. As for Kconfig, yeah.. probably I can improve the wording. How about "OpenFirmware bindings for GPIO connected LEDs"? Would that work? Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: fsl_uli1575: fix RTC quirk to work on MPC8572DS and MPC8610HPCD
On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote: This patch fixes RTC on MPC8572DS boards: dummy read helps only when reading at the end of the bridge's memory (i.e. outside of behind the bridge devices' assigned regions). With this change the quirk also makes RTC work on MPC8610HPCD, so it's unlikely that this will break MPC8641HPCN or MPC8544DS boards. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/platforms/fsl_uli1575.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add documentation for CPM GPIO banks
On Jul 5, 2008, at 6:29 AM, Jochen Friedrich wrote: Signed-off-by: Jochen Friedrich <[EMAIL PROTECTED]> --- Documentation/powerpc/device-tree/fsl/cpm/gpio.txt | 38 +++ + 1 files changed, 38 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/device-tree/fsl/cpm/gpio.txt applied. Moved to new location dts-bindings/fsl/cpm_qe/gpio.txt - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
On Tue, 2008-07-15 at 17:24 +0400, Anton Vorontsov wrote: > On Tue, Jul 15, 2008 at 01:54:30PM +0100, Richard Purdie wrote: > > I don't have any issue with the driver itself, just the name which is > > going to confuse people no end. > > > > Can we come up with a better name for this driver please? [...] > > "openfirmware-led"? > > And this would be wrong, since this driver is for GPIO LEDs only, not > for all LEDs that OF can describe. In future there could be OF PWM LEDs > or something like this. Ok, will these be a separate driver or combined into the gpio driver? > > I'm mainly concerned with the more user visible bits like the name of > > the .c file, the wording of the Kconfig option and the module > > description. We need to play down the GPIO bit and play up the > > openfirmware bindings bit. > > Hm... file name is leds-of-gpio.c, how could I play up the "of" bit more > than this? ;-) Spell out openfirmware :). I initially had no idea "of == openfirmware" and I suspect others won't either... > > As an example the Kconfig says "LED Support for GPIO connected LEDs" > > which its not, the bit about openfirmware bindings is in brackets and > > hence looks incidental. > > As for Kconfig, yeah.. probably I can improve the wording. How about > "OpenFirmware bindings for GPIO connected LEDs"? Would that work? Yes, thats better. I think basically we need to spell out OF a bit more. Its probably obvious to powerpc people but not everyone else. Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] powerpc/86xx: mpc8610_hpcd: add support for ULI RTC
On Jun 11, 2008, at 6:04 PM, Anton Vorontsov wrote: The ULI "Super South Bridge" contains ISA bridge to the legacy devices, such as Super IO mouse/keyboard/floppy disk controllers, parallel port, i8259 interrupt controller and so on. i8259 is disabled on the MPC8610HPCD, and other peripherals are not traced out. So we use only RTC. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14 +++ arch/powerpc/configs/mpc8610_hpcd_defconfig | 51 ++ ++-- 2 files changed, 61 insertions(+), 4 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On 7/15/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote: > Hi Anton, > > > > Since no sane driver will ever match specific devices, what we want is > > to select most generic option (last). Then driver may call > > of_device_is_compatible() if it is really interested in details. > > > My original intention was to have alias entries for specific devices in the > i2c device drivers. Later, Jean decided to only have the most generic names > in there (like in > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21) > So your patch is correct. Why aren't we listing the chip names in the driver's id section? Large chip id tables are not unusual in the kernel, the e1000 driver has about 70 entries. Taking the chip id table out of the driver just means we have to build it somewhere else. It doesn't save space, the tables just get moved. Device firmware has the chip names in it so there has to be code in the kernel somewhere to do the mapping from chip id to linux driver name. Pushing the linux driver name down into the firmware is even crazier. + /* 2. search for linux, entry */ Now if the linux driver gets renamed everyone on the planet needs a firmware update. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Tue, Jul 15, 2008 at 09:08:28AM -0400, Jon Smirl wrote: > On 7/15/08, Mark Brown <[EMAIL PROTECTED]> wrote: > > Binding isn't the issue here - it's loading the driver in the first > > place. Once the drivers are loaded they can (hopefully) figure out if > > they are running on appropriate hardware. > In this case we would end up with two core PowerPC machine drivers > bound, not ALSA ones. We have machine drivers in the PowerPC core, > that's one reason why it is confusing to call the ALSA drivers machine > drivers too. Again, I'm not talking about binding anything. > > This is what I'm suggesting, modulo the fact that I'm suggesting *not* > > creating virtual devices but rather providing a mechanism for drivers to > > load without binding to anything. It strikes me that you're going to > If you have drivers for four different hardware releases compiled into > your kernel, the only kernel mechanism I know of to trigger only one > of these to initialize is to create a device and then let the probe > mechanism sort it out. This is even more true when the drivers are on > initrd and need to be dynamically loaded. The module load code will > search through the alias lists in the module .ko files. This can be handled in the module initialisation (rather than driver probe) - providing something can arrange for the driver to get loaded then the drivers can check the system they're running on when that happens and fail if it's inappropriate. The ARM ASoC drivers and x86 DMI based stuff do things this way, for example (ARM doesn't have the automatic module load stuff implemented, though). The infrastructure for automatically loading modules is usable separately from device registration, though normally the two do go hand in hand. > It has been pointed out that a lite5200b-fabric device isn't really a > virtual devices. It's a device that represents the traces on the PCB > wiring the generic chip drivers together. This was brought up very early on when you guys first started working on it. :/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On Tue, 15 Jul 2008 09:40:08 -0400, Jon Smirl wrote: > On 7/15/08, Jochen Friedrich <[EMAIL PROTECTED]> wrote: > > Hi Anton, > > > > > > > Since no sane driver will ever match specific devices, what we want is > > > to select most generic option (last). Then driver may call > > > of_device_is_compatible() if it is really interested in details. > > > > > > My original intention was to have alias entries for specific devices in the > > i2c device drivers. Later, Jean decided to only have the most generic names > > in there (like in > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/media/video/tvaudio.c;h=c77914d99d15c5972c94e9763a08b5789098e90a;hp=6f9945b04e1f2bcd676f0ed8dc910994b29ed300;hb=ae429083efe996ca2c569c44fd6fea440676dc33;hpb=60b129d7bfa3e20450816983bd52c49bb0bc1c21) > > So your patch is correct. Eeeek. The patch you mention here is only the conversion of ONE driver. It is absolutely not relevant as to what the general rule is. Background: Some media drivers have been relying on autodetection for years. We will convert them to the new model as much as possible, however the knowledge of what chip is present on each board has sometimes been lost, so switching to the new i2c model isn't that easy. So, as a transition step, for a few media drivers, we decided to not enumerate all the supported chips (nobody would be able to instantiate any of them specifically anyway). This might change in the future, as developers gain knowledge about the hardware again. Jochen, I am very surprised that you dare drawing conclusions based on one random patch of mine. And I am unhappy that you even claim that I took some decision when I definitely did not. > Why aren't we listing the chip names in the driver's id section? Large > chip id tables are not unusual in the kernel, the e1000 driver has > about 70 entries. > > Taking the chip id table out of the driver just means we have to build > it somewhere else. It doesn't save space, the tables just get moved. > Device firmware has the chip names in it so there has to be code in > the kernel somewhere to do the mapping from chip id to linux driver > name. > > Pushing the linux driver name down into the firmware is even crazier. > + /* 2. search for linux, entry */ > Now if the linux driver gets renamed everyone on the planet needs a > firmware update. I can't comment on the specific issue at hand as I am not familiar with it, but overall Jon appears to be right. Listing individual chips in id_table is the standard way to go. That's even the very reason why we decided to add this id_table to i2c_driver, instead of matching on the driver name as we were doing before. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
> This is certainly significant, but a lot has happened between the two > versions. I few ideas: > > * compare some of the key configuration options: > # CONFIG_DEBUG_* > # CONFIG_PREEMPT* > # CONFIG_NO_HZ > # CONFIG_HZ 2.6.25: # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_DEBUG_FS is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUGGER is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_RCU is not set # CONFIG_NO_HZ is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 2.6.18: # CONFIG_DEBUG_DRIVER is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_RWSEMS is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_FS is not set # CONFIG_DEBUG_VM is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 > > * Try looking at where the time is spent, using oprofile or > readprofile Doing this now. > > * Try setting /proc/sys/kernel/compat/sched_yield to 1, to > get the legacy > behaviour of the scheduler. Made perfromance on .25 a few percent worse. (84 minutes on kernel compile instead of 81 minutes) > * Maybe there is a kernel version that supports your hardware in both > arch/ppc/ and arch/powerpc. In that case, you could see if > the platform > change had an impact. Will try. Last port in ppc branch was 2.6.18 and first in powerpc was 2.6.24. I should be able to port ppc to .25 also I think. Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
On Tue, 2008-07-15 at 20:05 +1000, Benjamin Herrenschmidt wrote: > On Tue, 2008-07-15 at 12:00 +0200, Gabriel Paubert wrote: > > Hi, > > > > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. > > The last message I have is: > > gunzip (0x <- some more hex digits) > > > > The configuration has been created from a working 2.6.25 one with > > make oldconfig and answering N to new config options. > > > > Anybody has seen this or do I have to start digging deeper? > > Unfortunately, I don't have a pegasos anymore. David, did you get a > chance to test anything recent on yours ? Matt ? I'm away from home for the next couple of weeks, but can test when I get home after OLS. I've run relatively recent kernels on Pegasos within the last 2-3 weeks. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
On Tue, Jul 15, 2008 at 02:31:27PM +0100, Richard Purdie wrote: > On Tue, 2008-07-15 at 17:24 +0400, Anton Vorontsov wrote: > > On Tue, Jul 15, 2008 at 01:54:30PM +0100, Richard Purdie wrote: > > > I don't have any issue with the driver itself, just the name which is > > > going to confuse people no end. > > > > > > Can we come up with a better name for this driver please? > [...] > > > "openfirmware-led"? > > > > And this would be wrong, since this driver is for GPIO LEDs only, not > > for all LEDs that OF can describe. In future there could be OF PWM LEDs > > or something like this. > > Ok, will these be a separate driver or combined into the gpio driver? I believe this must be a separate driver. The two drivers would have nothing in common except prologue registration stuff. > > > I'm mainly concerned with the more user visible bits like the name of > > > the .c file, the wording of the Kconfig option and the module > > > description. We need to play down the GPIO bit and play up the > > > openfirmware bindings bit. > > > > Hm... file name is leds-of-gpio.c, how could I play up the "of" bit more > > than this? ;-) > > Spell out openfirmware :). I initially had no idea "of == openfirmware" > and I suspect others won't either... This would be unusually long name, that is $ find . -iname '*openfirmware*' | wc -l 0 And in contrast: drivers/video/offb.c drivers/video/nvidia/nv_of.c drivers/usb/host/ohci-ppc-of.c drivers/usb/host/ehci-ppc-of.c drivers/serial/of_serial.c drivers/mtd/maps/physmap_of.c ... So, I think we should stick with the "of" for consistency, while confused users may consult with Kconfig for disambiguation. But if you really want the expanded name.. just repeat it, and I'll change the name. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/2] cell: cleanup sysreset_hack for IBM cell blades
From: Christian Krafft <[EMAIL PROTECTED]>
This patch adds a config option for the sysreset_hack used for
IBM Cell blades. The code is moves from pervasive.c into ras.c and
gets it's own init method.
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
Index: linux.git/arch/powerpc/platforms/cell/pervasive.c
===
--- linux.git.orig/arch/powerpc/platforms/cell/pervasive.c
+++ linux.git/arch/powerpc/platforms/cell/pervasive.c
@@ -38,8 +38,6 @@
#include "pervasive.h"
-static int sysreset_hack;
-
static void cbe_power_save(void)
{
unsigned long ctrl, thread_switch_control;
@@ -87,9 +85,6 @@ static void cbe_power_save(void)
static int cbe_system_reset_exception(struct pt_regs *regs)
{
- int cpu;
- struct cbe_pmd_regs __iomem *pmd;
-
switch (regs->msr & SRR1_WAKEMASK) {
case SRR1_WAKEEE:
do_IRQ(regs);
@@ -98,19 +93,7 @@ static int cbe_system_reset_exception(st
timer_interrupt(regs);
break;
case SRR1_WAKEMT:
- /*
-* The BMC can inject user triggered system reset exceptions,
-* but cannot set the system reset reason in srr1,
-* so check an extra register here.
-*/
- if (sysreset_hack && (cpu = smp_processor_id()) == 0) {
- pmd = cbe_get_cpu_pmd_regs(cpu);
- if (in_be64(&pmd->ras_esc_0) & 0x) {
- out_be64(&pmd->ras_esc_0, 0);
- return 0;
- }
- }
- break;
+ return cbe_sysreset_hack();
#ifdef CONFIG_CBE_RAS
case SRR1_WAKESYSERR:
cbe_system_error_exception(regs);
@@ -134,8 +117,6 @@ void __init cbe_pervasive_init(void)
if (!cpu_has_feature(CPU_FTR_PAUSE_ZERO))
return;
- sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
-
for_each_possible_cpu(cpu) {
struct cbe_pmd_regs __iomem *regs = cbe_get_cpu_pmd_regs(cpu);
if (!regs)
@@ -144,12 +125,6 @@ void __init cbe_pervasive_init(void)
/* Enable Pause(0) control bit */
out_be64(®s->pmcr, in_be64(®s->pmcr) |
CBE_PMD_PAUSE_ZERO_CONTROL);
-
- /* Enable JTAG system-reset hack */
- if (sysreset_hack)
- out_be32(®s->fir_mode_reg,
- in_be32(®s->fir_mode_reg) |
- CBE_PMD_FIR_MODE_M8);
}
ppc_md.power_save = cbe_power_save;
Index: linux.git/arch/powerpc/platforms/cell/Kconfig
===
--- linux.git.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux.git/arch/powerpc/platforms/cell/Kconfig
@@ -83,6 +83,14 @@ config CBE_RAS
depends on PPC_CELL_NATIVE
default y
+config PPC_IBM_CELL_RESETBUTTON
+ bool "IBM Cell Blade Pinhole reset button"
+ depends on CBE_RAS && PPC_IBM_CELL_BLADE
+ default y
+ help
+ Support Pinhole Resetbutton on IBM Cell blades.
+ This adds a method to trigger system reset via front panel pinhole
button. +
config CBE_THERM
tristate "CBE thermal support"
default m
Index: linux.git/arch/powerpc/platforms/cell/pervasive.h
===
--- linux.git.orig/arch/powerpc/platforms/cell/pervasive.h
+++ linux.git/arch/powerpc/platforms/cell/pervasive.h
@@ -30,4 +30,13 @@ extern void cbe_system_error_exception(s
extern void cbe_maintenance_exception(struct pt_regs *regs);
extern void cbe_thermal_exception(struct pt_regs *regs);
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+extern int cbe_sysreset_hack(void);
+#else
+static inline int cbe_sysreset_hack(void)
+{
+ return 1;
+}
+#endif /* CONFIG_PPC_IBM_CELL_RESETBUTTON */
+
#endif
Index: linux.git/arch/powerpc/platforms/cell/ras.c
===
--- linux.git.orig/arch/powerpc/platforms/cell/ras.c
+++ linux.git/arch/powerpc/platforms/cell/ras.c
@@ -230,6 +230,52 @@ static struct notifier_block cbe_ptcal_r
.notifier_call = cbe_ptcal_notify_reboot
};
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+static int sysreset_hack;
+
+static int __init cbe_sysreset_init(void)
+{
+ struct cbe_pmd_regs __iomem *regs;
+
+ sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
+ if (!sysreset_hack)
+ return 0;
+
+ regs = cbe_get_cpu_pmd_regs(0);
+ if (!regs)
+ return 0;
+
+ /* Enable JTAG system-reset hack */
+ out_be32(®s->fir_mode_reg,
+ in_be32(®s->fir_mode_reg) |
+ CBE_PMD_FIR_MODE_M8);
+
+ return 0;
+}
+device_initcall(cbe_sysreset_init);
+
+int cbe_sysreset_hack(v
[patch 0/2] support buttons on IBM cell blades
These patches add support for the buttons on IBM cell blades. Support for pinhole reset button was already in, the code just moved to ras.c and got it's own config option. -- Mit freundlichen Gruessen, kind regards, Christian Krafft Linux Kernel Development IBM Systems & Technology Group Phone: +49-07031-16-2032 IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaetsfuehung: Herbert Kircher Sitz der Gesellschaft: Boelingen Registergericht:Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/2] cell: add support for power button of future IBM cell blades
From: Christian Krafft <[EMAIL PROTECTED]>
This patch adds support for the power button on future IBM cell blades.
It actually doesn't shut down the machine. Instead it exposes an
input device /dev/input/event0 to userspace which sends KEY_POWER
if power button has been pressed.
haldaemon actually recognizes the button, so a plattform independent acpid
replacement should handle it correctly.
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
Index: linux.git/arch/powerpc/platforms/cell/Kconfig
===
--- linux.git.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux.git/arch/powerpc/platforms/cell/Kconfig
@@ -91,6 +91,14 @@ config PPC_IBM_CELL_RESETBUTTON
Support Pinhole Resetbutton on IBM Cell blades.
This adds a method to trigger system reset via front panel pinhole
button.
+config PPC_IBM_CELL_POWERBUTTON
+ tristate "IBM Cell Blade power button"
+ depends on PPC_IBM_CELL_BLADE && PPC_PMI && INPUT_EVDEV
+ default y
+ help
+ Support Powerbutton on IBM Cell blades.
+ This will enable the powerbutton as an input device.
+
config CBE_THERM
tristate "CBE thermal support"
default m
Index: linux.git/arch/powerpc/platforms/cell/cbe_powerbutton.c
===
--- /dev/null
+++ linux.git/arch/powerpc/platforms/cell/cbe_powerbutton.c
@@ -0,0 +1,117 @@
+/*
+ * driver for powerbutton on IBM cell blades
+ *
+ * (C) Copyright IBM Corp. 2005-2008
+ *
+ * Author: Christian Krafft <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+static struct input_dev *button_dev;
+static struct platform_device *button_pdev;
+
+static void cbe_powerbutton_handle_pmi(pmi_message_t pmi_msg)
+{
+ BUG_ON(pmi_msg.type != PMI_TYPE_POWER_BUTTON);
+
+ input_report_key(button_dev, KEY_POWER, 1);
+ input_sync(button_dev);
+ input_report_key(button_dev, KEY_POWER, 0);
+ input_sync(button_dev);
+}
+
+static struct pmi_handler cbe_pmi_handler = {
+ .type = PMI_TYPE_POWER_BUTTON,
+ .handle_pmi_message = cbe_powerbutton_handle_pmi,
+};
+
+static int __init cbe_powerbutton_init(void)
+{
+ int ret = 0;
+ struct input_dev *dev;
+
+ if (!machine_is_compatible("IBM,CBPLUS-1.0")) {
+ printk(KERN_ERR "%s: Not a cell blade.\n", __func__);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ dev = input_allocate_device();
+ if (!dev) {
+ ret = -ENOMEM;
+ printk(KERN_ERR "%s: Not enough memory.\n", __func__);
+ goto out;
+ }
+
+ set_bit(EV_KEY, dev->evbit);
+ set_bit(KEY_POWER, dev->keybit);
+
+ dev->name = "Power Button";
+ dev->id.bustype = BUS_HOST;
+
+ /* this makes the button look like an acpi power button
+* no clue whether anyone relies on that though */
+ dev->id.product = 0x02;
+ dev->phys = "LNXPWRBN/button/input0";
+
+ button_pdev = platform_device_register_simple("power_button", 0, NULL,
0);
+ if (IS_ERR(button_pdev)) {
+ ret = PTR_ERR(button_pdev);
+ goto out_free_input;
+ }
+
+ dev->dev.parent = &button_pdev->dev;
+ ret = input_register_device(dev);
+ if (ret) {
+ printk(KERN_ERR "%s: Failed to register device\n", __func__);
+ goto out_free_pdev;
+ }
+
+ button_dev = dev;
+
+ ret = pmi_register_handler(&cbe_pmi_handler);
+ if (ret) {
+ printk(KERN_ERR "%s: Failed to register with pmi.\n",
__func__);
+ goto out_free_pdev;
+ }
+
+ goto out;
+
+out_free_pdev:
+ platform_device_unregister(button_pdev);
+out_free_input:
+ input_free_device(dev);
+out:
+ return ret;
+}
+
+static void __exit cbe_powerbutton_exit(void)
+{
+ pmi_unregister_handler(&cbe_pmi_handler);
+ platform_device_unregister(button_pdev);
+ input_free_device(button_dev);
+}
+
+module_init(cbe_powerbutton_init);
+module_exit(cbe_powerbutton_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Christian Krafft <[EMAIL PROTECTED]>");
Index: linux.git/arch/powerpc/platforms/cell/Makefi
Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
On Tue, 2008-07-15 at 18:23 +0400, Anton Vorontsov wrote: > > Spell out openfirmware :). I initially had no idea "of == openfirmware" > > and I suspect others won't either... > > This would be unusually long name, that is > > $ find . -iname '*openfirmware*' | wc -l > 0 > > And in contrast: > > drivers/video/offb.c > drivers/video/nvidia/nv_of.c > drivers/usb/host/ohci-ppc-of.c > drivers/usb/host/ehci-ppc-of.c > drivers/serial/of_serial.c > drivers/mtd/maps/physmap_of.c > ... > > So, I think we should stick with the "of" for consistency, while > confused users may consult with Kconfig for disambiguation. The other cases don't have a gpio driver to confuse this new driver with. Lets spell it out please, the filesystems can handle the extra letters :). Cheers, Richard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
The FSL MSI code keeps a pointer to the of_node from the device
it represents. However it also has an irq_host, which contains
a pointer to the of_node, so use that one instead.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_msi.c | 12 +---
arch/powerpc/sysdev/fsl_msi.h |3 ---
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 2c5187c..d49fa99 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -108,7 +108,8 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
get_count_order(NR_MSI_IRQS));
- p = of_get_property(msi->of_node, "msi-available-ranges", &len);
+ p = of_get_property(msi->irqhost->of_node, "msi-available-ranges",
+ &len);
if (!p) {
/* No msi-available-ranges property,
@@ -120,7 +121,7 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
if ((len % (2 * sizeof(u32))) != 0) {
printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
- "property on %s\n", msi->of_node->full_name);
+ "property on %s\n", msi->irqhost->of_node->full_name);
return -EINVAL;
}
@@ -317,14 +318,11 @@ static int __devinit fsl_of_msi_probe(struct of_device
*dev,
goto error_out;
}
- msi->of_node = of_node_get(dev->node);
+ msi->irqhost = irq_alloc_host(dev->node, IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, &fsl_msi_host_ops, 0);
- msi->irqhost = irq_alloc_host(of_node_get(dev->node),
- IRQ_HOST_MAP_LINEAR,
- NR_MSI_IRQS, &fsl_msi_host_ops, 0);
if (msi->irqhost == NULL) {
dev_err(&dev->dev, "No memory for MSI irqhost\n");
- of_node_put(dev->node);
err = -ENOMEM;
goto error_out;
}
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index a653468..6574550 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -22,9 +22,6 @@
#define FSL_PIC_IP_IPIC0x0002
struct fsl_msi {
- /* Device node of the MSI interrupt*/
- struct device_node *of_node;
-
struct irq_host *irqhost;
unsigned long cascade_irq;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: Split-out common MSI bitmap logic into msi_bitmap.c
There are now two almost identical implementations of an MSI bitmap
allocator, one in mpic_msi.c and the other in fsl_msi.c.
Merge them together and put the result in msi_bitmap.c. Some of the
MPIC bits will remain to provide a nicer interface for the MPIC users.
In the process we fix two buglets. The first is that the allocation
routines, now msi_bitmap_alloc_hwirqs(), returned an unsigned result,
even though they use -1 to indicate allocation failure. Although all
the callers were checking correctly, it is much better for the routine
to just return an int. At least until someone wants > ~2 billion MSIs.
The second buglet is that the device tree reservation logic only
allowed power-of-two reservations. AFAICT that didn't effect any existing
code but it's nicer if we can reserve arbitrary irqs from MSI use.
We also add some selftests, which exposed the two buglets and now test
for them, as well as some basic sanity tests. The tests are only built
when CONFIG_DEBUG_KERNEL=y.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig.debug |5 +
arch/powerpc/sysdev/Kconfig |6 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/msi_bitmap.c | 247 ++
include/asm-powerpc/msi_bitmap.h | 35 ++
5 files changed, 294 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 2840ab6..03804a8 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -67,6 +67,11 @@ config FTR_FIXUP_SELFTEST
depends on DEBUG_KERNEL
default n
+config MSI_BITMAP_SELFTEST
+ bool "Run self-tests of the MSI bitmap code."
+ depends on DEBUG_KERNEL
+ default n
+
choice
prompt "Serial Port"
depends on KGDB
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..3965828 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,9 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI && 4xx
default n
+
+config PPC_MSI_BITMAP
+ bool
+ depends on PCI_MSI
+ default y if MPIC
+ default y if FSL_PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 16a0ed2..bf8278d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
+obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
new file mode 100644
index 000..f84217b
--- /dev/null
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright 2006-2008, Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include
+#include
+#include
+
+int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ /*
+* This is fast, but stricter than we need. We might want to add
+* a fallback routine which does a linear search with no alignment.
+*/
+ offset = bitmap_find_free_region(bmp->bitmap, bmp->irq_count, order);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+
+ pr_debug("msi_bitmap: allocated 0x%x (2^%d) at offset 0x%x\n",
+num, order, offset);
+
+ return offset;
+}
+
+void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
+ unsigned int num)
+{
+ unsigned long flags;
+ int order = get_count_order(num);
+
+ pr_debug("msi_bitmap: freeing 0x%x (2^%d) at offset 0x%x\n",
+num, order, offset);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ bitmap_release_region(bmp->bitmap, offset, order);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+}
+
+void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq)
+{
+ unsigned long flags;
+
+ pr_debug("msi_bitmap: reserving hwirq 0x%x\n", hwirq);
+
+ spin_lock_irqsave(&bmp->lock, flags);
+ bitmap_allocate_region(bmp->bitmap, hwirq, 0);
+ spin_unlock_irqrestore(&bmp->lock, flags);
+}
+
+/**
+ * msi_bitmap_reserve_dt_hwirqs - Reserve irqs specified in the device tree.
+ * @bmp: pointer to the MSI bitmap.
+ *
+ * Looks in the device tree to see if there is a property specifying which
+ * irqs can be used for MSI. If found those irqs reserved in the device tree
+ * are reserved in the bitmap.
+ *
+ * Retu
[PATCH 3/4] powerpc: Convert the FSL MSI code to use msi_bitmap
This is 90% straight forward, although we have to change a few
printk format strings as well because of the change in type of hwirq.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_msi.c | 103 ++---
arch/powerpc/sysdev/fsl_msi.h |5 +-
2 files changed, 17 insertions(+), 91 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d49fa99..f25ce81 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -14,7 +14,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -67,96 +66,22 @@ static struct irq_host_ops fsl_msi_host_ops = {
.map = fsl_msi_host_map,
};
-static irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
- int offset;
-
- spin_lock_irqsave(&msi->bitmap_lock, flags);
-
- offset = bitmap_find_free_region(msi->fsl_msi_bitmap,
- NR_MSI_IRQS, order);
-
- spin_unlock_irqrestore(&msi->bitmap_lock, flags);
-
- pr_debug("%s: allocated 0x%x (2^%d) at offset 0x%x\n",
- __func__, num, order, offset);
-
- return offset;
-}
-
-static void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug("%s: freeing 0x%x (2^%d) at offset 0x%x\n",
- __func__, num, order, offset);
-
- spin_lock_irqsave(&msi->bitmap_lock, flags);
- bitmap_release_region(msi->fsl_msi_bitmap, offset, order);
- spin_unlock_irqrestore(&msi->bitmap_lock, flags);
-}
-
-static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
-{
- int i;
- int len;
- const u32 *p;
-
- bitmap_allocate_region(msi->fsl_msi_bitmap, 0,
- get_count_order(NR_MSI_IRQS));
-
- p = of_get_property(msi->irqhost->of_node, "msi-available-ranges",
- &len);
-
- if (!p) {
- /* No msi-available-ranges property,
-* All the 256 MSI interrupts can be used
-*/
- fsl_msi_free_hwirqs(msi, 0, 0x100);
- return 0;
- }
-
- if ((len % (2 * sizeof(u32))) != 0) {
- printk(KERN_WARNING "fsl_msi: Malformed msi-available-ranges "
- "property on %s\n", msi->irqhost->of_node->full_name);
- return -EINVAL;
- }
-
- /* Format is: ( )+ */
- len /= 2 * sizeof(u32);
- for (i = 0; i < len; i++, p += 2)
- fsl_msi_free_hwirqs(msi, *p, *(p + 1));
-
- return 0;
-}
-
static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
{
int rc;
- int size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(u32);
- msi_data->fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+ rc = msi_bitmap_alloc(&msi_data->bitmap, NR_MSI_IRQS,
+ msi_data->irqhost->of_node);
+ if (rc)
+ return rc;
- if (msi_data->fsl_msi_bitmap == NULL) {
- pr_debug("%s: ENOMEM allocating allocator bitmap!\n",
- __func__);
- return -ENOMEM;
+ rc = msi_bitmap_reserve_dt_hwirqs(&msi_data->bitmap);
+ if (rc < 0) {
+ msi_bitmap_free(&msi_data->bitmap);
+ return rc;
}
- rc = fsl_msi_free_dt_hwirqs(msi_data);
- if (rc)
- goto out_free;
-
return 0;
-out_free:
- kfree(msi_data->fsl_msi_bitmap);
-
- msi_data->fsl_msi_bitmap = NULL;
- return rc;
-
}
static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
@@ -176,7 +101,8 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
if (entry->irq == NO_IRQ)
continue;
set_irq_msi(entry->irq, NULL);
- fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry->irq), 1);
+ msi_bitmap_free_hwirqs(&msi_data->bitmap,
+ virq_to_hw(entry->irq), 1);
irq_dispose_mapping(entry->irq);
}
@@ -198,15 +124,14 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int
hwirq,
static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
- irq_hw_number_t hwirq;
- int rc;
+ int rc, hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
struct fsl_msi *msi_data = fsl_msi;
list_for_each_entry(entry, &pdev->msi_list, list) {
- hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+ hwirq = msi_bitmap_alloc_hwirqs(&msi_data->bitmap, 1);
if (hwirq < 0) {
rc = hwirq;
pr_debug("%s: fail allocating msi interrupt\n",
@@ -217,9 +142,9 @@ static int fsl_setup_msi_irqs(
[PATCH 4/4] powerpc: Convert the MPIC MSI code to use msi_bitmap
This effects the U3 MSI code as well as the PASEMI MSI code. We keep
some of the MPIC routines as helpers, and also the U3 best-guess
reservation logic. The rest is replaced by the generic code.
And a few printk format changes due to hwirq type change.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/mpic.h|2 -
arch/powerpc/sysdev/mpic_msi.c| 123 +
arch/powerpc/sysdev/mpic_pasemi_msi.c | 24 ---
arch/powerpc/sysdev/mpic_u3msi.c | 22 +++---
include/asm-powerpc/mpic.h|4 +-
5 files changed, 44 insertions(+), 131 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index fbf8a26..6209c62 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -14,8 +14,6 @@
#ifdef CONFIG_PCI_MSI
extern void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq);
extern int mpic_msi_init_allocator(struct mpic *mpic);
-extern irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num);
-extern void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num);
extern int mpic_u3msi_init(struct mpic *mpic);
extern int mpic_pasemi_msi_init(struct mpic *mpic);
#else
diff --git a/arch/powerpc/sysdev/mpic_msi.c b/arch/powerpc/sysdev/mpic_msi.c
index de3e5e8..1d44eee 100644
--- a/arch/powerpc/sysdev/mpic_msi.c
+++ b/arch/powerpc/sysdev/mpic_msi.c
@@ -15,59 +15,17 @@
#include
#include
#include
+#include
#include
-static void __mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
-{
- pr_debug("mpic: reserving hwirq 0x%lx\n", hwirq);
- bitmap_allocate_region(mpic->hwirq_bitmap, hwirq, 0);
-}
-
void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
{
- unsigned long flags;
-
/* The mpic calls this even when there is no allocator setup */
- if (!mpic->hwirq_bitmap)
+ if (!mpic->msi_bitmap.bitmap)
return;
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
-}
-
-irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num)
-{
- unsigned long flags;
- int offset, order = get_count_order(num);
-
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- /*
-* This is fast, but stricter than we need. We might want to add
-* a fallback routine which does a linear search with no alignment.
-*/
- offset = bitmap_find_free_region(mpic->hwirq_bitmap, mpic->irq_count,
-order);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
-
- pr_debug("mpic: allocated 0x%x (2^%d) at offset 0x%x\n",
-num, order, offset);
-
- return offset;
-}
-
-void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug("mpic: freeing 0x%x (2^%d) at offset 0x%x\n",
-num, order, offset);
-
- spin_lock_irqsave(&mpic->bitmap_lock, flags);
- bitmap_release_region(mpic->hwirq_bitmap, offset, order);
- spin_unlock_irqrestore(&mpic->bitmap_lock, flags);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, hwirq);
}
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -83,13 +41,13 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
/* Reserve source numbers we know are reserved in the HW */
for (i = 0; i < 8; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
for (i = 42; i < 46; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
for (i = 100; i < 105; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, i);
np = NULL;
while ((np = of_find_all_nodes(np))) {
@@ -99,7 +57,7 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
while (of_irq_map_one(np, index++, &oirq) == 0) {
ops->xlate(mpic->irqhost, NULL, oirq.specifier,
oirq.size, &hwirq, &flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
+ msi_bitmap_reserve_hwirq(&mpic->msi_bitmap, hwirq);
}
}
@@ -112,70 +70,25 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
}
#endif
-static int mpic_msi_reserve_dt_hwirqs(struct mpic *mpic)
-{
- int i, len;
- const u32 *p;
-
- p = of_get_property(mpic->irqhost->of_node,
- "msi-available-ranges", &len);
- if (!p) {
- pr_debug("mpic: no msi-available-ranges property found on %s\n",
- mpic->irqhost->of_node->full_name);
- return -ENO
Re: [PATCH] of: i2c: improve last resort compatible entry selection
Hi Jean, > Eeeek. The patch you mention here is only the conversion of ONE driver. > It is absolutely not relevant as to what the general rule is. Sorry, i must have misunderstood you then. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af294867a52bf718df835a688e8c786d550bee26#patch9 is the same, my original patch listed all four supported chips in there (saa7126, saa7127, saa7128 and saa7129) while only one made it into the driver... > Jochen, I am very surprised that you dare drawing conclusions based on > one random patch of mine. And I am unhappy that you even claim that I > took some decision when I definitely did not. Maybe I draw wrong conclusions from the discussion with Jon Smirl then. > I can't comment on the specific issue at hand as I am not familiar with > it, but overall Jon appears to be right. Listing individual chips in > id_table is the standard way to go. That's even the very reason why we > decided to add this id_table to i2c_driver, instead of matching on the > driver name as we were doing before. I definitely agree here. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
GPIO drivers, other patches?
Anton, I think I've gotten most of the patches from you, but I know there are few I've lost. Can you just repost any patches that aren't in my powerpc-next tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [patch 1/2] cell: cleanup sysreset_hack for IBM cell blades
On Tuesday 15 July 2008, [EMAIL PROTECTED] wrote: > From: Christian Krafft <[EMAIL PROTECTED]> > > This patch adds a config option for the sysreset_hack used for > IBM Cell blades. The code is moves from pervasive.c into ras.c and > gets it's own init method. > > Signed-off-by: Christian Krafft <[EMAIL PROTECTED]> > thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] leds: implement OpenFirmare GPIO LED driver
Despite leds-gpio and leds-openfirmware-gpio similar purposes, there
is not much code can be shared between the two drivers (both are mostly
driver bindings anyway).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
- dropped Documentation/powerpc/ changes, since Kumar applied them via
powerpc tree.
- renamed leds-of-gpio to leds-openfirmware-gpio
drivers/leds/Kconfig |8 ++
drivers/leds/Makefile |1 +
drivers/leds/leds-openfirmware-gpio.c | 194 +
3 files changed, 203 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/leds-openfirmware-gpio.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c35dfa..a645e8d 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -119,6 +119,14 @@ config LEDS_GPIO
outputs. To be useful the particular board must have LEDs
and they must be connected to the GPIO lines.
+config LEDS_OPENFIRMWARE_GPIO
+ tristate "OpenFirmware bindings for GPIO connected LEDs"
+ depends on LEDS_CLASS && OF_GPIO
+ help
+ This option enables support for the LEDs connected to GPIO
+ outputs. To be useful the particular board must have LEDs
+ and they must be connected to the GPIO lines.
+
config LEDS_CM_X270
tristate "LED Support for the CM-X270 LEDs"
depends on LEDS_CLASS && MACH_ARMCORE
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 7156f99..0258ab7 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
+obj-$(CONFIG_LEDS_OPENFIRMWARE_GPIO) += leds-openfirmware-gpio.o
obj-$(CONFIG_LEDS_CM_X270) += leds-cm-x270.o
obj-$(CONFIG_LEDS_CLEVO_MAIL) += leds-clevo-mail.o
obj-$(CONFIG_LEDS_HP6XX) += leds-hp6xx.o
diff --git a/drivers/leds/leds-openfirmware-gpio.c
b/drivers/leds/leds-openfirmware-gpio.c
new file mode 100644
index 000..ce2c3cd
--- /dev/null
+++ b/drivers/leds/leds-openfirmware-gpio.c
@@ -0,0 +1,194 @@
+/*
+ * OpenFirmware bindings for GPIO connected LEDs
+ *
+ * Copyright (C) 2007 8D Technologies inc.
+ * Raphael Assenat <[EMAIL PROTECTED]>
+ * Copyright (C) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct of_gpio_led {
+ struct device_node *np;
+ struct led_classdev cdev;
+ unsigned int gpio;
+ struct work_struct work;
+ u8 new_level;
+ u8 can_sleep;
+};
+
+static void gpio_led_work(struct work_struct *work)
+{
+ struct of_gpio_led *led = container_of(work, struct of_gpio_led, work);
+
+ gpio_set_value_cansleep(led->gpio, led->new_level);
+}
+
+static void gpio_led_set(struct led_classdev *led_cdev,
+enum led_brightness value)
+{
+ struct of_gpio_led *led = container_of(led_cdev, struct of_gpio_led,
+ cdev);
+ int level;
+
+ if (value == LED_OFF)
+ level = 0;
+ else
+ level = 1;
+
+ /* Setting GPIOs with I2C/etc requires a task context, and we don't
+* seem to have a reliable way to know if we're already in one; so
+* let's just assume the worst.
+*/
+ if (led->can_sleep) {
+ led->new_level = level;
+ schedule_work(&led->work);
+ } else {
+ gpio_set_value(led->gpio, level);
+ }
+}
+
+static int __devinit of_gpio_leds_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct of_gpio_led *led;
+ struct device_node *np = ofdev->node;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ led->np = of_node_get(np);
+
+ ret = of_get_gpio(np, 0);
+ if (!gpio_is_valid(ret)) {
+ dev_err(&ofdev->dev, "gpio is invalid\n");
+ goto err_get_gpio;
+ }
+ led->gpio = ret;
+ led->can_sleep = gpio_cansleep(led->gpio);
+
+ led->cdev.name = of_get_property(np, "label", NULL);
+ if (!led->cdev.name)
+ led->cdev.name = dev_name(&ofdev->dev);
+ led->cdev.brightness_set = gpio_led_set;
+
+ ret = gpio_request(led->gpio, dev_name(&ofdev->dev));
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "could not request gpio, status is %d\n",
+
Re: [Cbe-oss-dev] [patch 2/2] cell: add support for power button of future IBM cell blades
On Tuesday 15 July 2008, [EMAIL PROTECTED] wrote: > From: Christian Krafft <[EMAIL PROTECTED]> > > This patch adds support for the power button on future IBM cell blades. > It actually doesn't shut down the machine. Instead it exposes an > input device /dev/input/event0 to userspace which sends KEY_POWER > if power button has been pressed. > haldaemon actually recognizes the button, so a plattform independent acpid > replacement should handle it correctly. > > Signed-off-by: Christian Krafft <[EMAIL PROTECTED]> > Thanks, applied. Note: this patch is line-wrapped, but I'll fix it up for you one more time ;-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
If you built this kernel yourself, you need to do it from a system with an up-to-date binutils (2.18) otherwise, it does this. If you got it from somewhere (like a distribution) then please tell us where, as there are some other troubles with load-base location for Fedora and so on... -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations Gabriel Paubert wrote: Hi, I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. The last message I have is: gunzip (0x <- some more hex digits) The configuration has been created from a working 2.6.25 one with make oldconfig and answering N to new config options. Anybody has seen this or do I have to start digging deeper? Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Hi Jean, On Tue, Jul 15, 2008 at 2:36 AM, Jean Delvare <[EMAIL PROTECTED]> wrote: >> Is there any way to use lspci and start at the LPC bridge, then find >> the SuperIO chip's IO address? What about ACPI tables? Perhaps probing >> logic could look for an LPC bridge before probing certain IO addresses >> even if the addresses are not in the LPC bridge config. > > I always assumed that there was no way to know in advance if a > Super-I/O (LPC) chip was present or not, let alone the exact model of > the chip. The I/O addresses are decoded by the Super-I/O chip itself, > and in general it has no relation to PCI. And I've never seen ports > 0x2e/0x2f nor 0x4e/0x4f listed in /proc/ioports. > > But of course if there is a way to know, we should use it. Avoiding > random access to I/O ports, even if they are relatively standard in > this case, is always good. I looked at my lspci output and did a little researching, and I think the only thing we can deduce is that there is an LPC bridge, so looking for a SuperIO is a good idea. If there is no LPC bridge listed, I can't say whether probing the ports is a good idea or not. David ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of: i2c: improve last resort compatible entry selection
On Tue, 15 Jul 2008 16:52:01 +0200, Jochen Friedrich wrote: > Hi Jean, > > > Eeeek. The patch you mention here is only the conversion of ONE driver. > > It is absolutely not relevant as to what the general rule is. > > Sorry, i must have misunderstood you then. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=af294867a52bf718df835a688e8c786d550bee26#patch9 > is the same, my original patch listed all four supported chips in there > (saa7126, saa7127, saa7128 and saa7129) while only one made it into the > driver... As I recall, your patch was done quickly and without knowledge of the chips in question. I did mine in close collaboration with Hans Verkuil who knows these chips very well, to make sure I wouldn't break anything. With success, as far as I can tell. Honestly, I can't remember why we decided to have a single chip name for all 4 variants. It might have been a shortcut to complete the conversion in time. Or, more likely, I didn't notice the other types because the driver was originally using the same name "saa7127" for all devices. If that is the case I'll update the driver to behave more in compliance with the new i2c device/driver matching scheme. I'll discuss this with Hans to make sure it's OK. So, again, please don't take this (nor any other) media driver conversion patch as an example of what should be done. The proper conversion of all media drivers will take a lot of time because of the history behind these drivers. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 82xx performance
On Tue Jul 15 02:34:03 EST 2008, Rune Togersen wrote: We are looking into switching kernels from 2.6.18 (ppc) to 2.6.25 (powerpc). I have been trying to run some benchmarks to see how the new kernel compares to the old one. So far it is performing worse. One test I ran was just compiling a 2.6.18 kernel on the system. The .25 performed 5 to 7 % slower: 2.6.18, make vmlinux real74m1.328s user68m48.196s sys 4m35.961s 2.6.25, make vmlinux real79m13.361s user72m41.318s sys 5m46.744s I also ran lmbench3. (slightly outdated, but still works) Most (if not all) results are worse on .25, especially context switching. Is this expected behaviour or is there anything I need to look at in my config? (I'll send config if anybody is interested) L M B E N C H 3 . 0 S U M M A R Y (Alpha software, do not distribute) Basic system parameters --- - -- Host OS Description Mhz tlb cache mem scal pages line par load bytes - - --- - - -- 9919_unit Linux 2.6.25 powerpc-linux-gnu 4343232 1. 1 9919_unit Linux 2.6.18 powerpc-linux-gnu 4453232 1.0100 1 Hmm, processor MHz is off by 11/445 Processor, Processes - times in microseconds - smaller is better --- - -- Host OS Mhz null null open slct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc - - 9919_unit Linux 2.6.25 434 0.47 1.26 10.7 35.6 34.1 1.76 14.3 2646 9964 33.K 9919_unit Linux 2.6.18 445 0.35 1.24 9.27 22.9 32.7 1.87 13.8 2157 7825 26.K Basic integer operations - times in nanoseconds - smaller is better --- Host OS intgr intgr intgr intgr intgr bit addmuldivmod - - -- -- -- -- -- 9919_unit Linux 2.6.25 2.3300 0.0100 10.7 46.2 56.0 9919_unit Linux 2.6.18 2.2300 0.0100 10.3 45.4 54.1 Basic float operations - times in nanoseconds - smaller is better - Host OS float float float float addmuldivbogo - - -- -- -- -- 9919_unit Linux 2.6.25 9.9500 10.1 46.2 66.2 9919_unit Linux 2.6.18 9.1100 9.0800 45.8 67.1 Basic double operations - times in nanoseconds - smaller is better -- Host OS double double double double addmuldivbogo - - -- -- -- -- 9919_unit Linux 2.6.25 9.3400 11.6 78.6 100.2 9919_unit Linux 2.6.18 9.1600 11.1 77.2 97.8 Integer and float operations are also off ... Context switching - times in microseconds - smaller is better --- - - Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw - - -- -- -- -- -- --- --- 9919_unit Linux 2.6.25 20.6 86.2 28.5 103.8 38.7 111.8 57.4 9919_unit Linux 2.6.18 5.3300 63.2 17.9 73.4 23.174.9 26.2 *Local* Communication latencies in microseconds - smaller is better - Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP ctxsw UNIX UDP TCP conn - - - - - - - - 9919_unit Linux 2.6.25 20.6 68.8 131. 353.1 533.4 461.7 1269 9919_unit Linux 2.6.18 5.330 36.1 87.8 225.3 402.7 331.8 520.1 970. File & VM system latencies in microseconds - smaller is better --- Host OS 0K File 10K File MmapProt Page 100fd Create Delete Create Delete Latency Fault Fault selct - - -- -- -- -- --- - --- - 9919_unit Linux 2.6.25 222.3 172.4 1003.0 350.5 41.5K 1.734 10.5 18.0 9919_unit Linux 2.6.18 181.5 144.3 789.3 293.9 23.9K 7.09560 19.3 *Local* Communication bandwidths in MB/s - bigger is better -
Re: GPIO drivers, other patches?
On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote: > Anton, > > I think I've gotten most of the patches from you, Yes, much thanks! > but I know there are > few I've lost. Can you just repost any patches that aren't in my > powerpc-next tree. Only this minor patch is missing: [PATCH v3] powerpc/83xx: update mpc83xx_defconfig to support MPC8360E-RDK http://patchwork.ozlabs.org/linuxppc/patch?id=18903 There are also last two patches I need to rework a bit (to be in compliance with latest power management work done by Scott Wood): [PATCH 1/2] [POWERPC] 86xx: suspend support http://patchwork.ozlabs.org/linuxppc/patch?id=18836 [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support http://patchwork.ozlabs.org/linuxppc/patch?id=18837 I'll resubmit them today or tomorrow. (Though, I'll appreciate if you will look into these two, maybe you'll have any comments I can fix before resubmitting). Thanks again, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
On Tue, Jul 15, 2008 at 04:27:49PM +0100, Matt Sealey wrote: > If you built this kernel yourself, you need to do it from a system with > an up-to-date binutils (2.18) otherwise, it does this. > Thanks, this is likely the problem. The distribution is Debian stable with all security udates but the binutils are still 2.17. I was also wondering why the zImage was exploding from 2 to 5MB and why it spent so much time in gzip at the end of a build. Trying to add Lenny source does not help, bummer. Aptitude fails with an error message like "Dynamic MMap ran out of room". Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO drivers, other patches?
On Jul 15, 2008, at 11:00 AM, Anton Vorontsov wrote: On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote: Anton, I think I've gotten most of the patches from you, Yes, much thanks! but I know there are few I've lost. Can you just repost any patches that aren't in my powerpc-next tree. Only this minor patch is missing: [PATCH v3] powerpc/83xx: update mpc83xx_defconfig to support MPC8360E-RDK http://patchwork.ozlabs.org/linuxppc/patch?id=18903 This one I'll hold off on until we update defconfigs after an -rc or two. There are also last two patches I need to rework a bit (to be in compliance with latest power management work done by Scott Wood): [PATCH 1/2] [POWERPC] 86xx: suspend support http://patchwork.ozlabs.org/linuxppc/patch?id=18836 [PATCH 2/2] [POWERPC] 86xx: mpc8610_hpcd: add wakeup-on-sw9 support http://patchwork.ozlabs.org/linuxppc/patch?id=18837 I'll resubmit them today or tomorrow. (Though, I'll appreciate if you will look into these two, maybe you'll have any comments I can fix before resubmitting). I want to hold off on these two patches. I'd like to understand how the function in the larger 8xxx PM world. I've applied Scott's 83xx PM patches for sleep and clearly we are doing a lot more work than on 86xx. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
On Tue, Jul 15, 2008 at 08:21:38AM -0500, Kumar Gala wrote: > > On Jul 4, 2008, at 11:53 AM, Anton Vorontsov wrote: > >> This patch adds few bindings for the new drivers to be submitted >> through >> the appropriate maintainers. >> >> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> >> --- >> >> Updated to decrypt MCU, and to split the bindings into appropriate >> files. >> >> .../powerpc/device-tree/fsl/mcu-mpc8349emitx.txt | 17 + >> Documentation/powerpc/device-tree/fsl/qe/usb.txt | 37 +++ >> + >> Documentation/powerpc/device-tree/fsl/upm-nand.txt | 28 +++ >> >> Documentation/powerpc/device-tree/gpio/led.txt | 15 >> 4 files changed, 97 insertions(+), 0 deletions(-) >> create mode 100644 Documentation/powerpc/device-tree/fsl/mcu- >> mpc8349emitx.txt >> create mode 100644 Documentation/powerpc/device-tree/fsl/qe/usb.txt >> create mode 100644 Documentation/powerpc/device-tree/fsl/upm-nand.txt >> create mode 100644 Documentation/powerpc/device-tree/gpio/led.txt > > applied. Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in my patch: commit 91993d56812fd09b6cccea12d3c83df623cb0ea6 Author: Anton Vorontsov <[EMAIL PROTECTED]> Date: Fri Jul 4 20:53:28 2008 +0400 powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings This patch adds few bindings for the new drivers to be submitted through the appropriate maintainers. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> diff --git a/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emit new file mode 100644 index 000..0f76633 --- /dev/null +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2.6.26] powerpc: Add support for multiple gfar mdio interfaces
On May 2, 2008, at 1:03 PM, Andy Fleming wrote: The old code assumed there was only one, but the 8572 actually has 3. Also, our usual id, 0xe0024520, gets resolved to -1 somewhere, and this was preventing the multiple buses from having different ids. So we only keep the low 20 bits, which have the interesting info, anyway. Signed-off-by: Andy Fleming <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/fsl_soc.c | 84 + +-- 1 files changed, 38 insertions(+), 46 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Fix a bunch of sparse warnings in the qe_lib
On May 7, 2008, at 1:19 PM, Andy Fleming wrote: Mostly having to do with not marking things __iomem. And some failure to use appropriate accessors to read MMIO regs. Signed-off-by: Andy Fleming <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/qe_lib/qe.c |6 +++--- arch/powerpc/sysdev/qe_lib/ucc.c |6 +++--- arch/powerpc/sysdev/qe_lib/ucc_fast.c | 16 include/asm-powerpc/ucc_fast.h|8 4 files changed, 18 insertions(+), 18 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.26 does not boot on Pegasos
On 7/15/08, Matt Sealey <[EMAIL PROTECTED]> wrote: > If you built this kernel yourself, you need to do it from a system with > an up-to-date binutils (2.18) otherwise, it does this. > > If you got it from somewhere (like a distribution) then please tell us > where, as there are some other troubles with load-base location for > Fedora and so on... Is it hard to put a check into the kernel make system to look for binutils 2.17 and refuse to build with a nice error message? I poked around in the makefile but I'm not 100% sure of how it works. > > -- > Matt Sealey <[EMAIL PROTECTED]> > Genesi, Manager, Developer Relations > > > Gabriel Paubert wrote: > > >Hi, > > > > I just tried to boot 2.6.26 on a Pegasos and the kernel does not boot. > > The last message I have is: > > gunzip (0x <- some more hex digits) > > > > The configuration has been created from a working 2.6.25 one with > > make oldconfig and answering N to new config options. > > > > Anybody has seen this or do I have to start digging deeper? > > > >Regards, > >Gabriel > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@ozlabs.org > > https://ozlabs.org/mailman/listinfo/linuxppc-dev > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] 86xx: suspend support
On Jun 6, 2008, at 2:24 PM, Anton Vorontsov wrote: This patch adds suspend (standby, not suspend-to-ram) support for MPC86xx processors. In standby mode MPC86xx is able to wakeup only upon external interrupts (including sreset). Signed-off-by: Scott Wood <[EMAIL PROTECTED]> Signed-off-by: Jason Jin <[EMAIL PROTECTED]> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig |2 +- arch/powerpc/platforms/86xx/Makefile |1 + arch/powerpc/platforms/86xx/mpc86xx_suspend.c | 92 + 3 files changed, 94 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c I'd like to understand how much PM support these patches really add w/ regards to the work Scott's done for 83xx PM. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [POWERPC] 86xx: suspend support
On Tue, Jul 15, 2008 at 11:16:14AM -0500, Kumar Gala wrote: > > On Jun 6, 2008, at 2:24 PM, Anton Vorontsov wrote: > >> This patch adds suspend (standby, not suspend-to-ram) support for >> MPC86xx >> processors. >> >> In standby mode MPC86xx is able to wakeup only upon external >> interrupts >> (including sreset). >> >> Signed-off-by: Scott Wood <[EMAIL PROTECTED]> >> Signed-off-by: Jason Jin <[EMAIL PROTECTED]> >> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> >> --- >> arch/powerpc/Kconfig |2 +- >> arch/powerpc/platforms/86xx/Makefile |1 + >> arch/powerpc/platforms/86xx/mpc86xx_suspend.c | 92 >> + >> 3 files changed, 94 insertions(+), 1 deletions(-) >> create mode 100644 arch/powerpc/platforms/86xx/mpc86xx_suspend.c > > I'd like to understand how much PM support these patches really add w/ > regards to the work Scott's done for 83xx PM. This support provides "sleep" mode, i.e. almost all internal core functions are off, some peripherals could be turned off, but sysclk must be preserved. Upon wakeup CPU continues execution where it was put to sleep. This is also called standby mode. This patch does not implement "deep sleep" (suspend-to-ram) mode yet. Deep sleep can save more power: CPU can be turned off completely (except SDRAM -- it must still receive refresh cycles). But deep sleep is also more tricky to implement.. During deep sleep CPU losing all track of execution and state, thus upon wakeup CPU starts execution of the firmware, so the firmware should be also aware of deep sleep capability. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in my patch: commit 91993d56812fd09b6cccea12d3c83df623cb0ea6 Author: Anton Vorontsov <[EMAIL PROTECTED]> Date: Fri Jul 4 20:53:28 2008 +0400 powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings This patch adds few bindings for the new drivers to be submitted through the appropriate maintainers. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- mpc8349emit new file mode 100644 index 000..0f76633 --- /dev/null +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt duh. will fix it up. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in my patch: commit 91993d56812fd09b6cccea12d3c83df623cb0ea6 Author: Anton Vorontsov <[EMAIL PROTECTED]> Date: Fri Jul 4 20:53:28 2008 +0400 powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings This patch adds few bindings for the new drivers to be submitted through the appropriate maintainers. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- mpc8349emit new file mode 100644 index 000..0f76633 --- /dev/null +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt Rebased the tree and fixed it. Can you look over the files and make sure everything looks ok. (I'm partially concerned about the QE usb node). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: GPIO drivers, other patches?
On Tue, Jul 15, 2008 at 08:00:48PM +0400, Anton Vorontsov wrote: > On Tue, Jul 15, 2008 at 10:10:21AM -0500, Kumar Gala wrote: > > Anton, > > > > I think I've gotten most of the patches from you, > > Yes, much thanks! > > > but I know there are > > few I've lost. Can you just repost any patches that aren't in my > > powerpc-next tree. While testing the tree in run-time found that this patch is missing: [PATCH 3/4] powerpc: rtc_cmos_setup: assign interrupts only if there is i8259 PIC http://patchwork.ozlabs.org/linuxppc/patch?id=18915 Without this patch rtc will fail to probe on MPC8610HPCD: rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0 rtc_cmos: probe of rtc_cmos failed with error -38 Did you deliberately hold off this patch, i.e. should I ask Benjamin to take this through his tree? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
On Tue, Jul 15, 2008 at 11:23:42AM -0500, Kumar Gala wrote: >>> >> Ugh, you fixed bindings' directory in Jochen's CPM patch, but not in >> my patch: >> >> commit 91993d56812fd09b6cccea12d3c83df623cb0ea6 >> Author: Anton Vorontsov <[EMAIL PROTECTED]> >> Date: Fri Jul 4 20:53:28 2008 +0400 >> >>powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings >> >>This patch adds few bindings for the new drivers to be submitted >> through >>the appropriate maintainers. >> >>Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> >>Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> >> >> diff --git a/Documentation/powerpc/device-tree/fsl/mcu- >> mpc8349emitx.txt b/Documentation/powerpc/device-tree/fsl/mcu- >> mpc8349emit >> new file mode 100644 >> index 000..0f76633 >> --- /dev/null >> +++ b/Documentation/powerpc/device-tree/fsl/mcu-mpc8349emitx.txt >> > > Rebased the tree and fixed it. Can you look over the files and make > sure everything looks ok. (I'm partially concerned about the QE usb > node). Yes, everything looks fine. b-w-of specified old QE USB bindings, and no single driver actually used them. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
> 9919_unit Linux 2.6.25 powerpc-linux-gnu 4343232 > > 1. 1 > > 9919_unit Linux 2.6.18 powerpc-linux-gnu 4453232 > > 1.0100 1 > > Hmm, processor MHz is off by 11/445 I noticed that. > And memory latency is off 13/500. > > That sounds like it will be 16/666. > > Are you using the same board and the same firmware? Yes. Same board, same firmware, same filesystem, just booted with different kernels. > > If so, look at /proc/cpuinfo and/or the boot log to see what > frequency linux thinks the processor is running at. It sounds > like someone introduced or fixed a rounding error error calculating > the timebase frequency for your board. 2.6.18 /proc/cpuinfo processor : 0 cpu : G2_LE revision: 1.4 (pvr 8082 2014) bogomips: 296.96 chipset : 8250 vendor : Innovative Systems LLC machine : AP Gold mem size: 0x4000 console baud: 115200 core clock : 447 MHz CPM clock : 298 MHz bus clock : 99 MHz 2.6.25 /proc/cpuinfo processor : 0 cpu : G2_LE clock : 447.897600MHz revision: 1.4 (pvr 8082 2014) bogomips: 49.53 timebase: 24883200 platform: Innovative Systems ApMax > Please try the sleep test: sleep for 100 seconds, and time with > either a stopwatch or another system. I think you will find they > take different amounts of time, and all the results need to be scaled. > You might be able to see it reading the hardware clock. Sleep 100 takes excactly 100 seconds on both kernels (verified with stopwatch and external ntp server) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
> * Maybe there is a kernel version that supports your hardware in both > arch/ppc/ and arch/powerpc. In that case, you could see if > the platform > change had an impact. Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile test I did is almost identical (within 1%) of what the arch/powerpc 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25 (I'll see if I can find an exact version, as I think my ppc port can be compiled for all versions from 2.6.18 to 25) And running oprofile didn't help much, as it seems not to have been able to figure out what in the kernel got called. (the Freescale 82xx dcoes not have hw performance registers) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
DTC: libfdt Install Woes
David, Somewhat recently, the DTC commit 6a6c972cdf9e "dtc: Clean up included Makefile fragments" removed this line LIBFDT_INCLUDES = fdt.h libfdt.h from the libfdt/Makefile.libfdt. As a result, the standalone "make install" is onw failing. We could put that line back, or remove the top-level Makefile install target that is trying to use this definition. I'm not sure which direction you want to head here. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 82xx performance
On Tuesday 15 July 2008, Rune Torgersen wrote: > Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile > test I did is almost identical (within 1%) of what the arch/powerpc > 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25 > (I'll see if I can find an exact version, as I think my ppc port can be > compiled for all versions from 2.6.18 to 25) You probably already know git-bisect, but if you don't, you should definitely give it a try. It's the best tool to find which patch exactly broke your performance. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/9] Cell patches for 2.6.27, version 2
Hi Ben, These are the remaining patches I have lined up for 2.6.27. Thanks for including the others already. There were a few comments in the last round that I hope all got addressed now. I'm not sure about the final two patches for the IOMMU, I think you wanted to investigate the situation more, but I haven't seen an update from you any more. I'm convinced going to weak ordering is the right move for the cell IOMMU, and even if it is not, it will not break anything on current machines because the firmware already overrides this setting. I have left the copy_to_user in AZFS in place, I think we need to follow up on this again, to either document that copy_fromto_user needs to be able to work on uncached memory, or to do an extra copy, but I think this should not hold up the AZFS merge. All other comments for it have been addressed. You can pull from the usual location at master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git cell-next Arnd <>< -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/9] powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Christian Krafft <[EMAIL PROTECTED]>
This patch adds a cpufreq governor that takes the number of running spus
into account. It's very similar to the ondemand governor, but not as complex.
Instead of hacking spu load into the ondemand governor it might be easier to
have cpufreq accepting multiple governors per cpu in future.
Don't know if this is the right way, but it would keep the governors simple.
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Acked-by: Dave Jones <[EMAIL PROTECTED]>
Cc: Jeremy Kerr <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/Kconfig |9 +
arch/powerpc/platforms/cell/Makefile|1 +
arch/powerpc/platforms/cell/cpufreq_spudemand.c | 184 +++
3 files changed, 194 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/cpufreq_spudemand.c
diff --git a/arch/powerpc/platforms/cell/Kconfig
b/arch/powerpc/platforms/cell/Kconfig
index 3959fcf..6ee571f 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -107,6 +107,15 @@ config CBE_CPUFREQ_PMI
processor will not only be able to run at lower speed,
but also at lower core voltage.
+config CBE_CPUFREQ_SPU_GOVERNOR
+ tristate "CBE frequency scaling based on SPU usage"
+ depends on SPU_FS && CPU_FREQ
+ default m
+ help
+ This governor checks for spu usage to adjust the cpu frequency.
+ If no spu is running on a given cpu, that cpu will be throttled to
+ the minimal possible frequency.
+
endmenu
config OPROFILE_CELL
diff --git a/arch/powerpc/platforms/cell/Makefile
b/arch/powerpc/platforms/cell/Makefile
index c2a7e4e..7fcf09b 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CBE_THERM) += cbe_thermal.o
obj-$(CONFIG_CBE_CPUFREQ_PMI) += cbe_cpufreq_pmi.o
obj-$(CONFIG_CBE_CPUFREQ) += cbe-cpufreq.o
cbe-cpufreq-y += cbe_cpufreq_pervasive.o cbe_cpufreq.o
+obj-$(CONFIG_CBE_CPUFREQ_SPU_GOVERNOR) += cpufreq_spudemand.o
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_CELL_NATIVE) += smp.o
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
new file mode 100644
index 000..a3c6c01
--- /dev/null
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -0,0 +1,184 @@
+/*
+ * spu aware cpufreq governor for the cell processor
+ *
+ * © Copyright IBM Corporation 2006-2008
+ *
+ * Author: Christian Krafft <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define POLL_TIME 10 /* in µs */
+#define EXP753 /* exp(-1) in fixed-point */
+
+struct spu_gov_info_struct {
+ unsigned long busy_spus;/* fixed-point */
+ struct cpufreq_policy *policy;
+ struct delayed_work work;
+ unsigned int poll_int; /* µs */
+};
+static DEFINE_PER_CPU(struct spu_gov_info_struct, spu_gov_info);
+
+static struct workqueue_struct *kspugov_wq;
+
+static int calc_freq(struct spu_gov_info_struct *info)
+{
+ int cpu;
+ int busy_spus;
+
+ cpu = info->policy->cpu;
+ busy_spus = atomic_read(&cbe_spu_info[cpu_to_node(cpu)].busy_spus);
+
+ CALC_LOAD(info->busy_spus, EXP, busy_spus * FIXED_1);
+ pr_debug("cpu %d: busy_spus=%d, info->busy_spus=%ld\n",
+ cpu, busy_spus, info->busy_spus);
+
+ return info->policy->max * info->busy_spus / FIXED_1;
+}
+
+static void spu_gov_work(struct work_struct *work)
+{
+ struct spu_gov_info_struct *info;
+ int delay;
+ unsigned long target_freq;
+
+ info = container_of(work, struct spu_gov_info_struct, work.work);
+
+ /* after cancel_delayed_work_sync we unset info->policy */
+ BUG_ON(info->policy == NULL);
+
+ target_freq = calc_freq(info);
+ __cpufreq_driver_target(info->policy, target_freq, CPUFREQ_RELATION_H);
+
+ delay = usecs_to_jiffies(info->poll_int);
+ queue_delayed_work_on(info->policy->cpu, kspugov_wq, &info->work,
delay);
+}
+
+static void spu_gov_init_work
[patch 3/9] powerpc/axonram: enable partitioning of the Axons DDR2 DIMMs
From: Maxim Shchetynin <[EMAIL PROTECTED]>
DDR2 memory DIMMs on the Axon could be accessed only as one partition
when using file system drivers which are using the direct_access() method.
This patch enables for such file system drivers to access Axon's DDR2 memory
even if it is splitted in several partitions.
Signed-off-by: Maxim Shchetynin <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/axonram.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 9b639ed..9e105cb 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -150,7 +150,10 @@ axon_ram_direct_access(struct block_device *device,
sector_t sector,
struct axon_ram_bank *bank = device->bd_disk->private_data;
loff_t offset;
- offset = sector << AXON_RAM_SECTOR_SHIFT;
+ offset = sector;
+ if (device->bd_part != NULL)
+ offset += device->bd_part->start_sect;
+ offset <<= AXON_RAM_SECTOR_SHIFT;
if (offset >= bank->size) {
dev_err(&bank->device->dev, "Access outside of address
space\n");
return -ERANGE;
--
1.5.4.3
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 7/9] azfs: initial submit of azfs, a non-buffered filesystem
From: Maxim Shchetynin <[EMAIL PROTECTED]> AZFS is a file system which keeps all files on memory mapped random access storage. It was designed to work on the axonram device driver for IBM QS2x blade servers, but can operate on any block device that exports a direct_access method. Signed-off-by: Maxim Shchetynin <[EMAIL PROTECTED]> Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- Documentation/filesystems/azfs.txt | 22 + arch/powerpc/configs/cell_defconfig |1 + fs/Kconfig | 15 + fs/Makefile |1 + fs/azfs/Makefile|7 + fs/azfs/inode.c | 1184 +++ 6 files changed, 1230 insertions(+), 0 deletions(-) create mode 100644 Documentation/filesystems/azfs.txt create mode 100644 fs/azfs/Makefile create mode 100644 fs/azfs/inode.c diff --git a/Documentation/filesystems/azfs.txt b/Documentation/filesystems/azfs.txt new file mode 100644 index 000..c4bf659 --- /dev/null +++ b/Documentation/filesystems/azfs.txt @@ -0,0 +1,22 @@ +AZFS is a file system which keeps all files on memory backed random +access storage. It was designed to work on the axonram device driver +for IBM QS2x blade servers, but can operate on any block device +that exports a direct_access method. + +Everything in AZFS is temporary in the sense that all the data stored +therein is lost when you switch off or reboot a system. If you unmount +an AZFS instance, all the data will be kept on device as long your system +is not shut down or rebooted. You can later mount AZFS on from device again +to get access to your files. + +AZFS uses a block device only for data but not for file information. +All inodes (file and directory information) is kept in RAM. + +When you mount AZFS you are able to specify a file system block size with +'-o bs=' option. There are no software limitations for +a block size but you would not be able to mmap files on AZFS if block size +is less than a system page size. If no '-o bs' option is specified on mount +a block size of the used block device is used as a default block size for AZFS. + +Other available mount options for AZFS are '-o uid=' and '-o gid=', +which allow you to set the owner and group of the root of the file system. diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig index c420e47..235a0c8 100644 --- a/arch/powerpc/configs/cell_defconfig +++ b/arch/powerpc/configs/cell_defconfig @@ -240,6 +240,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # CPU Frequency drivers # CONFIG_AXON_RAM=m +CONFIG_AZ_FS=m # CONFIG_FSL_ULI1575 is not set # diff --git a/fs/Kconfig b/fs/Kconfig index 2694648..2d4e42b 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1017,6 +1017,21 @@ config HUGETLBFS config HUGETLB_PAGE def_bool HUGETLBFS +config AZ_FS + tristate "AZFS filesystem support" + help + azfs is a file system for I/O attached memory backing. It requires + a block device with direct_access capability, e.g. axonram. + Mounting such device with azfs gives memory mapped access to the + underlying memory to user space. + + Read for details. + + To compile this file system support as a module, choose M here: the + module will be called azfs. + + If unsure, say N. + config CONFIGFS_FS tristate "Userspace-driven configuration filesystem" depends on SYSFS diff --git a/fs/Makefile b/fs/Makefile index 1e7a11b..20e3253 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -119,3 +119,4 @@ obj-$(CONFIG_HPPFS) += hppfs/ obj-$(CONFIG_DEBUG_FS) += debugfs/ obj-$(CONFIG_OCFS2_FS) += ocfs2/ obj-$(CONFIG_GFS2_FS) += gfs2/ +obj-$(CONFIG_AZ_FS)+= azfs/ diff --git a/fs/azfs/Makefile b/fs/azfs/Makefile new file mode 100644 index 000..ff04d41 --- /dev/null +++ b/fs/azfs/Makefile @@ -0,0 +1,7 @@ +# +# Makefile for azfs routines +# + +obj-$(CONFIG_AZ_FS) += azfs.o + +azfs-y := inode.o diff --git a/fs/azfs/inode.c b/fs/azfs/inode.c new file mode 100644 index 000..00dc2af --- /dev/null +++ b/fs/azfs/inode.c @@ -0,0 +1,1184 @@ +/* + * (C) Copyright IBM Deutschland Entwicklung GmbH 2007 + * + * Author: Maxim Shchetynin <[EMAIL PROTECTED]> + * + * Non-buffered filesystem driver. + * It registers a filesystem which may be used for all kind of block devices + * which have a direct_access() method in block_device_operations. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should
[patch 5/9] powerpc/cell: cleanup sysreset_hack for IBM cell blades
From: Christian Krafft <[EMAIL PROTECTED]>
This patch adds a config option for the sysreset_hack used for
IBM Cell blades. The code is moves from pervasive.c into ras.c and
gets it's own init method.
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/Kconfig |8 +
arch/powerpc/platforms/cell/pervasive.c | 27 +-
arch/powerpc/platforms/cell/pervasive.h |9 ++
arch/powerpc/platforms/cell/ras.c | 46 +++
4 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/platforms/cell/Kconfig
b/arch/powerpc/platforms/cell/Kconfig
index 6ee571f..2d1957b 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -83,6 +83,14 @@ config CBE_RAS
depends on PPC_CELL_NATIVE
default y
+config PPC_IBM_CELL_RESETBUTTON
+ bool "IBM Cell Blade Pinhole reset button"
+ depends on CBE_RAS && PPC_IBM_CELL_BLADE
+ default y
+ help
+ Support Pinhole Resetbutton on IBM Cell blades.
+ This adds a method to trigger system reset via front panel pinhole
button.
+
config CBE_THERM
tristate "CBE thermal support"
default m
diff --git a/arch/powerpc/platforms/cell/pervasive.c
b/arch/powerpc/platforms/cell/pervasive.c
index 8a3631c..efdacc8 100644
--- a/arch/powerpc/platforms/cell/pervasive.c
+++ b/arch/powerpc/platforms/cell/pervasive.c
@@ -38,8 +38,6 @@
#include "pervasive.h"
-static int sysreset_hack;
-
static void cbe_power_save(void)
{
unsigned long ctrl, thread_switch_control;
@@ -87,9 +85,6 @@ static void cbe_power_save(void)
static int cbe_system_reset_exception(struct pt_regs *regs)
{
- int cpu;
- struct cbe_pmd_regs __iomem *pmd;
-
switch (regs->msr & SRR1_WAKEMASK) {
case SRR1_WAKEEE:
do_IRQ(regs);
@@ -98,19 +93,7 @@ static int cbe_system_reset_exception(struct pt_regs *regs)
timer_interrupt(regs);
break;
case SRR1_WAKEMT:
- /*
-* The BMC can inject user triggered system reset exceptions,
-* but cannot set the system reset reason in srr1,
-* so check an extra register here.
-*/
- if (sysreset_hack && (cpu = smp_processor_id()) == 0) {
- pmd = cbe_get_cpu_pmd_regs(cpu);
- if (in_be64(&pmd->ras_esc_0) & 0x) {
- out_be64(&pmd->ras_esc_0, 0);
- return 0;
- }
- }
- break;
+ return cbe_sysreset_hack();
#ifdef CONFIG_CBE_RAS
case SRR1_WAKESYSERR:
cbe_system_error_exception(regs);
@@ -134,8 +117,6 @@ void __init cbe_pervasive_init(void)
if (!cpu_has_feature(CPU_FTR_PAUSE_ZERO))
return;
- sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
-
for_each_possible_cpu(cpu) {
struct cbe_pmd_regs __iomem *regs = cbe_get_cpu_pmd_regs(cpu);
if (!regs)
@@ -144,12 +125,6 @@ void __init cbe_pervasive_init(void)
/* Enable Pause(0) control bit */
out_be64(®s->pmcr, in_be64(®s->pmcr) |
CBE_PMD_PAUSE_ZERO_CONTROL);
-
- /* Enable JTAG system-reset hack */
- if (sysreset_hack)
- out_be32(®s->fir_mode_reg,
- in_be32(®s->fir_mode_reg) |
- CBE_PMD_FIR_MODE_M8);
}
ppc_md.power_save = cbe_power_save;
diff --git a/arch/powerpc/platforms/cell/pervasive.h
b/arch/powerpc/platforms/cell/pervasive.h
index 7b50947..fd4d7b7 100644
--- a/arch/powerpc/platforms/cell/pervasive.h
+++ b/arch/powerpc/platforms/cell/pervasive.h
@@ -30,4 +30,13 @@ extern void cbe_system_error_exception(struct pt_regs *regs);
extern void cbe_maintenance_exception(struct pt_regs *regs);
extern void cbe_thermal_exception(struct pt_regs *regs);
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+extern int cbe_sysreset_hack(void);
+#else
+static inline int cbe_sysreset_hack(void)
+{
+ return 1;
+}
+#endif /* CONFIG_PPC_IBM_CELL_RESETBUTTON */
+
#endif
diff --git a/arch/powerpc/platforms/cell/ras.c
b/arch/powerpc/platforms/cell/ras.c
index 505f9b9..2a14b05 100644
--- a/arch/powerpc/platforms/cell/ras.c
+++ b/arch/powerpc/platforms/cell/ras.c
@@ -236,6 +236,52 @@ static struct notifier_block cbe_ptcal_reboot_notifier = {
.notifier_call = cbe_ptcal_notify_reboot
};
+#ifdef CONFIG_PPC_IBM_CELL_RESETBUTTON
+static int sysreset_hack;
+
+static int __init cbe_sysreset_init(void)
+{
+ struct cbe_pmd_regs __iomem *regs;
+
+ sysreset_hack = machine_is_compatible("IBM,CBPLUS-1.0");
+ if (!sysreset_hack)
+ return 0;
+
+
[patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Mark Nelson <[EMAIL PROTECTED]>
Introduce a new dma attriblue DMA_ATTR_STRONG_ORDERING to use strong ordering
on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
implementation to use this.
The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs
(for both the dynamic and fixed mappings) which enforces strong ordering of
both reads and writes. This patch makes the default behaviour weak ordering
(the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the
new DMA_ATTR_STRONG_ORDERING needs to be used.
Dynamic mappings can be weakly or strongly ordered on an individual basis
but the fixed mapping is always weakly ordered.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
Documentation/DMA-attributes.txt| 12 +
arch/powerpc/platforms/cell/iommu.c | 93 ---
include/linux/dma-attrs.h |1 +
3 files changed, 99 insertions(+), 7 deletions(-)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 6d772f8..f2d2800 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -22,3 +22,15 @@ ready and available in memory. The DMA of the "completion
indication"
could race with data DMA. Mapping the memory used for completion
indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
+
+DMA_ATTR_STRONG_ORDERING
+--
+
+DMA_ATTR_STRONG_ORDERING specifies that previous reads and writes are
+performed in the order in which they're received by the IOMMU; thus
+reads and writes may not pass each other.
+
+Platforms that are strongly ordered by default will ignore this new
+attribute but platforms that are weakly ordered by default should not
+ignore this new attribute. Instead, they should return an error if a
+strongly ordered mapping cannot be used when one is requested.
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 3b70784..7f6ed20 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -194,11 +194,13 @@ static void tce_build_cell(struct iommu_table *tbl, long
index, long npages,
const unsigned long prot = 0xc48;
base_pte =
((prot << (52 + 4 * direction)) & (IOPTE_PP_W | IOPTE_PP_R))
- | IOPTE_M | IOPTE_SO_RW | (window->ioid & IOPTE_IOID_Mask);
+ | IOPTE_M | (window->ioid & IOPTE_IOID_Mask);
#else
- base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M | IOPTE_SO_RW |
+ base_pte = IOPTE_PP_W | IOPTE_PP_R | IOPTE_M |
(window->ioid & IOPTE_IOID_Mask);
#endif
+ if (unlikely(dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs)))
+ base_pte |= IOPTE_SO_RW;
io_pte = (unsigned long *)tbl->it_base + (index - tbl->it_offset);
@@ -539,7 +541,6 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
static unsigned long dma_iommu_fixed_base;
-struct dma_mapping_ops dma_iommu_fixed_ops;
static struct iommu_table *cell_get_iommu_table(struct device *dev)
{
@@ -563,6 +564,85 @@ static struct iommu_table *cell_get_iommu_table(struct
device *dev)
return &window->table;
}
+static void *dma_fixed_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag)
+{
+ return dma_direct_ops.alloc_coherent(dev, size, dma_handle, flag);
+}
+
+static void dma_fixed_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle)
+{
+ dma_direct_ops.free_coherent(dev, size, vaddr, dma_handle);
+}
+
+static dma_addr_t dma_fixed_map_single(struct device *dev, void *ptr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs))
+ return iommu_map_single(dev, cell_get_iommu_table(dev), ptr,
+ size, device_to_mask(dev), direction,
+ attrs);
+ else
+ return dma_direct_ops.map_single(dev, ptr, size, direction,
+attrs);
+}
+
+static void dma_fixed_unmap_single(struct device *dev, dma_addr_t dma_addr,
+ size_t size,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
+{
+ if (dma_get_attr(DMA_ATTR_STRONG_ORDERING, attrs))
+ iommu_unmap_single(cell_get_iommu_table(dev), dma_addr, size,
+ direction, attrs);
+ else
+ dma_direct_ops.unmap_single(dev, dma_addr, size, direction,
+
[patch 6/9] powerpc/cell: add support for power button of future IBM cell blades
From: Christian Krafft <[EMAIL PROTECTED]>
This patch adds support for the power button on future IBM cell blades.
It actually doesn't shut down the machine. Instead it exposes an
input device /dev/input/event0 to userspace which sends KEY_POWER
if power button has been pressed.
haldaemon actually recognizes the button, so a plattform independent acpid
replacement should handle it correctly.
Signed-off-by: Christian Krafft <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/Kconfig |8 ++
arch/powerpc/platforms/cell/Makefile |2 +
arch/powerpc/platforms/cell/cbe_powerbutton.c | 117 +
include/asm-powerpc/pmi.h |1 +
4 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/cbe_powerbutton.c
diff --git a/arch/powerpc/platforms/cell/Kconfig
b/arch/powerpc/platforms/cell/Kconfig
index 2d1957b..c14d7d8 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -91,6 +91,14 @@ config PPC_IBM_CELL_RESETBUTTON
Support Pinhole Resetbutton on IBM Cell blades.
This adds a method to trigger system reset via front panel pinhole
button.
+config PPC_IBM_CELL_POWERBUTTON
+ tristate "IBM Cell Blade power button"
+ depends on PPC_IBM_CELL_BLADE && PPC_PMI && INPUT_EVDEV
+ default y
+ help
+ Support Powerbutton on IBM Cell blades.
+ This will enable the powerbutton as an input device.
+
config CBE_THERM
tristate "CBE thermal support"
default m
diff --git a/arch/powerpc/platforms/cell/Makefile
b/arch/powerpc/platforms/cell/Makefile
index 7fcf09b..7fd8308 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -10,6 +10,8 @@ obj-$(CONFIG_CBE_CPUFREQ) += cbe-cpufreq.o
cbe-cpufreq-y += cbe_cpufreq_pervasive.o cbe_cpufreq.o
obj-$(CONFIG_CBE_CPUFREQ_SPU_GOVERNOR) += cpufreq_spudemand.o
+obj-$(CONFIG_PPC_IBM_CELL_POWERBUTTON) += cbe_powerbutton.o
+
ifeq ($(CONFIG_SMP),y)
obj-$(CONFIG_PPC_CELL_NATIVE) += smp.o
endif
diff --git a/arch/powerpc/platforms/cell/cbe_powerbutton.c
b/arch/powerpc/platforms/cell/cbe_powerbutton.c
new file mode 100644
index 000..dcddaa5
--- /dev/null
+++ b/arch/powerpc/platforms/cell/cbe_powerbutton.c
@@ -0,0 +1,117 @@
+/*
+ * driver for powerbutton on IBM cell blades
+ *
+ * (C) Copyright IBM Corp. 2005-2008
+ *
+ * Author: Christian Krafft <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+
+static struct input_dev *button_dev;
+static struct platform_device *button_pdev;
+
+static void cbe_powerbutton_handle_pmi(pmi_message_t pmi_msg)
+{
+ BUG_ON(pmi_msg.type != PMI_TYPE_POWER_BUTTON);
+
+ input_report_key(button_dev, KEY_POWER, 1);
+ input_sync(button_dev);
+ input_report_key(button_dev, KEY_POWER, 0);
+ input_sync(button_dev);
+}
+
+static struct pmi_handler cbe_pmi_handler = {
+ .type = PMI_TYPE_POWER_BUTTON,
+ .handle_pmi_message = cbe_powerbutton_handle_pmi,
+};
+
+static int __init cbe_powerbutton_init(void)
+{
+ int ret = 0;
+ struct input_dev *dev;
+
+ if (!machine_is_compatible("IBM,CBPLUS-1.0")) {
+ printk(KERN_ERR "%s: Not a cell blade.\n", __func__);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ dev = input_allocate_device();
+ if (!dev) {
+ ret = -ENOMEM;
+ printk(KERN_ERR "%s: Not enough memory.\n", __func__);
+ goto out;
+ }
+
+ set_bit(EV_KEY, dev->evbit);
+ set_bit(KEY_POWER, dev->keybit);
+
+ dev->name = "Power Button";
+ dev->id.bustype = BUS_HOST;
+
+ /* this makes the button look like an acpi power button
+* no clue whether anyone relies on that though */
+ dev->id.product = 0x02;
+ dev->phys = "LNXPWRBN/button/input0";
+
+ button_pdev = platform_device_register_simple("power_button", 0, NULL,
0);
+ if (IS_ERR(button_pdev)) {
+ ret = PTR_ERR(button_pdev);
+ goto out_free_input;
+ }
+
+ dev->dev.parent = &button_pdev->dev;
[patch 8/9] powerpc/dma: use the struct dma_attrs in iommu code
From: Mark Nelson <[EMAIL PROTECTED]>
Update iommu_alloc() to take the struct dma_attrs and pass them on to
tce_build(). This change propagates down to the tce_build functions of
all the platforms.
Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/iommu.c| 13 -
arch/powerpc/platforms/cell/iommu.c|5 +++--
arch/powerpc/platforms/iseries/iommu.c |3 ++-
arch/powerpc/platforms/pasemi/iommu.c |3 ++-
arch/powerpc/platforms/pseries/iommu.c | 14 +-
arch/powerpc/sysdev/dart_iommu.c |3 ++-
include/asm-powerpc/machdep.h |3 ++-
7 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 8c68ee9..2385f68 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -186,7 +186,8 @@ static unsigned long iommu_range_alloc(struct device *dev,
static dma_addr_t iommu_alloc(struct device *dev, struct iommu_table *tbl,
void *page, unsigned int npages,
enum dma_data_direction direction,
- unsigned long mask, unsigned int align_order)
+ unsigned long mask, unsigned int align_order,
+ struct dma_attrs *attrs)
{
unsigned long entry, flags;
dma_addr_t ret = DMA_ERROR_CODE;
@@ -205,7 +206,7 @@ static dma_addr_t iommu_alloc(struct device *dev, struct
iommu_table *tbl,
/* Put the TCEs in the HW table */
ppc_md.tce_build(tbl, entry, npages, (unsigned long)page &
IOMMU_PAGE_MASK,
-direction);
+direction, attrs);
/* Flush/invalidate TLB caches if necessary */
@@ -336,7 +337,8 @@ int iommu_map_sg(struct device *dev, struct iommu_table
*tbl,
npages, entry, dma_addr);
/* Insert into HW table */
- ppc_md.tce_build(tbl, entry, npages, vaddr & IOMMU_PAGE_MASK,
direction);
+ ppc_md.tce_build(tbl, entry, npages, vaddr & IOMMU_PAGE_MASK,
+direction, attrs);
/* If we are in an open segment, try merging */
if (segstart != s) {
@@ -573,7 +575,8 @@ dma_addr_t iommu_map_single(struct device *dev, struct
iommu_table *tbl,
align = PAGE_SHIFT - IOMMU_PAGE_SHIFT;
dma_handle = iommu_alloc(dev, tbl, vaddr, npages, direction,
-mask >> IOMMU_PAGE_SHIFT, align);
+mask >> IOMMU_PAGE_SHIFT, align,
+attrs);
if (dma_handle == DMA_ERROR_CODE) {
if (printk_ratelimit()) {
printk(KERN_INFO "iommu_alloc failed, "
@@ -642,7 +645,7 @@ void *iommu_alloc_coherent(struct device *dev, struct
iommu_table *tbl,
nio_pages = size >> IOMMU_PAGE_SHIFT;
io_order = get_iommu_order(size);
mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
- mask >> IOMMU_PAGE_SHIFT, io_order);
+ mask >> IOMMU_PAGE_SHIFT, io_order, NULL);
if (mapping == DMA_ERROR_CODE) {
free_pages((unsigned long)ret, order);
return NULL;
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index eeacb3a..3b70784 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -173,7 +173,8 @@ static void invalidate_tce_cache(struct cbe_iommu *iommu,
unsigned long *pte,
}
static void tce_build_cell(struct iommu_table *tbl, long index, long npages,
- unsigned long uaddr, enum dma_data_direction direction)
+ unsigned long uaddr, enum dma_data_direction direction,
+ struct dma_attrs *attrs)
{
int i;
unsigned long *io_pte, base_pte;
@@ -519,7 +520,7 @@ cell_iommu_setup_window(struct cbe_iommu *iommu, struct
device_node *np,
__set_bit(0, window->table.it_map);
tce_build_cell(&window->table, window->table.it_offset, 1,
- (unsigned long)iommu->pad_page, DMA_TO_DEVICE);
+ (unsigned long)iommu->pad_page, DMA_TO_DEVICE, NULL);
window->table.it_hint = window->table.it_blocksize;
return window;
diff --git a/arch/powerpc/platforms/iseries/iommu.c
b/arch/powerpc/platforms/iseries/iommu.c
index ab5d868..bc818e4 100644
--- a/arch/powerpc/platforms/iseries/iommu.c
+++ b/arch/powerpc/platforms/iseries/iommu.c
@@ -42,7 +42,8 @@
#include
static void tce_build_iSeries(struct iommu_table *tbl, long index, long npages,
- unsigned long uaddr, enum dma_data_direction direction)
+ unsigned long uaddr, enum dma_data_directio
[patch 1/9] powerpc/cell/edac: log a syndrome code in case of correctable error
From: Maxim Shchetynin <[EMAIL PROTECTED]>
If correctable error occurs the syndrome code was logged as 0. This patch
lets EDAC to log a correct syndrome code to make problem investigation
easier.
Signed-off-by: Maxim Shchetynin <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
drivers/edac/cell_edac.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index b54112f..0e024fe 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -33,7 +33,7 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int
chan, u64 ar)
{
struct cell_edac_priv *priv = mci->pvt_info;
struct csrow_info *csrow = &mci->csrows[0];
- unsigned long address, pfn, offset;
+ unsigned long address, pfn, offset, syndrome;
dev_dbg(mci->dev, "ECC CE err on node %d, channel %d, ar = 0x%016lx\n",
priv->node, chan, ar);
@@ -44,10 +44,11 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci,
int chan, u64 ar)
address = (address << 1) | chan;
pfn = address >> PAGE_SHIFT;
offset = address & ~PAGE_MASK;
+ syndrome = (ar & 0x1fe0ul) >> 21;
/* TODO: Decoding of the error addresss */
edac_mc_handle_ce(mci, csrow->first_page + pfn, offset,
- 0, 0, chan, "");
+ syndrome, 0, chan, "");
}
static void cell_edac_count_ue(struct mem_ctl_info *mci, int chan, u64 ar)
--
1.5.4.3
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/9] powerpc/axonram: use only one block device major number
From: Maxim Shchetynin <[EMAIL PROTECTED]>
Axonram module registers one block device for each DDR2 DIMM found
on a system. This means that each DDR2 DIMM becomes its own block device
major number. This patch lets axonram module to register the only one
block device for all DDR2 DIMMs which also spares kernel resources.
Signed-off-by: Maxim Shchetynin <[EMAIL PROTECTED]>
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/axonram.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index 7f59188..9b639ed 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -57,6 +57,8 @@
#define AXON_RAM_SECTOR_SIZE 1 << AXON_RAM_SECTOR_SHIFT
#define AXON_RAM_IRQ_FLAGS IRQF_SHARED | IRQF_TRIGGER_RISING
+static int azfs_major, azfs_minor;
+
struct axon_ram_bank {
struct of_device*device;
struct gendisk *disk;
@@ -227,19 +229,14 @@ axon_ram_probe(struct of_device *device, const struct
of_device_id *device_id)
goto failed;
}
- bank->disk->first_minor = 0;
+ bank->disk->major = azfs_major;
+ bank->disk->first_minor = azfs_minor;
bank->disk->fops = &axon_ram_devops;
bank->disk->private_data = bank;
bank->disk->driverfs_dev = &device->dev;
sprintf(bank->disk->disk_name, "%s%d",
AXON_RAM_DEVICE_NAME, axon_ram_bank_id);
- bank->disk->major = register_blkdev(0, bank->disk->disk_name);
- if (bank->disk->major < 0) {
- dev_err(&device->dev, "Cannot register block device\n");
- rc = -EFAULT;
- goto failed;
- }
bank->disk->queue = blk_alloc_queue(GFP_KERNEL);
if (bank->disk->queue == NULL) {
@@ -276,6 +273,8 @@ axon_ram_probe(struct of_device *device, const struct
of_device_id *device_id)
goto failed;
}
+ azfs_minor += bank->disk->minors;
+
return 0;
failed:
@@ -310,7 +309,6 @@ axon_ram_remove(struct of_device *device)
device_remove_file(&device->dev, &dev_attr_ecc);
free_irq(bank->irq_id, device);
- unregister_blkdev(bank->disk->major, bank->disk->disk_name);
del_gendisk(bank->disk);
iounmap((void __iomem *) bank->io_addr);
kfree(bank);
@@ -341,6 +339,14 @@ static struct of_platform_driver axon_ram_driver = {
static int __init
axon_ram_init(void)
{
+ azfs_major = register_blkdev(azfs_major, AXON_RAM_DEVICE_NAME);
+ if (azfs_major < 0) {
+ printk(KERN_ERR "%s cannot become block device major number\n",
+ AXON_RAM_MODULE_NAME);
+ return -EFAULT;
+ }
+ azfs_minor = 0;
+
return of_register_platform_driver(&axon_ram_driver);
}
@@ -351,6 +357,7 @@ static void __exit
axon_ram_exit(void)
{
of_unregister_platform_driver(&axon_ram_driver);
+ unregister_blkdev(azfs_major, AXON_RAM_DEVICE_NAME);
}
module_init(axon_ram_init);
--
1.5.4.3
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
Sorry for the late comments, I missed this when it went by before. > +DMA_ATTR_STRONG_ORDERING > +-- > + > +DMA_ATTR_STRONG_ORDERING specifies that previous reads and writes are > +performed in the order in which they're received by the IOMMU; thus > +reads and writes may not pass each other. I don't understand what this is trying to say. What is "previous" referring to? What does "received by the IOMMU" mean -- do you mean issued onto the bus by the CPU? When you say "reads and writes may not pass each other," do you mean just that reads may not pass writes and writes may not pass reads, or do you mean that reads also can't pass reads and writes can't pass writes? Since I don't know exactly what this attribute does, I can't be sure, but it seems that making weak ordering the default is dangerous in that it breaks drivers that expect usual memory ordering semantics. Would it be safer/better to make strong ordering the default and then add a "WEAK_ORDERING" attribute that drivers can use as an optimization? - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: correct CMO feature flag enablement
Correct string conversion for rtas value being read for CMO configuration. A value of -1 in the string indicates that CMO is not enabled and we had used simple_strtoul rather than simple_strtol which caused problems. Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> --- This patch applies on top of the CMO patchset sent to the list. --- arch/powerpc/platforms/pseries/setup.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: b/arch/powerpc/platforms/pseries/setup.c === --- a/arch/powerpc/platforms/pseries/setup.c +++ b/arch/powerpc/platforms/pseries/setup.c @@ -366,9 +366,9 @@ void pSeries_cmo_feature_init(void) } if (0 == strcmp(key, "PrPSP")) - PrPSP = simple_strtoul(value, NULL, 10); + PrPSP = simple_strtol(value, NULL, 10); else if (0 == strcmp(key, "SecPSP")) - SecPSP = simple_strtoul(value, NULL, 10); + SecPSP = simple_strtol(value, NULL, 10); value = key = ptr + 1; } ptr++; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Introduce local (non-broadcast) forms of tlb invalidates
Introduced a new set of low level tlb invalidate functions that do not broadcast invalidates on the bus: _tlbil_all - invalidate all _tlbil_pid - invalidate based on process id (or mm context) _tlbil_va - invalidate based on virtual address (ea + pid) On non-SMP configs _tlbil_all should be functionally equivalent to _tlbia and _tlbil_va should be functionally equivalent to _tlbie. The intent of this change is to handle SMP based invalidates via IPIs instead of broadcasts as the mechanism scales better for larger number of cores. On e500 (fsl-booke mmu) based cores move to using MMUCSR for invalidate alls and tlbsx/tlbwe for invalidate virtual address. Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/kernel/misc_32.S | 53 +++ arch/powerpc/kernel/ppc_ksyms.c |1 + include/asm-powerpc/reg_booke.h |7 + include/asm-powerpc/tlbflush.h | 13 ++--- 4 files changed, 69 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index 6321ae3..9245b75 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -274,6 +274,9 @@ _GLOBAL(real_writeb) /* * Flush MMU TLB */ +#ifndef CONFIG_FSL_BOOKE +_GLOBAL(_tlbil_all) +#endif _GLOBAL(_tlbia) #if defined(CONFIG_40x) sync/* Flush to memory before changing mapping */ @@ -344,6 +347,9 @@ _GLOBAL(_tlbia) /* * Flush MMU TLB for a particular address */ +#ifndef CONFIG_FSL_BOOKE +_GLOBAL(_tlbil_va) +#endif _GLOBAL(_tlbie) #if defined(CONFIG_40x) /* We run the search with interrupts disabled because we have to change @@ -436,6 +442,53 @@ _GLOBAL(_tlbie) #endif /* ! CONFIG_40x */ blr +#if defined(CONFIG_FSL_BOOKE) +/* + * Flush MMU TLB, but only on the local processor (no broadcast) + */ +_GLOBAL(_tlbil_all) +#define MMUCSR0_TLBFI (MMUCSR0_TLB0FI | MMUCSR0_TLB1FI | \ +MMUCSR0_TLB2FI | MMUCSR0_TLB3FI) + li r3,(MMUCSR0_TLBFI)@l + mtspr SPRN_MMUCSR0, r3 +1: + mfspr r3,SPRN_MMUCSR0 + andi. r3,r3,[EMAIL PROTECTED] + bne 1b + blr + +/* + * Flush MMU TLB for a particular process id, but only on the local processor + * (no broadcast) + */ +_GLOBAL(_tlbil_pid) + li r3,(MMUCSR0_TLBFI)@l + mtspr SPRN_MMUCSR0, r3 +1: + mfspr r3,SPRN_MMUCSR0 + andi. r1,r2,[EMAIL PROTECTED] + bne 1b + blr + +/* + * Flush MMU TLB for a particular address, but only on the local processor + * (no broadcast) + */ +_GLOBAL(_tlbil_va) + slwir4,r4,16 + mtspr SPRN_MAS6,r4/* assume AS=0 for now */ + tlbsx 0,r3 + mfspr r4,SPRN_MAS1/* check valid */ + andis. r3,r4,[EMAIL PROTECTED] + beq 1f + rlwinm r4,r4,0,1,31 + mtspr SPRN_MAS1,r4 + tlbwe +1: + blr +#endif /* CONFIG_FSL_BOOKE */ + + /* * Flush instruction cache. * This is a no-op on the 601. diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c index 958ecb9..b7e4ff0 100644 --- a/arch/powerpc/kernel/ppc_ksyms.c +++ b/arch/powerpc/kernel/ppc_ksyms.c @@ -114,6 +114,7 @@ EXPORT_SYMBOL(flush_instruction_cache); EXPORT_SYMBOL(flush_tlb_kernel_range); EXPORT_SYMBOL(flush_tlb_page); EXPORT_SYMBOL(_tlbie); +EXPORT_SYMBOL(_tlbil_va); #endif EXPORT_SYMBOL(__flush_icache_range); EXPORT_SYMBOL(flush_dcache_range); diff --git a/include/asm-powerpc/reg_booke.h b/include/asm-powerpc/reg_booke.h index be980f4..6745376 100644 --- a/include/asm-powerpc/reg_booke.h +++ b/include/asm-powerpc/reg_booke.h @@ -109,6 +109,7 @@ #define SPRN_EVPR 0x3D6 /* Exception Vector Prefix Register */ #define SPRN_L1CSR00x3F2 /* L1 Cache Control and Status Register 0 */ #define SPRN_L1CSR10x3F3 /* L1 Cache Control and Status Register 1 */ +#define SPRN_MMUCSR0 0x3F4 /* MMU Control and Status Register 0 */ #define SPRN_PIT 0x3DB /* Programmable Interval Timer */ #define SPRN_BUCSR 0x3F5 /* Branch Unit Control and Status */ #define SPRN_L2CSR00x3F9 /* L2 Data Cache Control and Status Register 0 */ @@ -410,6 +411,12 @@ #define L2CSR0_L2LOA 0x0080 /* L2 Cache Lock Overflow Allocate */ #define L2CSR0_L2LO0x0020 /* L2 Cache Lock Overflow */ +/* Bit definitions for MMUCSR0 */ +#define MMUCSR0_TLB1FI 0x0002 /* TLB1 Flash invalidate */ +#define MMUCSR0_TLB0FI 0x0004 /* TLB0 Flash invalidate */ +#define MMUCSR0_TLB2FI 0x0040 /* TLB2 Flash invalidate */ +#define MMUCSR0_TLB3FI 0x0020 /* TLB3 Flash invalidate */ + /* Bit definitions for SGR. */ #define SGR_NORMAL 0 /* Speculative fetching allowed. */ #define SGR_GUARDED1 /* Speculative fetching disallowed. */ diff --git a/include/asm-powerpc/tlbflush.h b/include/asm-powerpc/tlbflush.h index 5c91081..29da561 100644 --- a/include/asm-powerpc/tlbflush.h
Re: [patch 9/9] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
On Tuesday 15 July 2008, Roland Dreier wrote: > Sorry for the late comments, I missed this when it went by before. > > > +DMA_ATTR_STRONG_ORDERING > > +-- > > + > > +DMA_ATTR_STRONG_ORDERING specifies that previous reads and writes are > > +performed in the order in which they're received by the IOMMU; thus > > +reads and writes may not pass each other. > > I don't understand what this is trying to say. What is "previous" > referring to? What does "received by the IOMMU" mean -- do you mean > issued onto the bus by the CPU? This is all about inbound transfers, i.e. DMAs coming from the I/O bridge into the CPU, both DMA read and DMA write. The relevant paragraph in the specification is "If the SO bits in the I/O page table entry = ‘11’ and the IOIF S-bit is ‘1’, this READ or WRITE cannot be placed on the EIB until all previous READs and WRITEs from this CVCID and IOID have gotten an ACK or NULL type snoop response." Normally, this is only true for accesses going to the same cache line, accesses from one device to different cache lines that are issued in order also send their response in-order (unless you get an I/O exception, which means you're toast), but can arrive at the I/O location out of order. My interpretation is that strong ordering basically turns our whole I/O subsystem into single-issue non-posted accesses (all devices are currently configured to use the same CVCID and IOID), so we really should not do that. > When you say "reads and writes may not > pass each other," do you mean just that reads may not pass writes and > writes may not pass reads, or do you mean that reads also can't pass > reads and writes can't pass writes? > > Since I don't know exactly what this attribute does, I can't be sure, > but it seems that making weak ordering the default is dangerous in that > it breaks drivers that expect usual memory ordering semantics. Would it > be safer/better to make strong ordering the default and then add a > "WEAK_ORDERING" attribute that drivers can use as an optimization? With all our existing hardware, the I/O bridge overrides the setting to select weak ordering. The purpose of this patch is to change the default so that the bridge does not force weak ordering any more and some drivers are free to set strong ordering without impacting performance on the other drivers. Strong ordering is only active when both the bridge and the IOMMU enable it, but for correctly written drivers, this only results in a slowdown. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: correct CMO feature flag enablement
Acked by: Brian King <[EMAIL PROTECTED]> Robert Jennings wrote: > Correct string conversion for rtas value being read for CMO configuration. > A value of -1 in the string indicates that CMO is not enabled and we > had used simple_strtoul rather than simple_strtol which caused problems. > > Signed-off-by: Robert Jennings <[EMAIL PROTECTED]> > > --- > > This patch applies on top of the CMO patchset sent to the list. > > --- > arch/powerpc/platforms/pseries/setup.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: b/arch/powerpc/platforms/pseries/setup.c > === > --- a/arch/powerpc/platforms/pseries/setup.c > +++ b/arch/powerpc/platforms/pseries/setup.c > @@ -366,9 +366,9 @@ void pSeries_cmo_feature_init(void) > } > > if (0 == strcmp(key, "PrPSP")) > - PrPSP = simple_strtoul(value, NULL, 10); > + PrPSP = simple_strtol(value, NULL, 10); > else if (0 == strcmp(key, "SecPSP")) > - SecPSP = simple_strtoul(value, NULL, 10); > + SecPSP = simple_strtol(value, NULL, 10); > value = key = ptr + 1; > } > ptr++; -- Brian King Linux on Power Virtualization IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
SW TLB MMU rework and SMP issues
Ben, I've been giving some thought to the new software managed TLBs and SMP issues. I was wondering if you had any insights on how we should deal with the following issues: * tlb invalidates -- need to ensure we don't have multiple tlbsync's on the bus. I'm thinking for e500/fsl we will move to IPI based invalidate broadcast and do invalidates locally (http://patchwork.ozlabs.org/linuxppc/patch?id=19657 ) * 64-bit PTEs and reader vs writer hazards. How do we ensure that the TLB miss handler samples a consistent view of the pte. pte_updates seem ok since we only update the flag word. However set_pte_at seems like it could be problematic. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Comiler error compiling 2.6.26
Trying to cross-compile arch/powerpc for an freescale 8280: Gcc 4.1.2 Binutils 2.17 BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .ref.text lma 0xc024f000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .rodata lma 0xc0251000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .pci_fixup lma 0xc02dd2f0 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab lma 0xc02dd930 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab_gpl lma 0xc02e2088 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab_strings lma 0xc02e3a20 overlaps previous sections BFD: ./vmlinux.strip.7812: section __param lma 0xc02f08cc overlaps previous sections BFD: ./vmlinux.strip.7812: section __ex_table lma 0xc02f1000 overlaps previous sections BFD: ./vmlinux.strip.7812: section __bug_table lma 0xc02f22b8 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.text lma 0xc02f8000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .exit.text lma 0xc030f908 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.data lma 0xc0310468 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.setup lma 0xc0315b70 overlaps previous sections BFD: ./vmlinux.strip.7812: section .initcall.init lma 0xc0315e28 overlaps previous sections BFD: ./vmlinux.strip.7812: section .con_initcall.init lma 0xc0316050 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ftr_fixup lma 0xc0316058 overlaps previous sections BFD: ./vmlinux.strip.7812: section .machine.desc lma 0xc0317000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data lma 0xc0318000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.init_task lma 0xc033 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.page_aligned lma 0xc0332000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.cacheline_aligned lma 0xc0335000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.read_mostly lma 0xc0335820 overlaps previous sections ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] elf loader support for auxvec base platform string
Some IBM POWER-based platforms have the ability to run in a
mode which mostly appears to the OS as a different processor from the
actual hardware. For example, a Power6 system may appear to be a
Power5+, which makes the AT_PLATFORM value "power5+". This means that
programs are restricted to the ISA supported by Power5+;
Power6-specific instructions are treated as illegal.
However, some applications (virtual machines, optimized libraries) can
benefit from knowledge of the underlying CPU model. A new aux vector
entry, AT_BASE_PLATFORM, will denote the actual hardware. For
example, on a Power6 system in Power5+ compatibility mode, AT_PLATFORM
will be "power5+" and AT_BASE_PLATFORM will be "power6". The idea is
that AT_PLATFORM indicates the instruction set supported, while
AT_BASE_PLATFORM indicates the underlying microarchitecture.
If the architecture has defined ELF_BASE_PLATFORM, copy that value to
the user stack in the same manner as ELF_PLATFORM.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
fs/binfmt_elf.c| 23 +++
include/linux/auxvec.h |5 -
2 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index d48ff5f..834c2c4 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -131,6 +131,10 @@ static int padzero(unsigned long elf_bss)
#define STACK_ALLOC(sp, len) ({ sp -= len ; sp; })
#endif
+#ifndef ELF_BASE_PLATFORM
+#define ELF_BASE_PLATFORM NULL
+#endif
+
static int
create_elf_tables(struct linux_binprm *bprm, struct elfhdr *exec,
unsigned long load_addr, unsigned long interp_load_addr)
@@ -142,7 +146,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
elf_addr_t __user *envp;
elf_addr_t __user *sp;
elf_addr_t __user *u_platform;
+ elf_addr_t __user *u_base_platform;
const char *k_platform = ELF_PLATFORM;
+ const char *k_base_platform = ELF_BASE_PLATFORM;
int items;
elf_addr_t *elf_info;
int ei_index = 0;
@@ -172,6 +178,19 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
return -EFAULT;
}
+ /*
+* If this architecture has a "base" platform capability
+* string, copy it to userspace.
+*/
+ u_base_platform = NULL;
+ if (k_base_platform) {
+ size_t len = strlen(k_base_platform) + 1;
+
+ u_base_platform = (elf_addr_t __user *)STACK_ALLOC(p, len);
+ if (__copy_to_user(u_base_platform, k_base_platform, len))
+ return -EFAULT;
+ }
+
/* Create the ELF interpreter info */
elf_info = (elf_addr_t *)current->mm->saved_auxv;
/* update AT_VECTOR_SIZE_BASE if the number of NEW_AUX_ENT() changes */
@@ -208,6 +227,10 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
}
+ if (k_base_platform) {
+ NEW_AUX_ENT(AT_BASE_PLATFORM,
+ (elf_addr_t)(unsigned long)u_base_platform);
+ }
if (bprm->interp_flags & BINPRM_FLAGS_EXECFD) {
NEW_AUX_ENT(AT_EXECFD, bprm->interp_data);
}
diff --git a/include/linux/auxvec.h b/include/linux/auxvec.h
index ad89545..1adc61d 100644
--- a/include/linux/auxvec.h
+++ b/include/linux/auxvec.h
@@ -26,8 +26,11 @@
#define AT_SECURE 23 /* secure mode boolean */
+#define AT_BASE_PLATFORM 38/* string identifying real platform, may
+* differ from AT_PLATFORM. */
+
#ifdef __KERNEL__
-#define AT_VECTOR_SIZE_BASE (14 + 2) /* NEW_AUX_ENT entries in auxiliary table
*/
+#define AT_VECTOR_SIZE_BASE (14 + 3) /* NEW_AUX_ENT entries in auxiliary table
*/
#endif
#endif /* _LINUX_AUXVEC_H */
--
1.5.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] enable AT_BASE_PLATFORM aux vector for powerpc
Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 11 +++
include/asm-powerpc/cputable.h |2 ++
include/asm-powerpc/elf.h |8
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index f7f3c21..89d8731 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -23,6 +23,9 @@
struct cpu_spec* cur_cpu_spec = NULL;
EXPORT_SYMBOL(cur_cpu_spec);
+/* The platform string corresponding to the real PVR */
+const char *powerpc_base_platform;
+
/* NOTE:
* Unlike ppc32, ppc64 will only call this once for the boot CPU, it's
* the responsibility of the appropriate CPU save/restore functions to
@@ -1632,6 +1635,14 @@ struct cpu_spec * __init identify_cpu(unsigned long
offset, unsigned int pvr)
} else
*t = *s;
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
+
+ /*
+* Set the base platform string once; assumes
+* we're called with real pvr first.
+*/
+ if (powerpc_base_platform == NULL)
+ powerpc_base_platform = t->platform;
+
#if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
/* ppc64 and booke expect identify_cpu to also call
* setup_cpu for that processor. I will consolidate
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 2a3e907..ef8a248 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -127,6 +127,8 @@ extern struct cpu_spec *identify_cpu(unsigned long offset,
unsigned int pvr);
extern void do_feature_fixups(unsigned long value, void *fixup_start,
void *fixup_end);
+extern const char *powerpc_base_platform;
+
#endif /* __ASSEMBLY__ */
/* CPU kernel features */
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index 8966467..80d1f39 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -217,6 +217,14 @@ typedef elf_vrregset_t elf_fpxregset_t;
#define ELF_PLATFORM (cur_cpu_spec->platform)
+/* While ELF_PLATFORM indicates the ISA supported by the platform, it
+ * may not accurately reflect the underlying behavior of the hardware
+ * (as in the case of running in Power5+ compatibility mode on a
+ * Power6 machine). ELF_BASE_PLATFORM allows ld.so to load libraries
+ * that are tuned for the real hardware.
+ */
+#define ELF_BASE_PLATFORM (powerpc_base_platform)
+
#ifdef __powerpc64__
# define ELF_PLAT_INIT(_r, load_addr) do {\
_r->gpr[2] = load_addr; \
--
1.5.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
AT_BASE_PLATFORM (v2)
Background: Some IBM POWER-based systems have the ability to run in a "compatibility" mode which mostly appears to the OS as a different processor from the actual hardware. This feature of the platform is useful for live partition migration and for backwards compatibility with old kernels on new hardware. For example, a Power6 system may appear to be a Power5+, which makes the AT_PLATFORM value "power5+". Problem: Booting a system in a compatibility mode means that ld.so may load libraries that are inappropriately tuned for the real microarchitecture, and apps that use JIT techniques do not have the right information for generating tuned code. While the AT_PLATFORM auxiliary vector entry correctly indicates the ISA supported, it does not accurately reflect the underlying microarchitecture in this case, and there is no good way for userspace to get this information. Proposed solution: Add an AT_BASE_PLATFORM auxiliary vector entry which indicates the microarchitecture. This entry uses the same string format as AT_PLATFORM, and is readily usable by ld.so and other applications. Other solutions that have been suggested but found wanting: - Use a bit in AT_HWCAP to indicate compat mode -- this is not expressive enough. It's not possible to derive the microarchitecture from the combination of AT_PLATFORM's value and a single bit. - Use dsocaps -- this seems to be a ld.so-specific interface and not easily usable by other programs. ld.so/glibc is not the only program that can use knowledge of the microarchitecture. The following two patches: - add the base support to binfmt_elf.c for AT_BASE_PLATFORM - implement AT_BASE_PLATFORM for powerpc Changes since v1: - increment AT_VECTOR_SIZE_BASE - define AT_BASE_PLATFORM in generic code instead of powerpc ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Comiler error compiling 2.6.26
Trying to cross-compile arch/powerpc for an freescale 8280: Gcc 4.1.2 Binutils 2.17 BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps previous sections [etc] Could you try with binutils 2.18? If not, or if that doesn't help, we'll need to see your .config . Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
