Re: [PATCH] [spi_mpc83xx] Always enable legacy support.
Anton Vorontsov avoront...@ru.mvista.com wrote on 01/07/2009 23:12:12:
On Wed, Jul 01, 2009 at 09:16:12PM +0200, Joakim Tjernlund wrote:
There are out of tree boards that need this legacy support too.
Heh.
Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se
---
I hope this is OK. I just discovered that spi didn't work for
me in 2.6.30 and I have no time to work on coverting my boards.
I'd convert them for you if they were in-tree. :-) But I don't
think that moving the kernel backwards because of out-of-tree
boards is a good thing.
:), but allowing out-of-tree boards one or two kernel releases to catch up
with a legacy printout would have been nice.
I don't have a clue either on how to do that, any pointers
how to add a few spidev devices via OF?
Something like this will work:
s...@4c0 {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
compatible = fsl,spi;
reg = 0x4c0 0x40;
interrupts = 2;
interrupt-parent = qeic;
/* provide chip-selects here */
gpios = qe_pio_d 13 0 /* CS0 */
qe_pio_d 14 0; /* CS1 */
mode = cpu-qe;
dev...@0 {
compatible = spidev;
reg = 0; /* CS0*/
spi-max-frequency = 5000;
};
dev...@0 {
compatible = spidev;
reg = 1; /* CS1 */
spi-max-frequency = 5000;
};
};
You can look at arch/powerpc/boot/dts/mpc832x_rdb.dts as an
example.
Note that spidev isn't correct compatible entry to use,
but it's quick and dirty solution. A proper solution is to
add a proper compatible entry into the device-tree, and
add spidev alias into drivers/of/base.c:of_modalias_table.
Thanks
Jocke
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
On Wed, Jul 1, 2009 at 10:14 PM, Mikhail Zaturenskiymzaturenskiy...@gmail.com wrote: Hi Mikhail, Try setting CONFIG_EXT2_FS=y, then recompile your kernel and reboot. Hi Frank, just tried that but still getting the same Unpacking initramfs... failed! output Hmm... according to Kernel command line: console=ttyCPM0,9600n8 loglevel=7 you haven't specified where root is. Add root=/dev/ram to the kernel command line, and specify where the init process is located (for instance init=/sbin/init). I haven't tried Denks ramdisk image. You can create one for yourself using dd, gzip and U-Boots mkimage tool. If the ramdisk image is larger than 4MB, you must either change the default CONFIG_BLK_DEV_RAM_SIZE=4096, or set ramdisk size in the kernel command line. Btw, I use an older kernel than you use, but I have these defined: CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 Maybe they're obsolete now, but you can try to add them to your defconfig file. Good luck ;-) - Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Preemption question (4xx related)
On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote: I've toyed with that idea myself. I keep coming back to the fact that you need a workload that would really leverage it, and I don't have one at the moment. To some extent that's true but just turning full preemption including kernel side with all the associated debug bits and lockdep should make a whole bunch of things show up even with ordinary workloads. For 440 tend to boot an ubuntu distro off NFS root with all X DRI 3D etc... and then run compiz :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
AW: Direct MII connection between MPC8313 and VIRTEX FPGA
Hi Grant Thank you very much so far. It helped me a lot! Best regards Frank -Ursprüngliche Nachricht- Von: linuxppc-dev-bounces+frank.prepelica=ubidyne@lists.ozlabs.org [mailto:linuxppc-dev-bounces+frank.prepelica=ubidyne@lists.ozlabs.org] Im Auftrag von Grant Likely Gesendet: Dienstag, 30. Juni 2009 18:17 An: Frank Prepelica Cc: linuxppc-...@ozlabs.org Betreff: Re: Direct MII connection between MPC8313 and VIRTEX FPGA On Tue, Jun 30, 2009 at 2:35 AM, Frank Prepelicafrank.prepel...@ubidyne.com wrote: What kernel version are you using? We are using kernel version 2.6.24. I've searched for current speed in version 2.6.28.7 and I've found that string. Yes, you need to modify the DTB. You have a back to back MII connection, not a phy, so you do *not* want to have a PHY node in the device tree. Hmm, but I do have a PHY, don't I?. The PHY will be emulated in the FPGA. Of course, it's not a physical PHY but it should look like one. No, it sounds like you don't. If you've got a back-to-back MII connection, then you can fix the link speed and you don't need to do any form of PHY emulation. ie. you don't need to wire up the MDIO pins. So, do I really need the remove the complete PHY description in the DTB? yes. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
How to set DDR data bus width to 16Bit
Hi all, Does anyone knows how to set the DDR data bus width to 16Bit in linux? I've found that option in U-Boot in the MPC8313ERDB_config file. (verfied with a memory dump of the CPU register (DDR_SDRAM_CFG) - the 16Bit DBW is set(10b) ). But after starting linux the value is set to 00b (=reseverd). We are using a customized MPC8313ERDB board. Thanks in advance Kind regards Frank Prepelica Software Design Engineer Ubidyne GmbH Lise-Meitner-Str.-14 89081 Ulm - Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to set DDR data bus width to 16Bit
you have to do it via your bootloader (u-boot) which sets up the DDR memory controller. Linux (already) assumes memory is available. Are you sure linux kernel is changing DDR_SDRAM_CFG ? When our linux-2.6.28 kernel is up, it's still 0xc308 when I read physical address 0xe0002110. Btw. We did some performance tests with 16 bit bus-width (DDR2 memory) and surprisingly performance was almost as good as 32 bit bus-width --- N. van Bolhuis. Frank Prepelica wrote: Hi all, Does anyone knows how to set the DDR data bus width to 16Bit in linux? I've found that option in U-Boot in the MPC8313ERDB_config file. (verfied with a memory dump of the CPU register (DDR_SDRAM_CFG) - the 16Bit DBW is set(10b) ). But after starting linux the value is set to 00b (=reseverd). We are using a customized MPC8313ERDB board. Thanks in advance Kind regards Frank Prepelica Software Design Engineer Ubidyne GmbH Lise-Meitner-Str.-14 89081 Ulm - Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Preemption question (4xx related)
On Thu, 2009-07-02 at 08:13 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-06-30 at 05:55 -0700, Felix Radensky wrote: Hi, Preemption is disabled on the vast majority of powerpc targets. Are there any known problems in this area ? I'd like to enable CONFIG_PREEMPT_VOLUNTARY on AMCC 405EX target, to increase application responsiveness. Is it a bad idea ? In theory it should work, but as you may have noticed, it's generally disabled and thus not very well tested. It would be a good idea for us, some of the core devs, to turn that on in our usual test configs in fact. FWIW, on my PowerBook I've been running with CONFIG_PREEMPT_VOLUNTARY enabled for a long time (more than a year). No problems so far, and it definitely seems to help a lot for interactivity. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
AW: How to set DDR data bus width to 16Bit
you have to do it via your bootloader (u-boot) which sets up the DDR memory controller. Linux (already) assumes memory is available. Are you sure linux kernel is changing DDR_SDRAM_CFG ? When our linux-2.6.28 kernel is up, it's still 0xc308 when I read physical address 0xe0002110. Hi Norbert, thank you for your fast reply! You are absolutly right! I made a silly mistake. I've read the value of the 0xe0002110 with a 8bit pointer. The value is actually 0xC310 which means the 16bit bus width is set. Just to be sure. Is this the only change (in the bootloader) I have to make that all data accesses are 16bit wide? Btw. We did some performance tests with 16 bit bus-width (DDR2 memory) and surprisingly performance was almost as good as 32 bit bus-width This is exactly our intention to test. Thanks for that hint. Very good to know! Thank you. Best regards Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: How to set DDR data bus width to 16Bit
Hi Frank, Yes, it's 0xC310 for 16 bit. I showed the 32bit value. Yes, to go to 16 bit bus-width (1 DDR(2) device), this is the only change needed in u-boot, assuming you have 2 DDR(2) devices (like 8313E-RDB) which together provide 16+16 = 32bit bus-width. Since, surprisingly, the 16 bit application/u-boot performance was almost as good as 32 bit we even tested with I-cache and D-cache turned off. u-boot provides commands for this (which I didn't know, see some previous emails from me on this mailing-list). Also with I-cache and D-cache turned off the 16 bit bus-width performance was almost as good as 32 bit. So our conclusion was that the 16/32 bit DDR2 memory access is not the limiting factor when it comes to SW performance. Therefore we decided to go for 16 bit bus-width for a new/tiny 8313 based design. Please let me know your test results. I would expect you to conclude more or less the same. Best Regards, Norbert. Frank Prepelica wrote: you have to do it via your bootloader (u-boot) which sets up the DDR memory controller. Linux (already) assumes memory is available. Are you sure linux kernel is changing DDR_SDRAM_CFG ? When our linux-2.6.28 kernel is up, it's still 0xc308 when I read physical address 0xe0002110. Hi Norbert, thank you for your fast reply! You are absolutly right! I made a silly mistake. I've read the value of the 0xe0002110 with a 8bit pointer. The value is actually 0xC310 which means the 16bit bus width is set. Just to be sure. Is this the only change (in the bootloader) I have to make that all data accesses are 16bit wide? Btw. We did some performance tests with 16 bit bus-width (DDR2 memory) and surprisingly performance was almost as good as 32 bit bus-width This is exactly our intention to test. Thanks for that hint. Very good to know! Thank you. Best regards Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/86xx: Update GE Fanuc sbc310 DTS
Update GE Fanuc DTS to match the alterations suggested during the merge of the
ppc9a DTS in commit 740d36ae6344f38c4da64c2ede765d7d2dd1f132
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/boot/dts/gef_sbc310.dts | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts
b/arch/powerpc/boot/dts/gef_sbc310.dts
index 7810ea9..2107d3c 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -83,34 +83,34 @@
/* fl...@0,0 is a mirror of part of the memory in fl...@1,0
fl...@0,0 {
- compatible = cfi-flash;
- reg = 0 0 0x0100;
+ compatible = gef,sbc310-firmware-mirror, cfi-flash;
+ reg = 0x0 0x0 0x0100;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = firmware;
- reg = 0x 0x0100;
+ reg = 0x0 0x0100;
read-only;
};
};
*/
fl...@1,0 {
- compatible = cfi-flash;
- reg = 1 0 0x800;
+ compatible = gef,sbc310-paged-flash, cfi-flash;
+ reg = 0x1 0x0 0x800;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
partit...@0 {
label = user;
- reg = 0x 0x0780;
+ reg = 0x0 0x780;
};
partit...@780 {
label = firmware;
- reg = 0x0780 0x0080;
+ reg = 0x780 0x80;
read-only;
};
};
@@ -121,18 +121,16 @@
};
w...@4,2000 {
- #interrupt-cells = 2;
- device_type = watchdog;
- compatible = gef,fpga-wdt;
+ compatible = gef,sbc310-fpga-wdt, gef,fpga-wdt-1.00,
+ gef,fpga-wdt;
reg = 0x4 0x2000 0x8;
interrupts = 0x1a 0x4;
interrupt-parent = gef_pic;
};
/*
w...@4,2010 {
- #interrupt-cells = 2;
- device_type = watchdog;
- compatible = gef,fpga-wdt;
+ compatible = gef,sbc310-fpga-wdt, gef,fpga-wdt-1.00,
+ gef,fpga-wdt;
reg = 0x4 0x2010 0x8;
interrupts = 0x1b 0x4;
interrupt-parent = gef_pic;
@@ -141,7 +139,7 @@
gef_pic: p...@4,4000 {
#interrupt-cells = 1;
interrupt-controller;
- compatible = gef,fpga-pic;
+ compatible = gef,sbc310-fpga-pic, gef,fpga-pic;
reg = 0x4 0x4000 0x20;
interrupts = 0x8
0x9;
@@ -161,7 +159,7 @@
#size-cells = 1;
#interrupt-cells = 2;
device_type = soc;
- compatible = simple-bus;
+ compatible = fsl,mpc8641-soc, simple-bus;
ranges = 0x0 0xfef0 0x0010;
bus-frequency = ;
@@ -412,5 +410,4 @@
0x0 0x0040;
};
};
-
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/86xx: Update defconfig for GE Fanuc's PPC9A
General update of defconfig including the following notable changes: - Enable GPIO access via sysfs on GE Fanuc's PPC9A. - Enable Highmem support. - Support for PCMCIA based daughter card. Signed-off-by: Martyn Welch martyn.we...@gefanuc.com --- arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 518 + 1 files changed, 196 insertions(+), 322 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig index b6a23af..d8354d9 100644 --- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig +++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig @@ -1,26 +1,28 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc3 -# Wed May 13 17:22:31 2009 +# Linux kernel version: 2.6.30 +# Thu Jul 2 13:55:24 2009 # # CONFIG_PPC64 is not set # # Processor support # -CONFIG_6xx=y +CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y +CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_PHYS_64BIT is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set +CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PPC32=y @@ -32,6 +34,7 @@ CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y @@ -41,7 +44,6 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set @@ -56,11 +58,13 @@ CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y +CONFIG_DTC=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -112,9 +116,7 @@ CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y -# CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -127,8 +129,15 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_COUNTERS=y + +# +# Performance Counters +# +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set @@ -143,6 +152,10 @@ CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y + +# +# GCOV-based kernel profiling +# # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y @@ -156,7 +169,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -216,7 +229,7 @@ CONFIG_MPIC=y # # Kernel options # -# CONFIG_HIGHMEM is not set +CONFIG_HIGHMEM=y CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y @@ -235,6 +248,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=m # CONFIG_IOMMU_HELPER is not set +# CONFIG_SWIOTLB is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y @@ -256,9 +270,9 @@ CONFIG_MIGRATION=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y -CONFIG_UNEVICTABLE_LRU=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set @@ -285,14 +299,32 @@ CONFIG_PCI_DOMAINS=y CONFIG_PCI_SYSCALL=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y +# CONFIG_PCIE_ECRC is not set +# CONFIG_PCIEAER_INJECT is not set # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY is not set -CONFIG_PCI_DEBUG=y # CONFIG_PCI_STUB is not set # CONFIG_PCI_IOV is not set -# CONFIG_PCCARD is not set +CONFIG_PCCARD=y +# CONFIG_PCMCIA_DEBUG is not set +CONFIG_PCMCIA=y +# CONFIG_PCMCIA_LOAD_CIS is not set +# CONFIG_PCMCIA_IOCTL is not set +# CONFIG_CARDBUS is not set + +# +# PC-card bridges +# +CONFIG_YENTA=y +# CONFIG_YENTA_O2 is not set +# CONFIG_YENTA_RICOH is not set +CONFIG_YENTA_TI=y +# CONFIG_YENTA_TOSHIBA is not set +# CONFIG_PD6729 is not set +# CONFIG_I82092 is not set +CONFIG_PCCARD_NONSTATIC=y # CONFIG_HOTPLUG_PCI is not set # CONFIG_HAS_RAPIDIO is not set @@ -353,8 +385,8 @@ CONFIG_INET_XFRM_TUNNEL=m
[PATCH] powerpc/86xx: Update GE Fanuc sbc310 default configuration
General update of defconfig including the following notable changes: - Enable Highmem support. - Support for PCMCIA based daughter card. Signed-off-by: Martyn Welch martyn.we...@gefanuc.com --- arch/powerpc/configs/86xx/gef_sbc310_defconfig | 213 +--- 1 files changed, 154 insertions(+), 59 deletions(-) diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig b/arch/powerpc/configs/86xx/gef_sbc310_defconfig index a66910e..f2362e5 100644 --- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig +++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig @@ -1,26 +1,28 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc3 -# Wed May 13 17:22:29 2009 +# Linux kernel version: 2.6.30 +# Thu Jul 2 14:10:12 2009 # # CONFIG_PPC64 is not set # # Processor support # -CONFIG_6xx=y +CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y +CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_PHYS_64BIT is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set +CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PPC32=y @@ -32,6 +34,7 @@ CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y @@ -41,7 +44,6 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set @@ -56,11 +58,13 @@ CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y +CONFIG_DTC=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -91,7 +95,11 @@ CONFIG_CLASSIC_RCU=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 -# CONFIG_GROUP_SCHED is not set +CONFIG_GROUP_SCHED=y +CONFIG_FAIR_GROUP_SCHED=y +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y @@ -109,7 +117,6 @@ CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -122,8 +129,15 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_COUNTERS=y + +# +# Performance Counters +# +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set @@ -138,6 +152,10 @@ CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y + +# +# GCOV-based kernel profiling +# # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y @@ -151,7 +169,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set @@ -168,7 +186,6 @@ CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_FREEZER is not set -CONFIG_PPC_MSI_BITMAP=y # # Platform support @@ -212,7 +229,7 @@ CONFIG_MPIC=y # # Kernel options # -# CONFIG_HIGHMEM is not set +CONFIG_HIGHMEM=y CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y @@ -231,6 +248,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y # CONFIG_IOMMU_HELPER is not set +# CONFIG_SWIOTLB is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y @@ -252,9 +270,9 @@ CONFIG_MIGRATION=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y -CONFIG_UNEVICTABLE_LRU=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set @@ -281,13 +299,32 @@ CONFIG_PCI_DOMAINS=y CONFIG_PCI_SYSCALL=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y +# CONFIG_PCIE_ECRC is not set +# CONFIG_PCIEAER_INJECT is not set # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y -CONFIG_PCI_MSI=y +# CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY is not set # CONFIG_PCI_STUB is not set # CONFIG_PCI_IOV is not set -# CONFIG_PCCARD is not set +CONFIG_PCCARD=y +# CONFIG_PCMCIA_DEBUG is not set +CONFIG_PCMCIA=y +#
Re: RAMDISK on EP88xc
Mikhail Zaturenskiy wrote: On Thu, Jul 2, 2009 at 2:10 AM, Frank Svendsbøefrank.svends...@gmail.com wrote: On Wed, Jul 1, 2009 at 10:14 PM, Mikhail Zaturenskiymzaturenskiy...@gmail.com wrote: Hmm... according to Kernel command line: console=ttyCPM0,9600n8 loglevel=7 you haven't specified where root is. Add root=/dev/ram to the kernel command line, and specify where the init process is located (for instance init=/sbin/init). I haven't tried Denks ramdisk image. You can create one for yourself using dd, gzip and U-Boots mkimage tool. If the ramdisk image is larger than 4MB, you must either change the default CONFIG_BLK_DEV_RAM_SIZE=4096, or set ramdisk size in the kernel command line. Btw, I use an older kernel than you use, but I have these defined: CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 Maybe they're obsolete now, but you can try to add them to your defconfig file. Good luck ;-) Thanks Frank, this seems to be leading me down the right path. I tried some of those defines out yesterday and they got the kernel to at least attempt to load the ramdisk, so I'm getting somewhere. Also added root=/dev/ram (also tried /dev/ram0) and init=/sbin/init but for now things are failing before processing those args. I haven't tried CONFIG_BLK_DEV or CONFIG_BLK_DEV_LOOP and am still playing around with the values for CONFIG_BLK_DEV_RAM_COUNT and CONFIG_BLK_DEV_RAM_SIZE. Strangely, the DEV_RAM defines are completely missing from my config so I have to put them in manually... (as opposed to via menuconfig). I'll post back when it's working or when I've tried all of this and still am getting some error. If you don't have CONFIG_BLK_DEV defined, you can't have CONFIG_BLK_DEV_RAM_COUNT or CONFIG_BLK_DEV_RAM_SIZE. Use 'menuconfig' to help straighten this out. Meanwhile a side question - why does BLK_DEV_RAM_COUNT default to 16? This is just the number of unique RAM disk devices supported. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/5] Generic NVRAM support for large MMIO devices
The following series allows the generic NVRAM driver to access MMIO based NVRAMs. In addition it enables support for NVRAMs of sizes differing from those found on PowerPC Macs (providing a safe fallback). Patches are also included to enable support for the NVRAM found on the GE Fanuc PPC9A, SBC310 and SBC610. If this patch series is unsuitable this late in the day for 2.6.31, please concider it for 2.6.32. Martyn -- Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748 GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square, Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/5] Allow byte length reads from mmio NVRAM driver
Add a byte length read and write interface compatible with the nvram_generic
driver interface to the mmio driver.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/sysdev/mmio_nvram.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mmio_nvram.c b/arch/powerpc/sysdev/mmio_nvram.c
index 7b49633..2073242 100644
--- a/arch/powerpc/sysdev/mmio_nvram.c
+++ b/arch/powerpc/sysdev/mmio_nvram.c
@@ -53,6 +53,23 @@ static ssize_t mmio_nvram_read(char *buf, size_t count,
loff_t *index)
return count;
}
+static unsigned char mmio_nvram_read_val(int addr)
+{
+ unsigned long flags;
+ unsigned char val;
+
+ if (addr = mmio_nvram_len)
+ return 0xff;
+
+ spin_lock_irqsave(mmio_nvram_lock, flags);
+
+ val = ioread8(mmio_nvram_start + addr);
+
+ spin_unlock_irqrestore(mmio_nvram_lock, flags);
+
+ return val;
+}
+
static ssize_t mmio_nvram_write(char *buf, size_t count, loff_t *index)
{
unsigned long flags;
@@ -72,6 +89,19 @@ static ssize_t mmio_nvram_write(char *buf, size_t count,
loff_t *index)
return count;
}
+void mmio_nvram_write_val(int addr, unsigned char val)
+{
+ unsigned long flags;
+
+ if (addr mmio_nvram_len) {
+ spin_lock_irqsave(mmio_nvram_lock, flags);
+
+ iowrite8(val, mmio_nvram_start + addr);
+
+ spin_unlock_irqrestore(mmio_nvram_lock, flags);
+ }
+}
+
static ssize_t mmio_nvram_get_size(void)
{
return mmio_nvram_len;
@@ -114,6 +144,8 @@ int __init mmio_nvram_init(void)
printk(KERN_INFO mmio NVRAM, %luk at 0x%lx mapped to %p\n,
mmio_nvram_len 10, nvram_addr, mmio_nvram_start);
+ ppc_md.nvram_read_val = mmio_nvram_read_val;
+ ppc_md.nvram_write_val = mmio_nvram_write_val;
ppc_md.nvram_read = mmio_nvram_read;
ppc_md.nvram_write = mmio_nvram_write;
ppc_md.nvram_size = mmio_nvram_get_size;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/5] Mechanism to enable use Generic NVRAM driver for different size chips
Remove the reliance on a staticly defined NVRAM size, allowing platforms to
support NVRAMs with sizes differing from the standard. A fall back value is
provided for platforms not supporting this extension.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/include/asm/nvram.h |3 +++
arch/powerpc/kernel/setup_32.c |8
drivers/char/generic_nvram.c | 27 ---
3 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/nvram.h b/arch/powerpc/include/asm/nvram.h
index efde5ac..71df8b2 100644
--- a/arch/powerpc/include/asm/nvram.h
+++ b/arch/powerpc/include/asm/nvram.h
@@ -107,6 +107,9 @@ extern void pmac_xpram_write(int xpaddr, u8 data);
/* Synchronize NVRAM */
extern voidnvram_sync(void);
+/* Determine NVRAM size */
+extern ssize_t nvram_size(void);
+
/* Normal access to NVRAM */
extern unsigned char nvram_read_byte(int i);
extern void nvram_write_byte(unsigned char c, int i);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 1d15424..28f7570 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -208,6 +208,14 @@ void nvram_write_byte(unsigned char val, int addr)
}
EXPORT_SYMBOL(nvram_write_byte);
+ssize_t nvram_size(void)
+{
+ if (ppc_md.nvram_size)
+ return ppc_md.nvram_size();
+ return -1;
+}
+EXPORT_SYMBOL(nvram_size);
+
void nvram_sync(void)
{
if (ppc_md.nvram_sync)
diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
index a00869c..e5f71f3 100644
--- a/drivers/char/generic_nvram.c
+++ b/drivers/char/generic_nvram.c
@@ -2,7 +2,7 @@
* Generic /dev/nvram driver for architectures providing some
* generic hooks, that is :
*
- * nvram_read_byte, nvram_write_byte, nvram_sync
+ * nvram_read_byte, nvram_write_byte, nvram_sync, nvram_size
*
* Note that an additional hook is supported for PowerMac only
* for getting the nvram partition informations
@@ -28,6 +28,8 @@
#define NVRAM_SIZE 8192
+static ssize_t nvram_len;
+
static loff_t nvram_llseek(struct file *file, loff_t offset, int origin)
{
lock_kernel();
@@ -36,7 +38,7 @@ static loff_t nvram_llseek(struct file *file, loff_t offset,
int origin)
offset += file-f_pos;
break;
case 2:
- offset += NVRAM_SIZE;
+ offset += nvram_len;
break;
}
if (offset 0) {
@@ -56,9 +58,9 @@ static ssize_t read_nvram(struct file *file, char __user *buf,
if (!access_ok(VERIFY_WRITE, buf, count))
return -EFAULT;
- if (*ppos = NVRAM_SIZE)
+ if (*ppos = nvram_len)
return 0;
- for (i = *ppos; count 0 i NVRAM_SIZE; ++i, ++p, --count)
+ for (i = *ppos; count 0 i nvram_len; ++i, ++p, --count)
if (__put_user(nvram_read_byte(i), p))
return -EFAULT;
*ppos = i;
@@ -74,9 +76,9 @@ static ssize_t write_nvram(struct file *file, const char
__user *buf,
if (!access_ok(VERIFY_READ, buf, count))
return -EFAULT;
- if (*ppos = NVRAM_SIZE)
+ if (*ppos = nvram_len)
return 0;
- for (i = *ppos; count 0 i NVRAM_SIZE; ++i, ++p, --count) {
+ for (i = *ppos; count 0 i nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
nvram_write_byte(c, i);
@@ -133,9 +135,20 @@ static struct miscdevice nvram_dev = {
int __init nvram_init(void)
{
+ int ret = 0;
+
printk(KERN_INFO Generic non-volatile memory driver v%s\n,
NVRAM_VERSION);
- return misc_register(nvram_dev);
+ ret = misc_register(nvram_dev);
+ if (ret != 0)
+ goto out;
+
+ nvram_len = nvram_size();
+ if (nvram_len 0)
+ nvram_len = NVRAM_SIZE;
+
+out:
+ return ret;
}
void __exit nvram_cleanup(void)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/5] powerpc/86xx: Support for NVRAM on GE Fanuc's PPC9A
Add support for NVRAM on GE Fanuc's PPC9A.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/boot/dts/gef_ppc9a.dts |6 ++
arch/powerpc/configs/86xx/gef_ppc9a_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig |1 +
arch/powerpc/platforms/86xx/gef_ppc9a.c |5 +
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts
b/arch/powerpc/boot/dts/gef_ppc9a.dts
index 910944e..c86114e 100644
--- a/arch/powerpc/boot/dts/gef_ppc9a.dts
+++ b/arch/powerpc/boot/dts/gef_ppc9a.dts
@@ -118,6 +118,12 @@
};
};
+ nv...@3,0 {
+ device_type = nvram;
+ compatible = simtek,stk14ca8;
+ reg = 0x3 0x0 0x2;
+ };
+
f...@4,0 {
compatible = gef,ppc9a-fpga-regs;
reg = 0x4 0x0 0x40;
diff --git a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
index d8354d9..e175abf 100644
--- a/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
+++ b/arch/powerpc/configs/86xx/gef_ppc9a_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30
-# Thu Jul 2 13:55:24 2009
+# Thu Jul 2 13:59:13 2009
#
# CONFIG_PPC64 is not set
@@ -214,7 +214,7 @@ CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
-# CONFIG_MMIO_NVRAM is not set
+CONFIG_MMIO_NVRAM=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 6012022..2bbfd53 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -35,6 +35,7 @@ config MPC8610_HPCD
config GEF_PPC9A
bool GE Fanuc PPC9A
select DEFAULT_UIMAGE
+ select MMIO_NVRAM
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
diff --git a/arch/powerpc/platforms/86xx/gef_ppc9a.c
b/arch/powerpc/platforms/86xx/gef_ppc9a.c
index 287f7bd..a792e5d 100644
--- a/arch/powerpc/platforms/86xx/gef_ppc9a.c
+++ b/arch/powerpc/platforms/86xx/gef_ppc9a.c
@@ -33,6 +33,7 @@
#include asm/udbg.h
#include asm/mpic.h
+#include asm/nvram.h
#include sysdev/fsl_pci.h
#include sysdev/fsl_soc.h
@@ -95,6 +96,10 @@ static void __init gef_ppc9a_setup_arch(void)
printk(KERN_WARNING Unable to map board registers\n);
of_node_put(regs);
}
+
+#if defined(CONFIG_MMIO_NVRAM)
+ mmio_nvram_init();
+#endif
}
/* Return the PCB revision */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/5] powerpc/86xx: Enable NVRAM on GE Fanuc's SBC610
This patch enables the NVRAM found on the GE Fanuc SBC610
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/boot/dts/gef_sbc610.dts |6 ++
arch/powerpc/configs/86xx/gef_sbc610_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig|1 +
arch/powerpc/platforms/86xx/gef_sbc610.c |5 +
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts
b/arch/powerpc/boot/dts/gef_sbc610.dts
index 35a6318..30911ad 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -84,6 +84,12 @@
6 0 0xfd00 0x0080 // IO FPGA (8-bit)
7 0 0xfd80 0x0080; // IO FPGA (32-bit)
+ nv...@3,0 {
+ device_type = nvram;
+ compatible = simtek,stk14ca8;
+ reg = 0x3 0x0 0x2;
+ };
+
f...@4,0 {
compatible = gef,fpga-regs;
reg = 0x4 0x0 0x40;
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index c6a7fc8..b4a7c03 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -201,7 +201,7 @@ CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
-# CONFIG_MMIO_NVRAM is not set
+CONFIG_MMIO_NVRAM=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
@@ -1083,7 +1083,7 @@ CONFIG_UNIX98_PTYS=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
-# CONFIG_NVRAM is not set
+CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_RAW_DRIVER is not set
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 9c7b64a..9d02dea 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -51,6 +51,7 @@ config GEF_SBC310
config GEF_SBC610
bool GE Fanuc SBC610
select DEFAULT_UIMAGE
+ select MMIO_NVRAM
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
select HAS_RAPIDIO
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c
b/arch/powerpc/platforms/86xx/gef_sbc610.c
index 72b31a6..e10688a 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -33,6 +33,7 @@
#include asm/udbg.h
#include asm/mpic.h
+#include asm/nvram.h
#include sysdev/fsl_pci.h
#include sysdev/fsl_soc.h
@@ -95,6 +96,10 @@ static void __init gef_sbc610_setup_arch(void)
printk(KERN_WARNING Unable to map board registers\n);
of_node_put(regs);
}
+
+#if defined(CONFIG_MMIO_NVRAM)
+ mmio_nvram_init();
+#endif
}
/* Return the PCB revision */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/5] powerpc/86xx: Support for NVRAM on GE Fanuc's SBC310
Add support for NVRAM on GE Fanuc's SBC310.
Signed-off-by: Martyn Welch martyn.we...@gefanuc.com
---
arch/powerpc/boot/dts/gef_sbc310.dts |6 ++
arch/powerpc/configs/86xx/gef_sbc310_defconfig |4 ++--
arch/powerpc/platforms/86xx/Kconfig|1 +
arch/powerpc/platforms/86xx/gef_sbc310.c |5 +
4 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts
b/arch/powerpc/boot/dts/gef_sbc310.dts
index 2107d3c..820c2b3 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -115,6 +115,12 @@
};
};
+ nv...@3,0 {
+ device_type = nvram;
+ compatible = simtek,stk14ca8;
+ reg = 0x3 0x0 0x2;
+ };
+
f...@4,0 {
compatible = gef,fpga-regs;
reg = 0x4 0x0 0x40;
diff --git a/arch/powerpc/configs/86xx/gef_sbc310_defconfig
b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
index f2362e5..3d70f2a 100644
--- a/arch/powerpc/configs/86xx/gef_sbc310_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc310_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30
-# Thu Jul 2 14:10:12 2009
+# Thu Jul 2 14:10:51 2009
#
# CONFIG_PPC64 is not set
@@ -214,7 +214,7 @@ CONFIG_MPIC=y
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
# CONFIG_PPC_RTAS is not set
-# CONFIG_MMIO_NVRAM is not set
+CONFIG_MMIO_NVRAM=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_PPC_970_NAP is not set
# CONFIG_PPC_INDIRECT_IO is not set
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 9d02dea..6012022 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -43,6 +43,7 @@ config GEF_PPC9A
config GEF_SBC310
bool GE Fanuc SBC310
select DEFAULT_UIMAGE
+ select MMIO_NVRAM
select GENERIC_GPIO
select ARCH_REQUIRE_GPIOLIB
help
diff --git a/arch/powerpc/platforms/86xx/gef_sbc310.c
b/arch/powerpc/platforms/86xx/gef_sbc310.c
index 90754e7..6a1a613 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc310.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc310.c
@@ -33,6 +33,7 @@
#include asm/udbg.h
#include asm/mpic.h
+#include asm/nvram.h
#include sysdev/fsl_pci.h
#include sysdev/fsl_soc.h
@@ -95,6 +96,10 @@ static void __init gef_sbc310_setup_arch(void)
printk(KERN_WARNING Unable to map board registers\n);
of_node_put(regs);
}
+
+#if defined(CONFIG_MMIO_NVRAM)
+ mmio_nvram_init();
+#endif
}
/* Return the PCB revision */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
I haven't tried CONFIG_BLK_DEV or CONFIG_BLK_DEV_LOOP and am still playing around with the values for CONFIG_BLK_DEV_RAM_COUNT and CONFIG_BLK_DEV_RAM_SIZE. Strangely, the DEV_RAM defines are completely missing from my config so I have to put them in manually... (as opposed to via menuconfig). I'll post back when it's working or when I've tried all of this and still am getting some error. If you don't have CONFIG_BLK_DEV defined, you can't have CONFIG_BLK_DEV_RAM_COUNT or CONFIG_BLK_DEV_RAM_SIZE. Use 'menuconfig' to help straighten this out. Meanwhile a side question - why does BLK_DEV_RAM_COUNT default to 16? This is just the number of unique RAM disk devices supported. I see, thanks Gary, I'll leave that unmodified then. I only really need 1 but it doesn't seem to negatively affect anything if I leave it at 16. Just as an intermediate update on the issue, I've made progress and it hangs later down the line, see below: Using Embedded Planet EP88xC machine description Linux version 2.6.30-rc2-01402-gd4e2f68-dirty (dev...@localhost.localdomain) (gc c version 4.2.2) #3 Thu Jul 2 11:00:54 CDT 2009 Found initrd at 0xc3dbb000:0xc3f6d056 Zone PFN ranges: DMA 0x - 0x4000 Normal 0x4000 - 0x4000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x4000 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram loglevel=7 init=/sbin/ init NR_IRQS:512 PID hash table entries: 256 (order: 8, 1024 bytes) Decrementer Frequency = 0x5f5e10 clocksource: timebase mult[2800] shift[22] registered console [ttyCPM0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 60716k/65536k available (2136k kernel code, 4752k reserved, 100k data, 9 9k bss, 112k init) SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 12.39 BogoMIPS (lpj=61952) Mount-cache hash table entries: 512 net_namespace: 296 bytes NET: Registered protocol family 16 bio: create slab bio-0 at 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 1736k freed msgmni has been set to 122 io scheduler noop registered io scheduler deadline registered (default) Generic RTC Driver v1.07 fa80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART fa20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART brd: module loaded loop: module loaded eth0: fs_enet: 00:00:00:00:00:00 eth1: fs_enet: 00:00:00:00:00:00 FEC MII Bus: probed fe00.flash: Found 2 x16 devices at 0x0 in 32-bit bank Amd/Fujitsu Extended Query Table at 0x0040 fe00.flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 112k init Now searching for cause, looks like it's init related... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] ASoC: Fix mpc5200-psc-ac97 to ensure the data ready bit is cleared
From: Grant Likely grant.lik...@secretlab.ca When doing register reads, it is possible for there to be a stale data ready bit set which will cause subsequent reads to return prematurely with incorrect data. This patch fixes the issues by ensuring stale data is cleared before starting another transaction. Signed-off-by: Grant Likely grant.lik...@secretlab.ca --- sound/soc/fsl/mpc5200_psc_ac97.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 794a247..9b8503f 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -41,6 +41,10 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) pr_err(timeout on ac97 bus (rdy)\n); return -ENODEV; } + + /* Force clear the data valid bit */ + in_be32(psc_dma-psc_regs-ac97_data); + /* Send the read */ out_be32(psc_dma-psc_regs-ac97_cmd, (131) | ((reg 0x7f) 24)); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
From: Grant Likely grant.lik...@secretlab.ca
AC97 bus register read/write hooks need to provide locking, but the
mpc5200-psc-ac97 driver does not. This patch adds a mutex around
the register access routines.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
sound/soc/fsl/mpc5200_dma.c |1 +
sound/soc/fsl/mpc5200_dma.h |1 +
sound/soc/fsl/mpc5200_psc_ac97.c | 13 -
3 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index efec33a..f0a2d40 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
return -ENODEV;
spin_lock_init(psc_dma-lock);
+ mutex_init(psc_dma-mutex);
psc_dma-id = be32_to_cpu(*prop);
psc_dma-irq = irq;
psc_dma-psc_regs = regs;
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 2000803..8d396bb 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -55,6 +55,7 @@ struct psc_dma {
unsigned int irq;
struct device *dev;
spinlock_t lock;
+ struct mutex mutex;
u32 sicr;
uint sysclk;
int imr;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index 9b8503f..7eb5499 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97,
unsigned short reg)
int status;
unsigned int val;
+ mutex_lock(psc_dma-mutex);
+
/* Wait for command send status zero = ready */
status =
spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err(timeout on ac97 bus (rdy)\n);
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
@@ -54,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97,
unsigned short reg)
if (status == 0) {
pr_err(timeout on ac97 read (val) %x\n,
in_be16(psc_dma-psc_regs-sr_csr.status));
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
/* Get the data */
val = in_be32(psc_dma-psc_regs-ac97_data);
if (((val 24) 0x7f) != reg) {
pr_err(reg echo error on ac97 read\n);
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
val = (val 8) 0x;
+ mutex_unlock(psc_dma-mutex);
return (unsigned short) val;
}
@@ -72,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
{
int status;
+ mutex_lock(psc_dma-mutex);
+
/* Wait for command status zero = ready */
status =
spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err(timeout on ac97 bus (write)\n);
- return;
+ goto out;
}
/* Write data */
out_be32(psc_dma-psc_regs-ac97_cmd,
((reg 0x7f) 24) | (val 8));
+
+ out:
+ mutex_unlock(psc_dma-mutex);
}
static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: ppc405ex + gigabit ethernet
Yes. If you enable jumbo frames, the results will be definitely better. My result is with jumbo frame of 8982 enabled. If you say your CPU is 600 MHz, I guess there is still potential for you to improve the speed. In our case we had only 300 MHz and got a similar value of yours. Of course, there are many other issues which can be enabled to improve the performance, such as interrupt coaleasing, hardware checksum processing, etc.. Since we used Xilinx FPGA with embedded PowerPC and HW TEMAC, some work can be done with FPGA hardware resources. I don't know your case and it's hard to say how can you further improve. BR Ming Date: Wed, 1 Jul 2009 13:24:41 +0200 Subject: Re: ppc405ex + gigabit ethernet From: lada.podi...@gmail.com To: eeming...@hotmail.com CC: linuxppc-...@ozlabs.org Thank you for your reply! Yes, I agree the CPU is the bottleneck. But I have performed more tests with the netperf tool and results seem strange to me. If I send 800 B of data, the resulting speed is aproximately 100 Kb/s. On the other hand, If I try to send 32KB chunk of data with jumbo frames turned on, resulting speed is about 600 Kb/s (300-400 without jumbo frames). My ppc405ex runs at 600 MHz. So it seems that it is definetely better idea to call sendto() less frequently with bigger amounts of data, than to call it more often with smaler amounts. Is it because smaller data means more frequent user space/kernel space switching? Or is it network related issue? Thanks! Best, Lada 2009/7/1 LiuMing eeming...@hotmail.com Hi, According to our experience on PPC405 + Gigabit Enet, your result is already very reasonable. For UDP transmission, it can be around 400 Kb/s because of the CPU bottleneck (in our case 300 MHz ppc405). If you want to further improve it, a faster CPU is needed to process the TCP/IP stack, or you may buy commercial TCP/IP stack rather than using the free Linux one. BR Ming Date: Tue, 30 Jun 2009 15:58:53 +0200 Subject: ppc405ex + gigabit ethernet From: lada.podi...@gmail.com To: linuxppc-...@ozlabs.org Hi, I benchmarked performance of my network, which contains ppc405EX (Kilauea board, kernel 2.6.30 from Denx) connected with a linux desktop via gigabit ethernet. I used the netperf tool: netperf -t UDP_STREAM -H 192.168.1.1 -- -m 32768 So I was sending UDP packets to the desktop. The resulting speed was about 370 Kb/s. I tried to send the packets to several different computers - with the same result. So the ppc board is the bottleneck in this case. Is there any possibility to improve the gigabit capabilities of the ppc405EX? Is there anyone who achieved a better performance with ppc4xx boards? Thanks! Best, Lada Podivin 立刻下载 MSN 保护盾，保障 MSN 安全稳定！ 现在就下载！ _ Messenger安全保护中心，免费修复系统漏洞，保护Messenger安全！ http://im.live.cn/safe/___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
Just as an intermediate update on the issue, I've made progress and it hangs later down the line, see below: Using Embedded Planet EP88xC machine description Linux version 2.6.30-rc2-01402-gd4e2f68-dirty (dev...@localhost.localdomain) (gc c version 4.2.2) #3 Thu Jul 2 11:00:54 CDT 2009 Found initrd at 0xc3dbb000:0xc3f6d056 Zone PFN ranges: DMA 0x - 0x4000 Normal 0x4000 - 0x4000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x4000 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram loglevel=7 init=/sbin/ init NR_IRQS:512 PID hash table entries: 256 (order: 8, 1024 bytes) Decrementer Frequency = 0x5f5e10 clocksource: timebase mult[2800] shift[22] registered console [ttyCPM0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 60716k/65536k available (2136k kernel code, 4752k reserved, 100k data, 9 9k bss, 112k init) SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 12.39 BogoMIPS (lpj=61952) Mount-cache hash table entries: 512 net_namespace: 296 bytes NET: Registered protocol family 16 bio: create slab bio-0 at 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 1736k freed msgmni has been set to 122 io scheduler noop registered io scheduler deadline registered (default) Generic RTC Driver v1.07 fa80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART fa20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART brd: module loaded loop: module loaded eth0: fs_enet: 00:00:00:00:00:00 eth1: fs_enet: 00:00:00:00:00:00 FEC MII Bus: probed fe00.flash: Found 2 x16 devices at 0x0 in 32-bit bank Amd/Fujitsu Extended Query Table at 0x0040 fe00.flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 112k init Now searching for cause, looks like it's init related... Wow... I just found out that it's not actually hanging at this point.. it's just working in slow motion... I found out by leaving the machine and coming back half an hour later to find additional output and eventually even a prompt. Here is what's happening: * RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing unused kernel memory: 112k init 4 minutes pass init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST) 2 minutes pass starting pid 403, tty '': '/etc/rc.sh' etc... * I've tried a couple different ramdisk images (another one with a much older version of busybox), with similar results. Anybody have an idea about what's going on here? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ASoC: Fix mpc5200-psc-ac97 to ensure the data ready bit is cleared
On Thu, Jul 2, 2009 at 1:57 PM, Grant Likelygrant.lik...@secretlab.ca wrote: From: Grant Likely grant.lik...@secretlab.ca When doing register reads, it is possible for there to be a stale data ready bit set which will cause subsequent reads to return prematurely with incorrect data. This patch fixes the issues by ensuring stale data is cleared before starting another transaction. Signed-off-by: Grant Likely grant.lik...@secretlab.ca Acked-by: Jon Smirl jonsm...@gmail.com --- sound/soc/fsl/mpc5200_psc_ac97.c | 4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c index 794a247..9b8503f 100644 --- a/sound/soc/fsl/mpc5200_psc_ac97.c +++ b/sound/soc/fsl/mpc5200_psc_ac97.c @@ -41,6 +41,10 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97, unsigned short reg) pr_err(timeout on ac97 bus (rdy)\n); return -ENODEV; } + + /* Force clear the data valid bit */ + in_be32(psc_dma-psc_regs-ac97_data); + /* Send the read */ out_be32(psc_dma-psc_regs-ac97_cmd, (131) | ((reg 0x7f) 24)); -- Jon Smirl jonsm...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
Here is what's happening: * RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing unused kernel memory: 112k init 4 minutes pass init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST) 2 minutes pass starting pid 403, tty '': '/etc/rc.sh' etc... * went out to lunch for 20 minutes, new output on screen: * Freeing unused kernel memory: 112k init init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST) starting pid 403, tty '': '/etc/rc.sh' starting pid 408, tty '': '/bin/application' starting pid 409, tty '': '/bin/sh' ### Application running ... process '/bin/application' (pid 408) exited. Scheduling it for restart. starting pid 411, tty '': '/bin/application * ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
On Thu, Jul 2, 2009 at 1:57 PM, Grant Likelygrant.lik...@secretlab.ca wrote:
From: Grant Likely grant.lik...@secretlab.ca
AC97 bus register read/write hooks need to provide locking, but the
mpc5200-psc-ac97 driver does not. This patch adds a mutex around
the register access routines.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Acked-by: Jon Smirl jonsm...@gmail.com
---
sound/soc/fsl/mpc5200_dma.c | 1 +
sound/soc/fsl/mpc5200_dma.h | 1 +
sound/soc/fsl/mpc5200_psc_ac97.c | 13 -
3 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index efec33a..f0a2d40 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
return -ENODEV;
spin_lock_init(psc_dma-lock);
+ mutex_init(psc_dma-mutex);
psc_dma-id = be32_to_cpu(*prop);
psc_dma-irq = irq;
psc_dma-psc_regs = regs;
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 2000803..8d396bb 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -55,6 +55,7 @@ struct psc_dma {
unsigned int irq;
struct device *dev;
spinlock_t lock;
+ struct mutex mutex;
u32 sicr;
uint sysclk;
int imr;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c
b/sound/soc/fsl/mpc5200_psc_ac97.c
index 9b8503f..7eb5499 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97
*ac97, unsigned short reg)
int status;
unsigned int val;
+ mutex_lock(psc_dma-mutex);
+
/* Wait for command send status zero = ready */
status =
spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err(timeout on ac97 bus (rdy)\n);
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
@@ -54,16 +57,19 @@ static unsigned short psc_ac97_read(struct snd_ac97
*ac97, unsigned short reg)
if (status == 0) {
pr_err(timeout on ac97 read (val) %x\n,
in_be16(psc_dma-psc_regs-sr_csr.status));
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
/* Get the data */
val = in_be32(psc_dma-psc_regs-ac97_data);
if (((val 24) 0x7f) != reg) {
pr_err(reg echo error on ac97 read\n);
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
}
val = (val 8) 0x;
+ mutex_unlock(psc_dma-mutex);
return (unsigned short) val;
}
@@ -72,16 +78,21 @@ static void psc_ac97_write(struct snd_ac97 *ac97,
{
int status;
+ mutex_lock(psc_dma-mutex);
+
/* Wait for command status zero = ready */
status =
spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err(timeout on ac97 bus (write)\n);
- return;
+ goto out;
}
/* Write data */
out_be32(psc_dma-psc_regs-ac97_cmd,
((reg 0x7f) 24) | (val 8));
+
+ out:
+ mutex_unlock(psc_dma-mutex);
}
static void psc_ac97_warm_reset(struct snd_ac97 *ac97)
--
Jon Smirl
jonsm...@gmail.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] ASoC: add locking to mpc5200-psc-ac97 driver
Hi,
Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
AC97 bus register read/write hooks need to provide locking, but the
mpc5200-psc-ac97 driver does not. This patch adds a mutex around
the register access routines.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
sound/soc/fsl/mpc5200_dma.c |1 +
sound/soc/fsl/mpc5200_dma.h |1 +
sound/soc/fsl/mpc5200_psc_ac97.c | 13 -
3 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index efec33a..f0a2d40 100644
--- a/sound/soc/fsl/mpc5200_dma.c
+++ b/sound/soc/fsl/mpc5200_dma.c
@@ -456,6 +456,7 @@ int mpc5200_audio_dma_create(struct of_device *op)
return -ENODEV;
spin_lock_init(psc_dma-lock);
+ mutex_init(psc_dma-mutex);
psc_dma-id = be32_to_cpu(*prop);
psc_dma-irq = irq;
psc_dma-psc_regs = regs;
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 2000803..8d396bb 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -55,6 +55,7 @@ struct psc_dma {
unsigned int irq;
struct device *dev;
spinlock_t lock;
+ struct mutex mutex;
u32 sicr;
uint sysclk;
int imr;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_ac97.c
index 9b8503f..7eb5499 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -34,11 +34,14 @@ static unsigned short psc_ac97_read(struct snd_ac97 *ac97,
unsigned short reg)
int status;
unsigned int val;
+ mutex_lock(psc_dma-mutex);
+
/* Wait for command send status zero = ready */
status = spin_event_timeout(!(in_be16(psc_dma-psc_regs-sr_csr.status)
MPC52xx_PSC_SR_CMDSEND), 100, 0);
if (status == 0) {
pr_err(timeout on ac97 bus (rdy)\n);
+ mutex_unlock(psc_dma-mutex);
return -ENODEV;
maybe define an err variable and and a goto out.
Michael
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Non-contiguous physical memory on 8572
Hello, I wrote to this list quite some time ago concerning a board that has 2 gigs of ram mapped in at 0x0.. - 0x0.7fff., and a second 2 gigs of ram at 0x1.. - 0x1.7fff.. Kumar responded and mentioned that this wasn't currently supported in the powerpc architecture. I've had this on my 'curiosity' back burner to take a look at for some time. I found a little time to look at this, and what I discovered is that this seems to actually have been a fairly trivial problem to solve. I'd like to get some feedback on the method I used, if possible, to see if I've overlooked something blatantly obvious. In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets lmb.memory.cnt to zero, I instead walk through the memory regions and call lmb_reserve for each chunk of memory that lies in a 'hole'. There are then some minor fixups to make sure that total_memory and total_highmem get the right numbers. This small change allows all four gigabytes of memory to be accessed and used in my tests. Am I missing something obvious? Would you like this in a patch for 32 or next, or is there a reason that this would not be desirable in the powerpc branch? Thanks, Aaron ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
On Thu, Jul 2, 2009 at 8:42 PM, Mikhail Zaturenskiymzaturenskiy...@gmail.com wrote: Just as an intermediate update on the issue, I've made progress and it hangs later down the line, see below: Using Embedded Planet EP88xC machine description Linux version 2.6.30-rc2-01402-gd4e2f68-dirty (dev...@localhost.localdomain) (gc c version 4.2.2) #3 Thu Jul 2 11:00:54 CDT 2009 Found initrd at 0xc3dbb000:0xc3f6d056 Zone PFN ranges: DMA 0x - 0x4000 Normal 0x4000 - 0x4000 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x - 0x4000 MMU: Allocated 72 bytes of context maps for 16 contexts Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram loglevel=7 init=/sbin/ init NR_IRQS:512 PID hash table entries: 256 (order: 8, 1024 bytes) Decrementer Frequency = 0x5f5e10 clocksource: timebase mult[2800] shift[22] registered console [ttyCPM0] enabled Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 60716k/65536k available (2136k kernel code, 4752k reserved, 100k data, 9 9k bss, 112k init) SLUB: Genslabs=12, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 12.39 BogoMIPS (lpj=61952) Mount-cache hash table entries: 512 net_namespace: 296 bytes NET: Registered protocol family 16 bio: create slab bio-0 at 0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 1736k freed msgmni has been set to 122 io scheduler noop registered io scheduler deadline registered (default) Generic RTC Driver v1.07 fa80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART fa20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART brd: module loaded loop: module loaded eth0: fs_enet: 00:00:00:00:00:00 eth1: fs_enet: 00:00:00:00:00:00 FEC MII Bus: probed fe00.flash: Found 2 x16 devices at 0x0 in 32-bit bank Amd/Fujitsu Extended Query Table at 0x0040 fe00.flash: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 112k init Now searching for cause, looks like it's init related... Wow... I just found out that it's not actually hanging at this point.. it's just working in slow motion... I found out by leaving the machine and coming back half an hour later to find additional output and eventually even a prompt. Hi Mikhail, This is very interesting. I recently experienced a similar problem when upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel). I didn't had the time to figure out what was happening, so I went back to 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if the problem remains? - Frank Here is what's happening: * RAMDISK: gzip image found at block 0 VFS: Mounted root (ext2 filesystem) on device 1:0. Freeing unused kernel memory: 112k init 4 minutes pass init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST) 2 minutes pass starting pid 403, tty '': '/etc/rc.sh' etc... * I've tried a couple different ramdisk images (another one with a much older version of busybox), with similar results. Anybody have an idea about what's going on here? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
On Jul 2, 2009, at 3:11 PM, Aaron Pace wrote: Hello, I wrote to this list quite some time ago concerning a board that has 2 gigs of ram mapped in at 0x0.. - 0x0.7fff., and a second 2 gigs of ram at 0x1.. - 0x1.7fff.. Kumar responded and mentioned that this wasn't currently supported in the powerpc architecture. I've had this on my 'curiosity' back burner to take a look at for some time. I found a little time to look at this, and what I discovered is that this seems to actually have been a fairly trivial problem to solve. I'd like to get some feedback on the method I used, if possible, to see if I've overlooked something blatantly obvious. In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets lmb.memory.cnt to zero, I instead walk through the memory regions and call lmb_reserve for each chunk of memory that lies in a 'hole'. There are then some minor fixups to make sure that total_memory and total_highmem get the right numbers. This small change allows all four gigabytes of memory to be accessed and used in my tests. Am I missing something obvious? Would you like this in a patch for 32 or next, or is there a reason that this would not be desirable in the powerpc branch? What you described is one possible solution. However when I was thinking about support non-contiguous memory I was thinking about doing at based on CONFIG_DISCONTIGMEM (see include/asm-generic/ memory_model.h). I think ppc64 supports SPARSEMEM which is a variation on the them. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
Aaron Pace wrote: In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets lmb.memory.cnt to zero, I instead walk through the memory regions and call lmb_reserve for each chunk of memory that lies in a 'hole'. There are then some minor fixups to make sure that total_memory and total_highmem get the right numbers. This small change allows all four gigabytes of memory to be accessed and used in my tests. Am I missing something obvious? The main downsides that I see are wasted memory for bookkeeping of the hole (how acceptable this is depends on how large the hole is relative to the size of RAM -- it's a tradeoff against speed of looking up page structs), and that the reserved area may still be mapped in the TLB without the guarded bit set. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
This is very interesting. I recently experienced a similar problem when upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel). I didn't had the time to figure out what was happening, so I went back to 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if the problem remains? Frank! That worked like a charm! I downloaded linux-2.6.26 source from git.kernel.org, inserted the config options previously mentioned, compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up and no more slow motion issue. Thanks! Now I just need to make myself a custom ramdisk. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
Mikhail Zaturenskiy wrote: This is very interesting. I recently experienced a similar problem when upgrading from 2.6.26-rc6 to 2.6.31-rc1 (torvalds mainline kernel). I didn't had the time to figure out what was happening, so I went back to 2.6.26-rc6. Just for the test, could you try to go back to 2.6.26 and see if the problem remains? Frank! That worked like a charm! I downloaded linux-2.6.26 source from git.kernel.org, inserted the config options previously mentioned, compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up and no more slow motion issue. If you have time, could you bisect to see when the slowdown was introduced? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Non-contiguous physical memory on 8572
On Thu, Jul 2, 2009 at 3:14 PM, Scott Woodscottw...@freescale.com wrote: Aaron Pace wrote: In MMU_init of arch/powerpc/mm/init_32.c, where the current code sets lmb.memory.cnt to zero, I instead walk through the memory regions and call lmb_reserve for each chunk of memory that lies in a 'hole'. There are then some minor fixups to make sure that total_memory and total_highmem get the right numbers. This small change allows all four gigabytes of memory to be accessed and used in my tests. Am I missing something obvious? The main downsides that I see are wasted memory for bookkeeping of the hole (how acceptable this is depends on how large the hole is relative to the size of RAM -- it's a tradeoff against speed of looking up page structs), and that the reserved area may still be mapped in the TLB without the guarded bit set. -Scott Ah, thanks for the response. A couple of followup clarifications/questions, if you don't mind. As far as wasted memory for bookkeeping, aren't the reserved regions excluded from any zonelist/pagetable allocation? I'm looking through to verify, but if you know off the top of your head where any extra data would be required to keep track, I'd like to take a look to further educate my memory manager understanding. Secondly, can you elaborate on how/when the reserved area could be mapped into the TLB? I don't by any means lay claim to a complete understanding of this area, but aside from a direct ioremap/mmap call, how would this area get mapped at all? Thanks again, Aaron ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: RAMDISK on EP88xc
Frank! That worked like a charm! I downloaded linux-2.6.26 source from git.kernel.org, inserted the config options previously mentioned, compiled ok, keeping U-Boot ramdisk and my DTS same it booted right up and no more slow motion issue. If you have time, could you bisect to see when the slowdown was introduced? I'm leaving in 5 minutes, but I'll try to find some time next week to check this out. Mikhail ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Preemption question (4xx related)
On Thu, 2009-07-02 at 07:12 -0400, Josh Boyer wrote: On Thu, Jul 02, 2009 at 05:33:12PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote: I've toyed with that idea myself. I keep coming back to the fact that you need a workload that would really leverage it, and I don't have one at the moment. To some extent that's true but just turning full preemption including kernel side with all the associated debug bits and lockdep should make a whole bunch of things show up even with ordinary workloads. I can look at doing that for ppc44x_defconfig. I'll be honest and say I don't expect it to go well, particularly with lockdep :). For 440 tend to boot an ubuntu distro off NFS root with all X DRI 3D etc... and then run compiz :-) Yes. Because that's a totally realistic workload for a 440. I'm surprised you don't have a p595 machine acting as your home router too! ;) It doesn't need to be realistic. In fact, a realistic workload is the worst thing to test with because it won't exercise all the uncommon code path which are the ones likely to bite. So yesm it's not a realistic workload, but it's a good torture workload to find bugs. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Preemption question (4xx related)
On Fri, Jul 03, 2009 at 08:41:00AM +1000, Benjamin Herrenschmidt wrote: On Thu, 2009-07-02 at 07:12 -0400, Josh Boyer wrote: On Thu, Jul 02, 2009 at 05:33:12PM +1000, Benjamin Herrenschmidt wrote: On Wed, 2009-07-01 at 20:14 -0400, Josh Boyer wrote: I've toyed with that idea myself. I keep coming back to the fact that you need a workload that would really leverage it, and I don't have one at the moment. To some extent that's true but just turning full preemption including kernel side with all the associated debug bits and lockdep should make a whole bunch of things show up even with ordinary workloads. I can look at doing that for ppc44x_defconfig. I'll be honest and say I don't expect it to go well, particularly with lockdep :). For 440 tend to boot an ubuntu distro off NFS root with all X DRI 3D etc... and then run compiz :-) Yes. Because that's a totally realistic workload for a 440. I'm surprised you don't have a p595 machine acting as your home router too! ;) It doesn't need to be realistic. In fact, a realistic workload is the worst thing to test with because it won't exercise all the uncommon code path which are the ones likely to bite. So yesm it's not a realistic workload, but it's a good torture workload to find bugs. It was a joke. But yes, you make perfectly valid points :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Subject: [PATCH v8] spi: Add PPC4xx SPI driver
On Friday 26 June 2009, Steven A. Falco wrote: + + /* + * If there are no chip selects at all, or if this is the special + * case of a non-existent (dummy) chip select, do nothing. + */ + + if (!hw-master-num_chipselect || hw-gpios[cs] == -EEXIST) + return; + I'm going to send this in, but please send a followup patch making all this non-existent (dummy) chip select stuff use the SPI_NO_CS flag. + /* +* A count of zero implies a single SPI device without any chip-select. +* Note that of_gpio_count counts all gpios assigned to this spi master. +* This includes both null gpio's and real ones. +*/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error
-Original Message- From: Avi Kivity [mailto:a...@redhat.com] Sent: Thursday, July 02, 2009 7:20 PM To: Liu Yu-B13201 Cc: Yang Shi; holl...@us.ibm.com; kvm-...@vger.kernel.org; k...@vger.kernel.org; linuxppc-...@ozlabs.org Subject: Re: [PATCH 1/2] KVM/PPC: Fix PPC KVM e500_tlb.c build error On 07/02/2009 06:09 AM, Liu Yu-B13201 wrote: This fix is already accepted in kvm.git What about the other? Is it needed? No, it's already fixed by commit b57227e600f4ecc394d6ba3c2aaa558867b5addc. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH -mm v4][POWERPC] mpc8xxx : allow SPI without cs.
On Friday 19 June 2009, Rini van Zetten wrote: This patch adds the possibility to have a spi device without a cs. Note that there's now the SPI_NO_CS bit in spi_device.mode to describe this situation ... so no -EEXIST hackery should ever tempt anyone again. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
mpc52xx_uart.c - Port Overruns
Dear List,
I am writing to ask about some particular behaviour we saw with the MPC5121
PSC UART, using the 2.6.24 Freescle BSP kernel, although examining the code
of the linux-2.6-denx tree (git commit
7cb16ec2590815a67e5fb5c8994ead536613d922), the behavior is almost identical
except for incrementing an overrrun counter.
In particular, yesterday we observed a port overrun (from the overrun flags
being set when looking with the BDI) on one of our PSC Ports. When it was
observed, we saw that every second byte coming from the serial port was
0x00.
Examining the interrupt routine of the mpc52xx_uart.c:
static inline int
mpc52xx_uart_int_rx_chars(struct uart_port *port)
{
snip
tty_insert_flip_char(tty, ch, flag);
if (status MPC52xx_PSC_SR_OE) {
/*
* Overrun is special, since it's
* reported immediately, and doesn't
* affect the current character
*/
tty_insert_flip_char(tty, 0, TTY_OVERRUN);
port-icount.overrun++;
}
snip
}
So, from my deduction, it is inserting a 0x00 for every overrun error that
occurs, however, the overrun flag is never cleared. Therefore fro every
byte that is received, the overrup flag is still set and therefore we're
observing the 0x00 being inserted for every real byte coming into the port
Is there a particular reason why the overrun flag is not cleared? That is,
parity, framing and breaks are acknowledged with:
/* Clear error condition */
out_8(PSC(port)-command, MPC52xx_PSC_RST_ERR_STAT);
But the overrun isn't cleared. Is there are particular reason why? Is
userspace meant to detect this condition and reset the port? Was it
automatically cleared on the 5200 when reading the status, but the 5121 is
exhibiting strange behavior?
Best regards,
Damien Dusha.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
