* Re: [RFC] [PATCH] task_pt_regs for powerpc systems
From: Benjamin Herrenschmidt @ 2008-07-15 10:37 UTC (permalink / raw)
To: Srinivasa DS; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <487C7C48.8090308@in.ibm.com>
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.
^ permalink raw reply
* Re: powerpc.git merge status
From: Anton Vorontsov @ 2008-07-15 11:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1216101729.7740.84.camel@pasglop>
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 <linux/gpio.h> header
http://patchwork.ozlabs.org/linuxppc/patch?id=18750
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: powerpc.git merge status
From: Josh Boyer @ 2008-07-15 11:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216101729.7740.84.camel@pasglop>
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:
<snip>
> - 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
^ permalink raw reply
* Re: [PATCH] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-15 12:38 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Richard Purdie, linux-kernel
In-Reply-To: <20080715131004.32646dae.sfr@canb.auug.org.au>
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: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: dinesh @ 2008-07-15 12:38 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080715103333.GM25448@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
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 <broonie@opensource.wolfsonmicro.com>
To: dinesh <dinesh.dua@coraltele.com>
Cc: Grant Likely <grant.likely@secretlab.ca>, linuxppc-dev@ozlabs.org,
alsa-devel@alsa-project.org, liam.girdwood@wolfsonmicro.com
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
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[-- Attachment #2: Type: text/html, Size: 2205 bytes --]
^ permalink raw reply
* Re: [alsa-devel] [PATCH v2 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-15 12:46 UTC (permalink / raw)
To: dinesh; +Cc: linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <1216125499.9701.16.camel@dinesh.dua>
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.
^ permalink raw reply
* Re: powerpc.git merge status
From: Kumar Gala @ 2008-07-15 12:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1216101729.7740.84.camel@pasglop>
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
^ permalink raw reply
* Re: powerpc/cell/cpufreq: add spu aware cpufreq governor
From: Arnd Bergmann @ 2008-07-15 13:02 UTC (permalink / raw)
To: linuxppc-dev
Cc: Dave Jones, Stephen Rothwell, cpufreq, Jeremy Kerr, cbe-oss-dev
In-Reply-To: <20080709062958.GA24570@codemonkey.org.uk>
On Wednesday 09 July 2008, Dave Jones wrote:
>=20
> 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
> =A0config CBE_CPUFREQ
> =A0=A0=A0=A0=A0=A0=A0=A0tristate "CBE frequency scaling"
> =A0=A0=A0=A0=A0=A0=A0=A0depends on CBE_RAS && CPU_FREQ
> +=A0=A0=A0=A0=A0=A0=A0select CPU_FREQ_TABLE
> =A0=A0=A0=A0=A0=A0=A0=A0default m
> =A0=A0=A0=A0=A0=A0=A0=A0help
> =A0=A0=A0=A0=A0=A0=A0=A0 =A0This adds the cpufreq driver for Cell BE proc=
essors.
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.
=46ixed in the current version, will post later.
Arnd <><
^ permalink raw reply
* [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-15 12:40 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <20080715123822.GA10893@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
---
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 0000000..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:
+
+led@0 {
+ 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 0000000..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 <raph@8d.com>
+ * Copyright (C) 2008 MontaVista Software, Inc.
+ * Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * 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 <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/device.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
+#include <linux/leds.h>
+#include <linux/workqueue.h>
+
+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",
+ ret);
+ goto err_gpio;
+ }
+
+ ret = gpio_direction_output(led->gpio, 0);
+ if (ret) {
+ dev_err(&ofdev->dev, "gpio could not be an output, "
+ "status is %d\n", ret);
+ goto err_gpio;
+ }
+
+ INIT_WORK(&led->work, gpio_led_work);
+ dev_set_drvdata(&ofdev->dev, led);
+
+ ret = led_classdev_register(&ofdev->dev, &led->cdev);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "could register led cdev, status is %d\n",
+ ret);
+ gpio_free(led->gpio);
+ goto err_reg_cdev;
+ }
+
+ return 0;
+
+err_reg_cdev:
+ cancel_work_sync(&led->work);
+err_gpio:
+ gpio_free(led->gpio);
+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);
+ kfree(led);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM
+static int of_gpio_led_suspend(struct of_device *ofdev, pm_message_t state)
+{
+ struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
+
+ led_classdev_suspend(&led->cdev);
+ return 0;
+}
+
+static int of_gpio_led_resume(struct of_device *ofdev)
+{
+ struct of_gpio_led *led = dev_get_drvdata(&ofdev->dev);
+
+ led_classdev_resume(&led->cdev);
+ return 0;
+}
+#else
+#define of_gpio_led_suspend NULL
+#define of_gpio_led_resume NULL
+#endif /* CONFIG_PM */
+
+static const struct of_device_id of_gpio_leds_match[] = {
+ { .compatible = "gpio-led", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_gpio_leds_match);
+
+static struct of_platform_driver of_gpio_leds_driver = {
+ .driver = {
+ .name = "of_gpio_leds",
+ .owner = THIS_MODULE,
+ },
+ .match_table = of_gpio_leds_match,
+ .probe = of_gpio_leds_probe,
+ .remove = __devexit_p(of_gpio_leds_remove),
+ .suspend = of_gpio_led_suspend,
+ .resume = of_gpio_led_resume,
+};
+
+static int __init of_gpio_leds_init(void)
+{
+ return of_register_platform_driver(&of_gpio_leds_driver);
+}
+module_init(of_gpio_leds_init);
+
+static void __exit of_gpio_leds_exit(void)
+{
+ of_unregister_platform_driver(&of_gpio_leds_driver);
+}
+module_exit(of_gpio_leds_exit);
+
+MODULE_DESCRIPTION("OF GPIO LED driver");
+MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
+MODULE_LICENSE("GPL");
--
1.5.5.4
^ permalink raw reply related
* Re: [alsa-devel] [PATCH v2 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
From: Jon Smirl @ 2008-07-15 13:08 UTC (permalink / raw)
To: Timur Tabi, Grant Likely, linuxppc-dev, alsa-devel, liam.girdwood
In-Reply-To: <20080715101307.GL25448@sirena.org.uk>
On 7/15/08, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Jul 14, 2008 at 07:45:46PM -0400, Jon Smirl wrote:
> > On 7/14/08, Timur Tabi <timur@freescale.com> 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
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Richard Purdie @ 2008-07-15 12:54 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <20080715124013.GA13086@polina.dev.rtsoft.ru>
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
^ permalink raw reply
* Re: [PATCH] mpc7448: add alias list to DTS, clean out old chosen node
From: Kumar Gala @ 2008-07-15 13:13 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1215721295-17555-1-git-send-email-paul.gortmaker@windriver.com>
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 <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc7448hpc2.dts | 24 +++++++++++++++---------
> 1 files changed, 15 insertions(+), 9 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 4/6] Add fsl, magic-packet to, and clean up, the gianfar binding.
From: Kumar Gala @ 2008-07-15 13:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080711230443.GC3854@loki.buserror.net>
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31 ++++++++
> +--------------
> 1 files changed, 12 insertions(+), 19 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 3/6] mpc83xx: Power Management support
From: Kumar Gala @ 2008-07-15 13:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080711230441.GB3854@loki.buserror.net>
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 <scottwood@freescale.com>
> ---
> 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
^ permalink raw reply
* Re: [PATCH 6/6] mpc8313erdb: Add power management to the device tree.
From: Kumar Gala @ 2008-07-15 13:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080711230447.GE3854@loki.buserror.net>
On Jul 11, 2008, at 6:04 PM, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts | 241 ++++++++++++++++++++++
> +----------
> 1 files changed, 171 insertions(+), 70 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/83xx: fix ULPI setup for MPC8315 processors
From: Kumar Gala @ 2008-07-15 13:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080708173632.GA7140@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/83xx/mpc83xx.h | 4 ++++
> arch/powerpc/platforms/83xx/usb.c | 24 +++++++++++++++---------
> 2 files changed, 19 insertions(+), 9 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_soc: gianfar: don't probe disabled devices
From: Kumar Gala @ 2008-07-15 13:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080708173640.GB7140@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH v2] powerpc: add FHCI USB, FSL MCU, FSL UPM and GPIO LEDs bindings
From: Kumar Gala @ 2008-07-15 13:21 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080704165328.GA9962@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
> ---
>
> 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
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: pci config cleanup [rev2]
From: Kumar Gala @ 2008-07-15 13:22 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1214500077-9254-2-git-send-email-jrigby@freescale.com>
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 <long expression>
> 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 <jrigby@freescale.com>
> ---
> 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
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Move mpc83xx_add_bridge to fsl_pci.c [rev2]
From: Kumar Gala @ 2008-07-15 13:22 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <1214500077-9254-3-git-send-email-jrigby@freescale.com>
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 <jrigby@freescale.com>
> ---
> 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
^ permalink raw reply
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Anton Vorontsov @ 2008-07-15 13:24 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <1216126470.5345.55.camel@dax.rpnet.com>
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: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: fsl_uli1575: fix RTC quirk to work on MPC8572DS and MPC8610HPCD
From: Kumar Gala @ 2008-07-15 13:25 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080611230402.GA21351@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/platforms/fsl_uli1575.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Add documentation for CPM GPIO banks
From: Kumar Gala @ 2008-07-15 13:27 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev list, Paul Mackerras, Scott Wood
In-Reply-To: <486F5B18.1030508@scram.de>
On Jul 5, 2008, at 6:29 AM, Jochen Friedrich wrote:
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> 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
^ permalink raw reply
* Re: [PATCH v2] leds: implement OpenFirmare GPIO LED driver
From: Richard Purdie @ 2008-07-15 13:31 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Stephen Rothwell, linux-kernel
In-Reply-To: <20080715132438.GA26648@polina.dev.rtsoft.ru>
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
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/86xx: mpc8610_hpcd: add support for ULI RTC
From: Kumar Gala @ 2008-07-15 13:31 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080611230437.GD21351@polina.dev.rtsoft.ru>
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 <avorontsov@ru.mvista.com>
> ---
> arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14 +++++++
> arch/powerpc/configs/mpc8610_hpcd_defconfig | 51 ++++++++++++++++++
> ++++++--
> 2 files changed, 61 insertions(+), 4 deletions(-)
applied.
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox