Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 4 Mar 2009, Paul Mundt wrote: On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote: So would you accept a patch series that: 1. Adds the missing module aliases to rtc-parisc (which is a bugfix), 2. Moves the platform device creation out of rtc-ppc and into arch-specific code (which is also a bugfix), 3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a cleanup), 4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing [sg]et_rtc_time() users): a. without introducing ARCH_HAS_GENERIC_RTC, b. with a big fat warning in the Kconfig comment not relaxing the dependencies, as it's supposed to go away. 4. Converts the PS3 RTC support into a separate driver, called rtc-ps3 (as a bonus ;-) ? If yes, I'll cook it up. Other RTC platform support can be converted into separate drivers later. Did you miss the rtc-firmware thread? http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gstq=rtc-firmware#1d730cb4aa2f85f0 http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gstq=rtc-firmware#cb9c1530d9c3a433 Thanks Paul, I wasn't aware of that thread! Yes, this is almost the same. The only part I don't agree with is the move of the creation of the platform device from arch-specific code to rtc-firmware.c, as this makes autoloading the driver more difficult. Seems like everybody but the RTC maintainer has an interest in having an RTC class driver on top of [gs]et_rtc_time()... ;-) 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: [Cbe-oss-dev] [PATCH] powerpc/spufs: Fix incorrect buffer offset in regs write
On Wed, 4 Mar 2009, Jeremy Kerr wrote: We need to offset by *pos bytes, not *pos words. Signed-off-by: Jeremy Kerr j...@ozlabs.org --- arch/powerpc/platforms/cell/spufs/file.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c index 83ef889..6b10877 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -578,7 +578,7 @@ spufs_regs_write(struct file *file, const char __user *buffer, if (ret) return ret; - ret = copy_from_user(lscsa-gprs + *pos - size, + ret = copy_from_user((char *)lscsa-gprs + *pos - size, buffer, size) ? -EFAULT : size; spu_release_saved(ctx); Could this be abused by an attacker to write registers or local store he's not allowed to do? Should it be backported to stable? 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] Add unwind information for SPE registers of E500 core
SPE registers use the high part bit0~bit31 of E500 GPR0~GPR31. The unwind information in eh_frame section is used during exception handling and describes register information in the signal frame. But current unwind information doesn't cover SPE registers, which have been saved in the signal frame. This patch adds this unwind information to eh_frame section. SPE registers use register number 1200+N to identify register 'N', but they start from 113 in unwind column, which is computed from gcc source code, macro DWARF_REG_TO_UNWIND_COLUMN: #define FIRST_PSEUDO_REGISTER 114 #define DWARF_REG_TO_UNWIND_COLUMN(r) \ ((r) 1200 ? ((r) - 1200 + FIRST_PSEUDO_REGISTER - 1) : (r)) Signed-off-by: Liming Wang liming.w...@windriver.com --- arch/powerpc/kernel/vdso32/sigtramp.S | 34 + 1 files changed, 34 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/vdso32/sigtramp.S b/arch/powerpc/kernel/vdso32/sigtramp.S index 68d49dd..789a343 100644 --- a/arch/powerpc/kernel/vdso32/sigtramp.S +++ b/arch/powerpc/kernel/vdso32/sigtramp.S @@ -251,6 +251,40 @@ V_FUNCTION_END(__kernel_sigtramp_rt32) vsave_msr1 (31); \ vsave_msr2 (33, 32*16+12); \ vsave (32, 32*16) +#elif defined(CONFIG_SPE) +#define EH_FRAME_VMX \ + rsave (113, VREGS); \ + rsave (114, VREGS + 1*4);\ + rsave (115, VREGS + 2*4);\ + rsave (116, VREGS + 3*4);\ + rsave (117, VREGS + 4*4);\ + rsave (118, VREGS + 5*4);\ + rsave (119, VREGS + 6*4);\ + rsave (120, VREGS + 7*4);\ + rsave (121, VREGS + 8*4);\ + rsave (122, VREGS + 9*4);\ + rsave (123, VREGS + 10*4); \ + rsave (124, VREGS + 11*4); \ + rsave (125, VREGS + 12*4); \ + rsave (126, VREGS + 13*4); \ + rsave (127, VREGS + 14*4); \ + rsave (128, VREGS + 15*4); \ + rsave (129, VREGS + 16*4); \ + rsave (130, VREGS + 17*4); \ + rsave (131, VREGS + 18*4); \ + rsave (132, VREGS + 19*4); \ + rsave (133, VREGS + 20*4); \ + rsave (134, VREGS + 21*4); \ + rsave (135, VREGS + 22*4); \ + rsave (136, VREGS + 23*4); \ + rsave (137, VREGS + 24*4); \ + rsave (138, VREGS + 25*4); \ + rsave (139, VREGS + 26*4); \ + rsave (140, VREGS + 27*4); \ + rsave (141, VREGS + 28*4); \ + rsave (142, VREGS + 29*4); \ + rsave (143, VREGS + 30*4); \ + rsave (144, VREGS + 31*4); #else #define EH_FRAME_VMX #endif -- 1.6.0.2.GIT ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: optimise smp_mb
On Wed, Mar 04, 2009 at 03:03:15PM +1100, Benjamin Herrenschmidt wrote: Allright, sorry for the delay, I had those stored into my need more than half a brain cell for review list and only got to them today :-) No problem :) On Thu, 2009-02-19 at 18:12 +0100, Nick Piggin wrote: Using lwsync, isync sequence in a microbenchmark is 5 times faster on my G5 than using sync for smp_mb. Although it takes more instructions. Running tbench with 4 clients on my 4 core G5 (20 times) gives the following: unpatched AVG=920.33 STD=2.36 patched AVG=921.27 STD=2.77 So not a big improvement here, actually it could even be in the noise. But other workloads or systems might see a bigger win, and the patch maybe is interesting or could be improved, so I'll ask for comments. So not a huge objection here, however I have some doubts as to whether this will be worthwhile on power5,6,7 since those optimized somewhat the behaviour of the full sync. Since anything older than power4 doesn't have lwsync, that potentially makes it not worth the pain. I would be interested to know. Avoiding sync when there *is* outstanding IO operations happening should be a win? (My test of tbench on localhost obviously wouldn't generate much MMIO). I mean, even in the most optimised implementation possible, this sequence is less constraining than sync. But I need to measure to be sure... it might be that newer embedded processors that support lwsync and SMP (and that are using a different pipeline structure) might benefit from this. I'll try to run some tests later this week or next week, but ping me in case I forget. OK I'll ping you next week. Now what would be worth doing is to also try using a twi;isync sequence like we do to order MMIO reads, see if it's any better than cmp/branch Probably makes sense to use the same pattern. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: replace isync with lwsync
On Wed, Mar 04, 2009 at 03:04:11PM +1100, Benjamin Herrenschmidt wrote: On Thu, 2009-02-19 at 18:21 +0100, Nick Piggin wrote: OK, here is this patch again. You didn't think I'd let a 2% performance improvement be forgotten? :) Anyway, patch won't work well on architecture without lwsync, but I won't bother fixing that kind of thing and making it merge worthy until you guys say something positive about it. 20 runs of tbench on the G5 unpatched AVG=920.37 STD=2.36 patched AVG=938.89 STD=3.33 (throughput in MB/s) This is a 1.9% throughput increase. Definitely worth it believe. We could use a macro that uses michael new improvements on the CPU features code pathing so that the isync gets changed to lwsync on some CPUs based on the availability of it. OK. I guess the interesting part about this is that I can't find any IBM documentation for lwsync capable CPUs that suggest using this pattern for acquire locking. It would be interesting to know whether it helps other CPUs... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: oprofile: enable support for ppc750 processors
From: Benjamin Herrenschmidt b...@kernel.crashing.org
On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote:
Signed-off-by: Octavian Purdila opurd...@ixiacom.com
So I'm going to merge 1/2 but this one should really be changed to
advertise ppc/750 in oprofile_cpu_type (ie. to userspace).
Sure. Here is the new patch which uses ppc/750. It enables oprofile for all 3
FX variants and GX as well.
Thanks!
tavi
commit 70f4865a614e9b0ff4594ebd52b95f78e998b79f
Author: Octavian Purdila opurd...@ixiacom.com
Date: Tue Jan 6 12:51:43 2009 +0200
powerpc: oprofile: enable support for ppc750 processors
Signed-off-by: Octavian Purdila opurd...@ixiacom.com
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..c3ea72b 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -726,6 +726,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = ppc750,
+ .oprofile_cpu_type = ppc/750,
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750FX rev 2.0 must disable HID0[DPM] */
.pvr_mask = 0x,
@@ -741,6 +743,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750,
.machine_check = machine_check_generic,
.platform = ppc750,
+ .oprofile_cpu_type = ppc/750,
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750FX (All revs except 2.0) */
.pvr_mask = 0x,
@@ -756,6 +760,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750fx,
.machine_check = machine_check_generic,
.platform = ppc750,
+ .oprofile_cpu_type = ppc/750,
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 750GX */
.pvr_mask = 0x,
@@ -771,6 +777,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.cpu_setup = __setup_cpu_750fx,
.machine_check = machine_check_generic,
.platform = ppc750,
+ .oprofile_cpu_type = ppc/750,
+ .oprofile_type = PPC_OPROFILE_G4,
},
{ /* 740/750 (L2CR bit need fixup for 740) */
.pvr_mask = 0x,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 4 Mar 2009 09:26:29 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Thanks Paul, I wasn't aware of that thread! Yes, this is almost the same. The only part I don't agree with is the move of the creation of the platform device from arch-specific code to rtc-firmware.c, as this makes autoloading the driver more difficult. and it's also against a proper implementation of the device/driver model. Seems like everybody but the RTC maintainer has an interest in having an RTC class driver on top of [gs]et_rtc_time()... ;-) That's because everyone is lazy :) Seriously, if you want to handle it in the way we wrote in the previous emails, it's ok for me. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Wed, 4 Mar 2009, Alessandro Zummo wrote: On Wed, 4 Mar 2009 09:26:29 +0100 (CET) Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote: Thanks Paul, I wasn't aware of that thread! Yes, this is almost the same. The only part I don't agree with is the move of the creation of the platform device from arch-specific code to rtc-firmware.c, as this makes autoloading the driver more difficult. and it's also against a proper implementation of the device/driver model. Seems like everybody but the RTC maintainer has an interest in having an RTC class driver on top of [gs]et_rtc_time()... ;-) That's because everyone is lazy :) Seriously, if you want to handle it in the way we wrote in the previous emails, it's ok for me. OK, I will do so. Thanks! 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: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
On Tue, 2009-03-03 at 21:39 -0800, Steve DeLaney wrote: Here's an update on this issue. After verifying the device tree was OK, the OF traces led us to the root cause. powerpc irq.c irq_alloc_virt() assigns a virtual IRQ as a function of the input hardware IRQ hint, AND NUM_ISA_INTERRUPTS. it turns out that asm-ppc/irq.h defines NUM_ISA_INTERRUPTS 16, so that the allocated virq is offset by this amount. this accounts for the remap shown below for i2c and serial device vectors. I didn't realize before that /proc/interrupts serviced by irq.c show_interrupts() displays virtual vector numbers. For the mpc8349e-mitx this must be incorrect since there is no ISA? Essentially all that is needed is a 1:1 mapping hirq:virq since each interrupt source in the system appears to have a unique vector in the SOC IPIC. It seems this scheme is needlessly complex, at least for mpc8349e. For now we simply define irq.h NUM_ISA_INTERRUPTS 0 but this isn't a complete solution since our PCI device interrupt on hirq 20, ends up allocated on virq 1. To force this to work, the driver does an irq_create_mapping(NULL, 20), then assigns its own dev-irq=20 before calling request_irq() I'm sure someone has a more elegant solution but that's what we've been able to come up with so far. I'm not clear on what the problem is. The interrupt numbers in /proc/interrupts will no longer match what the old kernel had, because as you mention the values in /proc/interrupts are virtual irqs. If you want to see the mapping turn on CONFIG_VIRQ_DEBUG and you'll get a file in debugfs called virq_mapping that shows the details. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
Hi,
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.
What do you think? If this is accepted, I'll submit a patch to remove the MTD
ps3vram and add the new driver as ps3vram (instead of ps3vram-ng).
Thanks for your (review and other) comments!
---
From e19ce619675bc150cd82701e7b272f7018c36527 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
Date: Wed, 25 Feb 2009 18:32:10 +0100
Subject: [PATCH] ps3/block: Add ps3vram-ng driver for accessing video RAM as
block device
Add ps3vram-ng driver, which 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.
Notes:
- As both the existing MTD ps3vram and ps3vram-ng bind to the same PS3 system
bus device, the driver which is loaded first by udev wins. However, you can
unload ps3vram, and load ps3vram-ng later.
- ps3vram-ng is faster than ps3vram:
o 1 MiB blocks: +50% (read), +5% (write)
o 4 KiB blocks: +50% (read), +5% (write)
o 512 B blocks: +10% (read), +10% (write)
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
Cc: Jim Paris j...@jtan.com
Cc: Vivien Chappelier vivien.chappel...@free.fr
---
arch/powerpc/platforms/ps3/Kconfig |7 +
drivers/block/Makefile |1 +
drivers/block/ps3vram_ng.c | 916
3 files changed, 924 insertions(+), 0 deletions(-)
create mode 100644 drivers/block/ps3vram_ng.c
diff --git a/arch/powerpc/platforms/ps3/Kconfig
b/arch/powerpc/platforms/ps3/Kconfig
index 920cf7a..b3b7a20 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 PPC_PS3 BLOCK
+ 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..ad3e45e 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) += ps3disk.o
+obj-$(CONFIG_PS3_VRAM) += ps3vram_ng.o
obj-$(CONFIG_ATARI_FLOPPY) += ataflop.o
obj-$(CONFIG_AMIGA_Z2RAM) += z2ram.o
obj-$(CONFIG_BLK_DEV_RAM) += brd.o
diff --git a/drivers/block/ps3vram_ng.c b/drivers/block/ps3vram_ng.c
new file mode 100644
index 000..fa24a17
--- /dev/null
+++ b/drivers/block/ps3vram_ng.c
@@ -0,0 +1,916 @@
+/*
+ * ps3vram - Use extra PS3 video ram as MTD block device.
+ *
+ * Copyright 2009 Sony Corporation
+ *
+ * Based on the MTD ps3vram driver, which is
+ * Copyright (c) 2007-2008 Jim Paris j...@jtan.com
+ * Added support RSX DMA Vivien Chappelier vivien.chappel...@free.fr
+ */
+
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/kthread.h
+#include linux/proc_fs.h
+#include linux/seq_file.h
+
+#include asm/firmware.h
+#include asm/lv1call.h
+#include asm/ps3.h
+
+
+#define DEVICE_NAMEps3vram
+
+
+#define XDR_BUF_SIZE (2 * 1024 * 1024) /* XDR buffer (must be 1MiB aligned) */
+#define XDR_IOIF 0x0c00
+
+#define FIFO_BASE XDR_IOIF
+#define FIFO_SIZE (64 * 1024)
+
+#define DMA_PAGE_SIZE (4 * 1024)
+
+#define CACHE_PAGE_SIZE (256 * 1024)
+#define CACHE_PAGE_COUNT ((XDR_BUF_SIZE - FIFO_SIZE) / CACHE_PAGE_SIZE)
+
+#define CACHE_OFFSET CACHE_PAGE_SIZE
+#define FIFO_OFFSET 0
+
+#define CTRL_PUT 0x10
+#define CTRL_GET 0x11
+#define CTRL_TOP 0x15
+
+#define UPLOAD_SUBCH 1
+#define DOWNLOAD_SUBCH 2
+
+#define NV_MEMORY_TO_MEMORY_FORMAT_OFFSET_IN 0x030c
+#define NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY 0x0104
+
+#define L1GPU_CONTEXT_ATTRIBUTE_FB_BLIT 0x601
+
+#define CACHE_PAGE_PRESENT 1
+#define CACHE_PAGE_DIRTY 2
+
+struct ps3vram_tag {
+ unsigned int address;
+ unsigned int flags;
+};
+
+struct ps3vram_cache {
+ unsigned int page_count;
+ unsigned int page_size;
+ struct ps3vram_tag *tags;
+ unsigned
Re: [PATCH] ppc: detect sbc610 boards and only fixup nec usb on them
On Wed, Mar 04, 2009 at 05:42:20PM +1100, Benjamin Herrenschmidt wrote: Thanks, I applied Tony's patch and sent a pull request to Linus. Works for me. Thanks for being so quick, Ben! cheers, Kyle ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
I'm posting this back on the mailing list. You're not being dense and there are good questions here which others might elaborate more on. On Tue, Mar 3, 2009 at 2:56 PM, Michael Guntsche m...@it-loops.com wrote: The routeboard is already providing a device-tree albeit not a very good one, otherwise the board would not boot in the first please if I just use a plain kernel I need more information here. What do you mean when you say plain kernel. What file from the build process do you use, and how do you boot it? without an embedded tree. I need to fix this device tree since the new gianfar network code is expecting tbi-handle = tbi1; Entries in the ethernet nodes to find the PHY devices. I do not know if you looked at the source of rbppc.c in detail. There is already code in there to init the PCI bus since the tree is missing data for this. I don't see a file named rbppc.c in the current kernel tree. * Why can't I just add those missing values in the setup-arch section of the code? You might be able to use of_attach_node() prom_add_property() to modify the tree, but I've never done it myself. Give it a try and tell me if it works. :-) They are needed to init the NICs correctly so I can fix this here before the driver is loaded Another option is to add a workaround to the driver. This isn't ideal, but driver authors aren't supposed to break device tree bindings either. Drivers are supposed to remain backwards compatible with older device trees (either by patching the device tree or with explicit workarounds). Downside is that this type of change may be harder to get merged. And it's just plain not very pretty. * How could I add those information? Can't I just do something similar to platforms/iseries/vio.c (add_string_property and do_device_node)? Maybe. I don't know why those functions are tucked away in vio.c instead of being common code. If you go that approach, refactor the functions you use to be shared. This wold have the benefit of getting the rest of the data from the board and just patch it with the needed values. This is definitely preferred to wholesale replacement of the available tree. 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: PHY not found after migration of gianfar driver to an of_platform_driver
On Mar 4, 2009, at 16:57, Grant Likely wrote: I need more information here. What do you mean when you say plain kernel. What file from the build process do you use, and how do you boot it? I build the kernel with make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- vmlinux I take the kernel file and add a kernparm segment to it, where I specify my root directory. Then I dd the file to the first partition of my CF card on the board. As I said before, the bootloader looks at the first partition of the CF-card with a partition type of 0x27. It expects a standard elf kernel to be in there and boots that. That's all there is to it. I don't see a file named rbppc.c in the current kernel tree. Sorry, this patch is not in mainline yet. You can find it at http://cynigram.com/~nfontes/rb600/ It adds the pata driver, and the board specific stuff to the stock kernel. The patch applies cleanly to 2.6.28.x but fails due to the gianfar related changes in the 2.6.29 release cycle. You might be able to use of_attach_node() prom_add_property() to modify the tree, but I've never done it myself. Give it a try and tell me if it works. :-) I am trying to do it this way right now, when I was looking at them I was just wondering if those two functions were the correct ones to use. As for backwards compatibility. All in-tree drivers were fixed as well to work with the new code so you cannot call this change breakage IMHO. Off-tree code that is affected by it (like the one I am struggling with right now) just has to follow those changes. I do not think that the changes broke any defined interface standards. It would be a lot easier if the board would use uboot or cuboot in the first place, but there is no way I can change that, other thanflashing the boot-loader itself NS I am neither brave nor knowledgeable enough to try that anyway. Kind regards, Michael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: U-Boot image
Günter == Günter Leonhardt guenter.leonha...@men.de writes: Günter Hello, Günter I'am looking for an image to boot a embedded device with a Günter single image. Günter I though the generated uImage in arch/powerpc/boot should Günter work, but u-boot cannot but this, because the addresses of Günter initrd and dtb not found. Günter Now I'am creating the image by hand with mkimage: Günter mkimage -A ppc -n F302 -O linux \ Günter-T multi -C gzip -a 0x0 -e 0x0 \ Günter -d vmlinux.bin.gz:initramfs_data.cpio.gz:f302.dtb \ Günter uImage I posted a patch to add support for multi image uImages to the kernel makefiles, E.G. uImage.platform some time ago. It got nack'ed by wdenx though as he wants people to use the new fitimage stuff in u-boot instead. Anyway, it might be useful to you: http://peter.korsgaard.com/patches/linux/bootwrapper-uboot-multi-2.patch To use it, add: image-$(CONFIG_your-platform) + uImage.your-platform to arch/powerpc/boot/Makefile. Günter This file is bootable, but I don't understand how a standard Günter file has to be booted. With an external dtb / initrd. Günter Can someone explain me the different fileforamts for booting Günter a powerpc with u-boot? Which is the simplest to use? Have a look at Documentation/powerpc/bootwrapper.txt -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/11] sdhci: Add support for bus-specific IO memory accessors
On Sat, Feb 21, 2009 at 04:57:57PM +0100, Pierre Ossman wrote:
On Fri, 13 Feb 2009 17:40:39 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
No, on eSDHC the registers are big-endian, 32-bit width, with, for
example, two 16-bit logical registers packed into it.
That is,
0x4 0x5 0x6 0x7
|:|
| BLKCNT : BLKSZ |
|:|
31 0
( The register looks wrong, right? BLKSZ should be at 0x4. But imagine
that you swapped bytes in this 32 bit register... then the registers
and their byte addresses will look normal. )
So if we try to issue readw(SDHCI_BLOCK_SIZE), i.e. readw(0x4):
- We'll read BLKCNT, while we wanted BLKSZ. This is because the
address bits should be translated before we try word or byte
reads/writes.
- On powerpc read{l,w}() convert the read value from little-endian
to big-endian byte order, which is wrong for our case (the
register is big-endian already).
That means that we have to convert address, but we don't want to
convert the result of read/write ops.
*cries*
:-)
[...]
as far as I'm
concerned, so I'd prefer something like:
if (!host-ops-writel)
writel(host-ioaddr + reg, val);
else
host-ops-writel(host, val, reg);
Surely the overhead isn't measurable... but why we purposely make
things worse?
We can most likely do some micro-optimisation do make the compare part
cheaper, but the point was to avoid a function call for all the
properly implemented controllers out there. We could have a flag so
that it only has to check host-flags, which will most likely be in the
cache anyway.
Overhead for eSDHC is not a concern in my book, what is interesting is
how much this change slows things down for other controllers.
OK, I see. Will the patch down below make you a little bit more happy
wrt normal controllers? Two #ifdefs, but then there is absolutely
zero overhead for the fully compliant SDHCI controllers.
(So far it's just on top of this series, but I can incorporate it
into the sdhci: Add support for bus-specific IO memory accessors
patch, if you like).
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 73b79e1..69bd124 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -37,6 +37,13 @@ config MMC_SDHCI
If unsure, say N.
+config MMC_SDHCI_IO_ACCESSORS
+ bool
+ depends on MMC_SDHCI
+ help
+ This is silent Kconfig symbol that is selected by the drivers that
+ need to overwrite SDHCI IO memory accessors.
+
config MMC_SDHCI_PCI
tristate SDHCI support on PCI bus
depends on MMC_SDHCI PCI
@@ -68,6 +75,7 @@ config MMC_RICOH_MMC
config MMC_SDHCI_OF
tristate SDHCI support on OpenFirmware platforms
depends on MMC_SDHCI PPC_OF
+ select MMC_SDHCI_IO_ACCESSORS
help
This selects the OF support for Secure Digital Host Controller
Interfaces. So far, only the Freescale eSDHC controller is known
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 284bc5d..fb08d3b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -88,60 +88,6 @@ static void sdhci_dumpregs(struct sdhci_host *host)
* *
\*/
-void sdhci_writel(struct sdhci_host *host, u32 val, int reg)
-{
- if (unlikely(host-ops-writel))
- host-ops-writel(host, val, reg);
- else
- writel(val, host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_writel);
-
-void sdhci_writew(struct sdhci_host *host, u16 val, int reg)
-{
- if (unlikely(host-ops-writew))
- host-ops-writew(host, val, reg);
- else
- writew(val, host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_writew);
-
-void sdhci_writeb(struct sdhci_host *host, u8 val, int reg)
-{
- if (unlikely(host-ops-writeb))
- host-ops-writeb(host, val, reg);
- else
- writeb(val, host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_writeb);
-
-u32 sdhci_readl(struct sdhci_host *host, int reg)
-{
- if (unlikely(host-ops-readl))
- return host-ops-readl(host, reg);
- else
- return readl(host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_readl);
-
-u16 sdhci_readw(struct sdhci_host *host, int reg)
-{
- if (unlikely(host-ops-readw))
- return host-ops-readw(host, reg);
- else
- return readw(host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_readw);
-
-u8 sdhci_readb(struct sdhci_host *host, int reg)
-{
- if (unlikely(host-ops-readb))
- return host-ops-readb(host, reg);
- else
- return readb(host-ioaddr + reg);
-}
-EXPORT_SYMBOL_GPL(sdhci_readb);
-
static void sdhci_clear_set_irqs(struct sdhci_host *host,
Re: [PATCH 12/13] sdhci: Add quirk for controllers with max. block size up to 4096 bytes
On Sat, Feb 21, 2009 at 04:58:44PM +0100, Pierre Ossman wrote: On Fri, 13 Feb 2009 17:47:39 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: @@ -831,7 +832,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data) sdhci_set_transfer_irqs(host); /* We do not handle DMA boundaries, so set it to max (512 KiB) */ - sdhci_writew(host, SDHCI_MAKE_BLKSZ(7, data-blksz), SDHCI_BLOCK_SIZE); + if (host-quirks SDHCI_QUIRK_MAX_BLK_SZ_4096) + blksz = data-blksz; + else + blksz = SDHCI_MAKE_BLKSZ(7, data-blksz); + + sdhci_writew(host, blksz, SDHCI_BLOCK_SIZE); sdhci_writew(host, data-blocks, SDHCI_BLOCK_COUNT); } Hmm.. I seem to have overlooked this part previously. I guess they've basically stripped out the DMA boundary stuff and used the bits for other things? Yes, the last two DMA boundary bits are reserved, and the first one is re-used for blksz of 4096 bytes. At this point I'm leaning more towards simply not supporting their extended block size. Eh. But well, OK. We can always persuade you later. :-) I'll get rid of this particular patch, and put some BLOCK_SIZE magic into the writew accessor (to clean the DMA bits) instead. Though, I'll prepare another patch to force blksz to 2048, since eSDHC specifies 3 in the blksz capability bitfield, and that causes SDHCI core to fall back to the 512 byte blocks. After all, is it ever used? Not sure, maybe `dd bs=' can use it? A bit lazy to check this right now, but from the quick tests, enabling/disabling blksz of 4096 bytes doesn't cause any performance change. At least with the ordinary SD cards. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/13] sdhci: Add support for hosts with strict 32 bit addressing
On Sat, Feb 21, 2009 at 04:58:33PM +0100, Pierre Ossman wrote:
On Fri, 13 Feb 2009 17:47:22 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
SDHCI driver must take special care when working with triggering
registers on hosts with strict 32 bit addressing.
In FSL eSDHC hosts all registers are 32 bit width, writing to the
first half of any register will cause [undefined?] write the second
half of the register. That is, 16 bit write to the TRANSFER_MODE
register, makes hardware see a bogus write to the COMMAND register
(these two registers are adjacent).
This patch adds SDHCI_QUIRK_32BIT_REGISTERS quirk. When specified,
the sdhci driver will try to pack all dangerous writes into single
32 bit write transaction.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
What about the other places where we have 16 and 8 bit registers?
These are handled by the accessors:
+static void esdhc_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+ int base = reg ~0x3;
+ int shift = (reg 0x3) * 8;
+
+ clrsetbits_be32(host-ioaddr + base , 0xff shift, val shift);
^^ See, we're always issuing 32bit ops.
The point of this patch is to take care of triggering registers,
i.e. those registers that are used trigger send some data command.
There is just one (from the eSDHC point of view) such register:
TRANSFER_MODE+COMMAND (which is a single 32 bit register in eSDHC,
but two independant word-sized registers in standard SDHCI).
That register must be accessed with 32bit ops just _once_ per
data transfer, not two 32bit writes (half of a register one time,
and half of a register next time -- this won't work).
But I see the point of confusion... Instead of teaching
SDHCI core to work with 32 bits hosts, we'd better handle this
in the eSDHC part, in the accessors.
This is relatively trivial and should not cause much overhead
(at least when using DMA), just a small state machine with
the xfer mode register shadowed in software (plus, notice that
this also handles BLOCK_SIZE, as I promised in another email):
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 22bf006..5100d1d 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -30,6 +30,7 @@ struct sdhci_of_data {
struct sdhci_of_host {
unsigned int clock;
+ u16 xfer_mode_shadow;
};
/*
@@ -69,9 +70,31 @@ static void esdhc_writel(struct sdhci_host *host, u32 val,
int reg)
static void esdhc_writew(struct sdhci_host *host, u16 val, int reg)
{
+ struct sdhci_of_host *of_host = sdhci_priv(host);
int base = reg ~0x3;
int shift = (reg 0x2) * 8;
+ switch (reg) {
+ case SDHCI_TRANSFER_MODE:
+ /*
+* Postpone this write, we must do it together with a
+* command write that is down below.
+*/
+ of_host-xfer_mode_shadow = val;
+ return;
+ case SDHCI_COMMAND:
+ esdhc_writel(host, val 16 | of_host-xfer_mode_shadow,
+SDHCI_TRANSFER_MODE);
+ return;
+ case SDHCI_BLOCK_SIZE:
+ /*
+* Two last DMA bits are reserved, and first one is used for
+* non-standard blksz of 4096 bytes that we don't support
+* yet. So clear the DMA boundary bits.
+*/
+ val = ~SDHCI_MAKE_BLKSZ(0x7, 0);
+ /* fall through */
+ }
clrsetbits_be32(host-ioaddr + base, 0x shift, val shift);
}
@@ -137,13 +160,11 @@ static unsigned int esdhc_get_timeout_clock(struct
sdhci_host *host)
}
static struct sdhci_of_data sdhci_esdhc = {
- .quirks = SDHCI_QUIRK_32BIT_REGISTERS |
- SDHCI_QUIRK_BROKEN_CARD_DETECTION |
+ .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
SDHCI_QUIRK_INVERTED_WRITE_PROTECT |
SDHCI_QUIRK_NO_BUSY_IRQ |
SDHCI_QUIRK_NONSTANDARD_CLOCK |
SDHCI_QUIRK_PIO_NEEDS_DELAY |
- SDHCI_QUIRK_MAX_BLK_SZ_4096 |
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
SDHCI_QUIRK_NO_CARD_NO_RESET,
.ops = {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/13] sdhci: Add support for card-detection polling
On Sat, Feb 21, 2009 at 04:58:21PM +0100, Pierre Ossman wrote:
On Fri, 13 Feb 2009 17:47:18 +0300
Anton Vorontsov avoront...@ru.mvista.com wrote:
@@ -1110,13 +1113,18 @@ static void sdhci_request(struct mmc_host *mmc,
struct mmc_request *mrq)
host-mrq = mrq;
+ if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ goto send;
+
if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) SDHCI_CARD_PRESENT)
|| (host-flags SDHCI_DEVICE_DEAD)) {
host-mrq-cmd-error = -ENOMEDIUM;
tasklet_schedule(host-finish_tasklet);
- } else
- sdhci_send_command(host, mrq-cmd);
-
+ goto out;
+ }
+send:
+ sdhci_send_command(host, mrq-cmd);
+out:
mmiowb();
spin_unlock_irqrestore(host-lock, flags);
}
goto:s seem unnecessary here, and your patch is even incorrect as it
ignores the SDHCI_DEVICE_DEAD flag.
Oops.
Just modify the if-clause and
things will work.
That would look horrid...
if ((!(host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
!(sdhci_readl(host, SDHCI_PRESENT_STATE)
SDHCI_CARD_PRESENT)) ||
(host-flags SDHCI_DEVICE_DEAD)) {
Might want to add a comment also to make it more obvious what the
if-clause does.
Let's try to avoid the if-clause above? How about this:
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0cbde8e..d71c877 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -167,6 +167,9 @@ static void sdhci_set_card_detection(struct sdhci_host
*host, bool enable)
{
u32 irqs = SDHCI_INT_CARD_REMOVE | SDHCI_INT_CARD_INSERT;
+ if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ return;
+
if (enable)
sdhci_unmask_irqs(host, irqs);
else
@@ -1096,6 +1099,7 @@ out:
static void sdhci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct sdhci_host *host;
+ bool present;
unsigned long flags;
host = mmc_priv(mmc);
@@ -1110,8 +1114,14 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host-mrq = mrq;
- if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) SDHCI_CARD_PRESENT)
- || (host-flags SDHCI_DEVICE_DEAD)) {
+ /* If polling, assume that the card is always present. */
+ if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ present = true;
+ else
+ present = sdhci_readl(host, SDHCI_PRESENT_STATE)
+ SDHCI_CARD_PRESENT;
+
+ if (!present || host-flags SDHCI_DEVICE_DEAD) {
host-mrq-cmd-error = -ENOMEDIUM;
tasklet_schedule(host-finish_tasklet);
} else
@@ -1745,6 +1755,9 @@ int sdhci_add_host(struct sdhci_host *host)
if (caps SDHCI_CAN_DO_HISPD)
mmc-caps |= MMC_CAP_SD_HIGHSPEED;
+ if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
+ mmc-caps |= MMC_CAP_NEEDS_POLL;
+
mmc-ocr_avail = 0;
if (caps SDHCI_CAN_VDD_330)
mmc-ocr_avail |= MMC_VDD_32_33|MMC_VDD_33_34;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 1c29895..09a4363 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -212,6 +212,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_BROKEN_SMALL_PIO (113)
/* Controller does not provide transfer-complete interrupt when not busy */
#define SDHCI_QUIRK_NO_BUSY_IRQ(114)
+/* Controller has unreliable card detection */
+#define SDHCI_QUIRK_BROKEN_CARD_DETECTION (115)
int irq;/* Device IRQ */
void __iomem * ioaddr; /* Mapped address */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
GDB problem with Xilinx GIT Linux on Virtex5FX PPC440
Hi, At the moment I can't set any breakpoint under gdb or gdbserver on ML510 and AVNETV5FX30T, if I set one = die continuing Everything else is OK for a while on both boards: cross-compiling, dhcp, netperf, custom apps, but not debugging ! If you have a working gdb (and/or gdbserver) on PPC440 Linux , could you please anwer this message with the following piece of information: Board kernel revision kernel snapshot (day/number) used from Xilinx GIT defconfig used toolchain (ELDK/buildroot...) toolchain version location of the rootfs (ramdisk, SysACE partition, flash Uboot partition) Type of the rootfs Thank you very much in advance. Best regards, Frederic ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: add fsl, fifo-depth property to Freescale SSI device nodes
The Freescale Serial Synchronous Interface (SSI) is an audio device present on
some Freescale SOCs. Various implementations of the SSI have a different
transmit and receive FIFO depth, but are otherwise identical. To support
these variations, add a new property fsl,fifo-depth to the SSI node that
specifies the depth of the FIFOs.
Also update the MPC8610 HPCD device tree with this property.
Signed-off-by: Timur Tabi ti...@freescale.com
---
Updates to the SSI audio driver will come later. Currently, this driver
supports only one Freescale SOC, and so it's hard-coded to use the value 8.
If/when this driver is updated to support other SOCs (e.g. the i.MX parts
that have a FIFO depth of 15), the driver will check for this property. I
just want to get this DTS change in now.
Documentation/powerpc/dts-bindings/fsl/ssi.txt |2 ++
arch/powerpc/boot/dts/mpc8610_hpcd.dts |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
index a2d9639..7313322 100644
--- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt
@@ -30,6 +30,8 @@ Required properties:
- 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].
Optional properties:
- codec-handle : phandle to a 'codec' node that defines an audio
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index f724d72..1bd3ebe 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -217,6 +217,7 @@
codec-handle = cs4270;
fsl,playback-dma = dma00;
fsl,capture-dma = dma01;
+ fsl,fifo-depth = 8;
};
s...@16100 {
@@ -225,6 +226,7 @@
reg = 0x16100 0x100;
interrupt-parent = mpic;
interrupts = 63 2;
+ fsl,fifo-depth = 8;
};
d...@21300 {
--
1.6.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How to bring up fs_enet on 2.6.27?
On Wed, Feb 25, 2009 at 06:09:32PM +1100, Daniel Ng wrote: On Fri, Feb 20, 2009 at 4:01 PM, Daniel Ng daniel.ng1...@gmail.com wrote: Now, I'm seeing these boot messages: f0010d40:00 not found eth0: Could not attach to PHY IP-Config: Failed to open eth0 IP-Config: Device `eth0' not found. Previous mailing list discussions suggest that I use the correct PHY, which I am sure about because my 8272-based board only has the one PHY ie. PHY0 with reg = 0x0. Note the relevant parts of my Device Tree below. Currently, our PHY attributes eg. 'auto-negotiate' are not changeable, so we aren't actually using MDC+MDIO even the MDC+MDIO lines exist. Your device tree is telling the kernel that you *are* using those lines. If they're not connected the way the device tree describes them as being connected, you'll have to replace it with something that accurately describes your hardware. Also, the PHY interrupt line is not wired up. Hence the PHY0 interrupts field is 0 8 (or should it be removed altogether?). If your PHY interrupt is not connected, then you must remove the interrupts property altogether. 0 is a potentially valid interrupt number. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
On Tue, Mar 3, 2009 at 11:39 PM, Steve DeLaney onramp...@yahoo.com wrote: For the mpc8349e-mitx this must be incorrect since there is no ISA? That doesn't matter. We want the code to be as common as possible. The actual virtual IRQ value is irrelevant. The OF code gives you a virq number, and you just use that. Any code or board design that depends on any relationship between the virq and the hwirq is broken. Essentially all that is needed is a 1:1 mapping hirq:virq since Needed for who? For now we simply define irq.h NUM_ISA_INTERRUPTS 0 This is a bad idea. You will just break something else. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc8349e-mitx 2.6.25 serial IRQ assigned wrong
On Tue, Mar 3, 2009 at 10:39 PM, Steve DeLaney onramp...@yahoo.com wrote: I didn't realize before that /proc/interrupts serviced by irq.c show_interrupts() displays virtual vector numbers. For the mpc8349e-mitx this must be incorrect since there is no ISA? Essentially all that is needed is a 1:1 mapping hirq:virq since each interrupt source in the system appears to have a unique vector in the SOC IPIC. It seems this scheme is needlessly complex, at least for mpc8349e. It may look to be needlessly complex for boards that only have one interrupt controller, but it is far simpler than the alternative when you have boards with multiple cascaded IRQ controllers. This is not an uncommon circumstance any more, even on embedded boards. ie. I'm working on two different MPC5200 platforms and each has an FPGA which coalesces interrupts to a single MPC5200 external IRQ line. Without VIRQs, I'd need to slice up the IRQ number space for each board variant I work with and write the code to match. With VIRQs, there is no need to, and all of the boards can use common support code. 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] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device
On Wed, 2009-03-04 at 14:57 +0100, Geert Uytterhoeven wrote: Hi, 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 ? Cheers, Ben. What do you think? If this is accepted, I'll submit a patch to remove the MTD ps3vram and add the new driver as ps3vram (instead of ps3vram-ng). Thanks for your (review and other) comments! --- From e19ce619675bc150cd82701e7b272f7018c36527 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven geert.uytterhoe...@sonycom.com Date: Wed, 25 Feb 2009 18:32:10 +0100 Subject: [PATCH] ps3/block: Add ps3vram-ng driver for accessing video RAM as block device Add ps3vram-ng driver, which 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. Notes: - As both the existing MTD ps3vram and ps3vram-ng bind to the same PS3 system bus device, the driver which is loaded first by udev wins. However, you can unload ps3vram, and load ps3vram-ng later. - ps3vram-ng is faster than ps3vram: o 1 MiB blocks: +50% (read), +5% (write) o 4 KiB blocks: +50% (read), +5% (write) o 512 B blocks: +10% (read), +10% (write) Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com Cc: Jim Paris j...@jtan.com Cc: Vivien Chappelier vivien.chappel...@free.fr --- arch/powerpc/platforms/ps3/Kconfig |7 + drivers/block/Makefile |1 + drivers/block/ps3vram_ng.c | 916 3 files changed, 924 insertions(+), 0 deletions(-) create mode 100644 drivers/block/ps3vram_ng.c diff --git a/arch/powerpc/platforms/ps3/Kconfig b/arch/powerpc/platforms/ps3/Kconfig index 920cf7a..b3b7a20 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 PPC_PS3 BLOCK + 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..ad3e45e 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) += ps3disk.o +obj-$(CONFIG_PS3_VRAM) += ps3vram_ng.o obj-$(CONFIG_ATARI_FLOPPY) += ataflop.o obj-$(CONFIG_AMIGA_Z2RAM)+= z2ram.o obj-$(CONFIG_BLK_DEV_RAM)+= brd.o diff --git a/drivers/block/ps3vram_ng.c b/drivers/block/ps3vram_ng.c new file mode 100644 index 000..fa24a17 --- /dev/null +++ b/drivers/block/ps3vram_ng.c @@ -0,0 +1,916 @@ +/* + * ps3vram - Use extra PS3 video ram as MTD block device. + * + * Copyright 2009 Sony Corporation + * + * Based on the MTD ps3vram driver, which is + * Copyright (c) 2007-2008 Jim Paris j...@jtan.com + * Added support RSX DMA Vivien Chappelier vivien.chappel...@free.fr + */ + +#include linux/blkdev.h +#include linux/delay.h +#include linux/kthread.h +#include linux/proc_fs.h +#include linux/seq_file.h + +#include asm/firmware.h +#include asm/lv1call.h +#include asm/ps3.h + + +#define DEVICE_NAME ps3vram + + +#define XDR_BUF_SIZE (2 * 1024 * 1024) /* XDR buffer (must be 1MiB aligned) */ +#define XDR_IOIF 0x0c00 + +#define FIFO_BASE XDR_IOIF +#define FIFO_SIZE (64 * 1024) + +#define DMA_PAGE_SIZE (4 * 1024) + +#define CACHE_PAGE_SIZE (256 * 1024) +#define CACHE_PAGE_COUNT ((XDR_BUF_SIZE - FIFO_SIZE) / CACHE_PAGE_SIZE) + +#define CACHE_OFFSET CACHE_PAGE_SIZE +#define FIFO_OFFSET 0 + +#define CTRL_PUT 0x10 +#define CTRL_GET 0x11 +#define CTRL_TOP 0x15 + +#define UPLOAD_SUBCH 1 +#define
Re: [Cbe-oss-dev] [PATCH] powerpc/spufs: Fix incorrect buffer offset in regs write
Hi Geert,
Could this be abused by an attacker to write registers or local store
he's not allowed to do?
It looks like the user can only overwrite fields that it already has
access to. There's struct spu_lscsa:
struct spu_lscsa {
struct spu_reg128 gprs[128];
struct spu_reg128 fpcr;
struct spu_reg128 decr;
struct spu_reg128 decr_status;
struct spu_reg128 ppu_mb;
struct spu_reg128 ppuint_mb;
struct spu_reg128 tag_mask;
struct spu_reg128 event_mask;
struct spu_reg128 srr0;
struct spu_reg128 stopped_status;
unsigned char ls[LS_SIZE] __attribute__((aligned(65536)));
};
where spu_reg128 is a u32[4].
The maximum 'allowed' write offset to the regs file is 2047. The
(incorrect) maximum offset calculated by the old code would be 8188
(2047 * 4) bytes into struct spu_lscsa.
So, 8188 bytes covers all of the registers, but ends somewhere before
the start of the ls area (within the ls alignment padding). Let's look
at the registers:
gprs: user-writable
fpcr: user-writable
decr: user-writable
decr_status:only affects user-settable SPE state
ppu_mb: only affects user-settable SPE state
ppuint_mb: only affects user-settable SPE state
tag_mask: only affects user-settable SPE state
event_mask: only affects user-settable SPE state
srr0: only affects user-settable SPE state
stopped_status: only affects user-settable SPE state
So, I think we're fine. All a user can do with this bug is mess up their
own SPE state.
Should it be backported to stable?
Yes, I'll submit to the stable tree too.
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[no subject]
Dear Everyone: I have read in this list that someone asked for the document of IBM eBony board with PPC440GP. I don't know if he get it . But could anyone send me the document or tell me how to get it ? thanks a lot. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/cell: Only build Axon MSI driver for IBM Cell Blades
The hardware is only present on those machines, and the driver depends on infrastructure which is selected by the Kconfig for cell blades. Reported-by: Mikey Randconfig Monkey Neuling Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/platforms/cell/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/cell/Makefile b/arch/powerpc/platforms/cell/Makefile index 43eccb2..9330cf8 100644 --- a/arch/powerpc/platforms/cell/Makefile +++ b/arch/powerpc/platforms/cell/Makefile @@ -28,7 +28,9 @@ obj-$(CONFIG_SPU_BASE)+= spu_callbacks.o spu_base.o \ $(spu-manage-y) \ spufs/ +ifeq ($(CONFIG_PPC_IBM_CELL_BLADE),y) obj-$(CONFIG_PCI_MSI) += axon_msi.o +endif # qpace setup obj-$(CONFIG_PPC_CELL_QPACE) += qpace_setup.o -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH] Print linux_banner in prom_init
So at least you can see what kernel you're booting if you die before the kernel prints it mid-way through start_kernel(). Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/kernel/prom_init.c|2 ++ arch/powerpc/kernel/prom_init_check.sh |2 +- 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c index 7f1b33d..4d5ebb4 100644 --- a/arch/powerpc/kernel/prom_init.c +++ b/arch/powerpc/kernel/prom_init.c @@ -2283,6 +2283,8 @@ unsigned long __init prom_init(unsigned long r3, unsigned long r4, */ prom_init_stdout(); + prom_printf(Preparing to boot %s, PTRRELOC((char *)linux_banner)); + /* * Get default machine type. At this point, we do not differentiate * between pSeries SMP and pSeries LPAR diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh index ea3a2ec..1ac136b 100644 --- a/arch/powerpc/kernel/prom_init_check.sh +++ b/arch/powerpc/kernel/prom_init_check.sh @@ -20,7 +20,7 @@ WHITELIST=add_reloc_offset __bss_start __bss_stop copy_and_flush _end enter_prom memcpy memset reloc_offset __secondary_hold __secondary_hold_acknowledge __secondary_hold_spinloop __start strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224 -reloc_got2 kernstart_addr memstart_addr +reloc_got2 kernstart_addr memstart_addr linux_banner NM=$1 OBJ=$2 -- 1.5.6.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix mpc52xx_gpt when sysfs is not configured
mpc52xx_gpt_create_attribs is missing a parameter name and shouldn't
return anything since it's void.
Signed-off-by: Michael Neuling mi...@neuling.org
---
This is against benh's testing tree
arch/powerpc/platforms/52xx/mpc52xx_gpt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: clone1/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
===
--- clone1.orig/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ clone1/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -370,7 +370,7 @@ static void mpc52xx_gpt_create_attribs(s
}
#else /* defined(CONFIG_SYSFS) */
-static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return 0; }
+static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *gpt) {}
#endif /* defined(CONFIG_SYSFS) */
/* -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
GPIO and SPI on CPM2 (8260)?
Hi, I'm trying to get GPIO and SPI working on my 8272-based board. Would anyone know if the following exists?- 1) SPI driver for CPM2-based platforms? 2) GPIO driver for CPM2-based platforms? Also, has anyone used the gpiolib functionality on the CPM2-based platforms? Cheers, Daniel ___ 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 Thu, Mar 05 2009, Benjamin Herrenschmidt wrote: On Wed, 2009-03-04 at 14:57 +0100, Geert Uytterhoeven wrote: Hi, 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 :-) -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell: Only build Axon MSI driver for IBM Cell Blades
On Thu, Mar 05, 2009 at 03:41:41PM +1100, Michael Ellerman wrote: The hardware is only present on those machines, and the driver depends on infrastructure which is selected by the Kconfig for cell blades. Wouldn't it make more sense to make a separate (AXON_MSI) config option depend on PPC_IBM_CELL_BLADE? -Olof --- a/arch/powerpc/platforms/cell/Makefile +++ b/arch/powerpc/platforms/cell/Makefile @@ -28,7 +28,9 @@ obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \ $(spu-manage-y) \ spufs/ +ifeq ($(CONFIG_PPC_IBM_CELL_BLADE),y) obj-$(CONFIG_PCI_MSI)+= axon_msi.o +endif # qpace setup obj-$(CONFIG_PPC_CELL_QPACE) += qpace_setup.o ___ 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
Am 04.03.2009 um 14:57 schrieb Geert Uytterhoeven: 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. openSuSE already ships with the ps3vram driver since a two releases. A simple name based udev rule could symlink ps3vram to mtdblock0, so an upgrade will not break existing setups. +obj-$(CONFIG_PS3_VRAM) += ps3vram_ng.o Please give the driver the obvious name ps3vram, that way upgrading will be smooth. I see our old mtddriver does not have modalias support for autoloading. Hopefully the new driver has this feature. Olaf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PHY not found after migration of gianfar driver to an of_platform_driver
On Wed, 4 Mar 2009 08:57:59 -0700, Grant Likely grant.lik...@secretlab.ca wrote: You might be able to use of_attach_node() prom_add_property() to modify the tree, but I've never done it myself. Give it a try and tell me if it works. :-) Hello Grant, I made some progress in this area, but I have now hit a problem I do not know how to solve. Taking code from the iseries/vio.c files I am able to add properties with add_string_property and add_raw_property. The problem I have is adding properties like reg = 0x2520 0x20 I know how to add a property reg = 0x2520 but I do not know what data structure to pass to add_raw_property to add two numbers there. Kind regards, Michael ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
