* Re: [PATCH v4 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Mark Brown @ 2013-10-31 18:36 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
s.hauer, swarren, timur, rob.herring, linux-kernel,
ijc+devicetree, dmaengine, shawn.guo, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <dda0bc1221f053405da616192577228c51821040.1383226444.git.b42378@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 314 bytes --]
On Thu, Oct 31, 2013 at 09:44:15PM +0800, Nicolin Chen wrote:
> By enabling dual fifo mode, it would allow SSI enter a better performance
> to transimit/receive data without occasional hardware underrun/overrun.
>
> [ Passed compile-test with mpc85xx_defconfig ]
Acked-by: Mark Brown <broonie@linaro.org>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [Suggestion] drivers: powercap: 'dev_attrs' has already removed from 'struct class'
From: Rafael J. Wysocki @ 2013-10-31 16:25 UTC (permalink / raw)
To: Chen Gang, srinivas.pandruvada, jacob.jun.pan,
linuxppc-dev@lists.ozlabs.org
Cc: Greg KH
In-Reply-To: <5271BDFD.2050205@asianux.com>
On 10/31/2013 3:18 AM, Chen Gang wrote:
> Hello Maintainers
>
> It is removed by "bcc8edb driver core: remove dev_attrs from struct
> class" in Oct 5 2013. But "75d2364 PowerCap: Add class driver" still
> use it in Oct 11 2013.
>
> The related error (for powerpc with allmodconfig):
>
> CC drivers/powercap/powercap_sys.o
> drivers/powercap/powercap_sys.c:484:2: error: unknown field ‘dev_attrs’ specified in initializer
> drivers/powercap/powercap_sys.c:484:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/powercap/powercap_sys.c:484:2: warning: (near initialization for ‘powercap_class.suspend’) [enabled by default]
>
>
> Please give a check thanks.
That should have been fixed in the current linux-next already.
Thanks,
Rafael
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-10-31 15:19 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, LKML, Oleg Nesterov,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031150756.GB4067@linux.vnet.ibm.com>
On Thu, Oct 31, 2013 at 08:07:56AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
> > On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
> > > Before C/C++11, the closest thing to such a prohibition is use of
> > > volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
> > > use atomics to get anything resembing this prohibition.
> > >
> > > If you just use normal variables, the compiler is within its rights
> > > to transform something like the following:
> > >
> > > if (a)
> > > b = 1;
> > > else
> > > b = 42;
> > >
> > > Into:
> > >
> > > b = 42;
> > > if (a)
> > > b = 1;
> > >
> > > Many other similar transformations are permitted. Some are used to all
> > > vector instructions to be used -- the compiler can do a write with an
> > > overly wide vector instruction, then clean up the clobbered variables
> > > later, if it wishes. Again, if the variables are not marked volatile,
> > > or, in C/C++11, atomic.
> >
> > While I've heard you tell this story before, my mind keeps boggling how
> > we've been able to use shared memory at all, all these years.
> >
> > It seems to me stuff should have broken left, right and center if
> > compilers were really aggressive about this.
>
> Sometimes having stupid compilers is a good thing. But they really are
> getting more aggressive.
But surely we cannot go mark all data structures lodged in shared memory
as volatile, that's insane.
I'm sure you're quite worried about this as well. Suppose we have:
struct foo {
unsigned long value;
void *ptr;
unsigned long value1;
};
And our ptr member is RCU managed. Then while the assignment using:
rcu_assign_ptr() will use the volatile cast, what stops the compiler
from wrecking ptr while writing either of the value* members and
'fixing' her up after?
This is a completely untenable position.
How do the C/C++ people propose to deal with this?
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Paul E. McKenney @ 2013-10-31 15:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, Mathieu Desnoyers, LKML, Oleg Nesterov,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031090457.GU19466@laptop.lan>
On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
> On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
> > Before C/C++11, the closest thing to such a prohibition is use of
> > volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
> > use atomics to get anything resembing this prohibition.
> >
> > If you just use normal variables, the compiler is within its rights
> > to transform something like the following:
> >
> > if (a)
> > b = 1;
> > else
> > b = 42;
> >
> > Into:
> >
> > b = 42;
> > if (a)
> > b = 1;
> >
> > Many other similar transformations are permitted. Some are used to all
> > vector instructions to be used -- the compiler can do a write with an
> > overly wide vector instruction, then clean up the clobbered variables
> > later, if it wishes. Again, if the variables are not marked volatile,
> > or, in C/C++11, atomic.
>
> While I've heard you tell this story before, my mind keeps boggling how
> we've been able to use shared memory at all, all these years.
>
> It seems to me stuff should have broken left, right and center if
> compilers were really aggressive about this.
Sometimes having stupid compilers is a good thing. But they really are
getting more aggressive.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Russell King - ARM Linux @ 2013-10-31 14:49 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: alsa-devel, linux-doc, linux-wireless, linux-fbdev, dri-devel,
Hans Verkuil, linux-ide, devel, linux-samsung-soc, linux-scsi,
e1000-devel, b43-dev, linux-media, devicetree, linux-nvme,
linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-mmc,
linux-crypto, Greg Kroah-Hartman, uclinux-dist-devel,
linuxppc-dev
In-Reply-To: <20131031094640.205840a2@samsung.com>
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil <hverkuil@xs4all.nl> escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coherent_mask(dev, mask);
> > >
> > > with a call to the new helper dma_set_mask_and_coherent().
> > >
> > > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> >
> > Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> Somehow, I lost your original post (I got unsubscribed on a few days
> from all vger mailing lists at the end of september).
>
> I suspect that you want to sent this via your tree, right?
Yes please.
> If so:
>
> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Added, thanks.
> > > - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> > > - if (err)
> > > - return -ENODEV;
> > > - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> > > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > > if (err)
> > > return -ENODEV;
One thing I've just noticed is that return should be "return err" not
"return -ENODEV" - are you okay for me to change that in this patch?
Thanks.
^ permalink raw reply
* [PATCH v4 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
From: Nicolin Chen @ 2013-10-31 13:44 UTC (permalink / raw)
To: timur, shawn.guo, broonie, s.hauer
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383226444.git.b42378@freescale.com>
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
arch/arm/boot/dts/imx6sl.dtsi | 12 ++++++------
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 54cee65..1a71eac 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,8 +154,8 @@
reg = <0x70014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4307e80..7208fde 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,8 +153,8 @@
reg = <0x50014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 57e9c38..6e096ca 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -223,8 +223,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks 178>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <38 37>;
@@ -236,8 +236,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks 179>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <42 41>;
@@ -249,8 +249,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks 180>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <46 45>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c46651e..b32ba99 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -195,8 +195,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks IMX6SL_CLK_SSI1>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -207,8 +207,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks IMX6SL_CLK_SSI2>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -219,8 +219,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks IMX6SL_CLK_SSI3>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
--
1.8.4
^ permalink raw reply related
* [PATCH v4 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Nicolin Chen @ 2013-10-31 13:44 UTC (permalink / raw)
To: timur, shawn.guo, broonie, s.hauer
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383226444.git.b42378@freescale.com>
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
[ Passed compile-test with mpc85xx_defconfig ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
sound/soc/fsl/fsl_ssi.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 35e2773..0892111 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -143,6 +143,7 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -413,6 +414,12 @@ static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
}
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ }
+
return 0;
}
@@ -947,7 +954,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->fifo_depth = 8;
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
@@ -1001,6 +1008,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
dma_events[0], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas", dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+ * as even numbers due to dma script limitation.
+ */
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
} else if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(&pdev->dev, ssi_private->irq,
--
1.8.4
^ permalink raw reply related
* [PATCH v4 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
From: Nicolin Chen @ 2013-10-31 13:44 UTC (permalink / raw)
To: timur, shawn.guo, broonie, s.hauer
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383226444.git.b42378@freescale.com>
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 4 ++++
include/linux/platform_data/dma-imx.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d..68b83ec 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
19 IPU Memory
20 ASRC
21 ESAI
+ 22 SSI Dual FIFO (needs firmware ver >= 2)
The third cell specifies the transfer priority as below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index c7ece8d..efaa9a9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -725,6 +725,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
per_2_emi = sdma->script_addrs->app_2_mcu_addr;
emi_2_per = sdma->script_addrs->mcu_2_app_addr;
break;
+ case IMX_DMATYPE_SSI_DUAL:
+ per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+ break;
case IMX_DMATYPE_SSI_SP:
case IMX_DMATYPE_MMC:
case IMX_DMATYPE_SDHC:
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index beac6b8..bcbc6c3 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -39,6 +39,7 @@ enum sdma_peripheral_type {
IMX_DMATYPE_IPU_MEMORY, /* IPU Memory */
IMX_DMATYPE_ASRC, /* ASRC */
IMX_DMATYPE_ESAI, /* ESAI */
+ IMX_DMATYPE_SSI_DUAL, /* SSI Dual FIFO */
};
enum imx_dma_prio {
--
1.8.4
^ permalink raw reply related
* [PATCH v4 0/4] Add dual-fifo mode support of i.MX ssi
From: Nicolin Chen @ 2013-10-31 13:44 UTC (permalink / raw)
To: timur, shawn.guo, broonie, s.hauer
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
Changelog
v4:
* PATCH-3: Drop useless register configuration.
*
* Nothing changes for the other three patches
v3:
* PATCH-1: Add comments to indicate the end of v1 and v2 array.
* PATCH-3: Use better way to keep watermark as even number.
*
* Nothing changes for PATCH-2 and PATCH-4
v2:
* Instead of adding rogue scripts to current SDMA driver based on firmware
* V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1
* to two patches: The first is to add version check code to the SDMA driver;
* And the second is to add SSI dual FIFO DMATYPE.
*
* Nothing changes for the last two patches.
v1:
* SSI can reduce hardware overrun/underrun possibility when using dual
* fifo mode. To support this mode, we need to first update sdma sciprt
* list, and then enable dual fifo BIT in SSI driver, and last update DT
* bindings of i.MX series.
*
* ! This series of patches has a direct dependency between them. When
* ! applying them, we need to apply to one single branch. Otherwise,
* ! it would break currect branches.
Nicolin Chen (4):
dma: imx-sdma: Add sdma firmware version 2 support
dma: imx-sdma: Add new dma type for ssi dual fifo script
ASoC: fsl_ssi: Add dual fifo mode support
ARM: dts: imx: use dual-fifo sdma script for ssi
.../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
arch/arm/boot/dts/imx6sl.dtsi | 12 ++++++------
drivers/dma/imx-sdma.c | 19 ++++++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 +++++
include/linux/platform_data/dma-imx.h | 1 +
sound/soc/fsl/fsl_ssi.c | 18 +++++++++++++++++-
9 files changed, 58 insertions(+), 18 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH v4 1/4] dma: imx-sdma: Add sdma firmware version 2 support
From: Nicolin Chen @ 2013-10-31 13:44 UTC (permalink / raw)
To: timur, shawn.guo, broonie, s.hauer
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, dmaengine, ijc+devicetree,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383226444.git.b42378@freescale.com>
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
drivers/dma/imx-sdma.c | 15 ++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 +++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..c7ece8d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -323,6 +323,7 @@ struct sdma_engine {
struct clk *clk_ipg;
struct clk *clk_ahb;
spinlock_t channel_0_lock;
+ u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
};
@@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
}
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1 34
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 38
static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
@@ -1246,7 +1248,7 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
s32 *saddr_arr = (u32 *)sdma->script_addrs;
int i;
- for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
+ for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
}
@@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
goto err_firmware;
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
+ switch (header->version_major) {
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ return;
+ }
addr = (void *)header + header->script_addrs_start;
ram_code = (void *)header + header->ram_code_start;
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 3a39428..eabac4e 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
s32 dptc_dvfs_addr;
s32 utra_addr;
s32 ram_code_start_addr;
+ /* End of v1 array */
+ s32 mcu_2_ssish_addr;
+ s32 ssish_2_mcu_addr;
+ s32 hdmi_dma_addr;
+ /* End of v2 array */
};
/**
--
1.8.4
^ permalink raw reply related
* RE: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-10-31 12:55 UTC (permalink / raw)
To: David Laight
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra,
Frederic Weisbecker, LKML, Oleg Nesterov, Linux PPC dev,
Anton Blanchard, paulmck
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B73CC@saturn3.aculab.com>
"David Laight" <David.Laight@aculab.com> wrote on 10/31/2013 02:28:56 PM:
> So even though the wmb() in the writer ensures the writes are correctly
> ordered, the reader can read the old value from the second location from
> its local cache.
In case of circular buffer, the only thing that producer reads is @tail,
and nothing wrong will happen if producer reads old value of @tail.
Moreover,
adherents of smp_mb() insert it *after* the read of @tail, so it cannot
prevent reading of old value anyway.
-- Victor
^ permalink raw reply
* RE: perf events ring buffer memory barrier on powerpc
From: David Laight @ 2013-10-31 12:28 UTC (permalink / raw)
To: Victor Kaplansky, paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra,
Frederic Weisbecker, LKML, Oleg Nesterov, Linux PPC dev,
Anton Blanchard
In-Reply-To: <OFDF23985D.1D949148-ON42257C15.002DEB25-42257C15.0036DF93@il.ibm.com>
> "For instance, your producer must issue a "memory barrier" instruction
> after writing the data to shared memory and before inserting it on
> the queue; likewise, your consumer must issue a memory barrier
> instruction after removing an item from the queue and before reading
> from its memory. Otherwise, you risk seeing stale data, since, =
while
> the Alpha processor does provide coherent memory, it does not =
provide
> implicit ordering of reads and writes. (That is, the write of the
> producer's data might reach memory after the write of the queue, =
such
> that the consumer might read the new item from the queue but get the
> previous values from the item's memory."
>=20
> If yes, I don't think it explains the need of memory barrier on Alpha
> in our case (we all agree about the need of smp_wmb() right before =
@head
> update by producer). If not, could you please point to specific =
paragraph?
My understanding is that the extra read barrier the alpha needs isn't to
control the order the cpu performs the memory cycles in, but rather to
wait while the cache system performs all outstanding operations.
So even though the wmb() in the writer ensures the writes are correctly
ordered, the reader can read the old value from the second location from
its local cache.
David
^ permalink raw reply
* Re: [PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Chen Guangyu-B42378 @ 2013-10-31 12:28 UTC (permalink / raw)
To: Timur Tabi
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, pawel.moll@arm.com,
linux-doc@vger.kernel.org, s.hauer@pengutronix.de,
swarren@wwwdotorg.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, broonie@kernel.org,
philippe.retornaz@gmail.com, ijc+devicetree@hellion.org.uk,
dmaengine@vger.kernel.org, galak@codeaurora.org,
shawn.guo@linaro.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5272474D.5000207@tabi.org>
Thank you for the comments.
I'll refine this part.
Sent by Android device.
Timur Tabi <timur@tabi.org> wrote:
Nicolin Chen wrote:
> + if (ssi_private->use_dual_fifo) {
> + write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
> + write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
> + write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
> + } else {
> + write_ssi_mask(&ssi->srcr, CCSR_SSI_SRCR_RFEN1, 0);
> + write_ssi_mask(&ssi->stcr, CCSR_SSI_STCR_TFEN1, 0);
> + write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TCH_EN, 0);
> + }
Why do you need the "else" part? Why can't you just do this:
if (ssi_private->use_dual_fifo) {
write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
}
^ permalink raw reply
* Re: [PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Timur Tabi @ 2013-10-31 12:04 UTC (permalink / raw)
To: Nicolin Chen, s.hauer, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
In-Reply-To: <da997ce67d9817364248ca1eba716bb6c7814a24.1383207153.git.b42378@freescale.com>
Nicolin Chen wrote:
> + if (ssi_private->use_dual_fifo) {
> + write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
> + write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
> + write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
> + } else {
> + write_ssi_mask(&ssi->srcr, CCSR_SSI_SRCR_RFEN1, 0);
> + write_ssi_mask(&ssi->stcr, CCSR_SSI_STCR_TFEN1, 0);
> + write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TCH_EN, 0);
> + }
Why do you need the "else" part? Why can't you just do this:
if (ssi_private->use_dual_fifo) {
write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
}
^ permalink raw reply
* Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
From: Mauro Carvalho Chehab @ 2013-10-31 11:46 UTC (permalink / raw)
To: Hans Verkuil
Cc: alsa-devel, linux-doc, linux-mmc, linux-fbdev, linux-nvme,
linux-ide, devel, linux-samsung-soc, linux-scsi, e1000-devel,
b43-dev, Russell King, linux-media, devicetree, dri-devel,
linux-tegra, linux-omap, linux-arm-kernel,
Solarflare linux maintainers, netdev, linux-usb, linux-wireless,
linux-crypto, Greg Kroah-Hartman, uclinux-dist-devel,
linuxppc-dev
In-Reply-To: <5249673B.5020705@xs4all.nl>
Hi Russell,
Em Mon, 30 Sep 2013 13:57:47 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 09/19/2013 11:44 PM, Russell King wrote:
> > Replace the following sequence:
> >
> > dma_set_mask(dev, mask);
> > dma_set_coherent_mask(dev, mask);
> >
> > with a call to the new helper dma_set_mask_and_coherent().
> >
> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Somehow, I lost your original post (I got unsubscribed on a few days
from all vger mailing lists at the end of september).
I suspect that you want to sent this via your tree, right?
If so:
Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>
> Regards,
>
> Hans
>
> > ---
> > drivers/staging/media/dt3155v4l/dt3155v4l.c | 5 +----
> > 1 files changed, 1 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> > index 90d6ac4..081407b 100644
> > --- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
> > +++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
> > @@ -901,10 +901,7 @@ dt3155_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> > int err;
> > struct dt3155_priv *pd;
> >
> > - err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
> > - if (err)
> > - return -ENODEV;
> > - err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
> > + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
> > if (err)
> > return -ENODEV;
> > pd = kzalloc(sizeof(*pd), GFP_KERNEL);
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Cheers,
Mauro
^ permalink raw reply
* Re: Gianfar driver crashes in Kernel v3.10
From: Thomas Hühn @ 2013-10-31 11:51 UTC (permalink / raw)
To: claudiu.manoil@freescale.com; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <525E3BD7.1020208@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi Claudiu,
> Please try the following patch:
> http://patchwork.ozlabs.org/patch/283235/
>
> It should help with your issue.
>
Several OpenWrt users including myself have tested your patch on TPLink-4900 routers.
We do have positive feedback, as no crash nor system freeze was reported for different
network loads and router setups.
All different scenarios / details and two digit uptimes are in this forum thread:
https://forum.openwrt.org/viewtopic.php?id=42062&p=13
Thanks again for your work and I hope to see this patch merged upstream.
Greetings Thomas
[-- Attachment #2: Type: text/html, Size: 1760 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] of: move definition of of_find_next_cache_node into common code.
From: Sudeep KarkadaNagesha @ 2013-10-31 10:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: grant.likely@linaro.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, rob.herring@calxeda.com
In-Reply-To: <1383196834.28909.7.camel@pasglop>
Hi Ben,
On 31/10/13 05:20, Benjamin Herrenschmidt wrote:
> On Wed, 2013-09-18 at 11:53 +0100, Sudeep KarkadaNagesha wrote:
>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>
>> Since the definition of_find_next_cache_node is architecture independent=
,
>> the existing definition in powerpc can be moved to driver/of/base.c
>>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>=20
> I've seen no follow up on that, I'm happy to stick it in powerpc-next
> with some other late stuff.
>=20
Thanks for the follow up. Grant wanted to see usage of this outside PPC and=
I
pointed him[0] to the RFC[1] I had posted to support cacheinfo on ARM.
These patches are based on v3.12-rc1, let me know if you want me to
rebase/repost on any particular version.
Regards,
Sudeep
[0] http://www.spinics.net/lists/devicetree/msg05174.html
[1] https://lkml.org/lkml/2013/9/18/340
^ permalink raw reply
* Re: perf events ring buffer memory barrier on powerpc
From: Victor Kaplansky @ 2013-10-31 9:59 UTC (permalink / raw)
To: paulmck
Cc: Michael Neuling, Mathieu Desnoyers, Peter Zijlstra, LKML,
Oleg Nesterov, Linux PPC dev, Anton Blanchard,
Frederic Weisbecker
In-Reply-To: <20131031043258.GQ4126@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote on 10/31/2013
06:32:58 AM:
> If you want to play the "omit memory barriers" game, then proving a
> negative is in fact the task before you.
Generally it is not fair. Otherwise, anyone could put an smp_mb() at a
random place, and expect others to "prove" that it is not needed.
It is not fair also because it should be virtually impossible to prove lack
of any problem. OTH, if a problem exists, it should be easy for proponents
of a memory barrier to build a test case or design a scenario demonstrating
the problem.
Actually, advocates of the memory barrier in our case do have an argument -
- the rule of thumb saying that barriers should be paired. I consider this
rule only as a general recommendation to look into potentially risky
places.
And indeed, in our case if the store to circular wasn't conditional, it
would require a memory barrier to prevent the store to be performed before
the read of @tail. But in our case the store is conditional, so no memory
barrier is required.
> And the correctness of this code has been called into question. :-(
> An embarrassingly long time ago -- I need to get this either proven
> or fixed.
I agree.
> Before C/C++11, the closest thing to such a prohibition is use of
> volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
> use atomics to get anything resembing this prohibition.
>
> If you just use normal variables, the compiler is within its rights
> to transform something like the following:
>
> if (a)
> b = 1;
> else
> b = 42;
>
> Into:
>
> b = 42;
> if (a)
> b = 1;
>
> Many other similar transformations are permitted. Some are used to all
> vector instructions to be used -- the compiler can do a write with an
> overly wide vector instruction, then clean up the clobbered variables
> later, if it wishes. Again, if the variables are not marked volatile,
> or, in C/C++11, atomic.
All this can justify only compiler barrier() which is almost free from
performance point of view, since current gcc anyway doesn't perform store
hoisting optimization in our case.
(And I'm not getting into philosophical discussion whether kernel code
should consider future possible bugs/features in gcc or C/C++11
standard).
> The compilers don't always know as much as they might about the
underlying
> hardware's memory model.
That's correct in general. But can you point out a problem that really
exists?
> Of course, if this code is architecture specific,
> it can avoid DEC Alpha's fun and games, which could also violate your
> assumptions in the above paragraph:
>
> http://www.openvms.compaq.com/wizard/wiz_2637.html
Are you talking about this paragraph from above link:
"For instance, your producer must issue a "memory barrier" instruction
after writing the data to shared memory and before inserting it on
the queue; likewise, your consumer must issue a memory barrier
instruction after removing an item from the queue and before reading
from its memory. Otherwise, you risk seeing stale data, since, while
the Alpha processor does provide coherent memory, it does not provide
implicit ordering of reads and writes. (That is, the write of the
producer's data might reach memory after the write of the queue, such
that the consumer might read the new item from the queue but get the
previous values from the item's memory."
If yes, I don't think it explains the need of memory barrier on Alpha
in our case (we all agree about the need of smp_wmb() right before @head
update by producer). If not, could you please point to specific paragraph?
>
> Anyway, proving or fixing the code in Documentation/circular-buffers.txt
> has been on my list for too long, so I will take a closer look at it.
Thanks!
I'm concerned more about performance overhead imposed by the full memory
barrier in kfifo circular buffers. Even if it is needed on Alpha (I don't
understand why) we could try to solve this with some memory barrier which
is effective only on architectures which really need it.
Regards,
-- Victor
^ permalink raw reply
* [PATCH v2] offb: make the screen properties endian safe
From: Cédric Le Goater @ 2013-10-31 9:36 UTC (permalink / raw)
To: benh; +Cc: Cédric Le Goater, linuxppc-dev
In-Reply-To: <1383185307.5117.74.camel@pasglop>
The "screen" properties : depth, width, height, linebytes need
to be converted to the host endian order when read from the device
tree.
Signed-off-by: Cédric Le Goater <clg@fr.ibm.com>
---
Changes in v2:
- replaced be32_to_cpu() by be32_to_cpup()
- fixed setcolreg ops
drivers/video/offb.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/offb.c b/drivers/video/offb.c
index 0c4f343..68e8415 100644
--- a/drivers/video/offb.c
+++ b/drivers/video/offb.c
@@ -120,7 +120,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
mask <<= info->var.transp.offset;
value |= mask;
}
- pal[regno] = value;
+ pal[regno] = cpu_to_be32(value);
return 0;
}
@@ -536,7 +536,7 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
unsigned int flags, rsize, addr_prop = 0;
unsigned long max_size = 0;
u64 rstart, address = OF_BAD_ADDR;
- const u32 *pp, *addrp, *up;
+ const __be32 *pp, *addrp, *up;
u64 asize;
int foreign_endian = 0;
@@ -552,25 +552,25 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node)
if (pp == NULL)
pp = of_get_property(dp, "depth", &len);
if (pp && len == sizeof(u32))
- depth = *pp;
+ depth = be32_to_cpup(pp);
pp = of_get_property(dp, "linux,bootx-width", &len);
if (pp == NULL)
pp = of_get_property(dp, "width", &len);
if (pp && len == sizeof(u32))
- width = *pp;
+ width = be32_to_cpup(pp);
pp = of_get_property(dp, "linux,bootx-height", &len);
if (pp == NULL)
pp = of_get_property(dp, "height", &len);
if (pp && len == sizeof(u32))
- height = *pp;
+ height = be32_to_cpup(pp);
pp = of_get_property(dp, "linux,bootx-linebytes", &len);
if (pp == NULL)
pp = of_get_property(dp, "linebytes", &len);
if (pp && len == sizeof(u32) && (*pp != 0xffffffffu))
- pitch = *pp;
+ pitch = be32_to_cpup(pp);
else
pitch = width * ((depth + 7) / 8);
--
1.7.10.4
^ permalink raw reply related
* Re: perf events ring buffer memory barrier on powerpc
From: Peter Zijlstra @ 2013-10-31 9:04 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Michael Neuling, Mathieu Desnoyers, LKML, Oleg Nesterov,
Linux PPC dev, Anton Blanchard, Frederic Weisbecker,
Victor Kaplansky
In-Reply-To: <20131031043258.GQ4126@linux.vnet.ibm.com>
On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
> Before C/C++11, the closest thing to such a prohibition is use of
> volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
> use atomics to get anything resembing this prohibition.
>
> If you just use normal variables, the compiler is within its rights
> to transform something like the following:
>
> if (a)
> b = 1;
> else
> b = 42;
>
> Into:
>
> b = 42;
> if (a)
> b = 1;
>
> Many other similar transformations are permitted. Some are used to all
> vector instructions to be used -- the compiler can do a write with an
> overly wide vector instruction, then clean up the clobbered variables
> later, if it wishes. Again, if the variables are not marked volatile,
> or, in C/C++11, atomic.
While I've heard you tell this story before, my mind keeps boggling how
we've been able to use shared memory at all, all these years.
It seems to me stuff should have broken left, right and center if
compilers were really aggressive about this.
^ permalink raw reply
* [PATCH v3 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
From: Nicolin Chen @ 2013-10-31 8:22 UTC (permalink / raw)
To: s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383207153.git.b42378@freescale.com>
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
arch/arm/boot/dts/imx6sl.dtsi | 12 ++++++------
4 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 54cee65..1a71eac 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -154,8 +154,8 @@
reg = <0x70014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 4307e80..7208fde 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -153,8 +153,8 @@
reg = <0x50014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
- dmas = <&sdma 24 1 0>,
- <&sdma 25 1 0>;
+ dmas = <&sdma 24 22 0>,
+ <&sdma 25 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <25 24 23 22>; /* TX0 RX0 TX1 RX1 */
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 57e9c38..6e096ca 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -223,8 +223,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks 178>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <38 37>;
@@ -236,8 +236,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks 179>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <42 41>;
@@ -249,8 +249,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks 180>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
fsl,ssi-dma-events = <46 45>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index c46651e..b32ba99 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -195,8 +195,8 @@
reg = <0x02028000 0x4000>;
interrupts = <0 46 0x04>;
clocks = <&clks IMX6SL_CLK_SSI1>;
- dmas = <&sdma 37 1 0>,
- <&sdma 38 1 0>;
+ dmas = <&sdma 37 22 0>,
+ <&sdma 38 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -207,8 +207,8 @@
reg = <0x0202c000 0x4000>;
interrupts = <0 47 0x04>;
clocks = <&clks IMX6SL_CLK_SSI2>;
- dmas = <&sdma 41 1 0>,
- <&sdma 42 1 0>;
+ dmas = <&sdma 41 22 0>,
+ <&sdma 42 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
@@ -219,8 +219,8 @@
reg = <0x02030000 0x4000>;
interrupts = <0 48 0x04>;
clocks = <&clks IMX6SL_CLK_SSI3>;
- dmas = <&sdma 45 1 0>,
- <&sdma 46 1 0>;
+ dmas = <&sdma 45 22 0>,
+ <&sdma 46 22 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
status = "disabled";
--
1.8.4
^ permalink raw reply related
* [PATCH v3 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
From: Nicolin Chen @ 2013-10-31 8:22 UTC (permalink / raw)
To: s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383207153.git.b42378@freescale.com>
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 4 ++++
include/linux/platform_data/dma-imx.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d..68b83ec 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
19 IPU Memory
20 ASRC
21 ESAI
+ 22 SSI Dual FIFO (needs firmware ver >= 2)
The third cell specifies the transfer priority as below.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index c7ece8d..efaa9a9 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -725,6 +725,10 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
per_2_emi = sdma->script_addrs->app_2_mcu_addr;
emi_2_per = sdma->script_addrs->mcu_2_app_addr;
break;
+ case IMX_DMATYPE_SSI_DUAL:
+ per_2_emi = sdma->script_addrs->ssish_2_mcu_addr;
+ emi_2_per = sdma->script_addrs->mcu_2_ssish_addr;
+ break;
case IMX_DMATYPE_SSI_SP:
case IMX_DMATYPE_MMC:
case IMX_DMATYPE_SDHC:
diff --git a/include/linux/platform_data/dma-imx.h b/include/linux/platform_data/dma-imx.h
index beac6b8..bcbc6c3 100644
--- a/include/linux/platform_data/dma-imx.h
+++ b/include/linux/platform_data/dma-imx.h
@@ -39,6 +39,7 @@ enum sdma_peripheral_type {
IMX_DMATYPE_IPU_MEMORY, /* IPU Memory */
IMX_DMATYPE_ASRC, /* ASRC */
IMX_DMATYPE_ESAI, /* ESAI */
+ IMX_DMATYPE_SSI_DUAL, /* SSI Dual FIFO */
};
enum imx_dma_prio {
--
1.8.4
^ permalink raw reply related
* [PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
From: Nicolin Chen @ 2013-10-31 8:22 UTC (permalink / raw)
To: s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383207153.git.b42378@freescale.com>
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
[ Passed compile-test with mpc85xx_defconfig ]
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 35e2773..51a2022 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -143,6 +143,7 @@ struct fsl_ssi_private {
bool ssi_on_imx;
bool imx_ac97;
bool use_dma;
+ bool use_dual_fifo;
struct clk *clk;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct snd_dmaengine_dai_dma_data dma_params_rx;
@@ -413,6 +414,16 @@ static int fsl_ssi_setup(struct fsl_ssi_private *ssi_private)
write_ssi(CCSR_SSI_SOR_WAIT(3), &ssi->sor);
}
+ if (ssi_private->use_dual_fifo) {
+ write_ssi_mask(&ssi->srcr, 0, CCSR_SSI_SRCR_RFEN1);
+ write_ssi_mask(&ssi->stcr, 0, CCSR_SSI_STCR_TFEN1);
+ write_ssi_mask(&ssi->scr, 0, CCSR_SSI_SCR_TCH_EN);
+ } else {
+ write_ssi_mask(&ssi->srcr, CCSR_SSI_SRCR_RFEN1, 0);
+ write_ssi_mask(&ssi->stcr, CCSR_SSI_STCR_TFEN1, 0);
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TCH_EN, 0);
+ }
+
return 0;
}
@@ -947,7 +958,7 @@ static int fsl_ssi_probe(struct platform_device *pdev)
ssi_private->fifo_depth = 8;
if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx21-ssi")) {
- u32 dma_events[2];
+ u32 dma_events[2], dmas[4];
ssi_private->ssi_on_imx = true;
ssi_private->clk = devm_clk_get(&pdev->dev, NULL);
@@ -1001,6 +1012,15 @@ static int fsl_ssi_probe(struct platform_device *pdev)
dma_events[0], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
dma_events[1], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
+ if (!of_property_read_u32_array(pdev->dev.of_node, "dmas", dmas, 4)
+ && dmas[2] == IMX_DMATYPE_SSI_DUAL) {
+ ssi_private->use_dual_fifo = true;
+ /* When using dual fifo mode, we need to keep watermark
+ * as even numbers due to dma script limitation.
+ */
+ ssi_private->dma_params_tx.maxburst &= ~0x1;
+ ssi_private->dma_params_rx.maxburst &= ~0x1;
+ }
} else if (ssi_private->use_dma) {
/* The 'name' should not have any slashes in it. */
ret = devm_request_irq(&pdev->dev, ssi_private->irq,
--
1.8.4
^ permalink raw reply related
* [PATCH v3 1/4] dma: imx-sdma: Add sdma firmware version 2 support
From: Nicolin Chen @ 2013-10-31 8:22 UTC (permalink / raw)
To: s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
In-Reply-To: <cover.1383207153.git.b42378@freescale.com>
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
drivers/dma/imx-sdma.c | 15 ++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 +++++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..c7ece8d 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -323,6 +323,7 @@ struct sdma_engine {
struct clk *clk_ipg;
struct clk *clk_ahb;
spinlock_t channel_0_lock;
+ u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
};
@@ -1238,6 +1239,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
}
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1 34
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 38
static void sdma_add_scripts(struct sdma_engine *sdma,
const struct sdma_script_start_addrs *addr)
@@ -1246,7 +1248,7 @@ static void sdma_add_scripts(struct sdma_engine *sdma,
s32 *saddr_arr = (u32 *)sdma->script_addrs;
int i;
- for (i = 0; i < SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1; i++)
+ for (i = 0; i < sdma->script_number; i++)
if (addr_arr[i] > 0)
saddr_arr[i] = addr_arr[i];
}
@@ -1272,6 +1274,17 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
goto err_firmware;
if (header->ram_code_start + header->ram_code_size > fw->size)
goto err_firmware;
+ switch (header->version_major) {
+ case 1:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1;
+ break;
+ case 2:
+ sdma->script_number = SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2;
+ break;
+ default:
+ dev_err(sdma->dev, "unknown firmware version\n");
+ return;
+ }
addr = (void *)header + header->script_addrs_start;
ram_code = (void *)header + header->ram_code_start;
diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
index 3a39428..eabac4e 100644
--- a/include/linux/platform_data/dma-imx-sdma.h
+++ b/include/linux/platform_data/dma-imx-sdma.h
@@ -43,6 +43,11 @@ struct sdma_script_start_addrs {
s32 dptc_dvfs_addr;
s32 utra_addr;
s32 ram_code_start_addr;
+ /* End of v1 array */
+ s32 mcu_2_ssish_addr;
+ s32 ssish_2_mcu_addr;
+ s32 hdmi_dma_addr;
+ /* End of v2 array */
};
/**
--
1.8.4
^ permalink raw reply related
* [PATCH v3 0/4] Add dual-fifo mode support of i.MX ssi
From: Nicolin Chen @ 2013-10-31 8:22 UTC (permalink / raw)
To: s.hauer, timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
swarren, linux-kernel, rob.herring, philippe.retornaz, galak,
dmaengine, ijc+devicetree, linuxppc-dev, linux-arm-kernel
Changelog
v3:
* PATCH-1: Add comments to indicate the end of v1 and v2 array.
* PATCH-3: Use better way to keep watermark as even number.
*
* Nothing changes for PATCH-2 and PATCH-4
v2:
* Instead of adding rogue scripts to current SDMA driver based on firmware
* V1, we define the new SDMA firmware as version 2 and bisect the PATCH-1
* to two patches: The first is to add version check code to the SDMA driver;
* And the second is to add SSI dual FIFO DMATYPE.
*
* Nothing changes for the last two patches.
v1:
* SSI can reduce hardware overrun/underrun possibility when using dual
* fifo mode. To support this mode, we need to first update sdma sciprt
* list, and then enable dual fifo BIT in SSI driver, and last update DT
* bindings of i.MX series.
*
* ! This series of patches has a direct dependency between them. When
* ! applying them, we need to apply to one single branch. Otherwise,
* ! it would break currect branches.
Nicolin Chen (4):
dma: imx-sdma: Add sdma firmware version 2 support
dma: imx-sdma: Add new dma type for ssi dual fifo script
ASoC: fsl_ssi: Add dual fifo mode support
ARM: dts: imx: use dual-fifo sdma script for ssi
.../devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
arch/arm/boot/dts/imx6sl.dtsi | 12 ++++++------
drivers/dma/imx-sdma.c | 19 ++++++++++++++++++-
include/linux/platform_data/dma-imx-sdma.h | 5 +++++
include/linux/platform_data/dma-imx.h | 1 +
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++++-
9 files changed, 62 insertions(+), 18 deletions(-)
--
1.8.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox