Re: [PATCH 16/40] tags: recognize compat syscalls
On 23.6.2010 12:02, Ian Munsie wrote: From: Jason Baron jba...@redhat.com make tags.sh recognize the new syscall macros: COMPAT_SYSCALL_DEFINE#N() ARCH_COMPAT_SYSCALL_DEFINE#N() Signed-off-by: Jason Baron jba...@redhat.com Signed-off-by: Ian Munsie imun...@au1.ibm.com Acked-by: Michal Marek mma...@suse.cz Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 31/40] trace syscalls: Convert various generic compat syscalls
On 23.6.2010 12:37, Andi Kleen wrote: It also has maintenance costs, e.g. I doubt ctags and cscope will be able to deal with these kinds of macros, so it has a high cost for everyone using these tools. FWIW, patch 16/40 of this series teaches 'make tags' to recognize these macros: http://permalink.gmane.org/gmane.linux.kernel/1002103 Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Continuing UCC UART woes
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
cell-index = 4;
reg = 0x3200 0x200;
interrupts = 35;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg9;
tx-clock-name = brg10;
soft-uart;
};
With this setup, I can receive characters from the device, but
no characters ever go out. Same behaviour as before - the output
descriptors get filled, but no action seems to be taken, no interrupts,
etc. Except randomly there will be output! For example, if I
connect to the port with minicom, what I type is received by /dev/ttyQE2.
On some rare occasions, what I type is also echoed back, but when
this happens, it's only the first couple of characters, then nothing.
I verified that the CMXUCR registers are being set per the DTS
as well as the BRG registers. They all look correct:
ucc_set_qe_mux_rxtx - CMX: 0x000a
r...@ppc_target:~ stty /dev/ttyQE0 38400
qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 13200, RATE = 9600,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 13200, RATE = 9600,
MULTIPLIER = 1
qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 13200, RATE = 38400,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 13200, RATE = 38400,
MULTIPLIER = 1
I've also tried this on UCC5 UCC8 which show the identical
behaviour - input works, output does not. I've tried running
with only a single soft UART (UCC4) as well as having all three
configured. No changes seen.
At this point, I'm using the stock driver from 2.6.33.3
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at these two packages, it's unclear that they match. Certainly
the dates are very different:
[gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG
fsl_qe_ucode:
total 16
-rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin
-rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt
QERAMPKG:
total 972
-rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c
-rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44
Soft_UART_Microcode_Rel_0_1_2.pdf
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h
-rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx
-rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx
Any ideas what I'm doing wrong?
Thanks
--
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 v1]460EX on-chip SATA driverresubmisison
This patch enables the on-chip DWC SATA controller of the AppliedMicro
processor 460EX.
Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com
Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com
Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com
---
This patch incorporates the changes advised in the mailing list. The device
tree changes were submitted as a seperate patch.
drivers/ata/Kconfig |9 +
drivers/ata/Makefile |1 +
drivers/ata/sata_dwc_460ex.c | 1756 ++
3 files changed, 1766 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/sata_dwc_460ex.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index aa85a98..29e29a2 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -98,6 +98,15 @@ config SATA_SIL24
If unsure, say N.
+config SATA_DWC
+ tristate DesignWare Cores SATA support
+ depends on 460EX
+ help
+ This option enables support for the on-chip SATA controller of the
+ AppliedMicro processor 460EX.
+
+ If unsure, say N.
+
config ATA_SFF
bool ATA SFF support
default y
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 7ef89d7..d863e66 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o
obj-$(CONFIG_SATA_FSL) += sata_fsl.o
obj-$(CONFIG_SATA_INIC162X)+= sata_inic162x.o
obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
+obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
new file mode 100644
index 000..ea24c1e
--- /dev/null
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -0,0 +1,1756 @@
+/*
+ * drivers/ata/sata_dwc_460ex.c
+ *
+ * Synopsys DesignWare Cores (DWC) SATA host driver
+ *
+ * Author: Mark Miesfeld mmiesf...@amcc.com
+ *
+ * Ported from 2.6.19.2 to 2.6.25/26 by Stefan Roese s...@denx.de
+ * Copyright 2008 DENX Software Engineering
+ *
+ * Based on versions provided by AMCC and Synopsys which are:
+ * Copyright 2006 Applied Micro Circuits Corporation
+ * COPYRIGHT (C) 2005 SYNOPSYS, INC. ALL RIGHTS RESERVED
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifdef CONFIG_SATA_DWC_DEBUG
+#define DEBUG
+#endif
+
+#ifdef CONFIG_SATA_DWC_VDEBUG
+#define VERBOSE_DEBUG
+#define DEBUG_NCQ
+#endif
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/libata.h
+#include linux/slab.h
+#include libata.h
+
+#include scsi/scsi_host.h
+#include scsi/scsi_cmnd.h
+
+#define DRV_NAMEsata-dwc
+#define DRV_VERSION 1.0
+
+/* SATA DMA driver Globals */
+#define DMA_NUM_CHANS 1
+#define DMA_NUM_CHAN_REGS 8
+
+/* SATA DMA Register definitions */
+#define AHB_DMA_BRST_DFLT 64 /* 16 data items burst length*/
+
+struct dmareg {
+ u32 low;/* Low bits 0-31 */
+ u32 high; /* High bits 32-63 */
+};
+
+/* DMA Per Channel registers */
+struct dma_chan_regs {
+ struct dmareg sar; /* Source Address */
+ struct dmareg dar; /* Destination address */
+ struct dmareg llp; /* Linked List Pointer */
+ struct dmareg ctl; /* Control */
+ struct dmareg sstat;/* Source Status not implemented in core */
+ struct dmareg dstat;/* Destination Status not implemented in core*/
+ struct dmareg sstatar; /* Source Status Address not impl in core */
+ struct dmareg dstatar; /* Destination Status Address not implemente */
+ struct dmareg cfg; /* Config */
+ struct dmareg sgr; /* Source Gather */
+ struct dmareg dsr; /* Destination Scatter */
+};
+
+/* Generic Interrupt Registers */
+struct dma_interrupt_regs {
+ struct dmareg tfr; /* Transfer Interrupt */
+ struct dmareg block;/* Block Interrupt */
+ struct dmareg srctran; /* Source Transfer Interrupt */
+ struct dmareg dsttran; /* Dest Transfer Interrupt */
+ struct dmareg error;/* Error */
+};
+
+struct ahb_dma_regs {
+ struct dma_chan_regschan_regs[DMA_NUM_CHAN_REGS];
+ struct dma_interrupt_regs interrupt_raw;/* Raw Interrupt */
+ struct dma_interrupt_regs interrupt_status; /* Interrupt Status */
+ struct dma_interrupt_regs interrupt_mask; /* Interrupt Mask */
+ struct dma_interrupt_regs interrupt_clear; /* Interrupt Clear */
+ struct dmareg statusInt; /* Interrupt combined*/
+ struct dmareg
Re: Continuing UCC UART woes
On 06/24/2010 06:54 AM, Gary Thomas wrote:
I thought I had this working, but it seems to only work for UCC3.
Sadly, I can't get it to work on UCC4/UCC5/UCC8 at all.
Starting with UCC4, I have:
/* ttyQE0 (UCC4) */
serial_qe0: ser...@3200 {
device_type = serial;
compatible = ucc_uart;
cell-index = 4;
reg = 0x3200 0x200;
interrupts = 35;
interrupt-parent = qeic;
port-number = 0;
rx-clock-name = brg9;
tx-clock-name = brg10;
soft-uart;
};
With this setup, I can receive characters from the device, but
no characters ever go out. Same behaviour as before - the output
descriptors get filled, but no action seems to be taken, no interrupts,
etc. Except randomly there will be output! For example, if I
connect to the port with minicom, what I type is received by /dev/ttyQE2.
On some rare occasions, what I type is also echoed back, but when
this happens, it's only the first couple of characters, then nothing.
I verified that the CMXUCR registers are being set per the DTS
as well as the BRG registers. They all look correct:
ucc_set_qe_mux_rxtx - CMX: 0x000a
r...@ppc_target:~ stty /dev/ttyQE0 38400
qe_setbrg - BRG: fddfd660 = 0x000106b6, CLK = 13200, RATE = 9600,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x000106b5, CLK = 13200, RATE = 9600,
MULTIPLIER = 1
qe_setbrg - BRG: fddfd660 = 0x000101aa, CLK = 13200, RATE = 38400,
MULTIPLIER = 16
qe_setbrg - BRG: fddfd664 = 0x00011ada, CLK = 13200, RATE = 38400,
MULTIPLIER = 1
I've also tried this on UCC5 UCC8 which show the identical
behaviour - input works, output does not. I've tried running
with only a single soft UART (UCC4) as well as having all three
configured. No changes seen.
At this point, I'm using the stock driver from 2.6.33.3
One thing I noticed is that the firmware patch seems quite old.
I got the firmware package from http://opensource.freescale.com/firmware/
We were also told (by FreeScale) to look at
https://www.freescale.com/webapp/Download?colCode=QERAMPKG
Looking at these two packages, it's unclear that they match. Certainly
the dates are very different:
[gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG
fsl_qe_ucode:
total 16
-rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39
fsl_qe_ucode_uart_8360_21.bin
-rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt
QERAMPKG:
total 972
-rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04
SlowProtocols_8323rev11.c
-rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44
Soft_UART_Microcode_Rel_0_1_2.pdf
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49
Soft_UART_mpc8360_r2.0.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14
Soft_UART_mpc8360_r2.1.h
-rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14
Soft_UART_mpc8568_r1.1.h
-rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx
-rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c
-rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx
Any ideas what I'm doing wrong?
BTW, I tried converting the Soft_UART_mpc8360_r2.1.h file
to the firmware format. I had to fiddle with the conversion
program a bit because the firmware has version 0.1.2, but I
ended up with a new firmware file. Here's the change I made:
$ diff -u make_qe_firmware.py*
--- make_qe_firmware.py 2010-06-24 07:19:31.0 -0600
+++ make_qe_firmware.py~2010-06-24 07:15:54.0 -0600
@@ -260,7 +260,7 @@
print Unknown SOC model\n
exit(1)
-if not ucode_major and not ucode_minor:
+if not ucode_major:
print Unknown microcode version\n
exit(1)
No change in behaviour :-(
--
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
Re: Continuing UCC UART woes
One thing I noticed is that the firmware patch seems quite old. I got the firmware package from http://opensource.freescale.com/firmware/ We were also told (by FreeScale) to look at https://www.freescale.com/webapp/Download?colCode=QERAMPKG Looking at these two packages, it's unclear that they match. Certainly the dates are very different: [gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG fsl_qe_ucode: total 16 -rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin -rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt QERAMPKG: total 972 -rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c -rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44 Soft_UART_Microcode_Rel_0_1_2.pdf -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h -rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx -rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx Any ideas what I'm doing wrong? Hi Gary, At http://opensource.freescale.com/firmware there is a script make_qe_firmware.py that Timur said would create a firmware binary out of the firmware header file. I have not used this script, since the existing binary worked for me. But I am using only one UCC UART, so you are going beyond what I have done with this firmware. You can try to use that script to create a newer firmware binary from the header in that zip file. Make sure you are using the right one for your silicon rev. You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
On 06/24/2010 07:38 AM, Chuck Meade wrote: One thing I noticed is that the firmware patch seems quite old. I got the firmware package from http://opensource.freescale.com/firmware/ We were also told (by FreeScale) to look at https://www.freescale.com/webapp/Download?colCode=QERAMPKG Looking at these two packages, it's unclear that they match. Certainly the dates are very different: [gtho...@hermes 8358]$ ls -l fsl_qe_ucode QERAMPKG fsl_qe_ucode: total 16 -rw-rw-r-- 1 gthomas gthomas 5940 2007-12-10 14:39 fsl_qe_ucode_uart_8360_21.bin -rw-r--r-- 1 gthomas gthomas 7892 2007-11-30 10:14 license.txt QERAMPKG: total 972 -rw-rw-r-- 1 gthomas gthomas 132915 2009-04-07 14:04 SlowProtocols_8323rev11.c -rw-rw-r-- 1 gthomas gthomas 455446 2009-09-16 15:44 Soft_UART_Microcode_Rel_0_1_2.pdf -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:49 Soft_UART_mpc8360_r2.0.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8360_r2.1.h -rw-rw-r-- 1 gthomas gthomas 29379 2009-09-16 15:14 Soft_UART_mpc8568_r1.1.h -rw-rw-r-- 1 gthomas gthomas 105457 2009-09-16 16:00 SWUART_8360rev20.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:32 SWUART_8360rev20.srx -rw-rw-r-- 1 gthomas gthomas 105318 2009-09-16 15:59 SWUART_8360rev21.c -rw-rw-r-- 1 gthomas gthomas 34689 2009-09-16 15:14 SWUART_8360rev21.srx Any ideas what I'm doing wrong? Hi Gary, At http://opensource.freescale.com/firmware there is a script make_qe_firmware.py that Timur said would create a firmware binary out of the firmware header file. I have not used this script, since the existing binary worked for me. But I am using only one UCC UART, so you are going beyond what I have done with this firmware. You can try to use that script to create a newer firmware binary from the header in that zip file. Make sure you are using the right one for your silicon rev. As reported, I've done this - no change. You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. I've also done this - the descriptors are set up, never touched by the QE Odd that input always works, output works only very rarely. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. No change whether these pins are configured or not. -- 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
Re: [PATCH 12/40] x86, compat: convert ia32 layer to use
On Wed, Jun 23, 2010 at 12:23:44PM -0700, H. Peter Anvin wrote: arch/s390/kernel/sys_s390.c:SYSCALL_DEFINE(s390_fallocate)(int fd, int mode, loff_t offset, arch/sparc/kernel/sys_sparc_64.c:SYSCALL_DEFINE1(sparc_pipe_real, struct pt_regs *, regs) In fact we sort of wanted to standardize the name of arch overriden compat syscalls, so that userspace programs playing with syscalls tracing won't have to deal with arch naming differences. That seems totally wrong in so many ways. What userspace sees is the system call name, e.g. fallocate or pipe. It should *not* be visible to userspace that there is an arch-specici implementation. This is really just the in-kernel name. With tracing we export it to userspace, so agreed that we should stay consistent. We need a good way to override both native and compat system calls with arch version to always export the sys_ / compat_sys names. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Continuing UCC UART woes
You can use strategic printk debugging in the ucc_uart.c driver to determine on the Tx side what is going wrong. For example, after you tell the QE to output chars, wait a bit and printk out the BD. See if the QE is clearing the READY bit in that BD. That will tell you if the QE is even processing the BD or not. I've also done this - the descriptors are set up, never touched by the QE Odd that input always works, output works only very rarely. You could check alignment of the BD address to be sure that got setup correctly. Make sure you are not looking at a cached version of the BD, and make sure you waited long enough for the QE to have processed it. Also ensure that for all these other UCCs that you are using that the CD, CTS, RTS pins are set up as plain GPIO pins if you do not have them hooked up to actual CD, CTS, RTS signals. If you *are* using HW flow control, probe all the signals to be sure they are all correct. No change whether these pins are configured or not. I would definitely leave these configured as GPIOs if the correct signals are not present at the pins. You could look through the pdf that is in that zipfile and make sure you are following (that the driver is following) all the restrictions for soft UART mode. Perhaps printk debug in ucc_slow_init to make sure the UCC is getting set up correctly. I would probably also make sure that the Tx parameter ram is allocated and aligned OK. Make sure you specify unique port-number fields in your dts for each of these UCC UARTs. Beyond that, if printk-debugging does not show anything, then you may want to contact Freescale and try to find out what the Soft UART mode microcode patch capabilities are, in terms of exactly how many simultaneous UCC UARTs it has been proven to support. The QE has processing limits, and maybe the soft UART microcode patch can't support multiple UCC UARTs(?) It's worth it to find out from Freescale I suppose. Chuck Meade ch...@theptrgroup.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] kvm/ppc: fix build warning
Fix build warning:
arch/powerpc/kvm/book3s_64_mmu.c: In function
'kvmppc_mmu_book3s_64_esid_to_vsid':
arch/powerpc/kvm/book3s_64_mmu.c:446: warning: 'slb' may be used uninitialized
in this function
Signed-off-by: Denis Kirjanov dkirja...@kernel.org
---
arch/powerpc/kvm/book3s_64_mmu.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index 4025ea2..61f2621 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -443,7 +443,7 @@ static int kvmppc_mmu_book3s_64_esid_to_vsid(struct
kvm_vcpu *vcpu, ulong esid,
u64 *vsid)
{
ulong ea = esid SID_SHIFT;
- struct kvmppc_slb *slb;
+ struct kvmppc_slb *uninitialized_var(slb);
u64 gvsid = esid;
if (vcpu-arch.msr (MSR_DR|MSR_IR)) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kvm/ppc: fix build warning
On 24.06.2010, at 21:44, Denis Kirjanov wrote: Fix build warning: arch/powerpc/kvm/book3s_64_mmu.c: In function 'kvmppc_mmu_book3s_64_esid_to_vsid': arch/powerpc/kvm/book3s_64_mmu.c:446: warning: 'slb' may be used uninitialized in this function Signed-off-by: Denis Kirjanov dkirja...@kernel.org Are you sure this isn't a broken compiler? I don't see where it could be used uninitialized. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
Timur Tabi wrote: I'd say that there are plenty of unknown issues with this driver/hardware. For some reason, QE UART is just unreliable. I've had several people try to use the QE for UART, and almost everyone has problems with it. I finally got in touch with one of the other development teams, and they said that they got QE UART working with the 8569 and the P1021. The reference board we make with the 8568 does not have QE pinned to the UART, so they didn't try to support that. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UCC UART
On 06/24/2010 03:20 PM, Timur Tabi wrote: Timur Tabi wrote: I'd say that there are plenty of unknown issues with this driver/hardware. For some reason, QE UART is just unreliable. I've had several people try to use the QE for UART, and almost everyone has problems with it. I finally got in touch with one of the other development teams, and they said that they got QE UART working with the 8569 and the P1021. The reference board we make with the 8568 does not have QE pinned to the UART, so they didn't try to support that. What about 8358? I'm really stuck here - Rx seems to work, but Tx is totally dead... -- 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
Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
Oops... put the old linuxppc list on the CC, sorry! On Thu, Jun 24, 2010 at 23:45, Kyle Moffett k...@moffetthome.net wrote: Hello, I've got a new P2020 (32bit mpc85xx family) board I'm working on a port for that includes 2 NOR flashes (128MB each) and a removable SO-RDIMM of 2GB or 4GB. Unfortunately when I configure both flashes in the device-tree off my elbc, Linux is completely unable to access the second one because it attempts to ioremap() the entire virtual address space of both FLASH chips. Even with only one flash chip enabled, there's a bit of a noticeable performance degradation because the mapping consumes almost all of my available vmalloc space and forces bounce-buffering for all my HIGHMEM. It looks like the of-flash driver currently requires that the whole chip be mapped in the kernel at once. I would much rather have a 50% performance penalty on flash accesses (which are already very slow) and regain most of the vmap space. So the question is, is there a way to convince the MTD layer to iomap() only what it needs to access to do reads and writes? If not, what changes would need to be made to MTD and/or of-flash to create such functionality? Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: New P2020-based board (mpc85xx) gets Processor 1 is stuck on 2.6.34, not on 2.6.32
Oops, put the old linuxppc list on the CC, sorry! On Thu, Jun 24, 2010 at 23:32, Kyle Moffett k...@moffetthome.net wrote: Hello, I'm working on a new board port for a P2020-based board, and I'm having problems with my second core not starting up on 2.6.34, even though it starts up fine on 2.6.32. In adding various debugs to mpc85xx_kick_cpu(), it looks like the virtual address is detected as 0x7280 on both, and it seems to ioremap it to the same address. Furthermore, both of them get the ack from the other CPU almost immediately (within 1ms). Unfortunately, after that the second core fails to rendezvous elsewhere in the SMP code and as a result I get Processor 1 is stuck. Unfortunately I've had no luck looking through git log v2.6.32..v2.6.34 -- arch/powerpc/ by hand, and there are enough mechanical merge conflicts with my patchset to make bisection very painful (IE: git bisect, git cherry-pick, test, git reset --hard HEAD^, repeat) Any additional suggestions on where to look would be much appreciated. Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
