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=gst&q=rtc-firmware#1d730cb4aa2f85f0 > http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=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 > > --- > 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 --- 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
> On Tue, 2009-01-06 at 14:55 +0200, Octavian Purdila wrote:
> > Signed-off-by: Octavian Purdila
>
> 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
Date: Tue Jan 6 12:51:43 2009 +0200
powerpc: oprofile: enable support for ppc750 processors
Signed-off-by: Octavian Purdila
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 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 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
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
Cc: Jim Paris
Cc: Vivien Chappelier
---
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
+ * Added support RSX DMA Vivien Chappelier
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+
+#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 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 int hit;
+ unsigned int miss;
+};
+
+struct ps3vram_priv {
+ spinlock_t lock;/* Request queue spinlock */
+ struct task_struct *thread;
+ struct request_queue *queue;
+ struct gendisk *gen
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 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 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. 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_) + uImage. 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 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 r
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 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 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
> > ---
>
> 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 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 (1<<13)
/* Controller does not provide transfer-complete interrupt when not busy */
#define SDHCI_QUIRK_NO_BUSY_IRQ(1<<14)
+/* Controller has unreliable card detection */
+#define SDHCI_QUIRK_BROKEN_CARD_DETECTION (1<<15)
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
---
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 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 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 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 > 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 > Cc: Jim Paris > Cc: Vivien Chappelier > --- > 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 > + * Added support RSX DMA Vivien Chappelier > + */ > + > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > + > +#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 DOWNLOAD_SUBCH 2 > + > +#define NV_MEMORY_TO_MEMORY_FORMAT_OFFSET_IN 0x030c > +#define NV_MEMORY_
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 --- 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
---
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
---
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 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
