Re: [PATCH 5/9] powerpc/85xx: disable irq by hardware when suspend for 64-bit

2014-03-12 Thread Chenhui Zhao
On Tue, Mar 11, 2014 at 06:51:20PM -0500, Scott Wood wrote:
> On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > In 64-bit mode, kernel just clears the irq soft-enable flag
> > in struct paca_struct to disable external irqs. But, in
> > the case of suspend, irqs should be disabled by hardware.
> > Therefore, hook a function to ppc_md.suspend_disable_irqs
> > to really disable irqs.
> > 
> > Signed-off-by: Chenhui Zhao 
> > ---
> >  arch/powerpc/platforms/85xx/corenet_generic.c |   12 
> >  1 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c 
> > b/arch/powerpc/platforms/85xx/corenet_generic.c
> > index 3fdf9f3..983d81f 100644
> > --- a/arch/powerpc/platforms/85xx/corenet_generic.c
> > +++ b/arch/powerpc/platforms/85xx/corenet_generic.c
> > @@ -32,6 +32,13 @@
> >  #include 
> >  #include "smp.h"
> >  
> > +#if defined(CONFIG_PPC64) && defined(CONFIG_SUSPEND)
> > +static void fsl_suspend_disable_irqs(void)
> > +{
> > +   __hard_irq_disable();
> > +}
> > +#endif
> 
> Why the underscore version?  Don't you want PACA_IRQ_HARD_DIS to be set?
> 
> If hard disabling is appropriate here, shouldn't we do it in
> generic_suspend_disable_irqs()?
> 
> Are there any existing platforms that supply a
> ppc_md.suspend_disable_irqs()?  I don't see any when grepping.
> 
> -Scott

Will use hard_irq_disable().

I think this is a general problem for powerpc.
Should clear MSR_EE before suspend. I agree to put it
in generic_suspend_disable_irqs().

-Chenhui

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

Re: [PATCH 6/9] powerpc/85xx: support sleep feature on QorIQ SoCs with RCPM

2014-03-12 Thread Chenhui Zhao
On Tue, Mar 11, 2014 at 07:00:27PM -0500, Scott Wood wrote:
> On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > In sleep mode, the clocks of e500 cores and unused IP blocks is
> > turned off. The IP blocks which are allowed to wake up the processor
> > are still running.
> > 
> > The sleep mode is equal to the Standby state in Linux. Use the
> > command to enter sleep mode:
> >   echo standby > /sys/power/state
> > 
> > Signed-off-by: Chenhui Zhao 
> > ---
> >  arch/powerpc/Kconfig   |4 +-
> >  arch/powerpc/platforms/85xx/Makefile   |3 +
> >  arch/powerpc/platforms/85xx/qoriq_pm.c |   78 
> > 
> >  3 files changed, 83 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/powerpc/platforms/85xx/qoriq_pm.c
> > 
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 05f6323..e1d6510 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -222,7 +222,7 @@ config ARCH_HIBERNATION_POSSIBLE
> >  config ARCH_SUSPEND_POSSIBLE
> > def_bool y
> > depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx || \
> > -  (PPC_85xx && !PPC_E500MC) || PPC_86xx || PPC_PSERIES \
> > +  FSL_SOC_BOOKE || PPC_86xx || PPC_PSERIES \
> >|| 44x || 40x
> >  
> >  config PPC_DCR_NATIVE
> > @@ -709,7 +709,7 @@ config FSL_PCI
> >  config FSL_PMC
> > bool
> > default y
> > -   depends on SUSPEND && (PPC_85xx || PPC_86xx)
> > +   depends on SUSPEND && (PPC_85xx && !PPC_E500MC || PPC_86xx)
> 
> Don't mix && and || without parentheses.
> 
> Maybe convert this into being selected (similar to FSL_RCPM), rather
> than default y?

Yes, will do.

> 
> > diff --git a/arch/powerpc/platforms/85xx/Makefile 
> > b/arch/powerpc/platforms/85xx/Makefile
> > index 25cebe7..7fae817 100644
> > --- a/arch/powerpc/platforms/85xx/Makefile
> > +++ b/arch/powerpc/platforms/85xx/Makefile
> > @@ -2,6 +2,9 @@
> >  # Makefile for the PowerPC 85xx linux kernel.
> >  #
> >  obj-$(CONFIG_SMP) += smp.o
> > +ifeq ($(CONFIG_FSL_CORENET_RCPM), y)
> > +obj-$(CONFIG_SUSPEND)  += qoriq_pm.o
> > +endif
> 
> There should probably be a kconfig symbol for this.

OK.

> 
> > diff --git a/arch/powerpc/platforms/85xx/qoriq_pm.c 
> > b/arch/powerpc/platforms/85xx/qoriq_pm.c
> > new file mode 100644
> > index 000..915b13b
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/85xx/qoriq_pm.c
> > @@ -0,0 +1,78 @@
> > +/*
> > + * Support Power Management feature
> > + *
> > + * Copyright 2014 Freescale Semiconductor Inc.
> > + *
> > + * Author: Chenhui Zhao 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#define FSL_SLEEP  0x1
> > +#define FSL_DEEP_SLEEP 0x2
> 
> FSL_DEEP_SLEEP is unused.

Will be used in the last patch.
[PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

> 
> > +
> > +/* specify the sleep state of the present platform */
> > +int sleep_pm_state;
> > +/* supported sleep modes by the present platform */
> > +static unsigned int sleep_modes;
> 
> Why is one signed and the other unsigned?

Undesigned. Will change them all to unsigned.

> 
> > +
> > +static int qoriq_suspend_enter(suspend_state_t state)
> > +{
> > +   int ret = 0;
> > +
> > +   switch (state) {
> > +   case PM_SUSPEND_STANDBY:
> > +
> > +   if (cur_cpu_spec->cpu_flush_caches)
> > +   cur_cpu_spec->cpu_flush_caches();
> > +
> > +   ret = qoriq_pm_ops->plat_enter_state(sleep_pm_state);
> > +
> > +   break;
> > +
> > +   default:
> > +   ret = -EINVAL;
> > +
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static int qoriq_suspend_valid(suspend_state_t state)
> > +{
> > +   if (state == PM_SUSPEND_STANDBY && (sleep_modes & FSL_SLEEP))
> > +   return 1;
> > +
> > +   return 0;
> > +}
> > +
> > +static const struct platform_suspend_ops qoriq_suspend_ops = {
> > +   .valid = qoriq_suspend_valid,
> > +   .enter = qoriq_suspend_enter,
> > +};
> > +
> > +static int __init qoriq_suspend_init(void)
> > +{
> > +   struct device_node *np;
> > +
> > +   sleep_modes = FSL_SLEEP;
> > +   sleep_pm_state = PLAT_PM_SLEEP;
> > +
> > +   np = of_find_compatible_node(NULL, NULL, "fsl,qoriq-rcpm-2.0");
> > +   if (np)
> > +   sleep_pm_state = PLAT_PM_LPM20;
> > +
> > +   suspend_set_ops(&qoriq_suspend_ops);
> > +
> > +   return 0;
> > +}
> > +arch_initcall(qoriq_suspend_init);
> 
> Why is this not a platform driver?  If fsl_pmc can do it...
> 
> -Scott

It can be, but what advantage of being a platform driver.

-Chenhui

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https

[PATCH] powerpc/le: Show the endianess of the LPAR under PowerVM.

2014-03-12 Thread Tony Breeds
Signed-off-by: Tony Breeds 
---
 arch/powerpc/platforms/pseries/setup.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 972df0f..5a32caa 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -516,7 +516,11 @@ static void __init pSeries_setup_arch(void)
 static int __init pSeries_init_panel(void)
 {
/* Manually leave the kernel version on the panel. */
+#ifdef __BIG_ENDIAN__
ppc_md.progress("Linux ppc64\n", 0);
+#else
+   ppc_md.progress("Linux ppc64le\n", 0);
+#endif
ppc_md.progress(init_utsname()->version, 0);
 
return 0;
-- 
1.8.5.3


Yours Tony


pgpn_jgEk0TVp.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] T1040RDB: add qe node for T1040RDB dts

2014-03-12 Thread Zhao Qiang
Signed-off-by: Zhao Qiang 
---
 arch/powerpc/boot/dts/t1040rdb.dts | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/powerpc/boot/dts/t1040rdb.dts 
b/arch/powerpc/boot/dts/t1040rdb.dts
index e2eee18..6ff0412 100644
--- a/arch/powerpc/boot/dts/t1040rdb.dts
+++ b/arch/powerpc/boot/dts/t1040rdb.dts
@@ -268,6 +268,49 @@
fsl,fman-mac = <&enet4>;
};
};
+
+   qe: qe@ffe13 {
+   ranges = <0x0 0xf 0xfe14 0x4>;
+   reg = <0xf 0xfe14 0 0x480>;
+   brg-frequency = <0>;
+   bus-frequency = <0>;
+
+   si1: si@700 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,qe-si";
+   reg = <0x700 0x80>;
+   };
+
+   siram1: siram@1000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "fsl,qe-siram";
+   reg = <0x1000 0x800>;
+   };
+
+   tdma: ucc@2000 {
+   compatible = "fsl,ucc-tdm";
+   rx-clock-name = "clk3";
+   tx-clock-name = "clk4";
+   fsl,rx-sync-clock = "rsync_pin";
+   fsl,tx-sync-clock = "tsync_pin";
+   fsl,tx-timeslot = <0xfffe>;
+   fsl,rx-timeslot = <0xfffe>;
+   fsl,tdm-framer-type = "e1";
+   fsl,tdm-mode = "normal";
+   fsl,tdm-id = <0>;
+   fsl,siram-entry-id = <0>;
+   };
+
+   serial: ucc@2200 {
+   device_type = "serial";
+   compatible = "ucc_uart";
+   port-number = <1>;
+   rx-clock-name = "brg2";
+   tx-clock-name = "brg2";
+   };
+   };
 };
 /include/ "fsl/t1040si-post.dtsi"
 /include/ "fsl/qoriq-dpaa-res3.dtsi"
-- 
1.8.5


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

Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep

2014-03-12 Thread Chenhui Zhao
On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote:
> On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > From: Hongbo Zhang 
> > 
> > In the last stage of deep sleep, software will trigger a Finite
> > State Machine (FSM) to control the hardware precedure, such as
> > board isolation, killing PLLs, removing power, and so on.
> > 
> > When the system is waked up by an interrupt, the FSM controls the
> > hardware to complete the early resume precedure.
> > 
> > This patch configure the EPU FSM preparing for deep sleep.
> > 
> > Signed-off-by: Hongbo Zhang 
> > Signed-off-by: Chenhui Zhao 
> 
> Couldn't this be part of qoriq_pm.c?

Put the code in drivers/platform/fsl/ so that LS1 can share these code.

> 
> > diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
> > index 9b9a34a..eb83a30 100644
> > --- a/arch/powerpc/sysdev/fsl_soc.h
> > +++ b/arch/powerpc/sysdev/fsl_soc.h
> > @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops;
> >  
> >  extern int fsl_rcpm_init(void);
> >  
> > +extern void fsl_dp_fsm_setup(void *dcsr_base);
> > +extern void fsl_dp_fsm_clean(void *dcsr_base);
> 
> __iomem

Thanks. Will add.

> 
> > +
> >  #endif
> >  #endif
> > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
> > index 09fde58..6539e6d 100644
> > --- a/drivers/platform/Kconfig
> > +++ b/drivers/platform/Kconfig
> > @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig"
> >  endif
> >  
> >  source "drivers/platform/chrome/Kconfig"
> > +
> > +if FSL_SOC
> > +source "drivers/platform/fsl/Kconfig"
> > +endif
> 
> Chrome doesn't need an ifdef -- why does this?

Don't wish other platform see these options, and the X86 and GOLDFISH have
ifdefs.

> 
> > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
> > index 3656b7b..37c6f72 100644
> > --- a/drivers/platform/Makefile
> > +++ b/drivers/platform/Makefile
> > @@ -6,3 +6,4 @@ obj-$(CONFIG_X86)   += x86/
> >  obj-$(CONFIG_OLPC) += olpc/
> >  obj-$(CONFIG_GOLDFISH) += goldfish/
> >  obj-$(CONFIG_CHROME_PLATFORMS) += chrome/
> > +obj-$(CONFIG_FSL_SOC)  += fsl/
> > diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig
> > new file mode 100644
> > index 000..72ed053
> > --- /dev/null
> > +++ b/drivers/platform/fsl/Kconfig
> > @@ -0,0 +1,10 @@
> > +#
> > +# Freescale Specific Power Management Drivers
> > +#
> > +
> > +config FSL_SLEEP_FSM
> > +   bool
> > +   help
> > + This driver configures a hardware FSM (Finite State Machine) for deep 
> > sleep.
> > + The FSM is used to finish clean-ups at the last stage of system 
> > entering deep
> > + sleep, and also wakes up system when a wake up event happens.
> > diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile
> > new file mode 100644
> > index 000..d99ca0e
> > --- /dev/null
> > +++ b/drivers/platform/fsl/Makefile
> > @@ -0,0 +1,5 @@
> > +#
> > +# Makefile for linux/drivers/platform/fsl
> > +# Freescale Specific Power Management Drivers
> > +#
> > +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o
> 
> Why is this here while the other stuff is in arch/powerpc/sysdev?
> 
> > +/* Block offsets */
> > +#defineRCPM_BLOCK_OFFSET   0x00022000
> > +#defineEPU_BLOCK_OFFSET0x
> > +#defineNPC_BLOCK_OFFSET0x1000
> 
> Why don't these block offsets come from the device tree?

Have maped DCSR registers. Don't wish to remap them.

> 
> > +static void *g_dcsr_base;
> 
> __iomem

OK.

> 
> > +   /* Configure the EPU Counters */
> > +   epu_write(EPCCR15, 0x9284);
> > +   epu_write(EPCCR14, 0x9284);
> > +   epu_write(EPCCR12, 0x9284);
> > +   epu_write(EPCCR11, 0x9284);
> > +   epu_write(EPCCR10, 0x9284);
> > +   epu_write(EPCCR9, 0x9284);
> > +   epu_write(EPCCR8, 0x9284);
> > +   epu_write(EPCCR5, 0x9284);
> > +   epu_write(EPCCR4, 0x9284);
> > +   epu_write(EPCCR2, 0x9284);
> > +
> > +   /* Configure the SCUs Inputs */
> > +   epu_write(EPSMCR15, 0x7600);
> > +   epu_write(EPSMCR14, 0x0031);
> > +   epu_write(EPSMCR13, 0x3100);
> > +   epu_write(EPSMCR12, 0x7F00);
> > +   epu_write(EPSMCR11, 0x3174);
> > +   epu_write(EPSMCR10, 0x6530);
> > +   epu_write(EPSMCR9, 0x3000);
> > +   epu_write(EPSMCR8, 0x6430);
> > +   epu_write(EPSMCR7, 0x3000);
> > +   epu_write(EPSMCR6, 0x7C00);
> > +   epu_write(EPSMCR5, 0x2E00);
> > +   epu_write(EPSMCR4, 0x002F);
> > +   epu_write(EPSMCR3, 0x2F00);
> > +   epu_write(EPSMCR2, 0x6C70);
> 
> Where do these magic numbers come from?  Which chips are they valid for?

They are for T1040. Can be found in the RCPM chapter of T1040RM.

> 
> > +void fsl_dp_fsm_clean(void *dcsr_base)
> > +{
> > +
> > +   epu_write(EPEVTCR2, 0);
> > +   epu_write(EPEVTCR9, 0);
> > +
> > +   epu_write(EPGCR, 0);
> > +   epu_write(EPECR15, 0);
> > +
> > +   rcpm_write(CSTTACR0, 0);
> > +   rcpm_write(CG1CR0, 0);
> > +
> 

Re: [PATCH 8/9] powerpc/85xx: add save/restore functions for core registers

2014-03-12 Thread Chenhui Zhao
On Tue, Mar 11, 2014 at 07:45:14PM -0500, Scott Wood wrote:
> On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > From: Wang Dongsheng 
> > 
> > Add booke_cpu_state_save() and booke_cpu_state_restore() functions which 
> > can be
> > used to save/restore CPU's registers in the case of deep sleep and 
> > hibernation.
> > 
> > Supported processors: E6500, E5500, E500MC, E500v2 and E500v1.
> > 
> > Signed-off-by: Wang Dongsheng 
> > Signed-off-by: Chenhui Zhao 
> > ---
> >  arch/powerpc/include/asm/booke_save_regs.h |   96 
> >  arch/powerpc/kernel/Makefile   |1 +
> >  arch/powerpc/kernel/booke_save_regs.S  |  361 
> > 
> >  3 files changed, 458 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/powerpc/include/asm/booke_save_regs.h
> >  create mode 100644 arch/powerpc/kernel/booke_save_regs.S
> > 
> > diff --git a/arch/powerpc/include/asm/booke_save_regs.h 
> > b/arch/powerpc/include/asm/booke_save_regs.h
> > new file mode 100644
> > index 000..87c357a
> > --- /dev/null
> > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > @@ -0,0 +1,96 @@
> > +/*
> > + *  Save/restore e500 series core registers
> 
> Filename says booke, comment says e500.
> 
> Filename and comment also fail to point out that this is specifically
> for standby/suspend, not for hibernate which is implemented in
> swsusp_booke.S/swsusp_asm64.S.

Sorry for inconsistency. Will changes e500 to booke.
Hibernation and suspend can share the code.

> 
> > + *
> > + * Author: Wang Dongsheng 
> > + *
> > + * Copyright 2014 Freescale Semiconductor Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef __ASM_FSL_SLEEP_H
> > +#define __ASM_FSL_SLEEP_H
> > +
> > +/*
> > + * 8 bytes for each register, which is compatible with
> > + * both 32-bit and 64-bit registers
> > + *
> > + * Acronyms:
> > + * dw(data width)  0x08
> > + *
> > + * Map:
> > + * General-Purpose Registers
> > + * GPR1(sp)0
> > + * GPR20x8 (dw * 1)
> > + * GPR13 - GPR31   0x10 ~ 0xa0 (dw * 2 ~ dw * 20)
> 
> Putting these values in a comment separate from the code that defines it
> sounds like a good way to get a mismatch between the two.

Ok.

> 
> > + * Foating-point registers
> > + * FPR14 - FPR31   0xa8 ~ 0x130(dw * 21 ~ dw * 38)
> 
> Call enable_kernel_fp() or similar, rather than saving FP regs here.
> Likewise with altivec.  And why starting at FPR14?  Volatile versus
> nonvolatile is irrelevant because Linux doesn't participate in the FP
> ABI.  Everything is non-volatile *if* we have a user FP context
> resident, and everything is volatile otherwise.

Will remove them.

> 
> > + * Timer Registers
> > + * TCR 0x168   (dw * 45)
> > + * TB(64bit)   0x170   (dw * 46)
> > + * TBU(32bit)  0x178   (dw * 47)
> > + * TBL(32bit)  0x180   (dw * 48)
> 
> Why are you saving TBU/L separate from TB?  They're the same thing.

Will remove TBU and TBL.

> 
> > + * Interrupt Registers
> > + * IVPR0x188   (dw * 49)
> > + * IVOR0 - IVOR15  0x190 ~ 0x208   (dw * 50 ~ dw * 65)
> > + * IVOR32 - IVOR41 0x210 ~ 0x258   (dw * 66 ~ dw * 75)
> 
> What about IVOR42 (LRAT error)?

Will add it.

> 
> > + * Software-Use Registers
> > + * SPRG1   0x260   (dw * 76), 64-bit need to save.
> > + * SPRG3   0x268   (dw * 77), 32-bit need to save.
> 
> What about "CPU and NUMA node for VDSO getcpu" on 64-bit?  Currently
> SPRG3, but it will need to change for critical interrupt support.
> 
> > + * MMU Registers
> > + * PID0 - PID2 0x270 ~ 0x280   (dw * 78 ~ dw * 80)
> 
> PID1/PID2 are e500v1/v2 only -- and Linux doesn't use them outside of
> KVM (and you're not in KVM when you're running this code).
> 
> Are we ever going to have a non-zero PID at this point?

I incline to the view that saving all registers regardless of used or
unused. The good point is that it can be compliant to the future
changes of the usage of registers.

What do you think?

> 
> > + * Debug Registers
> > + * DBCR0 - DBCR2   0x288 ~ 0x298   (dw * 81 ~ dw * 83)
> > + * IAC1 - IAC4 0x2a0 ~ 0x2b8   (dw * 84 ~ dw * 87)
> > + * DAC1 - DAC2 0x2c0 ~ 0x2c8   (dw * 88 ~ dw * 89)
> > + *
> > + */
> 
> IAC3-4 are not implemented on e500.
> 
> Do we really need to save the debug registers?  We're not going to be in
> a debugged process when we do suspend.  If the concern is kgdb, it
> probably needs to be told to get out of the way during suspend for other
> reasons.

I think in the ideal case the suspend would not break any context. We
should try to save/restore all cpu state. Of cause, trade-off is
unavoida

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

2014-03-12 Thread Chenhui Zhao
On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote:
> > From: Zhao Chenhui 
> > 
> > T1040 supports deep sleep feature, which can switch off most parts of
> > the SoC when it is in deep sleep mode. This way, it becomes more
> > energy-efficient.
> > 
> > The DDR controller will also be powered off in deep sleep. Therefore,
> > the last stage (the latter part of fsl_dp_enter_low) will run without DDR
> > access. This piece of code and related TLBs will be prefetched.
> > 
> > Due to the different initialization code between 32-bit and 64-bit, they
> > have seperate resume entry and precedure.
> > 
> > The feature supports 32-bit and 64-bit kernel mode.
> > 
> > Signed-off-by: Zhao Chenhui 
> > ---
> >  arch/powerpc/include/asm/booke_save_regs.h |3 +
> >  arch/powerpc/kernel/cpu_setup_fsl_booke.S  |   17 ++
> >  arch/powerpc/kernel/head_fsl_booke.S   |   30 +++
> >  arch/powerpc/platforms/85xx/Makefile   |2 +-
> >  arch/powerpc/platforms/85xx/deepsleep.c|  201 +++
> >  arch/powerpc/platforms/85xx/qoriq_pm.c |   38 
> >  arch/powerpc/platforms/85xx/sleep.S|  295 
> > 
> >  arch/powerpc/sysdev/fsl_soc.h  |7 +
> >  8 files changed, 592 insertions(+), 1 deletions(-)
> >  create mode 100644 arch/powerpc/platforms/85xx/deepsleep.c
> >  create mode 100644 arch/powerpc/platforms/85xx/sleep.S
> > 
> > diff --git a/arch/powerpc/include/asm/booke_save_regs.h 
> > b/arch/powerpc/include/asm/booke_save_regs.h
> > index 87c357a..37c1f6c 100644
> > --- a/arch/powerpc/include/asm/booke_save_regs.h
> > +++ b/arch/powerpc/include/asm/booke_save_regs.h
> > @@ -88,6 +88,9 @@
> >  #define HIBERNATION_FLAG   1
> >  #define DEEPSLEEP_FLAG 2
> >  
> > +#define CPLD_FLAG  1
> > +#define FPGA_FLAG  2
> 
> What is this?

We have two kind of boards, QDS and RDB. They have different register
map. Use the flag to indicate the current board is using which kind
of register map.

> 
> >  #ifndef __ASSEMBLY__
> >  extern void booke_cpu_state_save(void *buf, int type);
> >  extern void *booke_cpu_state_restore(void *buf, int type);
> > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S 
> > b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > index e59d6de..ea9bc28 100644
> > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > @@ -318,6 +318,23 @@ flush_backside_L2_cache:
> >  2:
> > blr
> >  
> > +#define CPC_CPCCSR00x0
> > +#define CPC_CPCCSR0_CPCFL  0x800
> 
> This is supposed to be CPU setup, not platform setup.
> 
> > +/* r3 : the base address of CPC  */
> > +_GLOBAL(fsl_flush_cpc_cache)
> > +   lwz r6, CPC_CPCCSR0(r3)
> > +   ori r6, r6, CPC_CPCCSR0_CPCFL
> > +   stw r6, CPC_CPCCSR0(r3)
> > +   sync
> > +
> > +   /* Wait until completing the flush */
> > +1: lwz r6, CPC_CPCCSR0(r3)
> > +   andi.   r6, r6, CPC_CPCCSR0_CPCFL
> > +   bne 1b
> > +
> > +   blr
> > +
> >  _GLOBAL(__flush_caches_e500v2)
> 
> I'm not sure that this belongs here either.

Will find a better place.

> 
> > mflr r0
> > bl  flush_dcache_L1
> > diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
> > b/arch/powerpc/kernel/head_fsl_booke.S
> > index 20204fe..3285752 100644
> > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > @@ -162,6 +162,19 @@ _ENTRY(__early_start)
> >  #include "fsl_booke_entry_mapping.S"
> >  #undef ENTRY_MAPPING_BOOT_SETUP
> >  
> > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > +   /* if deep_sleep_flag != 0, jump to the deep sleep resume entry */
> > +   LOAD_REG_ADDR(r4, deep_sleep_flag)
> > +   lwz r3, 0(r4)
> > +   cmpwi   r3, 0
> > +   beq 11f
> > +   /* clear deep_sleep_flag */
> > +   li  r3, 0
> > +   stw r3, 0(r4)
> > +   b   fsl_deepsleep_resume
> > +11:
> > +#endif
> 
> Why do you come in via the normal kernel entry, versus specifying a
> direct entry point for deep sleep resume?  How does U-Boot even know
> what the normal entry is when resuming?

I wish to return to a specified point (like 64-bit mode), but the code in
fsl_booke_entry_mapping.S only can run in the first page. Because it
only setups a temp mapping of 4KB.

> 
> Be careful of the "beq set_ivor" in the CONFIG_RELOCATABLE section
> above.  Also you probably don't want the relocation code to run again
> when resuming.

When resuming, will run from the point __early_start. Don't run the code
in the CONFIG_RELOCATABLE section.

> 
> > +#if defined(CONFIG_SUSPEND) && defined(CONFIG_FSL_CORENET_RCPM)
> > +_ENTRY(__entry_deep_sleep)
> > +/*
> > + * Bootloader will jump to here when resuming from deep sleep.
> > + * After executing the init code in fsl_booke_entry_mapping.S,
> > + * will jump to the real resume entry.
> > + */
> > +   li  r8, 1
> > +   bl  12f
> > +12:mflrr9
> > +   addir9, r9, (dee

[PATCH RFC v9 0/6] MPC512x DMA slave s/g support, OF DMA lookup

2014-03-12 Thread Alexander Popov
2013/7/14 Gerhard Sittig :
> this series
> - introduces slave s/g support (that's support for DMA transfers which
>involve peripherals in contrast to mem-to-mem transfers)
> - adds device tree based lookup support for DMA channels
> - combines floating patches and related feedback which already covered
>several aspects of what the suggested LPB driver needs, to demonstrate
>how integration might be done
> - carries Q&D SD card support to enable another DMA client during test,
>while this patch needs to get dropped upon pickup

Changes in v2:
> - re-order mpc8308 related code paths for improved readability, no
>change in behaviour, introduction of symbolic channel names here
>already
> - squash 'execute() start condition' and 'terminate all' into the
>introduction of 'slave s/g prep' and 'device control' support; refuse
>s/g lists with more than one item since slave support is operational
>yet proper s/g support is missing (can get addressed later)
> - always start transfers from software on MPC8308 as there are no
>external request lines for peripheral flow control
> - drop dt-bindings header file and symbolic channel names in OF nodes

Changes in v3 and v4:
 Part 1/5:
 - use #define instead of enum since individual channels don't require
special handling.
 Part 2/5:
 - add a flag "will_access_peripheral" to DMA transfer descriptor
according recommendations of Gerhard Sittig.
This flag is set in mpc_dma_prep_memcpy() and mpc_dma_prep_slave_sg()
and is evaluated in mpc_dma_execute() to choose a type of start for
the transfer.
 - prevent descriptors of transfers which involve peripherals from
being chained together;
each of such transfers needs hardware initiated start.
 - add locking while working with struct mpc_dma_chan
according recommendations of Lars-Peter Clausen.
 - remove default nbytes value. Client kernel modules must set
src_maxburst and dst_maxburst fields of struct dma_slave_config 
(dmaengine.h).

Changes in v5:
 Part 2/5:
 - add and improve comments;
 - improve the code moving transfer descriptors from 'queued' to 'active' list
in mpc_dma_execute();
 - allow mpc_dma_prep_slave_sg() to run with non-empty 'active' list;
 - take 'mdesc' back to 'free' list in case of error in mpc_dma_prep_slave_sg();
 - improve checks of the transfer parameters;
 - provide the default value for 'maxburst' in mpc_dma_device_control().

Changes in v6:
 Part 2/5:
 - remove doubtful comment;
 - fix coding style issues;
 - set default value for 'maxburst' to 1 which applies to most cases;
 Part 3/5:
 - use dma_get_slave_channel() instead of dma_request_channel()
in new function of_dma_xlate_by_chan_id() according recommendations of
Arnd Bergmann;
 Part 4/5:
 - set DMA_PRIVATE flag for MPC512x DMA controller since its driver relies on
of_dma_xlate_by_chan_id() which doesn't use dma_request_channel()
any more; (removed in v7)
 - resolve little patch conflict;
 Part 5/5:
 - resolve little patch conflict;

Changes in v7:
 Part 2:
 - improve comment;
 Part 4:
 - split in two separate patches. Part 4/6 contains device tree
binding document and in part 5/6 MPC512x DMA controller is registered
for device tree channel lookup;
 - remove setting DMA_PRIVATE flag for MPC512x DMA controller from part 5/6;

Changes in v8:
 Part 2:
 - improve comments;
 - fix style issues;
 Part 6:
 - remove since it has become obsolete;

Changes in v9:
 A new patch (part 3/6) is added to this series according the
   feedback of Andy Shevchenko.
 Part 2/6:
 - keep style of the comments;
 - use is_slave_direction() instead of manual checks;
 - remove redundant else branches of the conditions;
 - make mpc_dma_device_control() return -ENXIO for unknown command;
 Part 6/6:
 - change according the new part 3/6;
 - fix style issues;

> known issues:
> - it's yet to get confirmed whether MPC8308 can use slave support or
>whether the DMA controller's driver shall actively reject it, the
>information that's available so far suggests that peripheral transfers
>to IP bus attached I/O is useful and shall not get blocked right away
 - adding support for transfers which don't increment the RAM address or
do increment the peripheral "port's" address is easy with
this implementation; but which options of the common API
should be used for specifying such transfers?
2014/02/13 Gerhard Sittig :
> - The MPC512x DMA completely lacks a binding document, so one
>should get added.
> - The MPC8308 hardware is similar and can re-use the MPC512x
>binding, which should be stated.
> - The Linux implementation currently has no OF based channel
>lookup support, so '#dma-cells' is "a future feature".  I guess
>the binding can and should already discuss the feature,
>regardless of whether all implementations support it.


Alexander Popov (5):
  dma: mpc512x: reorder mpc8308 specific instructions
  dma: mpc512x: add support for peripher

[PATCH RFC v9 1/6] dma: mpc512x: reorder mpc8308 specific instructions

2014-03-12 Thread Alexander Popov
Concentrate the specific code for MPC8308 in the 'if' branch
and handle MPC512x in the 'else' branch.
This modification only reorders instructions but doesn't change behaviour.

Signed-off-by: Alexander Popov 
Acked-by: Anatolij Gustschin 
Acked-by: Gerhard Sittig 
---
 drivers/dma/mpc512x_dma.c | 42 +-
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 448750d..2ce248b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -52,9 +52,17 @@
 #define MPC_DMA_DESCRIPTORS64
 
 /* Macro definitions */
-#define MPC_DMA_CHANNELS   64
 #define MPC_DMA_TCD_OFFSET 0x1000
 
+/*
+ * Maximum channel counts for individual hardware variants
+ * and the maximum channel count over all supported controllers,
+ * used for data structure size
+ */
+#define MPC8308_DMACHAN_MAX16
+#define MPC512x_DMACHAN_MAX64
+#define MPC_DMA_CHANNELS   64
+
 /* Arbitration mode of group and channel */
 #define MPC_DMA_DMACR_EDCG (1 << 31)
 #define MPC_DMA_DMACR_ERGA (1 << 3)
@@ -710,10 +718,10 @@ static int mpc_dma_probe(struct platform_device *op)
 
dma = &mdma->dma;
dma->dev = dev;
-   if (!mdma->is_mpc8308)
-   dma->chancnt = MPC_DMA_CHANNELS;
+   if (mdma->is_mpc8308)
+   dma->chancnt = MPC8308_DMACHAN_MAX;
else
-   dma->chancnt = 16; /* MPC8308 DMA has only 16 channels */
+   dma->chancnt = MPC512x_DMACHAN_MAX;
dma->device_alloc_chan_resources = mpc_dma_alloc_chan_resources;
dma->device_free_chan_resources = mpc_dma_free_chan_resources;
dma->device_issue_pending = mpc_dma_issue_pending;
@@ -747,7 +755,19 @@ static int mpc_dma_probe(struct platform_device *op)
 * - Round-robin group arbitration,
 * - Round-robin channel arbitration.
 */
-   if (!mdma->is_mpc8308) {
+   if (mdma->is_mpc8308) {
+   /* MPC8308 has 16 channels and lacks some registers */
+   out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
+
+   /* enable snooping */
+   out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
+   /* Disable error interrupts */
+   out_be32(&mdma->regs->dmaeeil, 0);
+
+   /* Clear interrupts status */
+   out_be32(&mdma->regs->dmaintl, 0x);
+   out_be32(&mdma->regs->dmaerrl, 0x);
+   } else {
out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_EDCG |
MPC_DMA_DMACR_ERGA | 
MPC_DMA_DMACR_ERCA);
 
@@ -768,18 +788,6 @@ static int mpc_dma_probe(struct platform_device *op)
/* Route interrupts to IPIC */
out_be32(&mdma->regs->dmaihsa, 0);
out_be32(&mdma->regs->dmailsa, 0);
-   } else {
-   /* MPC8308 has 16 channels and lacks some registers */
-   out_be32(&mdma->regs->dmacr, MPC_DMA_DMACR_ERCA);
-
-   /* enable snooping */
-   out_be32(&mdma->regs->dmagpor, MPC_DMA_DMAGPOR_SNOOP_ENABLE);
-   /* Disable error interrupts */
-   out_be32(&mdma->regs->dmaeeil, 0);
-
-   /* Clear interrupts status */
-   out_be32(&mdma->regs->dmaintl, 0x);
-   out_be32(&mdma->regs->dmaerrl, 0x);
}
 
/* Register DMA engine */
-- 
1.8.4.2

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

[PATCH RFC v9 2/6] dma: mpc512x: add support for peripheral transfers

2014-03-12 Thread Alexander Popov
Introduce support for slave s/g transfer preparation and the associated
device control callback in the MPC512x DMA controller driver, which adds
support for data transfers between memory and peripheral I/O to the
previously supported mem-to-mem transfers.

Signed-off-by: Alexander Popov 
---
 drivers/dma/mpc512x_dma.c | 236 +-
 1 file changed, 231 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ce248b..b1e430c 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -2,6 +2,7 @@
  * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
  * Copyright (C) Semihalf 2009
  * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2013
  *
  * Written by Piotr Ziecik . Hardware description
  * (defines, structures and comments) was taken from MPC5121 DMA driver
@@ -29,8 +30,17 @@
  */
 
 /*
- * This is initial version of MPC5121 DMA driver. Only memory to memory
- * transfers are supported (tested using dmatest module).
+ * MPC512x and MPC8308 DMA driver. It supports
+ * memory to memory data transfers (tested using dmatest module) and
+ * data transfers between memory and peripheral I/O memory
+ * by means of slave s/g with these limitations:
+ *  - chunked transfers (transfers with more than one part) are refused
+ * as long as proper support for scatter/gather is missing;
+ *  - transfers on MPC8308 always start from software as this SoC appears
+ * not to have external request lines for peripheral flow control;
+ *  - minimal memory <-> I/O memory transfer chunk is 4 bytes and consequently
+ * source and destination addresses must be 4-byte aligned
+ * and transfer size must be aligned on (4 * maxburst) boundary;
  */
 
 #include 
@@ -189,6 +199,7 @@ struct mpc_dma_desc {
dma_addr_t  tcd_paddr;
int error;
struct list_headnode;
+   int will_access_peripheral;
 };
 
 struct mpc_dma_chan {
@@ -201,6 +212,10 @@ struct mpc_dma_chan {
struct mpc_dma_tcd  *tcd;
dma_addr_t  tcd_paddr;
 
+   /* Settings for access to peripheral FIFO */
+   dma_addr_t  per_paddr;  /* FIFO address */
+   u32 tcd_nunits;
+
/* Lock for this structure */
spinlock_t  lock;
 };
@@ -251,8 +266,23 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
struct mpc_dma_desc *mdesc;
int cid = mchan->chan.chan_id;
 
-   /* Move all queued descriptors to active list */
-   list_splice_tail_init(&mchan->queued, &mchan->active);
+   while (!list_empty(&mchan->queued)) {
+   mdesc = list_first_entry(&mchan->queued,
+   struct mpc_dma_desc, node);
+   /*
+* Grab either several mem-to-mem transfer descriptors
+* or one peripheral transfer descriptor,
+* don't mix mem-to-mem and peripheral transfer descriptors
+* within the same 'active' list.
+*/
+   if (mdesc->will_access_peripheral) {
+   if (list_empty(&mchan->active))
+   list_move_tail(&mdesc->node, &mchan->active);
+   break;
+   } else {
+   list_move_tail(&mdesc->node, &mchan->active);
+   }
+   }
 
/* Chain descriptors into one transaction */
list_for_each_entry(mdesc, &mchan->active, node) {
@@ -278,7 +308,17 @@ static void mpc_dma_execute(struct mpc_dma_chan *mchan)
 
if (first != prev)
mdma->tcd[cid].e_sg = 1;
-   out_8(&mdma->regs->dmassrt, cid);
+
+   if (mdma->is_mpc8308) {
+   /* MPC8308, no request lines, software initiated start */
+   out_8(&mdma->regs->dmassrt, cid);
+   } else if (first->will_access_peripheral) {
+   /* Peripherals involved, start by external request signal */
+   out_8(&mdma->regs->dmaserq, cid);
+   } else {
+   /* Memory to memory transfer, software initiated start */
+   out_8(&mdma->regs->dmassrt, cid);
+   }
 }
 
 /* Handle interrupt on one half of DMA controller (32 channels) */
@@ -596,6 +636,7 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t dst, 
dma_addr_t src,
}
 
mdesc->error = 0;
+   mdesc->will_access_peripheral = 0;
tcd = mdesc->tcd;
 
/* Prepare Transfer Control Descriptor for this transaction */
@@ -643,6 +684,188 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t 
dst, dma_addr_t src,
return &mdesc->desc;
 }
 
+static struct dma_async_tx_descriptor *
+mpc_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ 

[PATCH RFC v9 3/6] dma: mpc512x: replace devm_request_irq() with request_irq()

2014-03-12 Thread Alexander Popov
Replace devm_request_irq() with request_irq() since there is no need
to use it because the original code always frees IRQ manually with
devm_free_irq(). Replace devm_free_irq() with free_irq() accordingly.

Signed-off-by: Alexander Popov 
---
 drivers/dma/mpc512x_dma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index b1e430c..ff7f678 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -921,16 +921,15 @@ static int mpc_dma_probe(struct platform_device *op)
mdma->tcd = (struct mpc_dma_tcd *)((u8 *)(mdma->regs)
+ MPC_DMA_TCD_OFFSET);
 
-   retval = devm_request_irq(dev, mdma->irq, &mpc_dma_irq, 0, DRV_NAME,
-   mdma);
+   retval = request_irq(mdma->irq, &mpc_dma_irq, 0, DRV_NAME, mdma);
if (retval) {
dev_err(dev, "Error requesting IRQ!\n");
return -EINVAL;
}
 
if (mdma->is_mpc8308) {
-   retval = devm_request_irq(dev, mdma->irq2, &mpc_dma_irq, 0,
-   DRV_NAME, mdma);
+   retval = request_irq(mdma->irq2, &mpc_dma_irq, 0,
+   DRV_NAME, mdma);
if (retval) {
dev_err(dev, "Error requesting IRQ2!\n");
return -EINVAL;
@@ -1020,7 +1019,7 @@ static int mpc_dma_probe(struct platform_device *op)
dev_set_drvdata(dev, mdma);
retval = dma_async_device_register(dma);
if (retval) {
-   devm_free_irq(dev, mdma->irq, mdma);
+   free_irq(mdma->irq, mdma);
irq_dispose_mapping(mdma->irq);
}
 
@@ -1033,7 +1032,7 @@ static int mpc_dma_remove(struct platform_device *op)
struct mpc_dma *mdma = dev_get_drvdata(dev);
 
dma_async_device_unregister(&mdma->dma);
-   devm_free_irq(dev, mdma->irq, mdma);
+   free_irq(mdma->irq, mdma);
irq_dispose_mapping(mdma->irq);
 
return 0;
-- 
1.8.4.2

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

[PATCH RFC v9 4/6] dma: of: Add common xlate function for matching by channel id

2014-03-12 Thread Alexander Popov
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use 
to
lookup the channel by the id.

Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.

Signed-off-by: Alexander Popov 
---
 drivers/dma/of-dma.c   | 35 +++
 include/linux/of_dma.h |  4 
 2 files changed, 39 insertions(+)

diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct 
of_phandle_args *dma_spec,
&dma_spec->args[0]);
 }
 EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec:  pointer to DMA specifier as found in the device tree
+ * @of_dma:pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which 
wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+struct of_dma *ofdma)
+{
+   struct dma_device *dev = ofdma->of_dma_data;
+   struct dma_chan *chan, *candidate = NULL;
+
+   if (!dev || dma_spec->args_count != 1)
+   return NULL;
+
+   list_for_each_entry(chan, &dev->channels, device_node)
+   if (chan->chan_id == dma_spec->args[0]) {
+   candidate = chan;
+   break;
+   }
+
+   if (!candidate)
+   return NULL;
+
+   return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct 
device_node *np,
 const char *name);
 extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args 
*dma_spec,
+   struct of_dma *ofdma);
 #else
 static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct 
of_phandle_args *dma_s
return NULL;
 }
 
+#define of_dma_xlate_by_chan_id NULL
+
 #endif
 
 #endif /* __LINUX_OF_DMA_H */
-- 
1.8.4.2

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

[PATCH RFC v9 5/6] dma: mpc512x: add device tree binding document

2014-03-12 Thread Alexander Popov
From: Gerhard Sittig 

introduce a device tree binding document for the MPC512x DMA controller

Signed-off-by: Gerhard Sittig 
[ a13xp0p0...@gmail.com: turn this into a separate patch ]
---
 .../devicetree/bindings/dma/mpc512x-dma.txt| 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt 
b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 000..a4867d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,55 @@
+* Freescale MPC512x DMA Controller
+
+The DMA controller in the Freescale MPC512x SoC can move blocks of
+memory contents between memory and peripherals or memory to memory.
+
+Refer to the "Generic DMA Controller and DMA request bindings" description
+in the dma.txt file for a more detailled discussion of the binding.  The
+MPC512x DMA engine binding follows the common scheme, but doesn't provide
+support for the optional channels and requests counters (those values are
+derived from the detected hardware features) and has a fixed client
+specifier length of 1 integer cell (the value is the DMA channel, since
+the DMA controller uses a fixed assignment of request lines per channel).
+
+
+DMA controller node properties:
+
+Required properties:
+- compatible:  should be "fsl,mpc5121-dma"
+- reg: address and size of the DMA controller's register set
+- interrupts:  interrupt spec for the DMA controller
+
+Optional properties:
+- #dma-cells:  must be <1>, describes the number of integer cells
+   needed to specify the 'dmas' property in client nodes,
+   strongly recommended since common client helper code
+   uses this property
+
+Example:
+
+   dma0: dma@14000 {
+   compatible = "fsl,mpc5121-dma";
+   reg = <0x14000 0x1800>;
+   interrupts = <65 0x8>;
+   #dma-cells = <1>;
+   };
+
+
+Client node properties:
+
+Required properties:
+- dmas:list of DMA specifiers, consisting each of a 
handle
+   for the DMA controller and integer cells to specify
+   the channel used within the DMA controller
+- dma-names:   list of identifier strings for the DMA specifiers,
+   client device driver code uses these strings to
+   have DMA channels looked up at the controller
+
+Example:
+
+   sdhc@1500 {
+   compatible = "fsl,mpc5121-sdhc";
+   /* ... */
+   dmas = <&dma0 30>;
+   dma-names = "rx-tx";
+   };
-- 
1.8.4.2

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

[PATCH RFC v9 6/6] dma: mpc512x: register for device tree channel lookup

2014-03-12 Thread Alexander Popov
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file

Signed-off-by: Gerhard Sittig 
Signed-off-by: Alexander Popov 
---
 arch/powerpc/boot/dts/mpc5121.dtsi |  1 +
 drivers/dma/mpc512x_dma.c  | 21 ++---
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi 
b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+   #dma-cells = <1>;
};
};
 
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index ff7f678..453b1cb 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1018,11 +1019,23 @@ static int mpc_dma_probe(struct platform_device *op)
/* Register DMA engine */
dev_set_drvdata(dev, mdma);
retval = dma_async_device_register(dma);
-   if (retval) {
-   free_irq(mdma->irq, mdma);
-   irq_dispose_mapping(mdma->irq);
+   if (retval)
+   goto out_irq;
+
+   /* Register with OF helpers for DMA lookups (nonfatal) */
+   if (dev->of_node) {
+   retval = of_dma_controller_register(dev->of_node,
+   of_dma_xlate_by_chan_id, mdma);
+   if (retval)
+   dev_warn(dev, "could not register for OF lookup\n");
}
 
+   return 0;
+
+out_irq:
+   free_irq(mdma->irq, mdma);
+   irq_dispose_mapping(mdma->irq);
+
return retval;
 }
 
@@ -1031,6 +1044,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
 
+   if (dev->of_node)
+   of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
free_irq(mdma->irq, mdma);
irq_dispose_mapping(mdma->irq);
-- 
1.8.4.2

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

Re: Node 0 not necessary for powerpc?

2014-03-12 Thread Christoph Lameter
On Tue, 11 Mar 2014, Nishanth Aravamudan wrote:
> I have a P7 system that has no node0, but a node0 shows up in numactl
> --hardware, which has no cpus and no memory (and no PCI devices):

Well as you see from the code there has been so far the assumption that
node 0 has memory. I have never run a machine that has no node 0 memory.

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

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

2014-03-12 Thread Scott Wood
On Wed, 2014-03-12 at 13:57 +0800, Kevin Hao wrote:
> On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
> > > + FSL_DIS_ALL_IRQ
> > > +
> > > + /*
> > > +  * Place DDR controller in self refresh mode.
> > > +  * From here on, DDR can't be access any more.
> > > +  */
> > > + lwz r10, 0(r13)
> > > + orisr10, r10, CCSR_DDR_SDRAM_CFG_2_FRC_SR@h
> > > + stw r10, 0(r13)
> > > +
> > > + /* can't call udelay() here, so use a macro to delay */
> > > + FSLDELAY(50)
> > 
> > A timebase loop doesn't require accessing DDR.
> > 
> > You also probably want to do a "sync, readback, data dependency, isync"
> > sequence to make sure that the store has hit CCSR before you begin your
> > delay (or is a delay required at all if you do that?).
> 
> Shouldn't we use "readback, sync" here? The following is quoted form t4240RM:
>   To guarantee that the results of any sequence of writes to configuration
>   registers are in effect, the final configuration register write should be
>   immediately followed by a read of the same register, and that should be
>   followed by a SYNC instruction. Then accesses can safely be made to memory
>   regions affected by the configuration register write.

I agree that the sync before the readback is probably not necessary,
since transactions to the same address should already be ordered.

A sync after the readback helps if you're trying to order the readback
with subsequent memory accesses, though in that case wouldn't a sync
alone (no readback) be adequate?  Though maybe not always -- see the
comment near the end of fsl_elbc_write_buf() in
drivers/mtd/nand_fsl_elbc.c.  I guess the readback does more than just
make sure the device has seen the write, ensuring that the device has
finished the transaction to the point of acting on another one.

The data dependency plus isync sequence, which is done by the normal I/O
accessors used from C code, orders the readback versus all future
instructions (not just I/O).  The delay loop is not I/O.

> > > + /* Enable SCU15 to trigger on RCPM Concentrator 0 */
> > > + lwz r10, 0(r15)
> > > + orisr10, r10, DCSR_EPU_EPECR15_IC0@h
> > > + stw r10, 0(r15)
> > > +
> > > + /* put Core0 in PH15 mode, trigger EPU FSM */
> > > + lwz r10, 0(r12)
> > > + ori r10, r10, CCSR_RCPM_PCPH15SETR_CORE0
> > > + stw r10, 0(r12)
> > 
> > Shouldn't there be a sync to ensure that the previous I/O happens before
> > the final store to enter PH15?
> 
> Do we really need a sync here? According to the PowerISA, the above stores
> should be performed in program order.
>   If two Store instructions or two Load instructions
>   specify storage locations that are both Caching
>   Inhibited and Guarded, the corresponding storage
>   accesses are performed in program order with
>   respect to any processor or mechanism.

OK, wasn't aware of that.

-Scott


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

[PATCH] powerpc: Update ppc4xx maintainer

2014-03-12 Thread Josh Boyer
Alistair Popple has volunteered to take over maintainership of the ppc4xx
stuff upstream.  Switch the MAINTAINERS entry over to him.

Signed-off-by: Josh Boyer 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ecfde1..6d220c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5245,11 +5245,10 @@ F:  arch/powerpc/platforms/512x/
 F: arch/powerpc/platforms/52xx/
 
 LINUX FOR POWERPC EMBEDDED PPC4XX
-M: Josh Boyer 
+M:  Alistair Popple 
 M: Matt Porter 
 W: http://www.penguinppc.org/
 L: linuxppc-dev@lists.ozlabs.org
-T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
 S: Maintained
 F: arch/powerpc/platforms/40x/
 F: arch/powerpc/platforms/44x/
-- 
1.8.5.3

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

Re: [PATCH] T1040RDB: add qe node for T1040RDB dts

2014-03-12 Thread Scott Wood
On Wed, 2014-03-12 at 16:26 +0800, Zhao Qiang wrote:
> Signed-off-by: Zhao Qiang 
> ---
>  arch/powerpc/boot/dts/t1040rdb.dts | 43 
> ++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/arch/powerpc/boot/dts/t1040rdb.dts 
> b/arch/powerpc/boot/dts/t1040rdb.dts
> index e2eee18..6ff0412 100644
> --- a/arch/powerpc/boot/dts/t1040rdb.dts
> +++ b/arch/powerpc/boot/dts/t1040rdb.dts
> @@ -268,6 +268,49 @@
>   fsl,fman-mac = <&enet4>;
>   };
>   };
> +
> + qe: qe@ffe13 {
> + ranges = <0x0 0xf 0xfe14 0x4>;
> + reg = <0xf 0xfe14 0 0x480>;

reg does not match unit address

Missing compatible

> + si1: si@700 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,qe-si";
> + reg = <0x700 0x80>;
> + };

Missing binding

> +
> + siram1: siram@1000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,qe-siram";
> + reg = <0x1000 0x800>;
> + };

Missing binding

> +
> + tdma: ucc@2000 {
> + compatible = "fsl,ucc-tdm";
> + rx-clock-name = "clk3";
> + tx-clock-name = "clk4";
> + fsl,rx-sync-clock = "rsync_pin";
> + fsl,tx-sync-clock = "tsync_pin";
> + fsl,tx-timeslot = <0xfffe>;
> + fsl,rx-timeslot = <0xfffe>;
> + fsl,tdm-framer-type = "e1";
> + fsl,tdm-mode = "normal";
> + fsl,tdm-id = <0>;
> + fsl,siram-entry-id = <0>;
> + };

Missing binding

> + serial: ucc@2200 {
> + device_type = "serial";
> + compatible = "ucc_uart";
> + port-number = <1>;
> + rx-clock-name = "brg2";
> + tx-clock-name = "brg2";
> + };

Missing binding

-Scott


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

Re: [PATCH] T1040RDB: add qe node for T1040RDB dts

2014-03-12 Thread Scott Wood
On Wed, 2014-03-12 at 16:26 +0800, Zhao Qiang wrote:
> Signed-off-by: Zhao Qiang 
> ---
>  arch/powerpc/boot/dts/t1040rdb.dts | 43 
> ++
>  1 file changed, 43 insertions(+)

Presumably this is on top of this patch:
http://patchwork.ozlabs.org/patch/314138/

...since there's no existing t1040 device tree support.  Always mention
when your patch is on top of a patch that hasn't yet been merged and
isn't in the same patch set.

At least some of this stuff seems like it should be in t1040si-post.dts
(or a file included by it), rather than the board dts.

> + tdma: ucc@2000 {
> + compatible = "fsl,ucc-tdm";
> + rx-clock-name = "clk3";
> + tx-clock-name = "clk4";
> + fsl,rx-sync-clock = "rsync_pin";
> + fsl,tx-sync-clock = "tsync_pin";
> + fsl,tx-timeslot = <0xfffe>;
> + fsl,rx-timeslot = <0xfffe>;
> + fsl,tdm-framer-type = "e1";
> + fsl,tdm-mode = "normal";
> + fsl,tdm-id = <0>;
> + fsl,siram-entry-id = <0>;
> + };
> +
> + serial: ucc@2200 {
> + device_type = "serial";
> + compatible = "ucc_uart";
> + port-number = <1>;
> + rx-clock-name = "brg2";
> + tx-clock-name = "brg2";
> + };

Missing reg.

-Scott


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

Re: [PATCH v3 00/52] CPU hotplug: Fix issues with callback registration

2014-03-12 Thread Srivatsa S. Bhat
On 03/12/2014 03:37 AM, Andrew Morton wrote:
> On Tue, 11 Mar 2014 02:03:52 +0530 "Srivatsa S. Bhat" 
>  wrote:
> 
>> Hi,
>>
>> Many subsystems and drivers have the need to register CPU hotplug callbacks
>> from their init routines and also perform initialization for the CPUs that 
>> are
>> already online. But unfortunately there is no race-free way to achieve this
>> today.
>>
>> For example, consider this piece of code:
>>
>>  get_online_cpus();
>>
>>  for_each_online_cpu(cpu)
>>  init_cpu(cpu);
>>
>>  register_cpu_notifier(&foobar_cpu_notifier);
>>
>>  put_online_cpus();
>>
>> This is not safe because there is a possibility of an ABBA deadlock involving
>> the cpu_add_remove_lock and the cpu_hotplug.lock.
>>
>>   CPU 0 CPU 1
>>   - -
>>
>>Acquire cpu_hotplug.lock
>>[via get_online_cpus()]
>>
>>   CPU online/offline operation
>>   takes cpu_add_remove_lock
>>   [via cpu_maps_update_begin()]
>>
>>Try to acquire
>>cpu_add_remove_lock
>>[via register_cpu_notifier()]
>>
>>   CPU online/offline operation
>>   tries to acquire 
>> cpu_hotplug.lock
>>   [via cpu_hotplug_begin()]
> 
> Can't we fix this by using a different (ie: new) lock to protect
> cpu_chain?
> 

No, that won't be a better solution than this one :-( The reason is that
CPU_POST_DEAD notifiers are invoked with the cpu_hotplug.lock dropped (by
design). So if we introduce the new lock, the locking would look as shown
below at the CPU hotplug side:

[ Note that it is unsafe to acquire and release the cpu-chain lock separately
for each invocation of the notifiers, because that would allow manipulations
of the cpu-chain in between two sets of notifications (such as CPU_DOWN_PREPARE
and CPU_DEAD, corresponding to the same CPU hotplug operation), which is
clearly wrong. So we need to acquire the new lock at the very beginning of
the hotplug operation and release it at the very end, after all notifiers
have been invoked.]


cpu_maps_update_begin(); //acquire cpu_add_remove_lock
cpu_hotplug_begin(); //acquire cpu_hotplug.lock

cpu_chain_lock(); //acquire a new lock that protects the cpu_chain

Invoke CPU_DOWN_PREPARE notifiers
//take cpu offline using stop-machine
Invoke CPU_DEAD notifiers

cpu_hotplug_done(); //release cpu_hotplug.lock

Invoke CPU_POST_DEAD notifiers

cpu_chain_unlock(); //release a new lock that protects the cpu_chain

cpu_maps_update_done(); //release cpu_add_remove_lock


So, if you observe the nesting of locks, it looks weird, because
cpu_hotplug.lock is acquired first, followed by cpu_chain_lock,
but they are released in the same order! IOW, they don't nest "properly".

To avoid this, if we reorder the locks in such a way that cpu_chain_lock
is the outer lock compared to cpu_hotplug.lock, then it becomes exactly
same as cpu_add_remove_lock. In other words, we can reuse the
cpu_add_remove_lock for this very purpose of protecting the cpu-chains
without adding any new lock to the CPU hotplug core code. And this is
what the existing code already does. I just utilize this fact and make
sure that we don't deadlock in the scenarios mentioned in the cover-letter
of this patchset.

Regards,
Srivatsa S. Bhat

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

RE: [PATCH] T1040RDB: add qe node for T1040RDB dts

2014-03-12 Thread qiang.z...@freescale.com
On Wed, 2014-03-13 at 2:46 AM, Scott wrote:

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 13, 2014 2:46 AM
> To: Zhao Qiang-B45475
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061
> Subject: Re: [PATCH] T1040RDB: add qe node for T1040RDB dts
> 
> On Wed, 2014-03-12 at 16:26 +0800, Zhao Qiang wrote:
> > Signed-off-by: Zhao Qiang 
> > ---
> >  arch/powerpc/boot/dts/t1040rdb.dts | 43
> > ++
> >  1 file changed, 43 insertions(+)
> 
> Presumably this is on top of this patch:
> http://patchwork.ozlabs.org/patch/314138/
> 
> ...since there's no existing t1040 device tree support.  Always mention
> when your patch is on top of a patch that hasn't yet been merged and
> isn't in the same patch set.
> 
> At least some of this stuff seems like it should be in t1040si-post.dts
> (or a file included by it), rather than the board dts.

Every board can use ucc differently, It is not correct to put this node into 
t1040si-post.dtsi.
For example t1040qds can use ucc1 to tdm while maybe t1040rdb use ucc1 to uart.

> 
> > +   tdma: ucc@2000 {
> > +   compatible = "fsl,ucc-tdm";
> > +   rx-clock-name = "clk3";
> > +   tx-clock-name = "clk4";
> > +   fsl,rx-sync-clock = "rsync_pin";
> > +   fsl,tx-sync-clock = "tsync_pin";
> > +   fsl,tx-timeslot = <0xfffe>;
> > +   fsl,rx-timeslot = <0xfffe>;
> > +   fsl,tdm-framer-type = "e1";
> > +   fsl,tdm-mode = "normal";
> > +   fsl,tdm-id = <0>;
> > +   fsl,siram-entry-id = <0>;
> > +   };
> > +
> > +   serial: ucc@2200 {
> > +   device_type = "serial";
> > +   compatible = "ucc_uart";
> > +   port-number = <1>;
> > +   rx-clock-name = "brg2";
> > +   tx-clock-name = "brg2";
> > +   };
> 
> Missing reg.
> 
> -Scott
> 

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