RE: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform

2014-09-27 Thread dongsheng.w...@freescale.com
Thanks for your review. :)


> -Original Message-
> From: Kumar Gala [mailto:ga...@codeaurora.org]
> Sent: Friday, September 26, 2014 10:04 PM
> To: Wang Dongsheng-B40534
> Cc: Santosh Shilimkar; Sandeep Nair; Olof Johansson; shawn@linaro.org; 
> Greg
> KH; Paul Walmsley; Arnd Bergmann; linux-kernel@vger.kernel.org; Guo 
> Shawn-R65073
> Subject: Re: [PATCH 2/2] soc/fsl: add ftm alarm driver for ls1021a platform
> 
> 
> On Sep 26, 2014, at 1:48 AM, Dongsheng Wang  
> wrote:
> 
> > From: Wang Dongsheng 
> >
> > Only Ftm0 can be used when system going to deep sleep. So this driver
> > to support ftm0 as a wakeup source.
> >
> > Signed-off-by: Wang Dongsheng 
> 
> How does this differ from drivers/clocksource/fsl_ftm_timer.c

Fsl_ftm_timer.c is only for system to provide a clock driver. FTM ip-block can 
be used
by other functions such as PWM. I think we should not put all of functions into 
a .c file.
So ftm0 alarm function as a specific block driver in SOC dir.

> 
> Why not extend that with the alarm functionality you need?
The framework of clocksource not provide sys interface to set alarm. And codes 
of ftm0-alarm
not touch on clocksource framework.

> 
> Also, where is the DT binding spec for this (if you plan on having a separate
> driver)?
Yes, now only a driver. My DT depend on LS1 device tree patches, now LS1 DT is 
upstreaming but not apply.
After LS1 DT apply, I will add ftm alarm device node.

Regards,
-Dongsheng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Powerpc: e1000e cannot work normally after system resume from sleep(standby)

2014-04-17 Thread dongsheng.w...@freescale.com
Hi all,

Now I'm developing Freescale PCIe power management feature. The following is my 
PCIe
suspend/resume code.

when I test system wake up from sleep(STANDBY), I got below calltrace. Looks 
like e1000e
cannot transfer data, maybe watchdog has some issue. Or maybe some of the other 
causes.
I think this is not root cause. Because If changed mdelay(10) to 20ms. E1000 
will work normal.
Maybe e1000e need more time to recover? Or ?

Here are my test results:
E1000e plug in PCIe slot 1, we need to delay 10ms.
E1000e plug in PCIe slot 2, we need to delay 20ms.
E1000e plug in PCIe slot 3, we need to delay 60ms.

Anyone have any idea about this?


*Suspend flow*: 
if (fsl_pcie_check_link(hose))
return;

/* Send PME_Turn_Off Message Request */
setbits32(&pci->pex_pmcr, PEX_PMCR_PTOMR);

/* Wait trun off done */
/* RC will get this detect quickly */
for (i = 0; i < 50; i++) {
dr = in_be32(&pci->pex_pme_mes_dr);
if (dr & ENL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}

udelay(1000);
}

/*
 * "PCI Bus Power Management Interface Specification" define
 * Minimum System Software Guaranteed Delays
 *
 * D0, D1 or D2 --> D3, need delay 10ms.
 * But we need to delay more time when EP plug in p1022 slot2.
 */
mdelay(10);


*Resume flow*:
if (fsl_pcie_check_link(hose))
return;

/* Send Exit L2 State Message */
setbits32(&pci->pex_pmcr, PEX_PMCR_EXL2S);

/* Wait exit done */
/* RC will get this detect quickly */
for (i = 0; i < 50; i++) {
dr = in_be32(&pci->pex_pme_mes_dr);
if (dr & EXL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}

udelay(1000);
}

/*
 * "PCI Bus Power Management Interface Specification" define
 * Minimum System Software Guaranteed Delays
 *
 * D3 hot --> D0, need delay 10ms.
 * But we need to delay more time when EP plug in p1022 slot2.
 */
mdelay(10);


CALL TRACE


[root@p1022 /root]# udhcpc -i eth0
udhcpc (v1.11.2) started
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending discover...
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...
Sending discover...
NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
[ cut here ]
WARNING: at net/sched/sch_generic.c:264
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-173871-g9964256-dirty #42
task: ee0534e0 ti: ee07 task.ti: ee07
NIP: c036267c LR: c036267c CTR: c028b834
REGS: ee071d00 TRAP: 0700   Not tainted  (3.14.0-173871-g9964256-dirty)
MSR: 00029000   CR: 4222  XER: 2000

GPR00: c036267c ee071db0 ee0534e0 003a c16393b0 c16398e8 01079000 c05c03a8
GPR08: 0001 0001 01079000 0132 0132  0004 c05ed040
GPR16: 0001 0100 0004 fffef539  c05c10c0 0038 
GPR24:  0001 ee07 0004 c05e c05f ee3c 
NIP [c036267c] dev_watchdog+0x2c8/0x2d8
LR [c036267c] dev_watchdog+0x2c8/0x2d8
Call Trace:
[ee071db0] [c036267c] dev_watchdog+0x2c8/0x2d8 (unreliable)
[ee071de0] [c004778c] call_timer_fn.isra.24+0x28/0x84
[ee071e00] [c00479b8] run_timer_softirq+0x1d0/0x248
[ee071e40] [c004090c] __do_softirq+0x104/0x20c
[ee071ea0] [c0040cd8] irq_exit+0xa4/0xc8
[ee071eb0] [c0009ef4] timer_interrupt+0xb8/0xdc
[ee071ed0] [c000f57c] ret_from_except+0x0/0x18
--- Exception: 901 at arch_cpu_idle+0x24/0x5c
LR = arch_cpu_idle+0x24/0x5c
[ee071f90] [c0089534] rcu_idle_enter+0xa4/0xd0 (unreliable)
[ee071fa0] [c0076010] cpu_startup_entry+0x120/0x17c
[ee071fd0] [c0010bbc] start_secondary+0x214/0x224
[ee071ff0] [c0002154] __secondary_start+0x7c/0xc8
Instruction dump:
4e800421 80fe0224 4b4c 7fc3f378 4bfe5401 7fc4f378 7c651b78 3c60c055
7fe6fb78 3863e0f4 4cc63182 480e9a05 <0fe0> 3921 993c6f38 4bb4
---[ end trace 2d4f2cedfa86e32f ]---
e1000e 0002:05:00.0: Net device Info
e1000e: Device Name statetrans_start  last_rx
e1000e: eth00003 FFFEF040 
e1000e 0002:05:00.0: Register Dump
e1000e:  Register Name   Value
e1000e: CTRL58100248
e1000e: STATUS  00080783
e1000e: CTRL_EXT1858
e1000e: ICR 
e1000e: RCTL04008002
e1000e: RDLEN   1000
e1000e: RDH 001d
e1000e: RDT 00f0
e1000e: RDTR0020
e1000e: RXDCTL[0-1] 01040420 01040420
e1000e: ERT 
e1000e: RDBAL   2d39
e1000e: RDBAH   
e1000e: RDFH020a
e1000e: RDFT020a
e1000e: RDFHS   020a
e1000e: RDFTS

RE: [RFC][PATCH 1/3] ARM: dts: vf610: Add Freescale FlexTimer Module timer node.

2014-04-15 Thread dongsheng.w...@freescale.com


> -Original Message-
> From: Xiubo Li [mailto:li.xi...@freescale.com]
> Sent: Wednesday, April 16, 2014 10:20 AM
> To: daniel.lezc...@linaro.org; t...@linutronix.de; shawn@linaro.org; Lu
> Jingchang-B35083; Jin Zhengxiong-R64188; Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Xiubo Li-B47053
> Subject: [RFC][PATCH 1/3] ARM: dts: vf610: Add Freescale FlexTimer Module 
> timer
> node.
> 
> Signed-off-by: Xiubo Li 
> Cc: Shawn Guo 
> Cc: Jingchang Lu 
> ---
>  arch/arm/boot/dts/vf610.dtsi | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
> index 107e2c0..c3a276f 100644
> --- a/arch/arm/boot/dts/vf610.dtsi
> +++ b/arch/arm/boot/dts/vf610.dtsi
> @@ -153,6 +153,19 @@
>   clock-names = "pit";
>   };
> 
> + ftm0: ftm@40038000 {
> + compatible = "fsl,vf610-ftm-timer";
> + reg = <0x40038000 0x2000>;
> + interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "ftm0", "ftm1",
> + "ftm0_counter_en", "ftm1_counter_en";
> + clocks = <&clks VF610_CLK_FTM0>,
> + <&clks VF610_CLK_FTM1>,
> + <&clks VF610_CLK_FTM0_EXT_FIX_EN>,
> + <&clks VF610_CLK_FTM1_EXT_FIX_EN>;
> + status = "disabled";
> + };
> +

They need to be separated. ftm0, ftm1.

>   wdog@4003e000 {
>   compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
>   reg = <0x4003e000 0x1000>;
> --
> 1.8.4
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [RFC][PATCH 3/3] clocksource: Add Freescale FlexTimer Module (FTM) timer support

2014-04-15 Thread dongsheng.w...@freescale.com


> -Original Message-
> From: Xiubo Li [mailto:li.xi...@freescale.com]
> Sent: Wednesday, April 16, 2014 10:20 AM
> To: daniel.lezc...@linaro.org; t...@linutronix.de; shawn@linaro.org; Lu
> Jingchang-B35083; Jin Zhengxiong-R64188; Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Xiubo Li-B47053
> Subject: [RFC][PATCH 3/3] clocksource: Add Freescale FlexTimer Module (FTM)
> timer support
> 
> The Freescale FlexTimer Module time reference is a 16-bit counter
> that can be used as an unsigned or signed counter.one 16-bits
> increase counter.
> 
> Here using the FTM0 as clock event device and the FTM1 as clock
> source device.
> 
> Signed-off-by: Xiubo Li 
> Cc: Shawn Guo 
> Cc: Jingchang Lu 
> ---
>  drivers/clocksource/Kconfig |   5 +
>  drivers/clocksource/Makefile|   1 +
>  drivers/clocksource/fsl_ftm_timer.c | 238 
> 
>  3 files changed, 244 insertions(+)
>  create mode 100644 drivers/clocksource/fsl_ftm_timer.c
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index cd6950f..28321c5 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -136,6 +136,11 @@ config CLKSRC_SAMSUNG_PWM
> for all devicetree enabled platforms. This driver will be
> needed only on systems that do not have the Exynos MCT available.
> 
> +config FSL_FTM_TIMER
> + bool
> + help
> +   Support for Freescale FlexTimer Module (FTM) timer.
> +
>  config VF_PIT_TIMER
>   bool
>   help
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index c7ca50a..ce0a967 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -31,6 +31,7 @@ obj-$(CONFIG_CADENCE_TTC_TIMER) += cadence_ttc_timer.o
>  obj-$(CONFIG_CLKSRC_EFM32)   += time-efm32.o
>  obj-$(CONFIG_CLKSRC_EXYNOS_MCT)  += exynos_mct.o
>  obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
> +obj-$(CONFIG_FSL_FTM_TIMER)  += fsl_ftm_timer.o
>  obj-$(CONFIG_VF_PIT_TIMER)   += vf_pit_timer.o
> 
>  obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
> diff --git a/drivers/clocksource/fsl_ftm_timer.c
> b/drivers/clocksource/fsl_ftm_timer.c
> new file mode 100644
> index 000..988449e
> --- /dev/null
> +++ b/drivers/clocksource/fsl_ftm_timer.c
> @@ -0,0 +1,238 @@
> +/*
> + * Freescale FlexTimer Module (FTM) timer driver.
> + *
> + * 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
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define FTM_OFFSET(n)(0x1000 * n)
> +
> +#define FTM_SC   0x00
> +#define FTM_SC_CLK_SHIFT 3
> +#define FTM_SC_CLK_MASK  (0x3 << FTM_SC_CLK_SHIFT)
> +#define FTM_SC_CLK(c)((c) << FTM_SC_CLK_SHIFT)
> +#define FTM_SC_PS_MASK   0x7
> +#define FTM_SC_TOIE  BIT(6)
> +#define FTM_SC_TOF   BIT(7)
> +
> +#define FTM_CNT  0x04
> +#define FTM_MOD  0x08
> +
> +#define FTM_CSC_BASE 0x0C
> +#define FTM_CSC_MSB  BIT(5)
> +#define FTM_CSC_MSA  BIT(4)
> +#define FTM_CSC_ELSB BIT(3)
> +#define FTM_CSC_ELSA BIT(2)
> +
> +#define FTM_CV_BASE  0x10
> +#define FTM_CNTIN0x4C
> +#define FTM_STATUS   0x50
> +
> +#define FTM_MODE 0x54
> +#define FTM_MODE_FTMEN   BIT(0)
> +#define FTM_MODE_WPDIS   BIT(2)
> +#define FTM_MODE_PWMSYNC BIT(3)
> +
> +#define FTM_SYNC 0x58
> +#define FTM_OUTINIT  0x5C
> +#define FTM_OUTMASK  0x60
> +#define FTM_COMBINE  0x64
> +#define FTM_DEADTIME 0x68
> +#define FTM_EXTTRIG  0x6C
> +#define FTM_POL  0x70
> +#define FTM_FMS  0x74
> +#define FTM_FILTER   0x78
> +#define FTM_FLTCTRL  0x7C
> +#define FTM_QDCTRL   0x80
> +#define FTM_CONF 0x84
> +#define FTM_FLTPOL   0x88
> +#define FTM_SYNCONF  0x8C
> +#define FTM_INVCTRL  0x90
> +#define FTM_SWOCTRL  0x94
> +#define FTM_PWMLOAD  0x98
> +
> +static void __iomem *clksrc_base;
> +static void __iomem *clkevt_base;
> +static unsigned long peroidic_cyc;
> +
> +static inline void __init ftm_timer_enable(void __iomem *base)
> +{
> + u32 val;
> +
> + /* select and enable counter clock source */
> + val = __raw_readl(base + FTM_SC);
> + val &= ~FTM_SC_CLK_MASK;
> + val |= FTM_SC_CLK(1);
> + __raw_writel(val, base + FTM_SC);
> +}
> +
> +static u64 ftm_read_sched_clock(void)
> +{
> + return __raw_readl(clksrc_base + FTM_CNT);
> +}
> +
> +static int __init ftm_clocksource_init(unsigned long freq)
> +{
> + int ret;
> +
> + __raw_writel(0x00, clksrc_base + FTM_CNTIN);
> + __raw_writel(~0UL, clksrc_base + FT

RE: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts for Tx and Rx streams

2014-03-31 Thread dongsheng.w...@freescale.com


> -Original Message-
> From: Nicolin Chen [mailto:guangyu.c...@freescale.com]
> Sent: Tuesday, April 01, 2014 11:38 AM
> To: Wang Dongsheng-B40534
> Cc: broo...@kernel.org; alsa-de...@alsa-project.org; Xiubo Li-B47053; 
> linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; ti...@tabi.org
> Subject: Re: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts 
> for
> Tx and Rx streams
> 
> On Tue, Apr 01, 2014 at 11:48:16AM +0800, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Nicolin Chen [mailto:guangyu.c...@freescale.com]
> > > Sent: Tuesday, April 01, 2014 11:14 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: broo...@kernel.org; alsa-de...@alsa-project.org; Xiubo Li-B47053;
> linuxppc-
> > > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; ti...@tabi.org
> > > Subject: Re: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable 
> > > interrupts
> for
> > > Tx and Rx streams
> > >
> > > On Tue, Apr 01, 2014 at 11:25:02AM +0800, Wang Dongsheng-B40534 wrote:
> > > > > Subject: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable 
> > > > > interrupts
> for
> > > Tx
> > > > > and Rx streams
> > > > >
> > > > > We only enable one side interrupt for each stream since over/underrun
> > > > > on the opposite stream would be resulted from what we previously did,
> > > > > enabling TERE but remaining FRDE disabled, even though the xrun on the
> > > > > opposite direction will not break the current stream.
> > > > >
> > > > > Signed-off-by: Nicolin Chen 
> > > > > Acked-by: Xiubo Li 
> > > > > ---
> > > > >  sound/soc/fsl/fsl_sai.c | 8 ++--
> > > > >  sound/soc/fsl/fsl_sai.h | 1 +
> > > > >  2 files changed, 7 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > > > > index bdfd497..d64c33f 100644
> > > > > --- a/sound/soc/fsl/fsl_sai.c
> > > > > +++ b/sound/soc/fsl/fsl_sai.c
> > > > > @@ -397,4 +397,6 @@ static int fsl_sai_trigger(struct 
> > > > > snd_pcm_substream
> > > > > *substream, int cmd,
> > > > >
> > > > >   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > > > +FSL_SAI_CSR_xIE_MASK, FSL_SAI_FLAGS);
> > > > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > > >  FSL_SAI_CSR_FRDE, FSL_SAI_CSR_FRDE);
> > > > >   break;
> > > > > @@ -404,4 +406,6 @@ static int fsl_sai_trigger(struct 
> > > > > snd_pcm_substream
> > > > > *substream, int cmd,
> > > > >   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > > >  FSL_SAI_CSR_FRDE, 0);
> > > > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > > > +FSL_SAI_CSR_xIE_MASK, 0);
> > > > >
> > > > >   if (!(tcsr & FSL_SAI_CSR_FRDE || rcsr & 
> > > > > FSL_SAI_CSR_FRDE)) {
> > > > > @@ -464,6 +468,6 @@ static int fsl_sai_dai_probe(struct snd_soc_dai
> *cpu_dai)
> > > > >   struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
> > > > >
> > > > > - regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x,
> FSL_SAI_FLAGS);
> > > > > - regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x,
> FSL_SAI_FLAGS);
> > > > > + regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x, 0x0);
> > > > > + regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x, 0x0);
> > > >
> > > > Why are you remove this macro? Don't use magic number.
> > >
> > > It's pretty clear that the so-called magic number is to clear the settings
> > > in the registers for driver init as what this driver did at the first 
> > > place
> > > -- no offense but I don't think you would ask this if you check the 
> > > git-log
> > > of the driver.
> > >
> > ~FSL_SAI_MASK is better than 0x0. And you also replace 0x.
> 
> I would later send a patch to reset SAI for a true init instead of these lines
> but not within this patch as it's focusing on the interrupts enabling.
> 
> So please don't grasp the mask here. Just let me continue.
> 

:), fine.

Regards,
-Dongsheng

> Thank you,
> Nicolin Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts for Tx and Rx streams

2014-03-31 Thread dongsheng.w...@freescale.com


> -Original Message-
> From: Nicolin Chen [mailto:guangyu.c...@freescale.com]
> Sent: Tuesday, April 01, 2014 11:14 AM
> To: Wang Dongsheng-B40534
> Cc: broo...@kernel.org; alsa-de...@alsa-project.org; Xiubo Li-B47053; 
> linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; ti...@tabi.org
> Subject: Re: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts 
> for
> Tx and Rx streams
> 
> On Tue, Apr 01, 2014 at 11:25:02AM +0800, Wang Dongsheng-B40534 wrote:
> > > Subject: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts 
> > > for
> Tx
> > > and Rx streams
> > >
> > > We only enable one side interrupt for each stream since over/underrun
> > > on the opposite stream would be resulted from what we previously did,
> > > enabling TERE but remaining FRDE disabled, even though the xrun on the
> > > opposite direction will not break the current stream.
> > >
> > > Signed-off-by: Nicolin Chen 
> > > Acked-by: Xiubo Li 
> > > ---
> > >  sound/soc/fsl/fsl_sai.c | 8 ++--
> > >  sound/soc/fsl/fsl_sai.h | 1 +
> > >  2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> > > index bdfd497..d64c33f 100644
> > > --- a/sound/soc/fsl/fsl_sai.c
> > > +++ b/sound/soc/fsl/fsl_sai.c
> > > @@ -397,4 +397,6 @@ static int fsl_sai_trigger(struct snd_pcm_substream
> > > *substream, int cmd,
> > >
> > >   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > +FSL_SAI_CSR_xIE_MASK, FSL_SAI_FLAGS);
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > >  FSL_SAI_CSR_FRDE, FSL_SAI_CSR_FRDE);
> > >   break;
> > > @@ -404,4 +406,6 @@ static int fsl_sai_trigger(struct snd_pcm_substream
> > > *substream, int cmd,
> > >   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > >  FSL_SAI_CSR_FRDE, 0);
> > > + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> > > +FSL_SAI_CSR_xIE_MASK, 0);
> > >
> > >   if (!(tcsr & FSL_SAI_CSR_FRDE || rcsr & FSL_SAI_CSR_FRDE)) {
> > > @@ -464,6 +468,6 @@ static int fsl_sai_dai_probe(struct snd_soc_dai 
> > > *cpu_dai)
> > >   struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
> > >
> > > - regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x, 
> > > FSL_SAI_FLAGS);
> > > - regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x, 
> > > FSL_SAI_FLAGS);
> > > + regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x, 0x0);
> > > + regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x, 0x0);
> >
> > Why are you remove this macro? Don't use magic number.
> 
> It's pretty clear that the so-called magic number is to clear the settings
> in the registers for driver init as what this driver did at the first place
> -- no offense but I don't think you would ask this if you check the git-log
> of the driver.
> 
~FSL_SAI_MASK is better than 0x0. And you also replace 0x.

Regards,
-Dongsheng

> Thank you,
> Nicolin Chen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts for Tx and Rx streams

2014-03-31 Thread dongsheng.w...@freescale.com


> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of Nicolin Chen
> Sent: Tuesday, April 01, 2014 11:17 AM
> To: broo...@kernel.org
> Cc: alsa-de...@alsa-project.org; Xiubo Li-B47053; 
> linuxppc-...@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; ti...@tabi.org
> Subject: [PATCH bisect 2/2] ASoC: fsl_sai: Separately enable interrupts for Tx
> and Rx streams
> 
> We only enable one side interrupt for each stream since over/underrun
> on the opposite stream would be resulted from what we previously did,
> enabling TERE but remaining FRDE disabled, even though the xrun on the
> opposite direction will not break the current stream.
> 
> Signed-off-by: Nicolin Chen 
> Acked-by: Xiubo Li 
> ---
>  sound/soc/fsl/fsl_sai.c | 8 ++--
>  sound/soc/fsl/fsl_sai.h | 1 +
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index bdfd497..d64c33f 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -397,4 +397,6 @@ static int fsl_sai_trigger(struct snd_pcm_substream
> *substream, int cmd,
> 
>   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> +FSL_SAI_CSR_xIE_MASK, FSL_SAI_FLAGS);
> + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
>  FSL_SAI_CSR_FRDE, FSL_SAI_CSR_FRDE);
>   break;
> @@ -404,4 +406,6 @@ static int fsl_sai_trigger(struct snd_pcm_substream
> *substream, int cmd,
>   regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
>  FSL_SAI_CSR_FRDE, 0);
> + regmap_update_bits(sai->regmap, FSL_SAI_xCSR(tx),
> +FSL_SAI_CSR_xIE_MASK, 0);
> 
>   if (!(tcsr & FSL_SAI_CSR_FRDE || rcsr & FSL_SAI_CSR_FRDE)) {
> @@ -464,6 +468,6 @@ static int fsl_sai_dai_probe(struct snd_soc_dai *cpu_dai)
>   struct fsl_sai *sai = dev_get_drvdata(cpu_dai->dev);
> 
> - regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x, 
> FSL_SAI_FLAGS);
> - regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x, 
> FSL_SAI_FLAGS);
> + regmap_update_bits(sai->regmap, FSL_SAI_TCSR, 0x, 0x0);
> + regmap_update_bits(sai->regmap, FSL_SAI_RCSR, 0x, 0x0);

