[RFC PATCH powerpc] Fix compiling error in powernv/rng.c

2013-11-14 Thread Li Zhong 
This is seen when CONFIG_SMP is not enabled:

arch/powerpc/platforms/powernv/rng.c: In function 'rng_init_per_cpu':
arch/powerpc/platforms/powernv/rng.c:74: error: implicit declaration of 
function 'cpu_to_chip_id'

Signed-off-by: Li Zhong 
---
 arch/powerpc/platforms/powernv/rng.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/rng.c 
b/arch/powerpc/platforms/powernv/rng.c
index 8844628..04430a7 100644
--- a/arch/powerpc/platforms/powernv/rng.c
+++ b/arch/powerpc/platforms/powernv/rng.c
@@ -59,6 +59,7 @@ int powernv_get_random_long(unsigned long *v)
 }
 EXPORT_SYMBOL_GPL(powernv_get_random_long);
 
+#ifdef CONFIG_SMP
 static __init void rng_init_per_cpu(struct powernv_rng *rng,
struct device_node *dn)
 {
@@ -75,6 +76,13 @@ static __init void rng_init_per_cpu(struct powernv_rng *rng,
}
}
 }
+#else
+static __init void rng_init_per_cpu(struct powernv_rng *rng,
+   struct device_node *dn)
+{
+   per_cpu(powernv_rng, 0) = rng;
+}
+#endif
 
 static __init int rng_create(struct device_node *dn)
 {


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Add a vga alias node for P1022

2013-11-14 Thread Jason Jin 
In u-boot, when set the video as console, the name 'vga' is used
as a general name for the video device, during the fdt_fixup_stdout
process, the 'vga' name is used to search in the dtb to setup the
'linux,stdout-path' node. Though the P1022 DIU is not VGA-compatible device,
to meet the 'vga' name used in u-boot, the vga alias node is added for
P1022 in this patch. At the same time, a display alias is also added
so that no other components grow dependencies on the vga alias node.

Signed-off-by: Jason Jin 
---
V2: Update the description and also add a display alias.

 arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
 arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi  | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
index e179803..be49300 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-post.dtsi
@@ -174,7 +174,7 @@
 
 /include/ "pq3-gpio-0.dtsi"
 
-   display@1 {
+   display: display@1 {
compatible = "fsl,diu", "fsl,p1022-diu";
reg = <0x1 1000>;
interrupts = <64 2 0 0>;
diff --git a/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
index 1956dea..de76ae8 100644
--- a/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi
@@ -50,6 +50,8 @@
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
+   vga = &display;
+   display = &display;
};
 
cpus {
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000

2013-11-14 Thread Nicolin Chen 
On Fri, Nov 15, 2013 at 02:42:01PM +0800, Shawn Guo wrote:
> On Thu, Nov 14, 2013 at 07:07:09PM +0800, Nicolin Chen wrote:
> > We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
> > Thus change bypass value 0x8000 to what we exactly need.
> > 
> > This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
> > up/down the pin after turning into tristate. When we use SSI normal mode to
> > playback monaural audio via I2S signal, there'd be a pulled curve occur to
> > its signal at the second slot if setting PUE bit for TXD. And it will make
> > the second channel to play a constant noise. So by keeping the signal level
> > in the second slot, we can get a constant high level signal (-1) or a low
> > level one (0).
> > 
> > Signed-off-by: Nicolin Chen 
> > ---
> >  arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
> >  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> We have moved all pin groups settings into
> arch/arm/boot/dts/imx6qdl-pingrp.h.  I just rebased and applied the
> patch.  Please check my imx/dt branch and ensure I applied the changes
> correctly.

Simply perfect. Thank you.
Nicolin

---


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000

2013-11-14 Thread Shawn Guo 
On Thu, Nov 14, 2013 at 07:07:09PM +0800, Nicolin Chen wrote:
> We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
> Thus change bypass value 0x8000 to what we exactly need.
> 
> This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
> up/down the pin after turning into tristate. When we use SSI normal mode to
> playback monaural audio via I2S signal, there'd be a pulled curve occur to
> its signal at the second slot if setting PUE bit for TXD. And it will make
> the second channel to play a constant noise. So by keeping the signal level
> in the second slot, we can get a constant high level signal (-1) or a low
> level one (0).
> 
> Signed-off-by: Nicolin Chen 
> ---
>  arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)

We have moved all pin groups settings into
arch/arm/boot/dts/imx6qdl-pingrp.h.  I just rebased and applied the
patch.  Please check my imx/dt branch and ensure I applied the changes
correctly.

Shawn

> 
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 6e096ca..6b76e55 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -601,27 +601,27 @@
>   audmux {
>   pinctrl_audmux_1: audmux-1 {
>   fsl,pins = <
> - 
> MX6QDL_PAD_SD2_DAT0__AUD4_RXD  0x8000
> - 
> MX6QDL_PAD_SD2_DAT3__AUD4_TXC  0x8000
> - 
> MX6QDL_PAD_SD2_DAT2__AUD4_TXD  0x8000
> - 
> MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x8000
> + 
> MX6QDL_PAD_SD2_DAT0__AUD4_RXD  0x130b0
> + 
> MX6QDL_PAD_SD2_DAT3__AUD4_TXC  0x130b0
> + 
> MX6QDL_PAD_SD2_DAT2__AUD4_TXD  0x110b0
> + 
> MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x130b0
>   >;
>   };
>  
>   pinctrl_audmux_2: audmux-2 {
>   fsl,pins = <
> - 
> MX6QDL_PAD_CSI0_DAT7__AUD3_RXD  0x8000
> - 
> MX6QDL_PAD_CSI0_DAT4__AUD3_TXC  0x8000
> - 
> MX6QDL_PAD_CSI0_DAT5__AUD3_TXD  0x8000
> - 
> MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x8000
> + 
> MX6QDL_PAD_CSI0_DAT7__AUD3_RXD  0x130b0
> + 
> MX6QDL_PAD_CSI0_DAT4__AUD3_TXC  0x130b0
> + 
> MX6QDL_PAD_CSI0_DAT5__AUD3_TXD  0x110b0
> + 
> MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
>   >;
>   };
>  
>   pinctrl_audmux_3: audmux-3 {
>   fsl,pins = <
> - 
> MX6QDL_PAD_DISP0_DAT16__AUD5_TXC  0x8000
> - 
> MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x8000
> - 
> MX6QDL_PAD_DISP0_DAT19__AUD5_RXD  0x8000
> + 
> MX6QDL_PAD_DISP0_DAT16__AUD5_TXC  0x130b0
> + 
> MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x130b0
> + 
> MX6QDL_PAD_DISP0_DAT19__AUD5_RXD  0x130b0
>   >;
>   };
>   };
> -- 
> 1.8.4
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH powerpc] Fix compiling error in rng.c

2013-11-14 Thread Li Zhong 
This patch tries to fix following compiling errors, by including the
needed header file:

arch/powerpc/platforms/pseries/rng.c: In function 'pseries_get_random_long':
arch/powerpc/platforms/pseries/rng.c:20: error: 'PLPAR_HCALL_BUFSIZE' 
undeclared (first use in this function)
...

Signed-off-by: Li Zhong 
---
 arch/powerpc/platforms/pseries/rng.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/rng.c 
b/arch/powerpc/platforms/pseries/rng.c
index a702f1c..62c7838 100644
--- a/arch/powerpc/platforms/pseries/rng.c
+++ b/arch/powerpc/platforms/pseries/rng.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 #include 
-
+#include 
 
 static int pseries_get_random_long(unsigned long *v)
 {


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Remove a few lines of oops output

2013-11-14 Thread Michael Neuling 
Anton Blanchard  wrote:

> 
> We waste quite a few lines in our oops output:
> 
> ...
> MSR: 80009032   CR: 28044024  XER: 
> SOFTE: 0
> CFAR: 9088
> DAR: 001c, DSISR: 4000
> 
> GPR00: c00c74f0 c0037cc1b010 c0d2bb30  
> ...
> 
> We can do a better job here and remove 3 lines:
> 
> MSR: 80009032   CR: 28044024  XER: 
> CFAR: 9088 DAR: 0010, DSISR: 4000 SOFTE: 1 
> GPR00: c00e3d10 c0037cc2fda0 c0d2c3a8 0001 
> 
> Also move PACATMSCRATCH up, it doesn't really belong in the stack
> trace section.
> 

I like it.

> Signed-off-by: Anton Blanchard 
> ---
> 
> PACATMSCRATCH is a long and not very descriptive name. It appears to be
> an MSR so should it instead be called TM_MSR?

We also use it to store the stack point in the reclaim code.  

> Also, could we save a line and only print it if MSR_TM_ACTIVE()?

Yeah that would be fine.

Mikey

> 
> Index: b/arch/powerpc/kernel/process.c
> ===
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -858,17 +858,20 @@ void show_regs(struct pt_regs * regs)
>   printk("MSR: "REG" ", regs->msr);
>   printbits(regs->msr, msr_bits);
>   printk("  CR: %08lx  XER: %08lx\n", regs->ccr, regs->xer);
> -#ifdef CONFIG_PPC64
> - printk("SOFTE: %ld\n", regs->softe);
> -#endif
>   trap = TRAP(regs);
>   if ((regs->trap != 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
> - printk("CFAR: "REG"\n", regs->orig_gpr3);
> + printk("CFAR: "REG" ", regs->orig_gpr3);
>   if (trap == 0x200 || trap == 0x300 || trap == 0x600)
>  #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
> - printk("DEAR: "REG", ESR: "REG"\n", regs->dar, regs->dsisr);
> + printk("DEAR: "REG" ESR: "REG" ", regs->dar, regs->dsisr);
>  #else
> - printk("DAR: "REG", DSISR: %08lx\n", regs->dar, regs->dsisr);
> + printk("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
> +#endif
> +#ifdef CONFIG_PPC64
> + printk("SOFTE: %ld ", regs->softe);
> +#endif
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + printk("\nPACATMSCRATCH: %016llx ", get_paca()->tm_scratch);
>  #endif
>  
>   for (i = 0;  i < 32;  i++) {
> @@ -887,9 +890,6 @@ void show_regs(struct pt_regs * regs)
>   printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
>   printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
>  #endif
> -#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> - printk("PACATMSCRATCH [%llx]\n", get_paca()->tm_scratch);
> -#endif
>   show_stack(current, (unsigned long *) regs->gpr[1]);
>   if (!user_mode(regs))
>   show_instructions(regs);
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: Remove a few lines of oops output

2013-11-14 Thread Anton Blanchard 

We waste quite a few lines in our oops output:

...
MSR: 80009032   CR: 28044024  XER: 
SOFTE: 0
CFAR: 9088
DAR: 001c, DSISR: 4000

GPR00: c00c74f0 c0037cc1b010 c0d2bb30  
...

We can do a better job here and remove 3 lines:

MSR: 80009032   CR: 28044024  XER: 
CFAR: 9088 DAR: 0010, DSISR: 4000 SOFTE: 1 
GPR00: c00e3d10 c0037cc2fda0 c0d2c3a8 0001 

Also move PACATMSCRATCH up, it doesn't really belong in the stack
trace section.

Signed-off-by: Anton Blanchard 
---

PACATMSCRATCH is a long and not very descriptive name. It appears to be
an MSR so should it instead be called TM_MSR?

Also, could we save a line and only print it if MSR_TM_ACTIVE()?

Index: b/arch/powerpc/kernel/process.c
===
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -858,17 +858,20 @@ void show_regs(struct pt_regs * regs)
printk("MSR: "REG" ", regs->msr);
printbits(regs->msr, msr_bits);
printk("  CR: %08lx  XER: %08lx\n", regs->ccr, regs->xer);
-#ifdef CONFIG_PPC64
-   printk("SOFTE: %ld\n", regs->softe);
-#endif
trap = TRAP(regs);
if ((regs->trap != 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
-   printk("CFAR: "REG"\n", regs->orig_gpr3);
+   printk("CFAR: "REG" ", regs->orig_gpr3);
if (trap == 0x200 || trap == 0x300 || trap == 0x600)
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
-   printk("DEAR: "REG", ESR: "REG"\n", regs->dar, regs->dsisr);
+   printk("DEAR: "REG" ESR: "REG" ", regs->dar, regs->dsisr);
 #else
-   printk("DAR: "REG", DSISR: %08lx\n", regs->dar, regs->dsisr);
+   printk("DAR: "REG" DSISR: %08lx ", regs->dar, regs->dsisr);
+#endif
+#ifdef CONFIG_PPC64
+   printk("SOFTE: %ld ", regs->softe);
+#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+   printk("\nPACATMSCRATCH: %016llx ", get_paca()->tm_scratch);
 #endif
 
for (i = 0;  i < 32;  i++) {
@@ -887,9 +890,6 @@ void show_regs(struct pt_regs * regs)
printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
 #endif
-#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
-   printk("PACATMSCRATCH [%llx]\n", get_paca()->tm_scratch);
-#endif
show_stack(current, (unsigned long *) regs->gpr[1]);
if (!user_mode(regs))
show_instructions(regs);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: print DAR and DSISR on machine check oopses

2013-11-14 Thread Anton Blanchard 

Machine check exceptions set DAR and DSISR, so print them in our
oops output.

Signed-off-by: Anton Blanchard 
---

Index: b/arch/powerpc/kernel/process.c
===
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -864,7 +864,7 @@ void show_regs(struct pt_regs * regs)
trap = TRAP(regs);
if ((regs->trap != 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
printk("CFAR: "REG"\n", regs->orig_gpr3);
-   if (trap == 0x300 || trap == 0x600)
+   if (trap == 0x200 || trap == 0x300 || trap == 0x600)
 #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
printk("DEAR: "REG", ESR: "REG"\n", regs->dar, regs->dsisr);
 #else
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] powerpc/powernv: Get FSP memory errors and plumb into memory poison infrastructure.

2013-11-14 Thread Mahesh J Salgaonkar 
From: Mahesh Salgaonkar 

Get the memory errors reported by opal and plumb it into memory poison
infrastructure. This patch uses new messaging channel infrastructure to
pull the fsp memory errors to linux.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/include/asm/opal.h|   52 +++
 arch/powerpc/platforms/powernv/Makefile|1 
 .../powerpc/platforms/powernv/opal-memory-errors.c |  146 
 3 files changed, 199 insertions(+)
 create mode 100644 arch/powerpc/platforms/powernv/opal-memory-errors.c

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 3de7ac6..5fe041c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -418,6 +418,58 @@ struct opal_machine_check_event {
} u;
 };
 
+/* FSP memory errors handling */
+enum OpalMemErr_Version {
+   OpalMemErr_V1 = 1,
+};
+
+enum OpalMemErrType {
+   OPAL_MEM_ERR_TYPE_RESILIENCE= 0,
+   OPAL_MEM_ERR_TYPE_DYN_DALLOC,
+   OPAL_MEM_ERR_TYPE_SCRUB,
+};
+
+/* Memory Reilience error type */
+enum OpalMemErr_ResilErrType {
+   OPAL_MEM_RESILIENCE_CE  = 0,
+   OPAL_MEM_RESILIENCE_UE,
+   OPAL_MEM_RESILIENCE_UE_SCRUB,
+};
+
+/* Dynamic Memory Deallocation type */
+enum OpalMemErr_DynErrType {
+   OPAL_MEM_DYNAMIC_DEALLOC= 0,
+};
+
+/* OpalMemoryErrorData->flags */
+#define OPAL_MEM_CORRECTED_ERROR   0x0001
+#define OPAL_MEM_THRESHOLD_EXCEEDED0x0002
+#define OPAL_MEM_ACK_REQUIRED  0x8000
+
+struct OpalMemoryErrorData {
+   enum OpalMemErr_Version version:8;  /* 0x00 */
+   enum OpalMemErrType type:8; /* 0x01 */
+   uint16_tflags;  /* 0x02 */
+   uint8_t reserved_1[4];  /* 0x04 */
+
+   union {
+   /* Memory Resilience corrected/uncorrected error info */
+   struct {
+   enum OpalMemErr_ResilErrType resil_err_type:8;
+   uint8_t reserved_1[7];
+   uint64_tphysical_address_start;
+   uint64_tphysical_address_end;
+   } resilience;
+   /* Dynamic memory deallocation error info */
+   struct {
+   enum OpalMemErr_DynErrType dyn_err_type:8;
+   uint8_t reserved_1[7];
+   uint64_tphysical_address_start;
+   uint64_tphysical_address_end;
+   } dyn_dealloc;
+   } u;
+};
+
 enum {
OPAL_P7IOC_DIAG_TYPE_NONE   = 0,
OPAL_P7IOC_DIAG_TYPE_RGC= 1,
diff --git a/arch/powerpc/platforms/powernv/Makefile 
b/arch/powerpc/platforms/powernv/Makefile
index 300c437..0a57286 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,3 +4,4 @@ obj-y   += opal-rtc.o opal-nvram.o opal-lpc.o
 obj-$(CONFIG_SMP)  += smp.o
 obj-$(CONFIG_PCI)  += pci.o pci-p5ioc2.o pci-ioda.o
 obj-$(CONFIG_EEH)  += eeh-ioda.o eeh-powernv.o
+obj-$(CONFIG_MEMORY_FAILURE)   += opal-memory-errors.o
diff --git a/arch/powerpc/platforms/powernv/opal-memory-errors.c 
b/arch/powerpc/platforms/powernv/opal-memory-errors.c
new file mode 100644
index 000..ec41322
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-memory-errors.c
@@ -0,0 +1,146 @@
+/*
+ * OPAL asynchronus Memory error handling support in PowreNV.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2013 IBM Corporation
+ * Author: Mahesh Salgaonkar 
+ */
+
+#undef DEBUG
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static int opal_mem_err_nb_init;
+static LIST_HEAD(opal_memory_err_list);
+static DEFINE_SPINLOCK(opal_mem_err_lock);
+
+struct OpalMsgNode {
+   struct list_head list;
+   struct opal_msg msg;
+};
+
+static void handle_memory_error_event(struct OpalMemoryErrorData *merr_evt)
+{
+   uint64_t paddr_start, paddr_end;
+
+   pr_debug("%s: Retrived memory error event, type: 0x%x\n",
+ __func__, merr_evt->type);
+   switch (merr_evt->type) {
+   case OPAL_MEM_ERR_TYPE_RESILIENCE:
+   paddr_start = merr_evt->u.resilience.physical_addres

[PATCH 1/2] powerpc/powernv: Add config option for hwpoisoning.

2013-11-14 Thread Mahesh J Salgaonkar 
From: Mahesh Salgaonkar 

Add config option to enable generic memory hwpoisoning infrastructure for
ppc64.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/Kconfig |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 38f3b7e..4690f5a 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -375,6 +375,12 @@ config ARCH_HAS_WALK_MEMORY
 config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
 
+config PPC64_SUPPORTS_MEMORY_FAILURE
+   bool "Add support for memory hwpoison"
+   depends on PPC_BOOK3S_64
+   default "y" if PPC_POWERNV
+   select ARCH_SUPPORTS_MEMORY_FAILURE
+
 config KEXEC
bool "kexec system call"
depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/2] powerpc/powernv: Plumb fsp memory errors to memory poison infrastructure.

2013-11-14 Thread Mahesh J Salgaonkar 
Hi,

Please find the patch set that implements FSP memory error handling and
plumbs then into memory poison infrastructure.

Patch 1 enables the generic memory hwpoisoning infrastructure for ppc64.
Patch 2 reads the memory errors reported from opal layer and plumbs them
into memory poison infrastructure.

This patch uses new messaging channel infrastructure (proposed through a
separate patch at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-November/113331.html)
to pull the fsp memory errors to linux.

Thanks,
-Mahesh.
---

Mahesh Salgaonkar (2):
  powerpc/powernv: Add config option for hwpoisoning.
  powerpc/powernv: Get FSP memory errors and plumb into memory poison 
infrastructure.


 arch/powerpc/Kconfig   |6 +
 arch/powerpc/include/asm/opal.h|   52 +++
 arch/powerpc/platforms/powernv/Makefile|1 
 .../powerpc/platforms/powernv/opal-memory-errors.c |  146 
 4 files changed, 205 insertions(+)
 create mode 100644 arch/powerpc/platforms/powernv/opal-memory-errors.c

-- 
-Mahesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[RFC PATCH] powerpc/powernv: infrastructure to read opal messages in generic format.

2013-11-14 Thread Mahesh J Salgaonkar 
From: Mahesh Salgaonkar 

Opal now has a new messaging infrastructure to push the messages to
linux in a generic format for different type of messages using only one
event bit. The format of the opal message is as below:

struct opal_msg {
uint32_t msg_type;
uint32_t reserved;
uint64_t params[8];
};

This patch allows clients to subscribe for notification for specific
message type. It is upto the subscriber to decipher the messages who showed
interested in receiving specific message type.

The interface to subscribe for notification is:

int opal_message_notifier_register(enum OpalMessageType msg_type,
struct notifier_block *nb)


The notifier will fetch the opal message when available and notify the
subscriber with message type and the opal message. It is subscribers
responsibility to copy the message data before returning from notifier
callback.

I will post a seperate patch series for fsp memory handling which uses
this new messaging channel to pull fsp memory errors.

Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/include/asm/opal.h|   23 ++
 arch/powerpc/platforms/powernv/opal-wrappers.S |2 +
 arch/powerpc/platforms/powernv/opal.c  |   90 
 3 files changed, 114 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c5cd728..3de7ac6 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -129,6 +129,8 @@ extern int opal_enter_rtas(struct rtas_args *args,
 #define OPAL_LPC_READ  67
 #define OPAL_LPC_WRITE 68
 #define OPAL_RETURN_CPU69
+#define OPAL_GET_MSG   80
+#define OPAL_CHECK_COMP81
 
 #ifndef __ASSEMBLY__
 
@@ -208,7 +210,16 @@ enum OpalPendingState {
OPAL_EVENT_ERROR_LOG= 0x40,
OPAL_EVENT_EPOW = 0x80,
OPAL_EVENT_LED_STATUS   = 0x100,
-   OPAL_EVENT_PCI_ERROR= 0x200
+   OPAL_EVENT_PCI_ERROR= 0x200,
+   OPAL_EVENT_PENDING_MSGS = 0x400,
+};
+
+enum OpalMessageType {
+   OPAL_MSG_ASYNC_COMP = 0,
+   OPAL_MSG_MEM_ERR,
+   OPAL_MSG_EPOW,
+   OPAL_MSG_SHUTDOWN,
+   OPAL_MSG_TYPE_MAX,
 };
 
 /* Machine check related definitions */
@@ -353,6 +364,12 @@ enum OpalLPCAddressType {
OPAL_LPC_FW = 2,
 };
 
+struct opal_msg {
+   uint32_t msg_type;
+   uint32_t reserved;
+   uint64_t params[8];
+};
+
 struct opal_machine_check_event {
enum OpalMCE_Versionversion:8;  /* 0x00 */
uint8_t in_use; /* 0x01 */
@@ -656,6 +673,8 @@ int64_t opal_lpc_write(uint32_t chip_id, enum 
OpalLPCAddressType addr_type,
   uint32_t addr, uint32_t data, uint32_t sz);
 int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
  uint32_t addr, uint32_t *data, uint32_t sz);
+int64_t opal_get_msg(uint64_t buffer, size_t size);
+int64_t opal_check_completion(uint64_t buffer, size_t size, uint64_t token);
 
 /* Internal functions */
 extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int 
depth, void *data);
@@ -670,6 +689,8 @@ extern int early_init_dt_scan_opal(unsigned long node, 
const char *uname,
   int depth, void *data);
 
 extern int opal_notifier_register(struct notifier_block *nb);
+extern int opal_message_notifier_register(enum OpalMessageType msg_type,
+   struct notifier_block *nb);
 extern void opal_notifier_enable(void);
 extern void opal_notifier_disable(void);
 extern void opal_notifier_update_evt(uint64_t evt_mask, uint64_t evt_val);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 8f38445..a082d42 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -116,3 +116,5 @@ OPAL_CALL(opal_xscom_write, 
OPAL_XSCOM_WRITE);
 OPAL_CALL(opal_lpc_read,   OPAL_LPC_READ);
 OPAL_CALL(opal_lpc_write,  OPAL_LPC_WRITE);
 OPAL_CALL(opal_return_cpu, OPAL_RETURN_CPU);
+OPAL_CALL(opal_get_msg,OPAL_GET_MSG);
+OPAL_CALL(opal_check_completion,   OPAL_CHECK_COMP);
diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 2911abe..d3759f7 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -33,6 +33,7 @@ extern u64 opal_mc_secondary_handler[];
 static unsigned int *opal_irqs;
 static unsigned int opal_irq_count;
 static ATOMIC_NOTIFIER_HEAD(opal_notifier_head);
+static struct atomic_notifier_head opal_msg_notifi

Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c

2013-11-14 Thread Nicolin Chen 
On Fri, Nov 15, 2013 at 11:22:52AM +0800, Shawn Guo wrote:
> On Fri, Nov 15, 2013 at 10:59:57AM +0800, Nicolin Chen wrote:
> > Hi Shawn,
> >
> > On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> > > On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > > > This series of patches need to be applied into one single tree because
> > > > the second patch depends on the first one. Without it, SSI would 
> > > > playback
> > > > constant noise to the right channel when playback monaural audio files 
> > > > on
> > > > i.MX6 Series board.
> > > 
> > > Let me try to understand if the dependency is true.
> > > 
> > > Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> > > patch on his tree, will there be any regression on either IMX tree or
> > > Mark's tree?  The monaural playback on imx6qdl never worked, so it's not
> > > a regression.  If there is no regression on either tree, there is no
> > > dependency to maintain.
> > 
> > It's fair enough to understand in this way. It looks like I misunderstood
> > the dependency here.
> > 
> > Do I need to resend them separately?
> 
> No, I will just pick up the DTS patch with some testing.
> 
> Shawn

Thank you.
Nicolin Chen


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c

2013-11-14 Thread Shawn Guo 
On Fri, Nov 15, 2013 at 10:59:57AM +0800, Nicolin Chen wrote:
> Hi Shawn,
>
> On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> > On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > > This series of patches need to be applied into one single tree because
> > > the second patch depends on the first one. Without it, SSI would playback
> > > constant noise to the right channel when playback monaural audio files on
> > > i.MX6 Series board.
> > 
> > Let me try to understand if the dependency is true.
> > 
> > Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> > patch on his tree, will there be any regression on either IMX tree or
> > Mark's tree?  The monaural playback on imx6qdl never worked, so it's not
> > a regression.  If there is no regression on either tree, there is no
> > dependency to maintain.
> 
> It's fair enough to understand in this way. It looks like I misunderstood
> the dependency here.
> 
> Do I need to resend them separately?

No, I will just pick up the DTS patch with some testing.

Shawn

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes

2013-11-14 Thread Varun Sethi 
Haiying/Scott,
Forgot to mention this, the PAMU driver has to handle stash destination 
settings both for power and dsp cores (on B4 platform). For the dsp cores we 
would expect the physical core id (not controlled by Linux). To make the 
interface consistent, I would expect the caller (for iommu_set_attr) to pass 
the physical core id.

Regards
Varun

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, November 15, 2013 3:40 AM
> To: Wang Haiying-R54964
> Cc: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-
> d...@lists.ozlabs.org; Sethi Varun-B16395
> Subject: Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the
> matched cpu nodes
> 
> On Thu, 2013-11-14 at 14:30 -0500, Haiying Wang wrote:
> > In the case we miss to bring up some cpus, we need to make sure we can
> > find the correct cpu nodes in the device tree based on the given
> > logical cpu index from the caller.
> >
> > Signed-off-by: Haiying Wang 
> > ---
> >  drivers/iommu/fsl_pamu.c |3 ++-
> >  1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c index
> > cba0498..a9ab57b 100644
> > --- a/drivers/iommu/fsl_pamu.c
> > +++ b/drivers/iommu/fsl_pamu.c
> > @@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
> 
> Should probably also s/vcpu/cpu/g as vcpu makes no sense outside of
> virtualization code.
> 
> > u32 cache_level;
> > int len, found = 0;
> > int i;
> > +   u32 cpuid = get_hard_smp_processor_id(vcpu);
> 
> s/cpuid/phys_cpu/ or similar
> 
> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c

2013-11-14 Thread Nicolin Chen 
Hi Shawn,
   
On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > This series of patches need to be applied into one single tree because
> > the second patch depends on the first one. Without it, SSI would playback
> > constant noise to the right channel when playback monaural audio files on
> > i.MX6 Series board.
> 
> Let me try to understand if the dependency is true.
> 
> Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> patch on his tree, will there be any regression on either IMX tree or
> Mark's tree?  The monaural playback on imx6qdl never worked, so it's not
> a regression.  If there is no regression on either tree, there is no
> dependency to maintain.

It's fair enough to understand in this way. It looks like I misunderstood
the dependency here.

Do I need to resend them separately?

Thank you.

> 
> Shawn
> 
> > 
> > We might also need to apply the iomux change to the other i.MX platforms,
> > just currently I don't have those boards so I drop their changes for now.
> > 
> > Nicolin Chen (2):
> >   ARM: dts: imx: specify the value of audmux pinctrl instead of
> > 0x8000
> >   ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
> > 
> >  arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
> >  sound/soc/fsl/fsl_ssi.c| 22 +++---
> >  2 files changed, 30 insertions(+), 14 deletions(-)
> > 
> > -- 
> > 1.8.4
> > 
> > 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c

2013-11-14 Thread Shawn Guo 
On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> This series of patches need to be applied into one single tree because
> the second patch depends on the first one. Without it, SSI would playback
> constant noise to the right channel when playback monaural audio files on
> i.MX6 Series board.

Let me try to understand if the dependency is true.

Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
patch on his tree, will there be any regression on either IMX tree or
Mark's tree?  The monaural playback on imx6qdl never worked, so it's not
a regression.  If there is no regression on either tree, there is no
dependency to maintain.

Shawn

> 
> We might also need to apply the iomux change to the other i.MX platforms,
> just currently I don't have those boards so I drop their changes for now.
> 
> Nicolin Chen (2):
>   ARM: dts: imx: specify the value of audmux pinctrl instead of
> 0x8000
>   ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
> 
>  arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
>  sound/soc/fsl/fsl_ssi.c| 22 +++---
>  2 files changed, 30 insertions(+), 14 deletions(-)
> 
> -- 
> 1.8.4
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes

2013-11-14 Thread Scott Wood 
On Thu, 2013-11-14 at 14:30 -0500, Haiying Wang wrote:
> In the case we miss to bring up some cpus, we need to make sure we can
> find the correct cpu nodes in the device tree based on the given logical
> cpu index from the caller.
> 
> Signed-off-by: Haiying Wang 
> ---
>  drivers/iommu/fsl_pamu.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index cba0498..a9ab57b 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)

Should probably also s/vcpu/cpu/g as vcpu makes no sense outside of
virtualization code.

>   u32 cache_level;
>   int len, found = 0;
>   int i;
> + u32 cpuid = get_hard_smp_processor_id(vcpu);

s/cpuid/phys_cpu/ or similar

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers

2013-11-14 Thread Gerhard Sittig 
On Tue, Nov 12, 2013 at 16:23 +0400, Alexander Popov wrote:
> 
> 2013/11/12 Gerhard Sittig :
> > 
> > It would be nice to get a response to the feedback that you
> > are given.  It may be appropriate not to obey to the
> > feedback, but at least it should get considered.
> 
> Yes, I see. My implicit response by RFCv5 was not efficient,
> sorry.  Now should I write a detailed answer in the thread with
> your feedback for improving readability of the discussion?

Don't you have a checklist of which feedback you got and which of
it you did address and which you didn't?  Reviewers don't usually
do the tracking for those who do the submissions.

I think that you may list "pending issues" or "non-issues" either
with new submissions or at the previous version's feedback,
whatever is more appropriate.  Maybe "pending" is useful with the
new announcement, while "won't, need not" is better kept with the
reviews.

As for the not yet addressed feedback:  From the top of my head I
can think of the execute comment which contradicts the code
(which suggests that at least one of them is wrong), and the data
type mismatch in the config routine (where code just happens to
work by coincidence).  And in bypassing I noticed that your
recent submission has coding style issues (braces, indentation),
which should no longer happen after several iterations as you
should know how to prepare and check the next version.

Again:  It may be OK to not follow the advice (especially if you
get multiple responses of differrent direction, or when you are
more familiar with the subject than an observer).  But you should
state when you don't agree and why.  Without feedback, reviewers
may see several submissions which suffer from the same issues,
and expect more to show up and thus feel that their feedback is
getting ignored.  Which quickly becomes tiring.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes

2013-11-14 Thread Haiying Wang 
In the case we miss to bring up some cpus, we need to make sure we can
find the correct cpu nodes in the device tree based on the given logical
cpu index from the caller.

Signed-off-by: Haiying Wang 
---
 drivers/iommu/fsl_pamu.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index cba0498..a9ab57b 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
u32 cache_level;
int len, found = 0;
int i;
+   u32 cpuid = get_hard_smp_processor_id(vcpu);
 
/* Fastpath, exit early if L3/CPC cache is target for stashing */
if (stash_dest_hint == PAMU_ATTR_CACHE_L3) {
@@ -559,7 +560,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
for_each_node_by_type(node, "cpu") {
prop = of_get_property(node, "reg", &len);
for (i = 0; i < len / sizeof(u32); i++) {
-   if (be32_to_cpup(&prop[i]) == vcpu) {
+   if (be32_to_cpup(&prop[i]) == cpuid) {
found = 1;
goto found_cpu_node;
}
-- 
1.7.3.1.50.g1e633




___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problem reading and programming memory location...

2013-11-14 Thread neorf3k 
Sorry, the address is 0x1002.
I've executed this code:

/* code */
   unsigned char *virt_base;
u8 regval;

/* map 4kbyte reg. space */
virt_base = ioremap(0x1002, 0x1000);
if (!virt_base) {
printk("fpga ioremap failed\n");
return;
}

regval = in_8(virt_base);


printk("reg. value 0x%02x\n", regval);
printk("reg. value %x\n", virt_base);
/* code */

and i've:

reg. value 0x10
address c90e8000

in U-BOOT in reg. value i've: 0xf8

Thank you so much again…

Lorenzo

On 14/nov/2013, at 10:09 AM, Anatolij Gustschin  wrote:

>  u8 regval;
> 
>   /* map 4kbyte reg. space */
>   virt_base = ioremap(0x1002, 0x1000);
>   if (!virt_base) {
> printk("fpga ioremap failed\n");
> return;
>   }
> 
>   regval = in_8(virt_base);
> 
>   printk("reg. value 0x%02x\n", regval);

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000

2013-11-14 Thread Nicolin Chen 
We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
Thus change bypass value 0x8000 to what we exactly need.

This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
up/down the pin after turning into tristate. When we use SSI normal mode to
playback monaural audio via I2S signal, there'd be a pulled curve occur to
its signal at the second slot if setting PUE bit for TXD. And it will make
the second channel to play a constant noise. So by keeping the signal level
in the second slot, we can get a constant high level signal (-1) or a low
level one (0).

Signed-off-by: Nicolin Chen 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6e096ca..6b76e55 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -601,27 +601,27 @@
audmux {
pinctrl_audmux_1: audmux-1 {
fsl,pins = <
-   
MX6QDL_PAD_SD2_DAT0__AUD4_RXD  0x8000
-   
MX6QDL_PAD_SD2_DAT3__AUD4_TXC  0x8000
-   
MX6QDL_PAD_SD2_DAT2__AUD4_TXD  0x8000
-   
MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x8000
+   
MX6QDL_PAD_SD2_DAT0__AUD4_RXD  0x130b0
+   
MX6QDL_PAD_SD2_DAT3__AUD4_TXC  0x130b0
+   
MX6QDL_PAD_SD2_DAT2__AUD4_TXD  0x110b0
+   
MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x130b0
>;
};
 
pinctrl_audmux_2: audmux-2 {
fsl,pins = <
-   
MX6QDL_PAD_CSI0_DAT7__AUD3_RXD  0x8000
-   
MX6QDL_PAD_CSI0_DAT4__AUD3_TXC  0x8000
-   
MX6QDL_PAD_CSI0_DAT5__AUD3_TXD  0x8000
-   
MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x8000
+   
MX6QDL_PAD_CSI0_DAT7__AUD3_RXD  0x130b0
+   
MX6QDL_PAD_CSI0_DAT4__AUD3_TXC  0x130b0
+   
MX6QDL_PAD_CSI0_DAT5__AUD3_TXD  0x110b0
+   
MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
>;
};
 
pinctrl_audmux_3: audmux-3 {
fsl,pins = <
-   
MX6QDL_PAD_DISP0_DAT16__AUD5_TXC  0x8000
-   
MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x8000
-   
MX6QDL_PAD_DISP0_DAT19__AUD5_RXD  0x8000
+   
MX6QDL_PAD_DISP0_DAT16__AUD5_TXC  0x130b0
+   
MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x130b0
+   
MX6QDL_PAD_DISP0_DAT19__AUD5_RXD  0x130b0
>;
};
};
-- 
1.8.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface

2013-11-14 Thread Nicolin Chen 
The normal mode of SSI allows it to send/receive data to/from the first
slot of each period. So we can use this normal mode to trick I2S signal
by puting/getting data to/from the first slot only (the left channel)
so as to support monaural audio playback and recording.

Signed-off-by: Nicolin Chen 
---
 sound/soc/fsl/fsl_ssi.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index f43be6d..ccf1d38 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -517,10 +517,12 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream 
*substream,
 {
struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+   unsigned int channels = params_channels(hw_params);
unsigned int sample_size =
snd_pcm_format_width(params_format(hw_params));
u32 wl = CCSR_SSI_SxCCR_WL(sample_size);
int enabled = read_ssi(&ssi->scr) & CCSR_SSI_SCR_SSIEN;
+   static u8 i2s_mode;
 
/*
 * If we're in synchronous mode, and the SSI is already enabled,
@@ -546,6 +548,21 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream 
*substream,
else
write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_WL_MASK, wl);
 
+   if (ssi_private->imx_ac97)
+   return 0;
+
+   /* Save i2s mode configuration so that we can restore it later */
+   switch (read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK) {
+   case CCSR_SSI_SCR_I2S_MODE_SLAVE:
+   case CCSR_SSI_SCR_I2S_MODE_MASTER:
+   i2s_mode = read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK;
+   default:
+   break;
+   }
+
+   write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,
+   channels == 1 ? 0 : CCSR_SSI_SCR_NET | i2s_mode);
+
return 0;
 }
 
@@ -658,14 +675,13 @@ static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
 static struct snd_soc_dai_driver fsl_ssi_dai_template = {
.probe = fsl_ssi_dai_probe,
.playback = {
-   /* The SSI does not support monaural audio. */
-   .channels_min = 2,
+   .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
},
.capture = {
-   .channels_min = 2,
+   .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
-- 
1.8.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 0/2] Add monaural audio support for fsl_ssi.c

2013-11-14 Thread Nicolin Chen 
This series of patches need to be applied into one single tree because
the second patch depends on the first one. Without it, SSI would playback
constant noise to the right channel when playback monaural audio files on
i.MX6 Series board.

We might also need to apply the iomux change to the other i.MX platforms,
just currently I don't have those boards so I drop their changes for now.

Nicolin Chen (2):
  ARM: dts: imx: specify the value of audmux pinctrl instead of
0x8000
  ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface

 arch/arm/boot/dts/imx6qdl.dtsi | 22 +++---
 sound/soc/fsl/fsl_ssi.c| 22 +++---
 2 files changed, 30 insertions(+), 14 deletions(-)

-- 
1.8.4


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 00/11] Consolidate asm/fixmap.h files

2013-11-14 Thread Michal Simek 
On 11/12/2013 04:55 PM, Mark Salter wrote:
> On Tue, 2013-11-12 at 16:39 +0100, Michal Simek wrote:
>> On 11/12/2013 02:22 PM, Mark Salter wrote:
>>>
>>>  arch/arm/include/asm/fixmap.h|  25 ++--
>>>  arch/hexagon/include/asm/fixmap.h|  40 +
>>>  arch/metag/include/asm/fixmap.h  |  32 +--
>>>  arch/microblaze/include/asm/fixmap.h |  44 +-
>>>  arch/mips/include/asm/fixmap.h   |  33 +--
>>>  arch/powerpc/include/asm/fixmap.h|  44 +-
>>>  arch/sh/include/asm/fixmap.h |  39 +
>>>  arch/tile/include/asm/fixmap.h   |  33 +--
>>>  arch/um/include/asm/fixmap.h |  40 +
>>>  arch/x86/include/asm/fixmap.h|  59 +--
>>>  include/asm-generic/fixmap.h | 107 
>>> +++
>>>  11 files changed, 125 insertions(+), 371 deletions(-)
>>>  create mode 100644 include/asm-generic/fixmap.h
>>
>> Any repo/branch with all these patches will be helpful.
> 
> https://github.com/mosalter/linux (fixmap branch)

Thanks,

For Microblaze
Tested-by: Michal Simek 

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problem reading and programming memory location...

2013-11-14 Thread neorf3k 
Thank you again…
we have checked, and the settings in Chip Select 4 Configuration, seems to be 
ok…

The strange thing is the return value from ioremap(). In U-Boot return value 
from address 0x1002000 is 0x45f80360… if we try to map it in our module, then 
we use ioremap(), return value is 0x10101010. So maybe the register address is 
mapped wrong… what could i fix it?
Then, after we have setted up the reg at 0x1002000 and we boot linux… the 
0x1002000 doesn’t change its value… 

Thanks again…

Lorenzo

On 13/nov/2013, at 07:06 PM, Anatolij Gustschin  wrote:

> On Wed, 13 Nov 2013 14:48:24 +0100
> neorf3k  wrote:
> 
>> Yes, that is a device on the lpb via an fpga. We  have tried to configure
>> the chip select 4 configuration register at address MBAR + 0x0310, and it
>> seems to be ok. what do you mean with “chip select parameters”?
> 
> I meant the settings you can set up in the Chip Select 1–7 Configuration
> Registers, like address and data bus size, wait-states, etc.
> 
>> We have been able to edit it in U-BOOT, and the board (that chip) now works…
>> The strange thing, is that when we read in linux, at that address, we see
>> other content value…
>> Suggestions?
> 
> if you can access the register under U-Boot and read out the
> expected values, then the access should work under Linux too,
> assuming the chip select config is not overwritten somewhere
> while booting and the register address range is mapped correctly.
> I don't know your code, so I would first check if the register
> mapping is done correctly, i.e. check the return value of ioremap()
> for errors, then check if the chip select configuration is still
> valid when the kernel is up. Also verify that your fpga is not
> in the reset state when Linux is running.
> 
> thanks,
> 
> Anatolij

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev