Re: [GIT PULL] LED updates for 2.6.29
On Sun, 11 Jan 2009, Richard Purdie wrote: > On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote: > > The LED tree makes more sense for what's left I think. There was a > > openfirmware gpio patch, but that's already gone in. What's left only > > touches led files and the device tree binding docs. > > > > AFAIK, there were no objections to the patches left. > > Ok, these are now queued in the LED tree: > > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/ > > I did merge the last three patches in one and make some changes to deal > with some other outstanding issues. Let me know ASAP if there are any > problems. Since the last patch looks like it's just my three patches folded into one, shouldn't I be listed as the author and the primary signed off by? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [GIT PULL] LED updates for 2.6.29
On Sun, 11 Jan 2009, Richard Purdie wrote: > Ok, these are now queued in the LED tree: > > http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/ > > I did merge the last three patches in one and make some changes to deal > with some other outstanding issues. Let me know ASAP if there are any > problems. As already replied off-list, looks good mostly to me. Just have to keep in mind, that this version relies on drivers initialising their struct led_classdev instances to 0. Maybe it would be better to set the new max_brightness to 0 (or to LED_FULL) explicitly for them, as I was doing in my v2 of the patch. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [GIT PULL] LED updates for 2.6.29
On Sat, 2009-01-10 at 04:31 -0800, Trent Piepho wrote: > On Fri, 9 Jan 2009, Richard Purdie wrote: > > On Fri, 2009-01-09 at 12:37 -0800, Trent Piepho wrote: > > > On Fri, 9 Jan 2009, Richard Purdie wrote: > > > > for the LED tree updates for 2.6.29. This includes some new drivers, > > > > bugfixes and a core improvement resulting in nicer code. > > > > > > > > > > Any chance of these patches getting accepted? They've been going back and > > > forth for months now. > > > > > > [v2,1/4] leds: Support OpenFirmware led bindings > > > http://patchwork.ozlabs.org/patch/13581/ > > > > > > [v2,2/4] leds: Add option to have GPIO LEDs start on > > > http://patchwork.ozlabs.org/patch/13580/ > > > > > > [v2,3/4] leds: Let GPIO LEDs keep their current state > > > http://patchwork.ozlabs.org/patch/13583/ > > > > > > [v2,4/4] leds: Use tristate property in platform data > > > http://patchwork.ozlabs.org/patch/13584/ > > > > I think there was some confusion as to who was going to take them. Are > > the PPC people happy with them? If so I'll merge through the LED tree. > > There are these and a couple of other patches around which have got lost > > in the system. If there is time which I'm hoping there might be, I'll > > try and get a second LED tree merge in. > > The LED tree makes more sense for what's left I think. There was a > openfirmware gpio patch, but that's already gone in. What's left only > touches led files and the device tree binding docs. > > AFAIK, there were no objections to the patches left. Ok, these are now queued in the LED tree: http://git.o-hand.com/cgit.cgi/linux-rpurdie-leds/log/ I did merge the last three patches in one and make some changes to deal with some other outstanding issues. Let me know ASAP if there are any problems. Cheers, Richard -- Richard Purdie Intel Open Source Technology Centre ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
On Fri, Jan 9, 2009 at 5:58 AM, Ilya Yanok wrote:
> This patch rewrites consistent dma allocations support to use vmalloc
> layer to allocate virtual memory space from vmalloc pool and get rid
> of CONFIG_CONSISTENT_{START,SIZE}.
Impressive patch. I'll pull it into my tree and see how it works on
4xx and 5200.
BTW, you can drop all the defconfig updates in this patch. The old
config values will just disappear when 'make *_defconfig' is run.
Putting them in the patch makes it far more likely that it won't apply
at a later date.
g.
>
> Signed-off-by: Ilya Yanok
> ---
> arch/powerpc/Kconfig | 25 --
> arch/powerpc/configs/40x/acadia_defconfig |2 -
> arch/powerpc/configs/40x/ep405_defconfig |2 -
> arch/powerpc/configs/40x/hcu4_defconfig|2 -
> arch/powerpc/configs/40x/kilauea_defconfig |2 -
> arch/powerpc/configs/40x/makalu_defconfig |2 -
> arch/powerpc/configs/40x/virtex_defconfig |2 -
> arch/powerpc/configs/40x/walnut_defconfig |2 -
> arch/powerpc/configs/44x/arches_defconfig |2 -
> arch/powerpc/configs/44x/bamboo_defconfig |2 -
> arch/powerpc/configs/44x/canyonlands_defconfig |2 -
> arch/powerpc/configs/44x/ebony_defconfig |2 -
> arch/powerpc/configs/44x/katmai_defconfig |2 -
> arch/powerpc/configs/44x/rainier_defconfig |2 -
> arch/powerpc/configs/44x/sam440ep_defconfig|2 -
> arch/powerpc/configs/44x/sequoia_defconfig |2 -
> arch/powerpc/configs/44x/taishan_defconfig |2 -
> arch/powerpc/configs/44x/virtex5_defconfig |2 -
> arch/powerpc/configs/44x/warp_defconfig|2 -
> arch/powerpc/configs/adder875_defconfig|2 -
> arch/powerpc/configs/c2k_defconfig |2 -
> arch/powerpc/configs/ep88xc_defconfig |2 -
> arch/powerpc/configs/mgsuvd_defconfig |2 -
> arch/powerpc/configs/mpc866_ads_defconfig |2 -
> arch/powerpc/configs/mpc885_ads_defconfig |2 -
> arch/powerpc/configs/ppc40x_defconfig |2 -
> arch/powerpc/configs/ppc44x_defconfig |2 -
> arch/powerpc/configs/prpmc2800_defconfig |2 -
> arch/powerpc/lib/dma-noncoherent.c | 278 +++
> 29 files changed, 37 insertions(+), 320 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 525c13a..a451a06 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -777,31 +777,6 @@ config TASK_SIZE
>default "0x8000" if PPC_PREP || PPC_8xx
>default "0xc000"
>
> -config CONSISTENT_START_BOOL
> - bool "Set custom consistent memory pool address"
> - depends on ADVANCED_OPTIONS && NOT_COHERENT_CACHE
> - help
> - This option allows you to set the base virtual address
> - of the consistent memory pool. This pool of virtual
> - memory is used to make consistent memory allocations.
> -
> -config CONSISTENT_START
> - hex "Base virtual address of consistent memory pool" if
> CONSISTENT_START_BOOL
> - default "0xfd00" if (NOT_COHERENT_CACHE && 8xx)
> - default "0xff10" if NOT_COHERENT_CACHE
> -
> -config CONSISTENT_SIZE_BOOL
> - bool "Set custom consistent memory pool size"
> - depends on ADVANCED_OPTIONS && NOT_COHERENT_CACHE
> - help
> - This option allows you to set the size of the
> - consistent memory pool. This pool of virtual memory
> - is used to make consistent memory allocations.
> -
> -config CONSISTENT_SIZE
> - hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
> - default "0x0020" if NOT_COHERENT_CACHE
> -
> config PIN_TLB
>bool "Pinned Kernel TLBs (860 ONLY)"
>depends on ADVANCED_OPTIONS && 8xx
> diff --git a/arch/powerpc/configs/40x/acadia_defconfig
> b/arch/powerpc/configs/40x/acadia_defconfig
> index 25572cc..ea5d89c 100644
> --- a/arch/powerpc/configs/40x/acadia_defconfig
> +++ b/arch/powerpc/configs/40x/acadia_defconfig
> @@ -265,8 +265,6 @@ CONFIG_PAGE_OFFSET=0xc000
> CONFIG_KERNEL_START=0xc000
> CONFIG_PHYSICAL_START=0x
> CONFIG_TASK_SIZE=0xc000
> -CONFIG_CONSISTENT_START=0xff10
> -CONFIG_CONSISTENT_SIZE=0x0020
> CONFIG_NET=y
>
> #
> diff --git a/arch/powerpc/configs/40x/ep405_defconfig
> b/arch/powerpc/configs/40x/ep405_defconfig
> index b80ba7a..1f3ebea 100644
> --- a/arch/powerpc/configs/40x/ep405_defconfig
> +++ b/arch/powerpc/configs/40x/ep405_defconfig
> @@ -267,8 +267,6 @@ CONFIG_PAGE_OFFSET=0xc000
> CONFIG_KERNEL_START=0xc000
> CONFIG_PHYSICAL_START=0x
> CONFIG_TASK_SIZE=0xc000
> -CONFIG_CONSISTENT_START=0xff10
> -CONFIG_CONSISTENT_SIZE=0x0020
> CONFIG_NET=y
>
> #
> diff --git a/arch/powerpc/configs/40x/hcu4_defconfig
> b/arch/powerpc/configs/40x/hcu4_defconfig
> index 45dcb82..bfb010d 100644
> --- a/arch/powerpc/configs/40x/hcu
Re: [BUG] 2.6.28-git-4 - powerpc - kernel expection 'c01 at .kernel_thread'
On Friday 02 January 2009, Kamalesh Babulal wrote: > Hi, > > 2.6.28-git4 kernel drops to xmon with kernel expection. Similar kernel > expection was seen next-20081230 and next-20081231 and was reported > earlier at http://lkml.org/lkml/2008/12/31/157 Is this a regression from 2.6.27? Rafael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Thu, 2009-01-08 at 13:51 -0800, Ira Snyder wrote: > The guests (PowerPC computers running Linux) are PCI cards in the host > system (an Intel Pentium3-M system). The guest computers can access all > of the host's memory. The guests provide a 1MB (movable) window into > their memory. > > The PowerPC computers also have a DMA controller, which I've used to get > better throughput from my driver. I have a way to create interrupts to > both the host and guest systems. That looks -very- similar to the PCI driver for CAB and Cell triblades that was, I think, submitted a while ago. Arnd what's the status with that driver ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 0/3] Overview, OProfile SPU event profiling support for IBM Cell processor
On Thu, 2009-01-08 at 16:26 -0800, Carl Love wrote: > I pulled down the git tree, compiled and installed it. I tested it > against the OProfile testsuite, which includes SPU event profiling > tests. Everything passed. The patch I submitted was against a 2.6.26 > tree. You are now on a 2.6.28 tree so perhaps that is why the patch did > not apply cleanly. The patch has been out there for some time. When you submited it on Dec 2, it should have been against whatever was the latest upstream at the time, not 2.6.26. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: rework dma-noncoherent to use generic vmap/vunmap functions
On Fri, 2009-01-09 at 15:58 +0300, Ilya Yanok wrote:
> This patch rewrites consistent dma allocations support to use vmalloc
> layer to allocate virtual memory space from vmalloc pool and get rid
> of CONFIG_CONSISTENT_{START,SIZE}.
Ah good, I like that. I haven't reviewed in details yet but that's the
right approach. I'll have a closer look hopefully tomorrow.
I seems too late for .29 though...
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support to access the flash on SLOF based systems
On Sat, Jan 10, 2009 at 11:52:56AM -0600, Milton Miller wrote:
> On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote:
>> This adds support for a simple character device to access the
>> flash for SLOF based systems like the PowerStation, QS2x and
>> PXCAB. In the SLOF git there is a user space program with
>> which the content of the flash for SLOF based systems can
>> be displayed and modified. This can be used to add a Linux
>> image to the flash and then directly boot the kernel from the
>> flash.
>>
>> Signed-off-by: Adrian Reber
>> ---
>>
>> This is based on the mmio NVRAM driver. I am not sure how useful this
>> is for anybody else but I am posting it anyway, hoping to get some
>> feedback. Also hoping it can be included at one point.
>
>
> Normally such drivers are written and mtd drivers.
>
> If slof were not an of implementation I would just say put the right
> properties on the node in the device tree, but the kernel should adapt
> to real OF. It should be easy to write a driver to hook up a mtd
> platform device if this is a direct mapped flash.
The reason why I did not use mtd is that part of the flash is used by
the firmware image and I do not know if that works with mtd, if only a
part of the flash can be used. SLOF does also a "CRC" check over the
firmware image, so that image must have valid SLOF "CRC". The flash is
a direct mapped flash, but the size of the firmware can vary.
>> +
>> +static void __iomem *slof_flash_start;
>> +static long slof_flash_len;
>> +static DEFINE_SPINLOCK(slof_flash_lock);
>> +
>> +
>> +static ssize_t slof_flash_read(struct file *file, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + unsigned long flags;
>> + char *tmp;
>> + int rc;
>> +
>> + spin_lock_irqsave(&slof_flash_lock, flags);
>> +
>> + memcpy_fromio(tmp, slof_flash_start + *ppos, count);
>> +
>> + spin_unlock_irqrestore(&slof_flash_lock, flags);
>> +
>
> Why do you need a spinlock? Why does it need to be irq safe?
I must confess I copied that code from the nvram driver and I do not
know if it is necessary.
> This decision is also driving the malloc of the temporary buffer, and
> you are intentionally returning a short read to userspace.
>
>> +
>> +const struct file_operations slof_flash_fops = {
>> + .owner = THIS_MODULE,
>> + .llseek = slof_flash_llseek,
>> + .read = slof_flash_read,
>> +};
>> +
>
> You mentioned userspace reflashing the image, but this driver seems to
> be read only access.
This driver is read only. I am writing the new flash image using the
RTAS functionality to update the firmware flash. Using this device I can
use a userspace tool to add a file to the flash. The tool puts the
result on the local filesystem. Then using the normal RTAS flash update
it can be rewritten. That way I can add a kernel (with a ramdisk) to the
flash and then let SLOF boot that kernel. This is especially interesting
for the PXCAB Cell based PCI Express card.
>> +static struct miscdevice slof_flash_dev = {
>> + SLOF_FLASH_MINOR,
>> + "slof_flash",
>> + &slof_flash_fops
>> +};
>> +
>> +
>> +static int __init slof_flash_init(void)
>> +{
>> + struct device_node *slof_flash;
>> + struct device_node *compatible;
>> + struct resource r;
>> + int rc;
>> + unsigned long slof_flash_addr;
>> + /* SLOF is known to run on systems with following values
>> +* for the compatible property: */
>> + char *compstrs[] = {"IBM,Bimini", "IBM,JS21", "IBM,JS20",
>> "IBM,CBEA" };
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(compstrs); i++) {
>> + compatible = of_find_compatible_node(NULL, NULL,
>> compstrs[i]);
>> +
>> + if (compatible)
>> + break;
>> + }
>
>
> Can you identify slof from the information in the /openprom node? I
Yes I can identify SLOF from the model property in the /openprom node. I
did not do it because there is almost no code accessing the /openprom
node and therefore I did not read it.
> don't think all js20 and 21 use slof, although the IBM provided firmware
> may also work with this driver.
There are probably only very few js20/js21 which are using SLOF. I do
not think the original IBM product firmware for those blades mentions
anything about js20/js21 in the compatible node. I do not have access to
such a system but the compatible node usually has some product number,
if I remember it correctly.
I am pretty sure that the original js20/js21 firmware does not have the
flash in the device tree, because RTAS is supposed to be the only valid
way to access the flash.
>> +
>> + /* not a system with a SLOF flash */
>> + if (!compatible)
>> + return -ENODEV;
>> +
>> + of_node_put(compatible);
>> +
>> + slof_flash = of_find_node_by_type(NULL, "flash");
>> + if (!slof_flash) {
>> + printk(KERN_WARNING
Re: [PATCH] powerpc: Add support to access the flash on SLOF based systems
On Sun Jan 11 at 02:31:22 EST in 2009, Adrian Reber wrote:
This adds support for a simple character device to access the
flash for SLOF based systems like the PowerStation, QS2x and
PXCAB. In the SLOF git there is a user space program with
which the content of the flash for SLOF based systems can
be displayed and modified. This can be used to add a Linux
image to the flash and then directly boot the kernel from the
flash.
Signed-off-by: Adrian Reber
---
This is based on the mmio NVRAM driver. I am not sure how useful this
is for anybody else but I am posting it anyway, hoping to get some
feedback. Also hoping it can be included at one point.
Normally such drivers are written and mtd drivers.
If slof were not an of implementation I would just say put the right
properties on the node in the device tree, but the kernel should adapt
to real OF. It should be easy to write a driver to hook up a mtd
platform device if this is a direct mapped flash.
+
+static void __iomem *slof_flash_start;
+static long slof_flash_len;
+static DEFINE_SPINLOCK(slof_flash_lock);
+
+
+static ssize_t slof_flash_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned long flags;
+ char *tmp;
+ int rc;
+
+ spin_lock_irqsave(&slof_flash_lock, flags);
+
+ memcpy_fromio(tmp, slof_flash_start + *ppos, count);
+
+ spin_unlock_irqrestore(&slof_flash_lock, flags);
+
Why do you need a spinlock? Why does it need to be irq safe?
This decision is also driving the malloc of the temporary buffer, and
you are intentionally returning a short read to userspace.
+
+const struct file_operations slof_flash_fops = {
+ .owner = THIS_MODULE,
+ .llseek = slof_flash_llseek,
+ .read = slof_flash_read,
+};
+
You mentioned userspace reflashing the image, but this driver seems to
be read only access.
+static struct miscdevice slof_flash_dev = {
+ SLOF_FLASH_MINOR,
+ "slof_flash",
+ &slof_flash_fops
+};
+
+
+static int __init slof_flash_init(void)
+{
+ struct device_node *slof_flash;
+ struct device_node *compatible;
+ struct resource r;
+ int rc;
+ unsigned long slof_flash_addr;
+ /* SLOF is known to run on systems with following values
+* for the compatible property: */
+ char *compstrs[] = {"IBM,Bimini", "IBM,JS21", "IBM,JS20",
"IBM,CBEA" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(compstrs); i++) {
+ compatible = of_find_compatible_node(NULL, NULL,
compstrs[i]);
+
+ if (compatible)
+ break;
+ }
Can you identify slof from the information in the /openprom node? I
don't think all js20 and 21 use slof, although the IBM provided
firmware may also work with this driver.
+
+ /* not a system with a SLOF flash */
+ if (!compatible)
+ return -ENODEV;
+
+ of_node_put(compatible);
+
+ slof_flash = of_find_node_by_type(NULL, "flash");
+ if (!slof_flash) {
+ printk(KERN_WARNING "SLOF FLASH: "
+ "no flash node found in device-tree\n");
+ return -ENODEV;
+ }
+ rc = of_address_to_resource(slof_flash, 0, &r);
+ if (rc) {
+ printk(KERN_WARNING "SLOF FLASH: "
+ "failed to get address (err %d)\n", rc);
+ goto out;
+ }
+
+ slof_flash_addr = r.start;
+ slof_flash_len = r.end - r.start + 1;
+
+ if ((slof_flash_len <= 0) || (!slof_flash_addr)) {
+ printk(KERN_WARNING "SLOF FLASH: address or length is
0\n");
+ rc = -EIO;
+ goto out;
+ }
Why are these warnings? again, debug is more approprate
+
+ slof_flash_start = ioremap(slof_flash_addr, slof_flash_len);
+ if (!slof_flash_start) {
+ printk(KERN_WARNING "SLOF FLASH: failed to ioremap\n");
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ printk(KERN_INFO "SLOF FLASH: %luk at 0x%lx mapped to %p\n",
+ slof_flash_len >> 10, slof_flash_addr,
slof_flash_start);
This looks to be a debug message at most.
+
+ rc = misc_register(&slof_flash_dev);
And as I said, this should be a mtd driver.
Thanks,
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx: Properly update irq_desc when set_type() is called.
Grant Likely wrote: Not entirely; it affects the details about how irqs are handled. check_irq_resend() for example. I don't think any 5200 platforms currently care; but it could be an issue with cascaded IRQ handlers. I'm not sure if that would be a problem or not. Would it shed some light on why Efika ATA DMA doesn't work? :) -- Matt Sealey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add support to access the flash on SLOF based systems
This adds support for a simple character device to access the
flash for SLOF based systems like the PowerStation, QS2x and
PXCAB. In the SLOF git there is a user space program with
which the content of the flash for SLOF based systems can
be displayed and modified. This can be used to add a Linux
image to the flash and then directly boot the kernel from the
flash.
Signed-off-by: Adrian Reber
---
This is based on the mmio NVRAM driver. I am not sure how useful this
is for anybody else but I am posting it anyway, hoping to get some
feedback. Also hoping it can be included at one point.
arch/powerpc/platforms/Kconfig |8 ++
arch/powerpc/sysdev/Makefile |2 +
arch/powerpc/sysdev/slof_flash.c | 174 ++
include/linux/miscdevice.h |1 +
4 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/slof_flash.c
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 47fe2be..7f436e0 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -301,6 +301,14 @@ config OF_RTC
Uses information from the OF or flattened device tree to instatiate
platform devices for direct mapped RTC chips like the DS1742 or
DS1743.
+config SLOF_FLASH
+ bool "SLOF flash device"
+ depends on PPC_MAPLE || PPC_IBM_CELL_BLADE
+ default y
+ help
+ Provide a read-only device to read out the flash
+ for SLOF based systems.
+
source "arch/powerpc/sysdev/bestcomm/Kconfig"
config MPC8xxx_GPIO
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..298485d 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -50,3 +50,5 @@ obj-$(CONFIG_UCODE_PATCH) += micropatch.o
ifeq ($(CONFIG_SUSPEND),y)
obj-$(CONFIG_6xx) += 6xx-suspend.o
endif
+
+obj-$(CONFIG_SLOF_FLASH) += slof_flash.o
diff --git a/arch/powerpc/sysdev/slof_flash.c b/arch/powerpc/sysdev/slof_flash.c
new file mode 100644
index 000..bc94d48
--- /dev/null
+++ b/arch/powerpc/sysdev/slof_flash.c
@@ -0,0 +1,174 @@
+/*
+ * SLOF flash access
+ *
+ * (C) Copyright MATRIX VISION GmbH 2009
+ *
+ * Authors : Adrian Reber
+ *
+ * Based on mmio NVRAM driver
+ *
+ * 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 void __iomem *slof_flash_start;
+static long slof_flash_len;
+static DEFINE_SPINLOCK(slof_flash_lock);
+
+static loff_t slof_flash_llseek(struct file *file, loff_t offset, int origin)
+{
+ switch (origin) {
+ case 1:
+ offset += file->f_pos;
+ break;
+ case 2:
+ offset += slof_flash_len;
+ break;
+ }
+ if (offset < 0)
+ return -EINVAL;
+ file->f_pos = offset;
+ return file->f_pos;
+}
+
+
+static ssize_t slof_flash_read(struct file *file, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned long flags;
+ char *tmp;
+ int rc;
+
+ if (*ppos >= slof_flash_len)
+ return 0;
+ if (*ppos + count > slof_flash_len)
+ count = slof_flash_len - *ppos;
+
+ count = min(count, PAGE_SIZE);
+ tmp = kzalloc(count, GFP_KERNEL);
+
+ if (!tmp)
+ return -ENOMEM;
+
+ spin_lock_irqsave(&slof_flash_lock, flags);
+
+ memcpy_fromio(tmp, slof_flash_start + *ppos, count);
+
+ spin_unlock_irqrestore(&slof_flash_lock, flags);
+
+ rc = count;
+ if (copy_to_user(buf, tmp, count)) {
+ rc = -EFAULT;
+ goto out;
+ }
+
+ *ppos += count;
+out:
+ kfree(tmp);
+ return rc;
+}
+
+const struct file_operations slof_flash_fops = {
+ .owner = THIS_MODULE,
+ .llseek = slof_flash_llseek,
+ .read = slof_flash_read,
+};
+
+static struct miscdevice slof_flash_dev = {
+ SLOF_FLASH_MINOR,
+ "slof_flash",
+ &slof_flash_fops
+};
+
+
+static int __init slof_flash_init(void)
+{
+ struct device_node *slof_flash;
+ struct device_node *compatible;
+ struct resource r;
+ int rc;
+ unsigned long slof_flash_addr;
+ /* SLOF is known to run on systems with following values
+* for
Re: [GIT PULL] LED updates for 2.6.29
On Fri, 9 Jan 2009, Richard Purdie wrote: > On Fri, 2009-01-09 at 12:37 -0800, Trent Piepho wrote: > > On Fri, 9 Jan 2009, Richard Purdie wrote: > > > for the LED tree updates for 2.6.29. This includes some new drivers, > > > bugfixes and a core improvement resulting in nicer code. > > > > > > > Any chance of these patches getting accepted? They've been going back and > > forth for months now. > > > > [v2,1/4] leds: Support OpenFirmware led bindings > > http://patchwork.ozlabs.org/patch/13581/ > > > > [v2,2/4] leds: Add option to have GPIO LEDs start on > > http://patchwork.ozlabs.org/patch/13580/ > > > > [v2,3/4] leds: Let GPIO LEDs keep their current state > > http://patchwork.ozlabs.org/patch/13583/ > > > > [v2,4/4] leds: Use tristate property in platform data > > http://patchwork.ozlabs.org/patch/13584/ > > I think there was some confusion as to who was going to take them. Are > the PPC people happy with them? If so I'll merge through the LED tree. > There are these and a couple of other patches around which have got lost > in the system. If there is time which I'm hoping there might be, I'll > try and get a second LED tree merge in. The LED tree makes more sense for what's left I think. There was a openfirmware gpio patch, but that's already gone in. What's left only touches led files and the device tree binding docs. AFAIK, there were no objections to the patches left. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