Why are you remove this macro? Don't use magic number.

Regards,
-Dongsheng


RE: [PATCH] powerpc/irq: Remove HAVE_IRQ_EXIT_ON_IRQ_STACK feature at powerpc platform

2014-03-28 Thread dongsheng.w...@freescale.com
Thanks Kevin. Your patch works normal. :)

I still have some confused. I think when __do_softirq always get a interrupt, 
the hard stack will be run out, isn't it?

Regards,
-Dongsheng

> -Original Message-
> From: Kevin Hao [mailto:haoke...@gmail.com]
> Sent: Friday, March 28, 2014 4:18 PM
> To: Wang Dongsheng-B40534
> Cc: fweis...@gmail.com; James Hogan; Andrew Morton; David S. Miller; Peter
> Zijlstra; Helge Deller; H. Peter Anvin; Heiko Carstens; linux-
> ker...@vger.kernel.org; Paul Mackerras; James E.J. Bottomley; Linus Torvalds;
> Jin Zhengxiong-R64188; Wood Scott-B07421; Thomas Gleixner; linuxppc-
> d...@lists.ozlabs.org; Ingo Molnar; Martin Schwidefsky
> Subject: Re: [PATCH] powerpc/irq: Remove HAVE_IRQ_EXIT_ON_IRQ_STACK feature at
> powerpc platform
> 
> On Fri, Mar 28, 2014 at 03:38:32PM +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > If softirq use hardirq stack, we will get kernel painc when a hard irq
> > coming again during __do_softirq enable local irq to deal with softirq
> > action. So we need to switch satck into softirq stack when invoke soft irq.
> >
> >  Task--->
> > | Task stack
> > |
> > Interrput->EXCEPTION->do_IRQ->
> > ^| Hard irq stack
> > ||
> > |irq_exit->__do_softirq->local_irq_enable-- 
> >   --
> >local_irq_disable
> > |   
> > | Hard irq
> stack
> > |   
> > |
> > |   
> > Interrupt
> coming again
> > |   There will get a Interrupt nesting  
> > |
> >
> > --
> > --
> >
> > Trace 1: Trap 900
> >
> > Kernel stack overflow in process e8152f40, r1=e8e05ec0
> > CPU: 0 PID: 2399 Comm: image_compress/ Not tainted
> > 3.13.0-rc3-03475-g2e3f85b #432
> > task: e8152f40 ti: c080a000 task.ti: ef176000
> > NIP: c05bec04 LR: c0305590 CTR: 0010
> > REGS: e8e05e10 TRAP: 0901   Not tainted  (3.13.0-rc3-03475-g2e3f85b)
> 
> Could you double check if you got the following patch applied?
> 
> commit 1a18a66446f3f289b05b634f18012424d82aa63a
> Author: Kevin Hao 
> Date:   Fri Jan 17 12:25:28 2014 +0800
> 
> powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
> 
> Guenter Roeck has got the following call trace on a p2020 board:
>   Kernel stack overflow in process eb3e5a00, r1=eb79df90
>   CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00
> #4
>   task: eb3e5a00 ti: c0616000 task.ti: ef44
>   NIP: c003a420 LR: c003a410 CTR: c0017518
>   REGS: eb79dee0 TRAP: 0901   Not tainted 
> (3.13.0-rc8-juniper-00146-g19eca00)
>   MSR: 00029000   CR: 24008444  XER: 
>   GPR00: c003a410 eb79df90 eb3e5a00  eb05d900 0001 65d87646
> 
>   GPR08:  020b8000   44008442
>   NIP [c003a420] __do_softirq+0x94/0x1ec
>   LR [c003a410] __do_softirq+0x84/0x1ec
>   Call Trace:
>   [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
>   [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
>   [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
>   [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
>   [ef441f40] [c000e7f4] ret_from_except+0x0/0x18
>   --- Exception: 501 at 0xfcda524
>   LR = 0x10024900
>   Instruction dump:
>   7c781b78 3b4a 3a73b040 543c0024 3a80 3b3913a0 7ef5bb78 48201bf9
>   5463103a 7d3b182e 7e89b92e 7c008146 <3ba0> 7e7e9b78 4814 
> 57fff87f
>   Kernel panic - not syncing: kernel stack overflow
>   CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00
> #4
>   Call Trace:
> 
> The reason is that we have used the wrong register to calculate the
> ksp_limit in commit cbc9565ee826 (powerpc: Remove ksp_limit on ppc64).
> Just fix it.
> 
> As suggested by Benjamin Herrenschmidt, also add the C prototype of the
> function in the comment in order to avoid such kind of errors in the
> future.
> 
> Cc: sta...@vger.kernel.org # 3.12
> Reported-by: Guenter Roeck 
> Tested-by: Guenter Roeck 
> Signed-off-by: Kevin Hao 
> Signed-off-by: Benjamin Herrenschmidt 
> 
> Thanks,
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/