Re: [PATCH, RFC]
On Fri, Mar 6, 2009 at 9:22 PM, Grant Likely wrote: > On Fri, Mar 6, 2009 at 3:32 PM, Eddie Dawydiuk wrote: >> Hello, >> >> Let's try this one more time. The last patch was using the clocks for a >> custom board based on the Yosemite board and was referencing a non-existent >> ethNadr( I forgot to pull out this code out). > > But the question remains: Why do you need simpleboot support for > Yosemite when you can use a uImage or cuImage with u-boot? On a more general note; this patch also diverges from the original model for simple image. The idea behind simpleimage was that it would contain a fully formed device tree, with no fixups necessary. I want to think carefully before diverging from that. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Fri, Mar 6, 2009 at 3:32 PM, Eddie Dawydiuk wrote:
> Hello,
>
> Let's try this one more time. The last patch was using the clocks for a
> custom board based on the Yosemite board and was referencing a non-existent
> ethNadr( I forgot to pull out this code out).
But the question remains: Why do you need simpleboot support for
Yosemite when you can use a uImage or cuImage with u-boot?
g.
>
> Signed-off-by: Eddie Dawydiuk
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31
> 17:00:00.0 -0700
> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c 2009-03-06
> 15:33:24.0 -0700
> @@ -0,0 +1,23 @@
> +#include "ops.h"
> +#include "stdio.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static void yosemite_fixups(void)
> +{
> + unsigned long sysclk = ;
> +
> + ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
> + ibm4xx_sdram_fixup_memsize();
> +}
> +
> +void platform_specific_init(void)
> +{
> + platform_ops.fixups = yosemite_fixups;
> + platform_ops.exit = ibm44x_dbcr_reset;
> +}
>
>> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
>> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
>> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31
>> 17:00:00.0 -0700
>> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c 2009-03-06
>> 14:55:46.0 -0700
>> @@ -0,0 +1,24 @@
>> +#include "ops.h"
>> +#include "stdio.h"
>> +#include "4xx.h"
>> +#include "44x.h"
>> +
>> +#define TARGET_4xx
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static void yosemite_fixups(void)
>> +{
>> + unsigned long sysclk = 5000;
>> +
>> + ibm440ep_fixup_clocks(sysclk, 11059200, 4);
>> + ibm4xx_sdram_fixup_memsize();
>> + dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
>> + dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
>> +}
>> +
>> +void platform_specific_init(void)
>> +{
>> + platform_ops.fixups = yosemite_fixups;
>> + platform_ops.exit = ibm44x_dbcr_reset;
>> +}
>>
>
>
> --
> Best Regards,
>
> Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
> 16525 East Laser Drive | fax: (480) 837-5300
> Fountain Hills, AZ 85268 | web: www.embeddedARM.com
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx: add Phytec phyCORE-MPC5200B-IO board (pcm032)
On Tue, Mar 3, 2009 at 3:12 AM, Robert Schwebel wrote: > On Sun, Mar 01, 2009 at 09:33:16PM -0700, Grant Likely wrote: >> On Sun, Mar 1, 2009 at 7:19 PM, Jon Smirl wrote: >> > Would it be easier to get Pengutronix to release a new u-boot for >> > the pcm030? I'm using U-Boot 1.2.0-mpc5200b-tiny-2 (Apr 17 2007 - >> > 11:49:20). >> >> Only if it is a chip IO setup problem (like port_config or clock >> setup). Otherwise the kernel should be setting up the PCI controller >> correctly. Regardless, I don't think the kernel should be crashing >> when PCI is in a funny state. > > Ack; I didn't follow the thread in detail, but if possible I'd like to > avoid bootloader updates; it's quite a lot of effort because there are > thousends of devices in the field, not to mention the whole > qualification mechanics at Phytec. On a pcm030 1245-1 u-boot-1.2.0-mpc5200b-tiny-3, boots ok and PCI is initialized correctly. The readme is not clear that tiny-3 should be used on 1245.1 hardware. http://www.pengutronix.de/oselas/bsp/phytec/download/phyCORE-MPC5200B-tiny/Readme This phrase implies the tiny-3 should only be used on 1245.2 hardware. "U-Boot binary to be used with OSELAS.BSP-Phytec-phyCORE-MPC5200B-tiny-6 (board revision 1245.2)" Where is the difference between the 1245.0, 1245.1 and 1245.2 hardware documented? > > Wolfram can check the issue when being back in the office. > > rsc > -- > Pengutronix e.K. | | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: USB Host in 2.6.24-r3 Arch=PPC
Hi, On Fri, 2009-03-06 at 16:51 +0100, A. Nolson wrote: > just a little question. I am using 2.6.24-rc3 (secretlab) and I would > like to use c67x00 driver from Peter Kosgaard for USB-Host in my Xilinx > ML403 board. Is there support to use USB Host in Arch=ppc Apparently I > cannot select CONFIG_USB_ARCH_HAS_HCD=y option. What should I do to get > the USB working? The problem of not being able to select the c67x00 driver, may be solved by simply pretending that ARCH=ppc "has a HCD" ... e.g.: diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 755823c..eea0277 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD default y if PCMCIA && !M32R# sl811_cs default y if ARM# SL-811 default y if SUPERH # r8a66597-hcd + default y if PPC default PCI # many non-PCI SOC chips embed OHCI BTW: For a long time I'm wondering about what is the reason for making it not selectable by default ... Joachim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MC Technology GMBH - Re: mpc83xx SPI driver never calls its probe function
Hello Joakim, I found your question - but it seems you got never an answer? I have the same problem too with AT91RM9200 - etwarm_board - Kernel 2.6.18. Please send me an answer or some informations - what ever had you found out. Steffen Kutsche MC Technology GmbH, Berlin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
Hello,
Let's try this one more time. The last patch was using the clocks for a custom
board based on the Yosemite board and was referencing a non-existent ethNadr( I
forgot to pull out this code out).
Signed-off-by: Eddie Dawydiuk
diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31
17:00:00.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c2009-03-06
15:33:24.0 -0700
@@ -0,0 +1,23 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = ;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+ ibm4xx_sdram_fixup_memsize();
+}
+
+void platform_specific_init(void)
+{
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+}
diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
1969-12-31 17:00:00.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
2009-03-06 14:55:46.0 -0700
@@ -0,0 +1,24 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = 5000;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 4);
+ ibm4xx_sdram_fixup_memsize();
+ dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
+ dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
+}
+
+void platform_specific_init(void)
+{
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+}
--
Best Regards,
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax:(480) 837-5300
Fountain Hills, AZ 85268| web: www.embeddedARM.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
Hello,
Your patch is word-wrapped. It also lacks the Signed-off-by tag, which
is required.
I apologize please see an updated patch below.
The changelog sounds as if there are bugs being fixed here, but really
you're adding support for something entirely new. The yosemite board
comes with U-Boot, which uses uImages. You seem to be adding support
for using simpleboot on the Yosemite board. Is that correct?
Yes, the patch ensures the simpleboot image works on the Yosemite board. I was
under the impression the code was broken as one can build a simpleImage for the
Yosemite board as described in Documentation/powerpc/bootwrapper.txt without any
modification on a vanilla kernel, although the resulting image does not work
without the following patches.
> You can't do this. If you hard code the MAC address of whatever board
> you are using in the kernel, everyone will have to edit it. You need
> to specify this in your board DTS file or via some other configurable
> mechansim.
Oops, sorry I forgot to pull out the debug code...
Signed-off-by: Eddie Dawydiuk
diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile
linux-2.6.28/arch/powerpc/boot/Makefile
--- linux-2.6.28.orig/arch/powerpc/boot/Makefile2008-12-24
16:26:37.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/Makefile 2009-03-05 17:35:53.0
-0700
@@ -70,7 +70,7 @@
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c
\
virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
- cuboot-acadia.c
+ cuboot-acadia.c simpleboot-yosemite.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -224,7 +224,7 @@
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-image-$(CONFIG_YOSEMITE) += cuImage.yosemite
+image-$(CONFIG_YOSEMITE) += cuImage.yosemite simpleImage.yosemite
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_MPC86XADS)
diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper
linux-2.6.28/arch/powerpc/boot/wrapper
--- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24 16:26:37.0
-0700
+++ linux-2.6.28/arch/powerpc/boot/wrapper 2009-03-05 17:36:10.0
-0700
@@ -214,8 +214,12 @@
platformo="$object/simpleboot.o $object/virtex.o"
binary=y
;;
+simpleboot-yosemite)
+platformo="$object/fixed-head.o $object/simpleboot.o
$object/simpleboot-yosemite.o"
+binary=y
+;;
simpleboot-*)
-platformo="$object/simpleboot.o"
+platformo="$object/fixed-head.o $object/simpleboot.o"
binary=y
;;
asp834x-redboot)
diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31
17:00:00.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c2009-03-06
14:55:46.0 -0700
@@ -0,0 +1,24 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = 5000;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 4);
+ ibm4xx_sdram_fixup_memsize();
+ dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
+ dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
+}
+
+void platform_specific_init(void)
+{
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+}
--
Best Regards,
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax:(480) 837-5300
Fountain Hills, AZ 85268| web: www.embeddedARM.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 1/2] powerpc/5200: add general purpose timer API for the MPC5200
On Fri, Mar 6, 2009 at 2:29 PM, Jon Smirl wrote:
> I'm using a GPT pin in input capture mode to implement IR. I attached
> my GPT driver code. I can convert to your API. That's a really cheap
> way to do IR, just IR sensor, resistor and a cap.
The driver I posted can't do input capture mode yet, but it shouldn't
be too difficult to add. Just another api function for setting the
mode I think. I don't have a use for that yet, so I haven't thought
much about it. Feel free to suggest what you think the API should
look like.
> This is my old device tree, what should the new one look like?
>
> ...@670 { /* General Purpose Timer 6 in Input mode */
> compatible = "gpt-ir";
> cell-index = <7>;
> reg = <0x670 0x10>;
> interrupts = <0x1 0x10 0x0>;
> interrupt-parent = <&mpc5200_pic>;
> };
You'd want a node for the IR device which uses the GPT node as its
interrupt controller.
so:
gpt7: g...@670 {
compatible = "fsl,mpc5200b-gpt"
reg = <0x670 0x10>;
interrupt = <1 16 0>;
interrupt-controller;
#interrupt-cells = <1>;
};
Then elsewhere:
ir {
compatible = "digispeaker,ir"; // or whatever best matches your board
interrupt-parent = <&gpt>;
interrupts = <0>; // IIRC, '0' means irq on both edges for
the GPT irq controller
};
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 1/2] powerpc/5200: add general purpose timer API for the MPC5200
I'm using a GPT pin in input capture mode to implement IR. I attached
my GPT driver code. I can convert to your API. That's a really cheap
way to do IR, just IR sensor, resistor and a cap.
I also have an in-kernel IR system but Christoph (lirc maintainer)
won't consider it. He is a microkernel type - he wants everything in
user space. My in-kernel version is tiny, less than 10K. It turns IR
events into keystrokes on a virtual keyboard device.
This is my old device tree, what should the new one look like?
i...@670 { /* General Purpose Timer 6 in Input mode */
compatible = "gpt-ir";
cell-index = <7>;
reg = <0x670 0x10>;
interrupts = <0x1 0x10 0x0>;
interrupt-parent = <&mpc5200_pic>;
};
--
Jon Smirl
jonsm...@gmail.com
jds-lirc-gpt
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 2/2] powerpc/5200: add LocalPlus bus FIFO device driver
From: Grant Likely
This is a driver for the LocalPlus bus FIFO device
Signed-off-by: Grant Likely
---
This also isn't complete, but I wanted to get it out there and reviewed
before I commit to the design. Comments appreciated.
g.
arch/powerpc/include/asm/mpc52xx.h| 11 +
arch/powerpc/platforms/52xx/Kconfig |4
arch/powerpc/platforms/52xx/Makefile |1
arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c | 282 +
4 files changed, 298 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 8273357..7ec34ea 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -282,6 +282,17 @@ extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv
*gpt, int period,
int continuous);
extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+/* mpc52xx_lpbfifo.c */
+extern int mpc52xx_lpbfifo_write(void *src, unsigned int cs,
+size_t offset, size_t size, int flags,
+void (*callback)(void *, size_t, int),
+void *callback_data);
+extern int mpc52xx_lpbfifo_read(void *dest, unsigned int cs,
+ size_t offset, size_t size, int flags,
+ void (*callback)(void *, size_t, int),
+ void *callback_data);
+extern void mpc52xx_lpbfifo_abort(void *callback_data);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/Kconfig
b/arch/powerpc/platforms/52xx/Kconfig
index 0465e5b..f117e23 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -61,3 +61,7 @@ config PPC_MPC5200_GPIO
select GENERIC_GPIO
help
Enable gpiolib support for mpc5200 based boards
+
+config PPC_MPC5200_LPBFIFO
+ tristate "MPC5200 LocalPlus bus FIFO driver"
+ depends on PPC_MPC52xx
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index bfd4f52..2bc8cd0 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -15,3 +15,4 @@ ifeq ($(CONFIG_PPC_LITE5200),y)
endif
obj-$(CONFIG_PPC_MPC5200_GPIO) += mpc52xx_gpio.o
+obj-$(CONFIG_PPC_MPC5200_LPBFIFO) += mpc52xx_lpbfifo.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
new file mode 100644
index 000..b00d763
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -0,0 +1,282 @@
+/*
+ * LocalPlus Bus FIFO driver for the Freescale MPC52xx.
+ *
+ * Copyright (C) 2009 Secret Lab Technologies Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Grant Likely ");
+MODULE_DESCRIPTION("MPC5200 LocalPlus FIFO device driver");
+MODULE_LICENSE("GPL");
+
+#define LPBFIFO_REG_PACKET_SIZE(0x00)
+#define LPBFIFO_REG_START_ADDRESS (0x04)
+#define LPBFIFO_REG_CONTROL(0x08)
+#define LPBFIFO_REG_ENABLE (0x0C)
+#define LPBFIFO_REG_BYTES_DONE_STATUS (0x14)
+#define LPBFIFO_REG_FIFO_DATA (0x40)
+#define LPBFIFO_REG_FIFO_STATUS(0x44)
+#define LPBFIFO_REG_FIFO_CONTROL (0x48)
+#define LPBFIFO_REG_FIFO_ALARM (0x4C)
+
+struct mpc52xx_lpbfifo {
+ struct device *dev;
+ void __iomem *regs;
+ int irq;
+ spinlock_t lock;
+
+ /* Current transfer data */
+ void *data;
+ int cs;
+ size_t offset;
+ size_t size;
+ size_t remaining;
+ void (*callback)(void *, size_t, int);
+ void *callback_data;
+};
+
+/* The MPC5200 has only one fifo, so only need one instance structure */
+static struct mpc52xx_lpbfifo lpbfifo;
+
+/**
+ * mpc52xx_lpbfifo_kick - Trigger the next block of data to be transfered
+ */
+static void mpc52xx_lpbfifo_kick(void)
+{
+ size_t transfer_size = lpbfifo.remaining;
+
+ /* While the FIFO can be setup for transfer sizes as large as 16M-1,
+* the FIFO itself is only 512 bytes deep and it does not generate
+* interrupts for FIFO full events (only transfer complete will
+* raise an IRQ). Therefore when not using Bestcomm to drive the
+* FIFO it needs to either be polled, or transfers need to constrained
+* to the size of the fifo.
+*
+* Here we choose to restrict the size of the transfer
+*/
+ if (transfer_size > 512)
+ transfer_size = 512;
+
+ /* Set and
[RFC 1/2] powerpc/5200: add general purpose timer API for the MPC5200
From: Grant Likely
This patch adds an interface for controlling the timer function of the
MPC5200 GPT devices.
Signed-off-by: Grant Likely
---
This probably isn't complete, but I wanted to get it out there and reviewed
before I commit to the design. Comments appreciated.
g.
arch/powerpc/include/asm/mpc52xx.h|7 ++
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 132 +++--
2 files changed, 129 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc52xx.h
b/arch/powerpc/include/asm/mpc52xx.h
index 81a2393..8273357 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -275,6 +275,13 @@ extern void mpc52xx_map_common_devices(void);
extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
extern void mpc52xx_restart(char *cmd);
+/* mpc52xx_gpt.c */
+struct mpc52xx_gpt_priv;
+extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
+extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
+int continuous);
+extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+
/* mpc52xx_pic.c */
extern void mpc52xx_init_irq(void);
extern unsigned int mpc52xx_get_irq(void);
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index bfbcd41..e9e040f 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -46,9 +46,12 @@
* the output mode. This driver does not change the output mode setting.
*/
+#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -68,16 +71,21 @@ MODULE_LICENSE("GPL");
* @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
*/
struct mpc52xx_gpt_priv {
+ struct list_head list; /* List of all GPT devices */
struct device *dev;
struct mpc52xx_gpt __iomem *regs;
spinlock_t lock;
struct irq_host *irqhost;
+ u32 ipb_freq;
#if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
#endif
};
+LIST_HEAD(mpc52xx_gpt_list);
+DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
+
#define MPC52xx_GPT_MODE_MS_MASK (0x07)
#define MPC52xx_GPT_MODE_MS_IC (0x01)
#define MPC52xx_GPT_MODE_MS_OC (0x02)
@@ -88,6 +96,9 @@ struct mpc52xx_gpt_priv {
#define MPC52xx_GPT_MODE_GPIO_OUT_LOW (0x20)
#define MPC52xx_GPT_MODE_GPIO_OUT_HIGH (0x30)
+#define MPC52xx_GPT_MODE_COUNTER_ENABLE(0x1000)
+#define MPC52xx_GPT_MODE_CONTINUOUS(0x0400)
+#define MPC52xx_GPT_MODE_OPEN_DRAIN(0x0200)
#define MPC52xx_GPT_MODE_IRQ_EN(0x0100)
#define MPC52xx_GPT_MODE_ICT_MASK (0x03)
@@ -190,7 +201,7 @@ static int mpc52xx_gpt_irq_xlate(struct irq_host *h, struct
device_node *ct,
dev_dbg(gpt->dev, "%s: flags=%i\n", __func__, intspec[0]);
- if ((intsize < 1) || (intspec[0] < 1) || (intspec[0] > 3)) {
+ if ((intsize < 1) || (intspec[0] > 3)) {
dev_err(gpt->dev, "bad irq specifier in %s\n", ct->full_name);
return -EINVAL;
}
@@ -211,13 +222,11 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt,
struct device_node *node)
{
int cascade_virq;
unsigned long flags;
-
- /* Only setup cascaded IRQ if device tree claims the GPT is
-* an interrupt controller */
- if (!of_find_property(node, "interrupt-controller", NULL))
- return;
+ u32 mode;
cascade_virq = irq_of_parse_and_map(node, 0);
+ if (!cascade_virq)
+ return;
gpt->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR, 1,
&mpc52xx_gpt_irq_ops, -1);
@@ -227,14 +236,16 @@ mpc52xx_gpt_irq_setup(struct mpc52xx_gpt_priv *gpt,
struct device_node *node)
}
gpt->irqhost->host_data = gpt;
-
set_irq_data(cascade_virq, gpt);
set_irq_chained_handler(cascade_virq, mpc52xx_gpt_irq_cascade);
- /* Set to Input Capture mode */
+ /* If the GPT is currently disabled, then change it to be in Input
+* Capture mode. If the mode is non-zero, then the pin could be
+* already in use for something. */
spin_lock_irqsave(&gpt->lock, flags);
- clrsetbits_be32(&gpt->regs->mode, MPC52xx_GPT_MODE_MS_MASK,
- MPC52xx_GPT_MODE_MS_IC);
+ mode = in_be32(&gpt->regs->mode);
+ if ((mode & MPC52xx_GPT_MODE_MS_MASK) == 0)
+ out_be32(&gpt->regs->mode, mode | MPC52xx_GPT_MODE_MS_IC);
spin_unlock_irqrestore(&gpt->lock, flags);
dev_dbg(gpt->dev, "%s() complete. virq=%i\n", __func__, cascade_virq);
@@ -335,6 +346,102 @@ static void
mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) { }
#endif /* defined(CONFIG_GPIOLIB) */
+/***
+ * Timer API
+ */
+
+/**
+ * mpc52xx_gp
Re: [PATCH] Fix Xilinx SystemACE driver to handle empty CF slot
On Fri, Mar 6, 2009 at 1:46 PM, Jens Axboe wrote: > On Fri, Mar 06 2009, Grant Likely wrote: >> > The SystemACE driver does not handle an empty CF slot gracefully. An >> > empty CF slot ends up hanging the system. This patch adds a check for >> > the CF state and stops trying to process requests if the slot is empty. > > So with patches like this, it's always nice to know what your target is. > Do you want this in .29, or just queued up for .30? It's not always easy > to judge the urgency of such patches :-) The driver completely falls down and hangs the system if the CF slot is empty, so I would like to get it into .29. On the other hand, it has been a long standing issue, so if merging it will raise any eyebrows then I'm okay to wait for .30. > Also, I note that you are using end_request() throughout the driver. We > really want to get away from that, you should be using blk_end_request() > as that will handle full requests and not just segment-by-segment. No > worries for this patch, but you may want to consider that for a future > patch. Okay, will do. Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix linkstation and storcenter compilation breakage
Defining flash partition table in platform code is deprecated, and due to recent changes linkstation and storcenter do not compile any more with their default configurations because of undefined references to physmap_set_partitions(). Instead of fixing them by using the correct kernel configuration macro in preprocessor conditional, remove partition table definitions altogether. Instead add support for partition definition on the command-line and in device tree to the default configurations. Signed-off-by: Guennadi Liakhovetski --- Kumar, could you push this up ASAP, please? This fixes [Bug #12811] undefined reference to `physmap_set_partitions' on powerpc diff --git a/arch/powerpc/configs/linkstation_defconfig b/arch/powerpc/configs/linkstation_defconfig index aa5855a..15900dc 100644 --- a/arch/powerpc/configs/linkstation_defconfig +++ b/arch/powerpc/configs/linkstation_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc2 -# Mon Jan 26 15:35:29 2009 +# Linux kernel version: 2.6.29-rc6 +# Fri Mar 6 00:07:38 2009 # # CONFIG_PPC64 is not set @@ -71,6 +71,15 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 @@ -88,6 +97,7 @@ CONFIG_NAMESPACES=y # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set +# CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y @@ -153,11 +163,6 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set -# CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_FREEZER is not set # @@ -294,7 +299,6 @@ CONFIG_NET=y # # Networking options # -# CONFIG_NET_NS is not set CONFIG_COMPAT_NET_DEV_OPS=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y @@ -508,8 +512,8 @@ CONFIG_MTD_CONCAT=y CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TESTS is not set # CONFIG_MTD_REDBOOT_PARTS is not set -# CONFIG_MTD_CMDLINE_PARTS is not set -# CONFIG_MTD_OF_PARTS is not set +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_OF_PARTS=y # CONFIG_MTD_AR7_PARTS is not set # @@ -587,7 +591,6 @@ CONFIG_MTD_PHYSMAP=y # LPDDR flash memory drivers # # CONFIG_MTD_LPDDR is not set -# CONFIG_MTD_QINFO_PROBE is not set # # UBI - Unsorted block images @@ -617,13 +620,19 @@ CONFIG_BLK_DEV_RAM_SIZE=8192 # CONFIG_BLK_DEV_HD is not set CONFIG_MISC_DEVICES=y # CONFIG_PHANTOM is not set -# CONFIG_EEPROM_93CX6 is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ICS932S401 is not set # CONFIG_ENCLOSURE_SERVICES is not set # CONFIG_HP_ILO is not set # CONFIG_C2PORT is not set + +# +# EEPROM support +# +# CONFIG_EEPROM_AT24 is not set +CONFIG_EEPROM_LEGACY=m +# CONFIG_EEPROM_93CX6 is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set @@ -839,6 +848,7 @@ CONFIG_R8169=y # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_ATL1E is not set +# CONFIG_ATL1C is not set # CONFIG_JME is not set CONFIG_NETDEV_1=y # CONFIG_CHELSIO_T1 is not set @@ -1037,8 +1047,6 @@ CONFIG_I2C_MPC=y # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set -# CONFIG_EEPROM_AT24 is not set -CONFIG_EEPROM_LEGACY=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set diff --git a/arch/powerpc/configs/storcenter_defconfig b/arch/powerpc/configs/storcenter_defconfig index 86512c8..9490346 100644 --- a/arch/powerpc/configs/storcenter_defconfig +++ b/arch/powerpc/configs/storcenter_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.29-rc2 -# Mon Jan 26 15:35:46 2009 +# Linux kernel version: 2.6.29-rc6 +# Fri Mar 6 00:09:08 2009 # # CONFIG_PPC64 is not set @@ -71,6 +71,15 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_GROUP_SCHED=y @@ -144,11 +153,6 @@ CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set -# CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_FREEZER is not set # @@ -377,8 +381,8 @@ CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_TEST
Re: [PATCH] Fix Xilinx SystemACE driver to handle empty CF slot
On Fri, Mar 06 2009, Grant Likely wrote: > Oops, sorry Jens. I forgot to CC: you on this patch. > > g. > > On Sat, Feb 28, 2009 at 1:46 PM, Grant Likely > wrote: > > From: Grant Likely > > > > The SystemACE driver does not handle an empty CF slot gracefully. An > > empty CF slot ends up hanging the system. This patch adds a check for > > the CF state and stops trying to process requests if the slot is empty. So with patches like this, it's always nice to know what your target is. Do you want this in .29, or just queued up for .30? It's not always easy to judge the urgency of such patches :-) Also, I note that you are using end_request() throughout the driver. We really want to get away from that, you should be using blk_end_request() as that will handle full requests and not just segment-by-segment. No worries for this patch, but you may want to consider that for a future patch. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/5200: remove sysfs debug file from GPT driver
Wolfram, you were right. This was a bad idea. I just took me a bit
longer to clue into it.
g.
On Fri, Mar 6, 2009 at 1:30 PM, Grant Likely wrote:
> From: Grant Likely
>
> Remove poorly designed debug sysfs attribute entry from the GPT driver.
>
> Signed-off-by: Grant Likely
> ---
>
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 39
> -
> 1 files changed, 0 insertions(+), 39 deletions(-)
>
>
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> index cb038dc..bfbcd41 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
> @@ -335,44 +335,6 @@ static void
> mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) {
> }
> #endif /* defined(CONFIG_GPIOLIB) */
>
> -/***
> - * SYSFS attributes
> - */
> -#if defined(CONFIG_SYSFS)
> -static ssize_t mpc52xx_gpt_show_regs(struct device *dev,
> - struct device_attribute *attr, char *buf)
> -{
> - struct mpc52xx_gpt_priv *gpt = dev_get_drvdata(dev);
> - int i, len = 0;
> - u32 __iomem *regs = (void __iomem *) gpt->regs;
> -
> - for (i = 0; i < 4; i++)
> - len += sprintf(buf + len, "%.8x ", in_be32(regs + i));
> - len += sprintf(buf + len, "\n");
> -
> - return len;
> -}
> -
> -static struct device_attribute mpc52xx_gpt_attrib[] = {
> - __ATTR(regs, S_IRUGO | S_IWUSR, mpc52xx_gpt_show_regs, NULL),
> -};
> -
> -static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *gpt)
> -{
> - int i, err = 0;
> -
> - for (i = 0; i < ARRAY_SIZE(mpc52xx_gpt_attrib); i++) {
> - err = device_create_file(gpt->dev, &mpc52xx_gpt_attrib[i]);
> - if (err)
> - dev_err(gpt->dev, "error creating attribute %i\n", i);
> - }
> -
> -}
> -
> -#else /* defined(CONFIG_SYSFS) */
> -static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return
> 0; }
> -#endif /* defined(CONFIG_SYSFS) */
> -
> /* -
> * of_platform bus binding code
> */
> @@ -395,7 +357,6 @@ static int __devinit mpc52xx_gpt_probe(struct of_device
> *ofdev,
>
> dev_set_drvdata(&ofdev->dev, gpt);
>
> - mpc52xx_gpt_create_attribs(gpt);
> mpc52xx_gpt_gpio_setup(gpt, ofdev->node);
> mpc52xx_gpt_irq_setup(gpt, ofdev->node);
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/5200: remove sysfs debug file from GPT driver
From: Grant Likely
Remove poorly designed debug sysfs attribute entry from the GPT driver.
Signed-off-by: Grant Likely
---
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 39 -
1 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index cb038dc..bfbcd41 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -335,44 +335,6 @@ static void
mpc52xx_gpt_gpio_setup(struct mpc52xx_gpt_priv *p, struct device_node *np) { }
#endif /* defined(CONFIG_GPIOLIB) */
-/***
- * SYSFS attributes
- */
-#if defined(CONFIG_SYSFS)
-static ssize_t mpc52xx_gpt_show_regs(struct device *dev,
-struct device_attribute *attr, char *buf)
-{
- struct mpc52xx_gpt_priv *gpt = dev_get_drvdata(dev);
- int i, len = 0;
- u32 __iomem *regs = (void __iomem *) gpt->regs;
-
- for (i = 0; i < 4; i++)
- len += sprintf(buf + len, "%.8x ", in_be32(regs + i));
- len += sprintf(buf + len, "\n");
-
- return len;
-}
-
-static struct device_attribute mpc52xx_gpt_attrib[] = {
- __ATTR(regs, S_IRUGO | S_IWUSR, mpc52xx_gpt_show_regs, NULL),
-};
-
-static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *gpt)
-{
- int i, err = 0;
-
- for (i = 0; i < ARRAY_SIZE(mpc52xx_gpt_attrib); i++) {
- err = device_create_file(gpt->dev, &mpc52xx_gpt_attrib[i]);
- if (err)
- dev_err(gpt->dev, "error creating attribute %i\n", i);
- }
-
-}
-
-#else /* defined(CONFIG_SYSFS) */
-static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return 0; }
-#endif /* defined(CONFIG_SYSFS) */
-
/* -
* of_platform bus binding code
*/
@@ -395,7 +357,6 @@ static int __devinit mpc52xx_gpt_probe(struct of_device
*ofdev,
dev_set_drvdata(&ofdev->dev, gpt);
- mpc52xx_gpt_create_attribs(gpt);
mpc52xx_gpt_gpio_setup(gpt, ofdev->node);
mpc52xx_gpt_irq_setup(gpt, ofdev->node);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx: SPI: driver not releasing memory
On Friday 06 March 2009, Grant Likely wrote:
> David,
>
> Are you okay with this patch and okay with it going in via Ben's
> powerpc tree? Ben wants to ensure that changes outside arch/powerpc/
> are properly acked before going into his tree.
Sure, no problem.
> Thanks,
> g.
>
> On Sat, Feb 28, 2009 at 9:09 PM, Grant Likely
> wrote:
> > On Fri, Feb 27, 2009 at 4:54 PM, John Linn wrote:
> >> The driver was not releasing memory when it was removed or
> >> when there was a failure during probe. This fixes it.
> >>
> >> Signed-off-by: John Linn
> >
> > Looks good.
> >
> > Acked-by: Grant Likely
Acked-by: David Brownell
> > I'll pick this up into my -next branch and ask Ben to pull it in the
> > next week or so.
>
> > ---
> > This is an incremental patch to the patch (updated driver
> > for device tree) that is in the next branch.
> > ---
> > drivers/spi/xilinx_spi.c | 9 +++--
> > 1 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> > index fe7e5f3..494d3f7 100644
> > --- a/drivers/spi/xilinx_spi.c
> > +++ b/drivers/spi/xilinx_spi.c
> > @@ -354,7 +354,7 @@ static int __init xilinx_spi_of_probe(struct of_device
> > *ofdev,
> > if (xspi->regs == NULL) {
> > rc = -ENOMEM;
> > dev_warn(&ofdev->dev, "ioremap failure\n");
> > - goto put_master;
> > + goto release_mem;
> > }
> > xspi->irq = r_irq->start;
> >
> > @@ -365,7 +365,7 @@ static int __init xilinx_spi_of_probe(struct of_device
> > *ofdev,
> > prop = of_get_property(ofdev->node, "xlnx,num-ss-bits", &len);
> > if (!prop || len < sizeof(*prop)) {
> > dev_warn(&ofdev->dev, "no 'xlnx,num-ss-bits' property\n");
> > - goto put_master;
> > + goto unmap_io;
> > }
> > master->num_chipselect = *prop;
> >
> > @@ -397,6 +397,8 @@ free_irq:
> > free_irq(xspi->irq, xspi);
> > unmap_io:
> > iounmap(xspi->regs);
> > +release_mem:
> > + release_mem_region(r_mem->start, resource_size(r_mem));
> > put_master:
> > spi_master_put(master);
> > return rc;
> > @@ -406,6 +408,7 @@ static int __devexit xilinx_spi_remove(struct of_device
> > *ofdev)
> > {
> > struct xilinx_spi *xspi;
> > struct spi_master *master;
> > + struct resource r_mem;
> >
> > master = platform_get_drvdata(ofdev);
> > xspi = spi_master_get_devdata(master);
> > @@ -413,6 +416,8 @@ static int __devexit xilinx_spi_remove(struct of_device
> > *ofdev)
> > spi_bitbang_stop(&xspi->bitbang);
> > free_irq(xspi->irq, xspi);
> > iounmap(xspi->regs);
> > + if (!of_address_to_resource(ofdev->node, 0, &r_mem))
> > + release_mem_region(r_mem.start, resource_size(&r_mem));
> > dev_set_drvdata(&ofdev->dev, 0);
> > spi_master_put(xspi->bitbang.master);
> >
> > --
> > 1.5.3.4
> >
> >
> >
> > This email and any attachments are intended for the sole use of the named
> > recipient(s) and contain(s) confidential information that may be
> > proprietary, privileged or copyrighted under applicable law. If you are not
> > the intended recipient, do not read, copy, or forward this email message or
> > any attachments. Delete this email message and any attachments immediately.
> >
> >
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
backtrace_symbols
Hi,
I am producing stacktraces by calling backtrace to get the
stack and backtrace_symbols to print each frame. backtrace_symbols
is returning some extra unprintable characters at the start of each
array entry.
each array entry starts with this unprintable character (repeats
7 times followed by \n).
0X8ff
void *arr[NUM_STACKFRAMES];
int nSize = backtrace(arr, NUM_STACKFRAMES);
char **sym = backtrace_symbols(arr, nSize);
int ii;
for (ii = 0; ii < nSize; ii++) {
printf("%s\n", sym[ii]);
}
free(sym);
Is there a way to get each stack entry without seeing
the unprintable characters ?
Tom
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Fri, Mar 6, 2009 at 11:40 AM, Josh Boyer wrote: > On Fri, Mar 06, 2009 at 10:41:48AM -0700, Eddie Dawydiuk wrote: >> @@ -214,8 +214,12 @@ >> platformo="$object/simpleboot.o $object/virtex.o" >> binary=y >> ;; >> +simpleboot-yosemite) >> + platformo="$object/fixed-head.o $object/simpleboot.o >> $object/simpleboot-yosemite.o" >> + binary=y >> + ;; >> simpleboot-*) >> - platformo="$object/simpleboot.o" >> + platformo="$object/fixed-head.o $object/simpleboot.o" > > Does this break other boards, or should it have always been there? This probably should have always been there. Same for the simpleboot virtex targets, but I'll need to test to be sure. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: clean up ssi.txt, add definition for fsl, ssi-asynchronous
Add the definition of the fsl,ssi-asynchronous property to ssi.txt (documentation of the device tree bindings for the Freescale SSI device). Also tidy up the layout of ssi.txt. Signed-off-by: Timur Tabi --- v2: fixed typo, improved wording. Documentation/powerpc/dts-bindings/fsl/ssi.txt | 68 ++-- 1 files changed, 40 insertions(+), 28 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt index a2d9639..5ff76c9 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt @@ -4,44 +4,56 @@ The SSI is a serial device that communicates with audio codecs. It can be programmed in AC97, I2S, left-justified, or right-justified modes. Required properties: -- compatible : compatible list, containing "fsl,ssi" -- cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on -- reg: offset and length of the register set for the device -- interrupts : where a is the interrupt number and b is a - field that represents an encoding of the sense and - level information for the interrupt. This should be - encoded based on the information in section 2) - depending on the type of interrupt controller you - have. -- interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. -- fsl,mode : the operating mode for the SSI interface - "i2s-slave" - I2S mode, SSI is clock slave - "i2s-master" - I2S mode, SSI is clock master - "lj-slave" - left-justified mode, SSI is clock slave - "lj-master" - l.j. mode, SSI is clock master - "rj-slave" - right-justified mode, SSI is clock slave - "rj-master" - r.j., SSI is clock master - "ac97-slave" - AC97 mode, SSI is clock slave - "ac97-master" - AC97 mode, SSI is clock master -- fsl,playback-dma: phandle to a node for the DMA channel to use for +- compatible: Compatible list, contains "fsl,ssi". +- cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. +- reg: Offset and length of the register set for the device. +- interrupts:where a is the interrupt number and b is a +field that represents an encoding of the sense and +level information for the interrupt. This should be +encoded based on the information in section 2) +depending on the type of interrupt controller you +have. +- interrupt-parent: The phandle for the interrupt controller that +services interrupts for this device. +- fsl,mode: The operating mode for the SSI interface. +"i2s-slave" - I2S mode, SSI is clock slave +"i2s-master" - I2S mode, SSI is clock master +"lj-slave" - left-justified mode, SSI is clock slave +"lj-master" - l.j. mode, SSI is clock master +"rj-slave" - right-justified mode, SSI is clock slave +"rj-master" - r.j., SSI is clock master +"ac97-slave" - AC97 mode, SSI is clock slave +"ac97-master" - AC97 mode, SSI is clock master +- fsl,playback-dma: Phandle to a node for the DMA channel to use for playback of audio. This is typically dictated by SOC design. See the notes below. -- fsl,capture-dma: phandle to a node for the DMA channel to use for +- fsl,capture-dma: Phandle to a node for the DMA channel to use for capture (recording) of audio. This is typically dictated by SOC design. See the notes below. +- fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. +This number is the maximum allowed value for SFCSR[TFWM0]. +- fsl,ssi-asynchronous: +If specified, the SSI is to be programmed in asynchronous +mode. In this mode, pins SRCK, STCK, SRFS, and STFS must +all be connected to valid signals. In synchronous mode, +SRCK and SRFS are ignored. Asynchronous mode allows +playback and capture to use different sample sizes and +sample rates. Some drivers may require that SRCK and STCK +be connected together, and SRFS and STFS be connected +together. This would still allow different sample sizes, +but not different sample rates. Optional properties: -- codec-handle : phandle to a 'codec' node that defines an audio - codec connected to this SSI. This node is typically - a child of a
[patch 2.6.29] powerpc/ps3: ps3_defconfig updates
Update ps3_defconfig. Sets these options: CONFIG_PS3_VRAM=m CONFIG_BLK_DEV_DM=m CONFIG_USB_HIDDEV=y CONFIG_EXT4_FS=y CONFIG_DYNAMIC_FTRACE=y Signed-off-by: Geoff Levand --- Ben, Please send upstream for 2.6.29. -Geoff arch/powerpc/configs/ps3_defconfig | 251 - 1 file changed, 193 insertions(+), 58 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.27-rc3 -# Wed Aug 20 08:16:53 2008 +# Linux kernel version: 2.6.29-rc7 +# Fri Mar 6 10:33:30 2009 # CONFIG_PPC64=y @@ -16,13 +16,14 @@ CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 -CONFIG_PPC_MERGE=y +CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y @@ -46,7 +47,7 @@ CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y -CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y @@ -74,10 +75,19 @@ CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set + +# +# RCU Subsystem +# +CONFIG_CLASSIC_RCU=y +# CONFIG_TREE_RCU is not set +# CONFIG_PREEMPT_RCU is not set +# CONFIG_TREE_RCU_TRACE is not set +# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 -# CONFIG_CGROUPS is not set # CONFIG_GROUP_SCHED is not set +# CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set @@ -86,11 +96,12 @@ CONFIG_NAMESPACES=y # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set +# CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y -# CONFIG_EMBEDDED is not set +CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y @@ -108,28 +119,28 @@ CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y +CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y -# CONFIG_MARKERS is not set +CONFIG_TRACEPOINTS=y +CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y -# CONFIG_HAVE_CLK is not set -CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y -# CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set @@ -137,7 +148,6 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set -CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set @@ -157,7 +167,7 @@ CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" -CONFIG_CLASSIC_RCU=y +# CONFIG_FREEZER is not set # # Platform support @@ -183,18 +193,20 @@ CONFIG_PS3_STORAGE=y CONFIG_PS3_DISK=y CONFIG_PS3_ROM=y CONFIG_PS3_FLASH=y -CONFIG_OPROFILE_PS3=y +CONFIG_PS3_VRAM=m CONFIG_PS3_LPM=m CONFIG_PPC_CELL=y # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PPC_CELLEB is not set +# CONFIG_PPC_CELL_QPACE is not set # # Cell Broadband Engine options # CONFIG_SPU_FS=y CONFIG_SPU_FS_64K_LS=y +# CONFIG_SPU_TRACE is not set CONFIG_SPU_BASE=y # CONFIG_PQ2ADS is not set # CONFIG_IPIC is not set @@ -210,6 +222,7 @@ CONFIG_SPU_BASE=y # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_FSL_ULI1575 is not set +# CONFIG_SIMPLE_GPIO is not set # # Kernel options @@ -229,6 +242,8 @@ CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT is not set CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +# CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y CONFIG_HUGETLB_PAGE_SIZE_VARIABLE=y # CONFIG_IOMMU_VMERGE is not set @@ -251,7 +266,6 @@ CONFIG_SELECT_MEMORY_MODEL=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y -# CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y # CONFIG_SPARSEMEM_VMEMMAP is not set @@ -261,11 +275,14 @@ CONFIG_MEMORY_HOTPLUG_SPARSE=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y -CONFIG_RESOURCES_64BIT=y +CONFIG_PHYS_ADDR_T_64BIT=y CONFIG_ZONE_DMA_FLAG=1
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> On Fri, 6 Mar 2009, Jens Axboe wrote:
> > On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > > driver down, and in the end, the version with a thread turns out to be
> > > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > > code, though.
> > > >
> > > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > > that performance dropped if you just shoved everything under a mutex.
> > > > You could be a little more smart and queue concurrent bio's for
> > > > processing when the current one is complete though, there are several
> > > > approaches there that be a lot faster than going all the way through the
> > > > IO stack and scheduler just to avoid concurrency.
> > >
> > > Yes, using a spinlock and queueing requests on a list if the driver is
> > > busy can be done after 2.6.29...
> >
> > Certainly. Even just replacing your current mutex with a spinlock during
> > the memcpy() would surely be a lot faster. Or even just grabbing the
> > mutex before calling into the write for the duration of the bio. The way
> > you do it is certain context switch death :-)
>
> It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so
> I cannot use a spinlock.
Ah right, I hadn't looked close enough. But putting the mutex_lock()
outside of the bio_for_each_segment() is going to be much faster than
getting/releasing it for each segment.
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH, RFC]
On Fri, Mar 06, 2009 at 10:41:48AM -0700, Eddie Dawydiuk wrote:
> Hello,
>
> The patch below resolves the following issues. The build system for the
> AMCC Yosemite eval board is not including the proper fixups(e.g. RAM
> initialization, timer initialization). In addition the wrapper script
> was not using the fixed-head.S source(e.g. add branch instruction so one
> can jump into the image at offset 0).
>
> Any feedback appreciated..
Your patch is word-wrapped. It also lacks the Signed-off-by tag, which
is required.
The changelog sounds as if there are bugs being fixed here, but really
you're adding support for something entirely new. The yosemite board
comes with U-Boot, which uses uImages. You seem to be adding support
for using simpleboot on the Yosemite board. Is that correct?
See below for further comments.
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile
> linux-2.6.28/arch/powerpc/boot/Makefile
> --- linux-2.6.28.orig/arch/powerpc/boot/Makefile2008-12-24
> 16:26:37.0 -0700
> +++ linux-2.6.28/arch/powerpc/boot/Makefile 2009-03-05
> 17:35:53.0 -0700
> @@ -70,7 +70,7 @@
> cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
> cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c
> simpleboot.c \
> virtex405-head.S virtex.c redboot-83xx.c
> cuboot-sam440ep.c \
> - cuboot-acadia.c
> + cuboot-acadia.c simpleboot-yosemite.c
> src-boot := $(src-wlib) $(src-plat) empty.c
>
> src-boot := $(addprefix $(obj)/, $(src-boot))
> @@ -224,7 +224,7 @@
> image-$(CONFIG_TAISHAN)+= cuImage.taishan
> image-$(CONFIG_KATMAI) += cuImage.katmai
> image-$(CONFIG_WARP) += cuImage.warp
> -image-$(CONFIG_YOSEMITE) += cuImage.yosemite
> +image-$(CONFIG_YOSEMITE) += cuImage.yosemite
> simpleImage.yosemite
>
> # Board ports in arch/powerpc/platform/8xx/Kconfig
> image-$(CONFIG_MPC86XADS) += cuImage.mpc866ads
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper
> linux-2.6.28/arch/powerpc/boot/wrapper
> --- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24
> 16:26:37.0 -0700
> +++ linux-2.6.28/arch/powerpc/boot/wrapper 2009-03-05
> 17:36:10.0 -0700
> @@ -214,8 +214,12 @@
> platformo="$object/simpleboot.o $object/virtex.o"
> binary=y
> ;;
> +simpleboot-yosemite)
> +platformo="$object/fixed-head.o $object/simpleboot.o
> $object/simpleboot-yosemite.o"
> +binary=y
> +;;
> simpleboot-*)
> -platformo="$object/simpleboot.o"
> +platformo="$object/fixed-head.o $object/simpleboot.o"
Does this break other boards, or should it have always been there?
> binary=y
> ;;
> asp834x-redboot)
>
> diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
> linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
> --- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c 1969-12-31
> 17:00:00.0 -0700
> +++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c 2009-03-06
> 10:48:19.0 -0700
> @@ -0,0 +1,27 @@
> +#include "ops.h"
> +#include "stdio.h"
> +#include "4xx.h"
> +#include "44x.h"
> +
> +#define TARGET_4xx
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static unsigned char eth0adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x34 };
> +static unsigned char eth1adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x56 };
You can't do this. If you hard code the MAC address of whatever board
you are using in the kernel, everyone will have to edit it. You need
to specify this in your board DTS file or via some other configurable
mechansim.
> +
> +static void yosemite_fixups(void)
> +{
> + unsigned long sysclk = 5000;
> +
> + ibm440ep_fixup_clocks(sysclk, 11059200, 4);
> + ibm4xx_sdram_fixup_memsize();
> + dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
> + dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
> +}
> +
> +void platform_specific_init(void)
> +{
> + platform_ops.fixups = yosemite_fixups;
> + platform_ops.exit = ibm44x_dbcr_reset;
> +}
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH, RFC]
Hello,
The patch below resolves the following issues. The build system for the
AMCC Yosemite eval board is not including the proper fixups(e.g. RAM
initialization, timer initialization). In addition the wrapper script
was not using the fixed-head.S source(e.g. add branch instruction so one
can jump into the image at offset 0).
Any feedback appreciated..
diff -urN linux-2.6.28.orig/arch/powerpc/boot/Makefile
linux-2.6.28/arch/powerpc/boot/Makefile
--- linux-2.6.28.orig/arch/powerpc/boot/Makefile2008-12-24
16:26:37.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/Makefile 2009-03-05
17:35:53.0 -0700
@@ -70,7 +70,7 @@
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c
simpleboot.c \
virtex405-head.S virtex.c redboot-83xx.c
cuboot-sam440ep.c \
- cuboot-acadia.c
+ cuboot-acadia.c simpleboot-yosemite.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -224,7 +224,7 @@
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
-image-$(CONFIG_YOSEMITE) += cuImage.yosemite
+image-$(CONFIG_YOSEMITE) += cuImage.yosemite
simpleImage.yosemite
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_MPC86XADS) += cuImage.mpc866ads
diff -urN linux-2.6.28.orig/arch/powerpc/boot/wrapper
linux-2.6.28/arch/powerpc/boot/wrapper
--- linux-2.6.28.orig/arch/powerpc/boot/wrapper 2008-12-24
16:26:37.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/wrapper 2009-03-05
17:36:10.0 -0700
@@ -214,8 +214,12 @@
platformo="$object/simpleboot.o $object/virtex.o"
binary=y
;;
+simpleboot-yosemite)
+platformo="$object/fixed-head.o $object/simpleboot.o
$object/simpleboot-yosemite.o"
+binary=y
+;;
simpleboot-*)
-platformo="$object/simpleboot.o"
+platformo="$object/fixed-head.o $object/simpleboot.o"
binary=y
;;
asp834x-redboot)
diff -urN linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
--- linux-2.6.28.orig/arch/powerpc/boot/simpleboot-yosemite.c
1969-12-31 17:00:00.0 -0700
+++ linux-2.6.28/arch/powerpc/boot/simpleboot-yosemite.c
2009-03-06 10:48:19.0 -0700
@@ -0,0 +1,27 @@
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+
+#define TARGET_4xx
+#define TARGET_44x
+#include "ppcboot.h"
+
+static unsigned char eth0adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x34 };
+static unsigned char eth1adr[] = { 0x0, 0xd0, 0x69, 0x41, 0x12, 0x56 };
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = 5000;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 4);
+ ibm4xx_sdram_fixup_memsize();
+ dt_fixup_mac_address_by_alias("ethernet0", eth0adr);
+ dt_fixup_mac_address_by_alias("ethernet1", eth1adr);
+}
+
+void platform_specific_init(void)
+{
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+}
--
Best Regards,
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax:(480) 837-5300
Fountain Hills, AZ 85268| web: www.embeddedARM.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
Thank you for your help! That bit resolved all of the RDMA/WDMA coherency issues on the CSB side...except: We expose a 1MB region of memory from CSB via a BAR (BAR1, if it matters) to the Host. This region is also not behaving correctly with respect to coherency on SOME hosts; again, disabling our cache makes it work correctly on all hosts. We have set PEX_DEVICE_CONTROL in PCI-E Config Space (0x54) to 0x2010 (sorry about the endianness below). We thought that CLEARING the no-snoop bit here would indicate that snooping was required for this region...is this a similar issue? - Ben On Fri, Mar 6, 2009 at 10:12 AM, Ben Menchaca wrote: > Testing now...it looks like it (almost) works, though! Why does setting > no-snoop cause snooping to work? More on the effect on setting that bit in > a few minutes...need more testing. > > ACR is 0x00030300. > > - Ben > > > On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 wrote: > >> Did you enable the descriptor bit 3 to have a try? >> >> -- >> *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] >> *Sent:* Friday, March 06, 2009 2:10 PM >> >> *To:* Liu Dave-R63238 >> *Cc:* linuxppc-dev@ozlabs.org >> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited >> >> I can look at ACR morning...although I can say with a fair amount of >> certainty that I have not changed it from the POR value. >> >> I will try enabling No Snoop for CSB in the descriptor (bit 3, >> yes?)...this seems a bit counterintuitive to me. >> >> What is the hope regarding these two? Some combination I am not seeing? >> >> >> On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 >> wrote: >> >>> what is the value of ACR register? >>> >>> -- >>> *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] >>> *Sent:* Friday, March 06, 2009 1:38 PM >>> *To:* Liu Dave-R63238 >>> *Cc:* linuxppc-dev@ozlabs.org >>> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited >>> >>> 1. BAT2 in linux is set to WIMG=0010, and covers all 64M >>> 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 >>> 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. >>> 4. OWAR0 is set to 0xF005, so NSNP is 0. >>> 5. The DMA descriptor (randomly chosen when I hit a trigger...just >>> ignore the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. >>> >>> >>> Core is 400MHz, and CSB is 133MHz. >>> >>> - Ben >>> >>> On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 >>> wrote: >>> and what settings is DMA description bit 3? > -Original Message- > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org > [mailto:linuxppc-dev-bounces+daveliu =freescale@ozlabs.org] > On Behalf Of Liu Dave-R63238 > Sent: Friday, March 06, 2009 1:22 PM > To: Ben Menchaca; linuxppc-dev@ozlabs.org > Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited > > Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and > PEX_RDMA_CTRL[SNOOP]? > > What is the freq settings? CORE/CSB bus. > > Thanks, Dave > > > > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org > [mailto:linuxppc-dev-bounces+daveliu =freescale@ozlabs.org] > On Behalf Of Ben Menchaca > Sent: Friday, March 06, 2009 12:33 PM > To: linuxppc-dev@ozlabs.org > Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited > > > I am working on a Freescale 8314e design, and the > embedded device is configured as a PCI-e endpoint running a > 2.6.27-5 kernel. For context, we have written a kernel > module which, among other things, uses the RDMA/WDMA engine > in the PCI-e IP block. On the host side, these DMAs are > coherent. However, on the embedded side, things are quite a > bit less rosy; we must manually flush/invalidate cache lines > for WDMA/RDMAs to occur successfully. After speaking with > (several) FAEs at Freescale, we believe there is a > configuration issue that is the cause, but we have yet to > have anyone successfully point to it. > > Disabling the data cache altogether resolves the issue > entirely, but of course, also completely tanks performance. > As a temporary workaround, I would like to simply mark the > pages (obtained currently via dma_alloc_coherent) involved as > cache-inhibited. I have attempted to do this via some > snippets remaining in fec.c (va_to_pte, uncache_pte to set > _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is > almost certainly braindead; va_to_pte is not a part of the > 83xx source, as far as I can tell; 8xx only. > > A quick pointer in the correct direction for marking > pages as cache-inhibited on a 2.6.27-5 kernel would be > appreciated, or
Please pull mpc52xx-next
Hey Ben, Here are some more for -next. The following changes since commit 652e8f8d579d61745094e36b4ff085026a332e73: Benjamin Herrenschmidt (1): Merge commit 'jwb/next' into next are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx next Grant Likely (2): powerpc/5200: Add 'simple-bus' to the of_platform probe list. powerpc/4xx: update ml507 .dts file to release reference design Grzegorz Bernacki (2): powerpc/5200: Add digsy-mtc support to mpc5200_defconfig powerpc/5200: On the digsy-mtc, configure PSC4 and PSC5 as UARTs arch/powerpc/boot/dts/digsy_mtc.dts | 12 ++-- arch/powerpc/boot/dts/virtex440-ml507.dts| 124 +++--- arch/powerpc/configs/mpc5200_defconfig | 71 +-- arch/powerpc/platforms/52xx/mpc52xx_common.c |3 +- 4 files changed, 184 insertions(+), 26 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 83xx: Marking or Allocating Pages as Cache-Inhibited
Testing now...it looks like it (almost) works, though! Why does setting no-snoop cause snooping to work? More on the effect on setting that bit in a few minutes...need more testing. ACR is 0x00030300. - Ben On Fri, Mar 6, 2009 at 12:30 AM, Liu Dave-R63238 wrote: > Did you enable the descriptor bit 3 to have a try? > > -- > *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] > *Sent:* Friday, March 06, 2009 2:10 PM > > *To:* Liu Dave-R63238 > *Cc:* linuxppc-dev@ozlabs.org > *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited > > I can look at ACR morning...although I can say with a fair amount of > certainty that I have not changed it from the POR value. > > I will try enabling No Snoop for CSB in the descriptor (bit 3, yes?)...this > seems a bit counterintuitive to me. > > What is the hope regarding these two? Some combination I am not seeing? > > > On Thu, Mar 5, 2009 at 11:40 PM, Liu Dave-R63238 wrote: > >> what is the value of ACR register? >> >> -- >> *From:* Ben Menchaca [mailto:ben.mench...@gmail.com] >> *Sent:* Friday, March 06, 2009 1:38 PM >> *To:* Liu Dave-R63238 >> *Cc:* linuxppc-dev@ozlabs.org >> *Subject:* Re: 83xx: Marking or Allocating Pages as Cache-Inhibited >> >> 1. BAT2 in linux is set to WIMG=0010, and covers all 64M >> 2. PEX_DEVICE_CONTROL in PCI-E Config Space (0x54): 0x1020 >> 3. PEX_xDMA_CTRL is set to 0x0401 at the initiation of the DMA. >> 4. OWAR0 is set to 0xF005, so NSNP is 0. >> 5. The DMA descriptor (randomly chosen when I hit a trigger...just ignore >> the size...) contains 0002AFF3 at offset 0, so nosnoops are cleared. >> >> Core is 400MHz, and CSB is 133MHz. >> >> - Ben >> >> On Thu, Mar 5, 2009 at 11:27 PM, Liu Dave-R63238 >> wrote: >> >>> and what settings is DMA description bit 3? >>> >>> > -Original Message- >>> > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org >>> > [mailto:linuxppc-dev-bounces+daveliu = >>> freescale@ozlabs.org] >>> > On Behalf Of Liu Dave-R63238 >>> > Sent: Friday, March 06, 2009 1:22 PM >>> > To: Ben Menchaca; linuxppc-dev@ozlabs.org >>> > Subject: RE: 83xx: Marking or Allocating Pages as Cache-Inhibited >>> > >>> > Did you enable the snoop bit at PEX_WDMA_CTRL[SNOOP] and >>> > PEX_RDMA_CTRL[SNOOP]? >>> > >>> > What is the freq settings? CORE/CSB bus. >>> > >>> > Thanks, Dave >>> > >>> > >>> > >>> > From: linuxppc-dev-bounces+daveliu=freescale@ozlabs.org >>> > [mailto:linuxppc-dev-bounces+daveliu = >>> freescale@ozlabs.org] >>> > On Behalf Of Ben Menchaca >>> > Sent: Friday, March 06, 2009 12:33 PM >>> > To: linuxppc-dev@ozlabs.org >>> > Subject: 83xx: Marking or Allocating Pages as Cache-Inhibited >>> > >>> > >>> > I am working on a Freescale 8314e design, and the >>> > embedded device is configured as a PCI-e endpoint running a >>> > 2.6.27-5 kernel. For context, we have written a kernel >>> > module which, among other things, uses the RDMA/WDMA engine >>> > in the PCI-e IP block. On the host side, these DMAs are >>> > coherent. However, on the embedded side, things are quite a >>> > bit less rosy; we must manually flush/invalidate cache lines >>> > for WDMA/RDMAs to occur successfully. After speaking with >>> > (several) FAEs at Freescale, we believe there is a >>> > configuration issue that is the cause, but we have yet to >>> > have anyone successfully point to it. >>> > >>> > Disabling the data cache altogether resolves the issue >>> > entirely, but of course, also completely tanks performance. >>> > As a temporary workaround, I would like to simply mark the >>> > pages (obtained currently via dma_alloc_coherent) involved as >>> > cache-inhibited. I have attempted to do this via some >>> > snippets remaining in fec.c (va_to_pte, uncache_pte to set >>> > _PAGE_NO_CACHE, flush_tlb_page, then unmap_pte), but this is >>> > almost certainly braindead; va_to_pte is not a part of the >>> > 83xx source, as far as I can tell; 8xx only. >>> > >>> > A quick pointer in the correct direction for marking >>> > pages as cache-inhibited on a 2.6.27-5 kernel would be >>> > appreciated, or if my approach to a workaround is flawed, a >>> > pointer to the correct way would be great. >>> > >>> > Ben Menchaca >>> > >>> > >>> > ___ >>> > 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
[RFC] drivers/base: Add bus_register_notifier_alldev() variant
From: Grant Likely
bus_register_notifier_alldev() is a variation on bus_register_notifier()
which also triggers the notifier callback for devices already on the bus
and already bound to drivers.
This function is useful for the case where a driver needs to get a
reference to a struct device other than the one it is bound to and
it is not known if the device will be bound before or after this
function is called. For example, an Ethernet device connected to
a PHY that is probed separately.
Signed-off-by: Grant Likely
CC: linux-ker...@vger.kernel.org
CC: linuxppc-dev@ozlabs.org
CC: Greg Kroah-Hartman
---
I'm using this as part of some changes to phylib to make it easier for
Ethernet drivers to find their PHY device. Before I'm completely committed
to this approach I'd like some feedback on this change to drivers core.
Thanks,
g.
drivers/base/bus.c | 47 +++
include/linux/device.h |2 ++
2 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 83f32b8..6edde85 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -962,6 +962,53 @@ int bus_register_notifier(struct bus_type *bus, struct
notifier_block *nb)
}
EXPORT_SYMBOL_GPL(bus_register_notifier);
+/**
+ * bus_register_notifier_alldev_helper - internal support function
+ * Used by bus_register_notifier_alldev() to create ADD and BOUND events
+ * for devices.
+ */
+static int bus_register_notifier_alldev_helper(struct device *dev, void *data)
+{
+ struct notifier_block *nb = data;
+ nb->notifier_call(nb, BUS_NOTIFY_ADD_DEVICE, dev);
+ if (dev->driver)
+ nb->notifier_call(nb, BUS_NOTIFY_BOUND_DRIVER, dev);
+ return 0;
+}
+
+/**
+ * bus_register_notifier_alldev - Register for bus events; include existing
devs
+ * @bus: pointer to bus_type
+ * @nb: pointer to notifier block to register with the bus
+ *
+ * Similar to bus_register_notifier() except it also generates events for
+ * devices already on the bus when the notifier is registered. When this
+ * function is called the notifier is called once for each device with
+ * the BUS_NOTIFY_ADD_DEVICE event, and once for each device registered to
+ * a driver * with the BUS_NOTIFY_BOUND_DRIVER event.
+ *
+ * There is a small chance that the notifier could be called more than once
+ * for a device. This would happen if a new device was registered on the bus
+ * or bound to a driver between the call to bus_register_notifier() and the
+ * call to bus_for_each_dev(). The only way I can see to protect against
+ * this would be to take the klist_devices spinlock while calling the
+ * notifier; but that would be a Very Bad Thing (tm). Caller needs to be
+ * aware that a notifier called before this function returns might get
+ * called a second time on the same device.
+ */
+int bus_register_notifier_alldev(struct bus_type *b, struct notifier_block *nb)
+{
+ int ret;
+
+ ret = bus_register_notifier(b, nb);
+ if (ret == 0) {
+ bus_for_each_dev(b, NULL, nb,
+bus_register_notifier_alldev_helper);
+ }
+ return ret;
+}
+EXPORT_SYMBOL_GPL(bus_register_notifier_alldev);
+
int bus_unregister_notifier(struct bus_type *bus, struct notifier_block *nb)
{
return blocking_notifier_chain_unregister(&bus->p->bus_notifier, nb);
diff --git a/include/linux/device.h b/include/linux/device.h
index 45e5b19..05c7d5b 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -103,6 +103,8 @@ struct notifier_block;
extern int bus_register_notifier(struct bus_type *bus,
struct notifier_block *nb);
+extern int bus_register_notifier_alldev(struct bus_type *b,
+ struct notifier_block *nb);
extern int bus_unregister_notifier(struct bus_type *bus,
struct notifier_block *nb);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix Xilinx SystemACE driver to handle empty CF slot
Oops, sorry Jens. I forgot to CC: you on this patch.
g.
On Sat, Feb 28, 2009 at 1:46 PM, Grant Likely wrote:
> From: Grant Likely
>
> The SystemACE driver does not handle an empty CF slot gracefully. An
> empty CF slot ends up hanging the system. This patch adds a check for
> the CF state and stops trying to process requests if the slot is empty.
>
> Signed-off-by: Grant Likely
> ---
>
> drivers/block/xsysace.c | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index 381d686..ec5b8ca 100644
> --- a/drivers/block/xsysace.c
> +++ b/drivers/block/xsysace.c
> @@ -489,6 +489,28 @@ static void ace_fsm_dostate(struct ace_device *ace)
> ace->fsm_state, ace->id_req_count);
> #endif
>
> + /* Verify that there is actually a CF in the slot. If not, then
> + * bail out back to the idle state and wake up all the waiters */
> + status = ace_in32(ace, ACE_STATUS);
> + if ((status & ACE_STATUS_CFDETECT) == 0) {
> + ace->fsm_state = ACE_FSM_STATE_IDLE;
> + ace->media_change = 1;
> + set_capacity(ace->gd, 0);
> + dev_info(ace->dev, "No CF in slot\n");
> +
> + /* Drop all pending requests */
> + while ((req = elv_next_request(ace->queue)) != NULL)
> + end_request(req, 0);
> +
> + /* Drop back to IDLE state and notify waiters */
> + ace->fsm_state = ACE_FSM_STATE_IDLE;
> + ace->id_result = -EIO;
> + while (ace->id_req_count) {
> + complete(&ace->id_completion);
> + ace->id_req_count--;
> + }
> + }
> +
> switch (ace->fsm_state) {
> case ACE_FSM_STATE_IDLE:
> /* See if there is anything to do */
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
USB Host in 2.6.24-r3 Arch=PPC
Hi, just a little question. I am using 2.6.24-rc3 (secretlab) and I would like to use c67x00 driver from Peter Kosgaard for USB-Host in my Xilinx ML403 board. Is there support to use USB Host in Arch=ppc Apparently I cannot select CONFIG_USB_ARCH_HAS_HCD=y option. What should I do to get the USB working? Is there any backport for hcd support in arch=ppc? Should I upgrade to powerpc ( painful ) ? Thx, /Albert ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Xilinx: SPI: driver not releasing memory
David,
Are you okay with this patch and okay with it going in via Ben's
powerpc tree? Ben wants to ensure that changes outside arch/powerpc/
are properly acked before going into his tree.
Thanks,
g.
On Sat, Feb 28, 2009 at 9:09 PM, Grant Likely wrote:
> On Fri, Feb 27, 2009 at 4:54 PM, John Linn wrote:
>> The driver was not releasing memory when it was removed or
>> when there was a failure during probe. This fixes it.
>>
>> Signed-off-by: John Linn
>
> Looks good.
>
> Acked-by: Grant Likely
>
> I'll pick this up into my -next branch and ask Ben to pull it in the
> next week or so.
> ---
> This is an incremental patch to the patch (updated driver
> for device tree) that is in the next branch.
> ---
> drivers/spi/xilinx_spi.c | 9 +++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
> index fe7e5f3..494d3f7 100644
> --- a/drivers/spi/xilinx_spi.c
> +++ b/drivers/spi/xilinx_spi.c
> @@ -354,7 +354,7 @@ static int __init xilinx_spi_of_probe(struct of_device
> *ofdev,
> if (xspi->regs == NULL) {
> rc = -ENOMEM;
> dev_warn(&ofdev->dev, "ioremap failure\n");
> - goto put_master;
> + goto release_mem;
> }
> xspi->irq = r_irq->start;
>
> @@ -365,7 +365,7 @@ static int __init xilinx_spi_of_probe(struct of_device
> *ofdev,
> prop = of_get_property(ofdev->node, "xlnx,num-ss-bits", &len);
> if (!prop || len < sizeof(*prop)) {
> dev_warn(&ofdev->dev, "no 'xlnx,num-ss-bits' property\n");
> - goto put_master;
> + goto unmap_io;
> }
> master->num_chipselect = *prop;
>
> @@ -397,6 +397,8 @@ free_irq:
> free_irq(xspi->irq, xspi);
> unmap_io:
> iounmap(xspi->regs);
> +release_mem:
> + release_mem_region(r_mem->start, resource_size(r_mem));
> put_master:
> spi_master_put(master);
> return rc;
> @@ -406,6 +408,7 @@ static int __devexit xilinx_spi_remove(struct of_device
> *ofdev)
> {
> struct xilinx_spi *xspi;
> struct spi_master *master;
> + struct resource r_mem;
>
> master = platform_get_drvdata(ofdev);
> xspi = spi_master_get_devdata(master);
> @@ -413,6 +416,8 @@ static int __devexit xilinx_spi_remove(struct of_device
> *ofdev)
> spi_bitbang_stop(&xspi->bitbang);
> free_irq(xspi->irq, xspi);
> iounmap(xspi->regs);
> + if (!of_address_to_resource(ofdev->node, 0, &r_mem))
> + release_mem_region(r_mem.start, resource_size(&r_mem));
> dev_set_drvdata(&ofdev->dev, 0);
> spi_master_put(xspi->bitbang.master);
>
> --
> 1.5.3.4
>
>
>
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any
> attachments. Delete this email message and any attachments immediately.
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: next branch status
On Mon, Mar 2, 2009 at 9:55 PM, Benjamin Herrenschmidt wrote: > Note: Kumar and Grant, pls be a bit more careful with files outside of > arch/powerpc ... like the 5200 fec driver change, even if it's really > powerpc only stuff and quite clearly so, it's in drivers/net, it > wouldn't have hurt to seek davem ack for it... No big deal, it's only 2 > or 3 files that I might need to give Linus an explanation about tho :-) Okay, will do. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull mpc52xx-merge
Hi Ben, One last one for 2.6.29. Single line cefconfig change only. This fixes defconfigs for Xilinx Virtex platforms that use the full 16550 uart instead of uartlite. The following changes since commit 778ef1e6cbb049c9bcbf405936ee6f2b6e451892: Linus Torvalds (1): Merge git://git.kernel.org/.../gregkh/staging-2.6 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git merge Grant Likely (1): powerpc/4xx: Enable SERIAL_OF support by default for Virtex platforms arch/powerpc/configs/40x/virtex_defconfig |2 +- arch/powerpc/configs/44x/virtex5_defconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Interrupt GPIOs with MPC5200b
On Fri, Mar 6, 2009 at 6:27 AM, Dave Best wrote: > > Hi, I am working on a MPC5200B-tiny with 2.6.23.1 Linux (pcm030). > > I want to use an interrupt GPIO to act as the source for my ISR, but i can't > find the IRQ numbers for the GPIOs so i can't call request_irq() to set my > ISR up. > > For other platforms there seems to be the function gpio_to_irq() where > enumerated GPIOs get an IRQ number for their request_irq calls. Which GPIO line are you using? Is it on the gpio_simple block? gpio_wkup? or one of the GPT lines? There is support in Ben Herrenschmidt's -next tree to use the GPT as an interrupt controller. A similar patch for the mpc52xx_gpio driver would be fairly easy to do. That would allow you to simply specify the GPIO controller as the interrupt controller in the device tree and get your IRQ number with a single call to of_irq_parse_and_map(). It also allows each GPIO line to be assigned an independent IRQ number and be enabled/acked independently from the others and for the enable/ack code to live with the mpc52xx-gpio driver where it belongs. See here for the GPT patch. You can use it as an example to do the same for the gpio driver. http://patchwork.ozlabs.org/patch/21914/ g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Davicom DM9000A on MPC5200B (powerpc) works using a dirty offsetting and byte trick
On Fri, Feb 20, 2009 at 2:51 AM, Henk Stegeman wrote:
> I have the following definition for this network device in my dts:
>
> enet1:ether...@fb00 {
> #size-cells = <1>;
> #address-cells = <1>;
The ethernet node doesn't have any children, so drop the #size-cells
and #address-cells properties.
> device_type = "network";
Drop device_type too. It only makes sense if you're running real OpenFirmware.
> compatible = "davicom,dm9000";
> reg = <0xfb00 0x0002 // DM9000 Address
> register
> 0xfb02 0x0002>; // DM9000 Data register
Just make this reg = <0xfb00 0x0004>;. Specify in the
documentation for the "davicom,dm9000" binding that the address
register is at offset 0 and the data register is at offset 2.
Actually, since this is the local plus bus, you should have this node
as a child of the localplus node. Like this:
localbus {
compatible = "fsl,mpc5200b-lpb", "fsl,mpc5200-lpb", "simple-bus";
#address-cells = <2>; // first cell is CS#, second is offset
#size-cells = <1>;
ranges = <1 0 0xfb00 0x4>; // CS#1, offset 0, mapped to
0xfb00, size=4
enet1: ether...@fb00 {
compatible = "davicom,dm9000";
reg = <0xfb00 0x0002// DM9000 Address register
mac-address = [ 00 00 00 00 00 00 ]; // Filled in by u-boot
interrupts = <1 1 0>; // External interrupt 1
};
};
Doing it this way provides drivers with the ability to get the chip
select number, which is important if you ever decide to use the
Localplus fifo to transfer to/from the device.
> To pass this information to the unmodified DM9000 driver I put
> together a wrapper arch/powerpc/sysdev/dm9000_dev.c (see below) for
> the of_ part (I reused most of the work from
> arch/powerpc/sysdev/tsi108_dev.c):
>
> Because the dm9000 driver uses the data address both as pointer to u16
> and pointer to u8, this works for a little-endian cpu to the
> little-endian dm9000, but not for the big endian MPC5200 to little
> endian dm9000.
> So I add an offset of 1 to this pointer when it is passed to the
> dm9000 driver. This offset of 1 is wrong for the u16 accesses of the
> DM9000 driver, besides that the data needs to be byteswapped for the
> dm9000 driver.
If the driver cannot handle big endian machines, then it is a driver
bug. Don't be afraid to modify the driver to fix this and send a
patch.
> For these two reasons I wrote the functions dm9000_outblk_16bit
> dm9000_intblk_16bit dm9000_dumpblk_16bit which are passed via the
> platform_data.
>
> Apart from comments on my assumptions I have the following questions
> about this situation and my code:
> - Is it the right way to make a separate arch/powerpc/sysdev/*_dev.c
> for reading the device-tree and passing it to a driver, in stead of
> adding it to the driver itself?
Personally, I'd use the of_platform bus infrastructure to probe the
new device. Register an of_platform_driver which will bind against
the device node for the ethernet device. Then you have a choice:
option 1) Your driver's probe method can either create a child
platform device which the original driver can bind against with the
correct pdata, or
option 2) your new driver can call into the original driver at a point
that bypasses the platform bus bindings (because they are handled by
the of_platform bus instead).
I typically choose option 2 because it requires less overhead and less
memory (one fewer probe call and one fewer struct device), but it will
probably require a little bit of refactoring the original driver to
provide call points to bypass the platform bus binding bit of the
driver. I've done this many times, but it does depend on the driver
maintainer being okay with multiple bus bindings (platform and
of_platform) for a driver. This is an ongoing debate.
See drivers/video/xilinxfb.c for an example of a driver with both
platform and of_platform bus bindings. You'll notice at the end of
the file that both a platform driver and an of_platform driver are
getting registered.
> - I think the best solution to handle the separate address and data
> register is the 2 entry register array in the device tree as above,
> this accounts for an odd connection to the DM9000's CMD pin. Agree?
no. If CMD could appear at a different offset, then define an
optional property (maybe cmd-reg-offset = <2>;) to handle the case
where CMD appears at a different offset.
> - The MPC5200's chip-select can be configured to do byte-swapping on
> read and write, however when I configured it as such and I removed my
> offsetting by 1 and byte-swapping code It didn't work.
> - Any suggestions to what could be wrong here? Or does the MPC5200 in
> this case only byte swap u16 reads, but a u8 read is unchanged?
This I don't know. I'd have to play with it to figure it out.
> - What about how the DM9000 driver de
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Fri, 6 Mar 2009, Jens Axboe wrote:
> On Fri, Mar 06 2009, Geert Uytterhoeven wrote:
> > On Fri, 6 Mar 2009, Jens Axboe wrote:
> > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote:
> > > > But then I noticed ps3vram_make_request() may be called concurrently,
> > > > so I had to add a mutex to avoid data corruption. This slows the
> > > > driver down, and in the end, the version with a thread turns out to be
> > > > ca. 1% faster. The version without a thread is about 50 lines less
> > > > code, though.
> > >
> > > That is correct, ->make_request_fn may get reentered. I'm not surprised
> > > that performance dropped if you just shoved everything under a mutex.
> > > You could be a little more smart and queue concurrent bio's for
> > > processing when the current one is complete though, there are several
> > > approaches there that be a lot faster than going all the way through the
> > > IO stack and scheduler just to avoid concurrency.
> >
> > Yes, using a spinlock and queueing requests on a list if the driver is
> > busy can be done after 2.6.29...
>
> Certainly. Even just replacing your current mutex with a spinlock during
> the memcpy() would surely be a lot faster. Or even just grabbing the
> mutex before calling into the write for the duration of the bio. The way
> you do it is certain context switch death :-)
It's not just the memcpy(). ps3vram_{up,down}load() call msleep(), so I cannot
use a spinlock.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: support IRQ from GPIO trough OF and GPIOLIB
I just saw that I missed an earlier very useful a suggestion from Grant Likely:
http://ozlabs.org/pipermail/linuxppc-dev/2009-February/068357.html
By defining the irq in the dts directly I don't need the gpio irq
support anymore.
On Thu, Mar 5, 2009 at 12:20 PM, Henk Stegeman wrote:
> I forgot to include my changes in arch/powerpc/include/asm/gpio.h:
>
> diff --git a/arch/powerpc/include/asm/gpio.h b/arch/powerpc/include/asm/gpio.h
> index ea04632..38762ed 100644
> --- a/arch/powerpc/include/asm/gpio.h
> +++ b/arch/powerpc/include/asm/gpio.h
> @@ -38,12 +38,9 @@ static inline int gpio_cansleep(unsigned int gpio)
> return __gpio_cansleep(gpio);
> }
>
> -/*
> - * Not implemented, yet.
> - */
> static inline int gpio_to_irq(unsigned int gpio)
> {
> - return -ENOSYS;
> + return __gpio_to_irq(gpio);
> }
>
> static inline int irq_to_gpio(unsigned int irq)
>
>
> On Thu, Mar 5, 2009 at 12:15 PM, Henk Stegeman
> wrote:
>> Hello,
>>
>> I have an SPI device that sends an IRQ to the CPU (MPC5200) via GPIO (GPT6):
>>
>> gpt6: ti...@660 { // General Purpose Timer GPT6 in GPIO mode for
>> SMC4000IO sample irq.
>> compatible = "fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
>> cell-index = <6>;
>> reg = <0x660 0x10>;
>> interrupts = <1 15 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> };
>>
>> s...@f00 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
>> reg = <0xf00 0x20>;
>> interrupts = <2 13 0 2 14 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> gpios = <&gpt4 0 0>;
>>
>> io-control...@0 {
>> compatible = "microkey,smc4000io";
>> linux,modalias = "of_smc4000io";
>> spi-max-frequency = <100>;
>> spi-cpha;
>> reg = <0>;
>> // gpios: first is IRQ to cpu
>> gpios = <&gpt6 0 0>;
>> word-delay-us = <0>;
>> };
>> };
>>
>> I've got it working for a mm_gpio, but it's probably not the right
>> approach, I have the following questions to get to the right solution:
>> - Should gpiolib's gpio_to_irq function indeed return the IRQ that was
>> specified at the GPIO by the DTS (interrupts = <1 15 0>)?
>> The effect is that if the IRQ is not specified in the DTS the
>> gpio_to_irq returns NO_IRQ.
>> (On the MPC5200 the IRQ is fixed for GPT6, so instead the cell-index
>> could also be used to return a gpio's IRQ)
>> - If a GPIO controller supports several GPIOs but one IRQ, is it
>> defined what gpio_to_irq should return?
>> - Is it okay for gpio_to_irq to return NO_IRQ? (returned by
>> irq_of_parse_and_map) if irq is not defined?
>>
>>
>> Henk.
>>
>> diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
>> index 6eea601..81927d7 100644
>> --- a/drivers/of/gpio.c
>> +++ b/drivers/of/gpio.c
>> @@ -150,6 +150,17 @@ int of_gpio_simple_xlate(struct of_gpio_chip
>> *of_gc, struct device_node *np,
>> }
>> EXPORT_SYMBOL(of_gpio_simple_xlate);
>>
>> +static int of_mm_gpio_to_irq(struct gpio_chip *gc, unsigned int gpio)
>> +{
>> + struct of_mm_gpio_chip *mm_gc;
>> + struct of_gpio_chip *of_gc;
>> +
>> + of_gc = container_of(gc, struct of_gpio_chip, gc);
>> + mm_gc = container_of(of_gc, struct of_mm_gpio_chip, of_gc);
>> + return mm_gc->irq;
>> +
>> +}
>> +
>> /**
>> * of_mm_gpiochip_add - Add memory mapped GPIO chip (bank)
>> * @np: device node of the GPIO chip
>> @@ -188,6 +199,9 @@ int of_mm_gpiochip_add(struct device_node *np,
>>
>> gc->base = -1;
>>
>> + mm_gc->irq = irq_of_parse_and_map(np, 0);
>> + gc->to_irq = of_mm_gpio_to_irq;
>> +
>> if (!of_gc->xlate)
>> of_gc->xlate = of_gpio_simple_xlate;
>>
>> diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
>> index fc2472c..17fe9ed 100644
>> --- a/include/linux/of_gpio.h
>> +++ b/include/linux/of_gpio.h
>> @@ -54,6 +54,7 @@ struct of_mm_gpio_chip {
>> struct of_gpio_chip of_gc;
>> void (*save_regs)(struct of_mm_gpio_chip *mm_gc);
>> void __iomem *regs;
>> + int irq;
>> };
>>
>> static inline struct of_mm_gpio_chip *to_of_mm_gpio_chip(struct gpio_chip
>> *gc)
>>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Interrupt GPIOs with MPC5200b
Hi, I am working on a MPC5200B-tiny with 2.6.23.1 Linux (pcm030). I want to use an interrupt GPIO to act as the source for my ISR, but i can't find the IRQ numbers for the GPIOs so i can't call request_irq() to set my ISR up. For other platforms there seems to be the function gpio_to_irq() where enumerated GPIOs get an IRQ number for their request_irq calls. Any help or hints appreciated. Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Fri, Mar 06 2009, Geert Uytterhoeven wrote: > On Fri, 6 Mar 2009, Jens Axboe wrote: > > On Thu, Mar 05 2009, Geert Uytterhoeven wrote: > > > But then I noticed ps3vram_make_request() may be called concurrently, > > > so I had to add a mutex to avoid data corruption. This slows the > > > driver down, and in the end, the version with a thread turns out to be > > > ca. 1% faster. The version without a thread is about 50 lines less > > > code, though. > > > > That is correct, ->make_request_fn may get reentered. I'm not surprised > > that performance dropped if you just shoved everything under a mutex. > > You could be a little more smart and queue concurrent bio's for > > processing when the current one is complete though, there are several > > approaches there that be a lot faster than going all the way through the > > IO stack and scheduler just to avoid concurrency. > > Yes, using a spinlock and queueing requests on a list if the driver is > busy can be done after 2.6.29... Certainly. Even just replacing your current mutex with a spinlock during the memcpy() would surely be a lot faster. Or even just grabbing the mutex before calling into the write for the duration of the bio. The way you do it is certain context switch death :-) -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ps3/block: Replace mtd/ps3vram by block/ps3vram (was: Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device)
On Thu, 5 Mar 2009, Jens Axboe wrote: > On Thu, Mar 05 2009, Benjamin Herrenschmidt wrote: > > On Wed, 2009-03-04 at 14:57 +0100, Geert Uytterhoeven wrote: > > > Below is the rewrite of the PS3 Video RAM Storage Driver as a plain block > > > device, as requested by Arnd Bergmann. > > > > > > The MTD-based PS3 Video RAM Storage Driver was integrated into the > > > mainline > > > kernel in 2.6.29-rc1. > > > > > > Ideally, we think it would be best if the existing MTD-based ps3vram > > > driver > > > would be replaced by the new block-based ps3vram driver before 2.6.29 is > > > released. This would relieve the burden of supporting two different swap > > > space > > > schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro > > > maintainer's shoulders, as in that case there would never have been a > > > stable > > > kernel version containing the MTD-based ps3vram driver. > > > > This is very very very late ... we are at rc7, probably one rc before > > final... as much as I like integrating drivers later, I'll ask Linus > > opinion on this one. > > > > Linus ? What do you reckon ? Maybe a better option is just to remove > > ps3nvram from .29 and merge the new one in .30 ? > > It's an isolated driver for a special purpose platform, I would have > zero problems merging it :-) Here's the new version, incorporating all the review comments. Please apply for 2.6.29, thanks! --- >From d7ddc1aaee1ff6dd6a73bd3663b6c390800e0500 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 25 Feb 2009 18:32:10 +0100 Subject: [PATCH] ps3/block: Replace mtd/ps3vram by block/ps3vram Convert the PS3 Video RAM Storage Driver from an MTD driver to a plain block device driver. The ps3vram driver exposes unused video RAM on the PS3 as a block device suitable for storage or swap. Fast data transfer is achieved using a local cache in system RAM and DMA transfers via the GPU. The new driver is ca. 50% faster for reading, and ca. 10% for writing. Signed-off-by: Geert Uytterhoeven Cc: Arnd Bergmann Cc: Jens Axboe Cc: David Woodhouse Cc: Vivien Chappelier Cc: Jim Paris --- The MTD-based PS3 Video RAM Storage Driver was integrated into the mainline kernel in 2.6.29-rc1. Ideally, we think it would be best if the existing MTD-based ps3vram driver would be replaced by the new block-based ps3vram driver before 2.6.29 is released. This would relieve the burden of supporting two different swap space schemes on PS3 (swap on /dev/mtdblock0 vs. /dev/ps3vram) from the distro maintainer's shoulders, as in that case there would never have been a stable kernel version containing the MTD-based ps3vram driver. Changes since previous submission (Wed, 4 Mar 2009 14:57:20 +0100 (CET)): - Use blk_queue_make_request() to get rid of the thread - Add a mutex (cfr. the old driver), as ps3vram_make_request() may be called concurrently TO DO (after 2.6.29): use a spinlock and a list to queue requests while the driver is busy - Remove the old MTD-based ps3vram driver and rename ps3vram-ng to ps3vram - Make PS3_VRAM depend on FB_PS3=y and m for now ps3vram relies on ps3fb being initialized first. The easiest way to do this is by making ps3vram modular, and ps3fb builtin - Remove the dependency on ps3fb_videomemory.size The loop to reduce ddr_size until it succeeds does the right thing anyway, and a few MiB of DDR RAM are reserved by the hypervisor - lv1 return codes can be int - Correct a few debug annotations arch/powerpc/platforms/ps3/Kconfig |7 + drivers/block/Makefile |1 + drivers/block/ps3vram.c| 865 drivers/mtd/devices/Kconfig|7 - drivers/mtd/devices/Makefile |1 - drivers/mtd/devices/ps3vram.c | 768 6 files changed, 873 insertions(+), 776 deletions(-) create mode 100644 drivers/block/ps3vram.c delete mode 100644 drivers/mtd/devices/ps3vram.c diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig index 920cf7a..740ef56 100644 --- a/arch/powerpc/platforms/ps3/Kconfig +++ b/arch/powerpc/platforms/ps3/Kconfig @@ -128,6 +128,13 @@ config PS3_FLASH be disabled on the kernel command line using "ps3flash=off", to not allocate this fixed buffer. +config PS3_VRAM + tristate "PS3 Video RAM Storage Driver" + depends on FB_PS3=y && BLOCK && m + help + This driver allows you to use excess PS3 video RAM as volatile + storage or system swap. + config PS3_LPM tristate "PS3 Logical Performance Monitor support" depends on PPC_PS3 diff --git a/drivers/block/Makefile b/drivers/block/Makefile index 204332b..87e120e 100644 --- a/drivers/block/Makefile +++ b/drivers/block/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_MAC_FLOPPY)+= swim3.o obj-$(CONFIG_BLK_DEV_FD) += floppy.o obj-$(CONFIG_AMIGA_FLOPPY) += amiflop.o obj-$(CONFIG_PS3_DISK)
Re: [PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Fri, 6 Mar 2009, Jens Axboe wrote: > On Thu, Mar 05 2009, Geert Uytterhoeven wrote: > > But then I noticed ps3vram_make_request() may be called concurrently, > > so I had to add a mutex to avoid data corruption. This slows the > > driver down, and in the end, the version with a thread turns out to be > > ca. 1% faster. The version without a thread is about 50 lines less > > code, though. > > That is correct, ->make_request_fn may get reentered. I'm not surprised > that performance dropped if you just shoved everything under a mutex. > You could be a little more smart and queue concurrent bio's for > processing when the current one is complete though, there are several > approaches there that be a lot faster than going all the way through the > IO stack and scheduler just to avoid concurrency. Yes, using a spinlock and queueing requests on a list if the driver is busy can be done after 2.6.29... With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: geert.uytterhoe...@sonycom.com Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/usb: Fix 440EPx USBH_3 & USBH_5 EHCI errata
Patch applies to 440EPx devices in USB EHCI host mode (USB 2.0).
>From the 440EPx errata:
USBH_3: Host hangs after underrun or overrun occurs
USBH_5: EHCI0_INSNREGxx registers are reset by a Soft or Light Host Controller
Reset
Workround for USBH_3 is to enable Break Memory Transfer (BMT) in INSNREG3. But
the controller is reset after this fix is applied, and thus the current
workround is lost. The following short patch ensures INSNREG3 is correctly set
after reset.
Signed-off-by: Jan Reyneke
---
ehci-hcd.c|7 +++
ehci-ppc-of.c | 30 +++---
ehci.h|5 +
3 files changed, 31 insertions(+), 11 deletions(-)
diff -uprN a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
--- a/drivers/usb/host/ehci.h2009-03-04 01:05:22.0 +
+++ b/drivers/usb/host/ehci.h2009-03-06 10:52:53.0 +
@@ -137,6 +137,11 @@ struct ehci_hcd {/* one per controlle
u8sbrn;/* packed release number */
+#if defined(CONFIG_440EPX)
+#define PPC440EPX_EHCI0_INSREG_BMT(0x1 << 0)
+__iomem u32 *insn_regs;/* INSNREGx device memory/io */
+#endif
+
/* irq statistics */
#ifdef EHCI_STATS
struct ehci_statsstats;
diff -uprN a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
--- a/drivers/usb/host/ehci-hcd.c2009-03-04 01:05:22.0 +
+++ b/drivers/usb/host/ehci-hcd.c2009-03-06 10:54:36.0 +
@@ -217,6 +217,13 @@ static int ehci_reset (struct ehci_hcd *
if (ehci_is_TDI(ehci))
tdi_reset (ehci);
+#if defined(CONFIG_440EPX)
+/* USBH_5: INSN values are lost on reset -> redo USBH_3.
+ See also ppc44x_enable_bmt.*/
+if (ehci->insn_regs)
+out_be32(ehci->insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
+#endif
+
return retval;
}
diff -uprN a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
--- a/drivers/usb/host/ehci-ppc-of.c2009-03-04 01:05:22.0 +
+++ b/drivers/usb/host/ehci-ppc-of.c2009-03-06 10:56:08.0 +
@@ -82,23 +82,24 @@ static const struct hc_driver ehci_ppc_o
/*
- * 440EPx Errata USBH_3
- * Fix: Enable Break Memory Transfer (BMT) in INSNREG3
- */
-#define PPC440EPX_EHCI0_INSREG_BMT(0x1 << 0)
+ * 440EPx Errata USBH_3 & USBH_5
+ * Fix: Enable Break Memory Transfer (BMT) in INSNREG3. Also cache
+ * the registers so we can redo the USBH_3 fix on future resets */
static int __devinit
-ppc44x_enable_bmt(struct device_node *dn)
+ppc44x_enable_bmt(struct device_node *dn, struct ehci_hcd* ehci)
{
-__iomem u32 *insreg_virt;
-insreg_virt = of_iomap(dn, 1);
-if (!insreg_virt)
+#if defined(CONFIG_440EPX)
+
+ehci->insn_regs = of_iomap(dn, 1);
+if (!ehci->insn_regs)
return -EINVAL;
-out_be32(insreg_virt + 3, PPC440EPX_EHCI0_INSREG_BMT);
+out_be32(ehci->insn_regs + 3, PPC440EPX_EHCI0_INSREG_BMT);
-iounmap(insreg_virt);
+#endif
return 0;
+
}
@@ -183,7 +184,7 @@ ehci_hcd_ppc_of_probe(struct of_device *
ehci->hcs_params = ehci_readl(ehci, &ehci->caps->hcs_params);
if (of_device_is_compatible(dn, "ibm,usb-ehci-440epx")) {
-rv = ppc44x_enable_bmt(dn);
+rv = ppc44x_enable_bmt(dn, ehci);
ehci_dbg(ehci, "Break Memory Transfer (BMT) is %senabled!\n",
rv ? "NOT ": "");
}
@@ -221,6 +222,13 @@ static int ehci_hcd_ppc_of_remove(struct
usb_remove_hcd(hcd);
+#if defined(CONFIG_440EPX)
+if (ehci->insn_regs) {
+iounmap(ehci->insn_regs);
+ehci->insn_regs = 0;
+}
+#endif
+
iounmap(hcd->regs);
irq_dispose_mapping(hcd->irq);
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
_
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
