Re: [PATCH v2 1/4] dma: imx-sdma: Add sdma firmware version 2 support
On Thu, Oct 31, 2013 at 02:32:03PM +0800, Nicolin Chen wrote:
> 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
> ---
> diff --git a/include/linux/platform_data/dma-imx-sdma.h
> b/include/linux/platform_data/dma-imx-sdma.h
> index 3a39428..14ca582 100644
> --- a/include/linux/platform_data/dma-imx-sdma.h
> +++ b/include/linux/platform_data/dma-imx-sdma.h
> @@ -43,6 +43,9 @@ struct sdma_script_start_addrs {
> s32 dptc_dvfs_addr;
> s32 utra_addr;
> s32 ram_code_start_addr;
You could add a comment here, like: /* End of v1 array */
Otherwise:
Acked-by: Sascha Hauer
> + s32 mcu_2_ssish_addr;
> + s32 ssish_2_mcu_addr;
> + s32 hdmi_dma_addr;
> };
>
> /**
> --
> 1.8.4
>
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/4] ASoC: fsl_ssi: Add dual fifo mode support
Hi, Philippe On Thu, Oct 31, 2013 at 08:54:12AM +0100, Philippe Rétornaz wrote: > Hi > > > > >+/* When using dual fifo mode, we need to keep watermark > >+ * as even numbers due to dma script limitation. > >+ */ > >+ssi_private->dma_params_tx.maxburst /= 2; > >+ssi_private->dma_params_tx.maxburst *= 2; > >+ssi_private->dma_params_rx.maxburst /= 2; > >+ssi_private->dma_params_rx.maxburst *= 2; > > > > Why not using a mask here ? > ssi_private->dma_params_tx.maxburst &= ~0x1; > ssi_private->dma_params_rx.maxburst &= ~0x1; I'll use this in v3. Thank you! Nicolin Chen > > Regards, > > Philippe > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/4] Add dual-fifo mode support of i.MX ssi
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/4] dma: imx-sdma: Add sdma firmware version 2 support
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
---
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_V134
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series. Signed-off-by: Nicolin Chen --- 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 = <0x0203 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";
Re: [PATCH v2 3/4] ASoC: fsl_ssi: Add dual fifo mode support
Hi + /* When using dual fifo mode, we need to keep watermark +* as even numbers due to dma script limitation. +*/ + ssi_private->dma_params_tx.maxburst /= 2; + ssi_private->dma_params_tx.maxburst *= 2; + ssi_private->dma_params_rx.maxburst /= 2; + ssi_private->dma_params_rx.maxburst *= 2; Why not using a mask here ? ssi_private->dma_params_tx.maxburst &= ~0x1; ssi_private->dma_params_rx.maxburst &= ~0x1; Regards, Philippe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] offb: make the screen properties endian safe
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 --- 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 != 0xu)) - pitch = *pp; + pitch = be32_to_cpup(pp); else pitch = width * ((depth + 7) / 8); -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
"Paul E. McKenney" 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] of: move definition of of_find_next_cache_node into common code.
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 >> >> 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 >> Cc: Grant Likely >> Cc: Rob Herring >> Signed-off-by: Sudeep KarkadaNagesha > > I've seen no follow up on that, I'm happy to stick it in powerpc-next > with some other late stuff. > 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil 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 > > Acked-by: Hans Verkuil 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 > > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
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);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar driver crashes in Kernel v3.10
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/4] ASoC: fsl_ssi: Add dual fifo mode support
Thank you for the comments.
I'll refine this part.
Sent by Android device.
Timur Tabi 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);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: perf events ring buffer memory barrier on powerpc
> "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? 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: perf events ring buffer memory barrier on powerpc
"David Laight" 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 1/4] dma: imx-sdma: Add sdma firmware version 2 support
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
---
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_V134
+#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V238
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 0/4] Add dual-fifo mode support of i.MX ssi
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 3/4] ASoC: fsl_ssi: Add dual fifo mode support
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 2/4] dma: imx-sdma: Add new dma type for ssi dual fifo script
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
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 4/4] ARM: dts: imx: use dual-fifo sdma script for ssi
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series. Signed-off-by: Nicolin Chen --- 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 = <0x0203 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";
Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper
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 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 > > > > Acked-by: Hans Verkuil > > 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 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. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: perf events ring buffer memory barrier on powerpc
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?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/4] ASoC: fsl_ssi: Add dual fifo mode support
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 signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[V2 PATCH 1/3] powerpc: Enable emulate_step In Little Endian Mode
From: Tom Musta This patch modifies the endian chicken switch in the single step emulation code (emulate_step()). The old (big endian) code bailed early if a load or store instruction was to be emulated in little endian mode. The new code modifies the check and only bails in a cross-endian situation (LE mode in a kernel compiled for BE and vice verse). V2: fixed bug in MSR[LE] check identified by Andreas Schwab and Geert Uytterhoeven. Signed-off-by: Tom Musta --- arch/powerpc/lib/sstep.c | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c index b1faa15..7bfaa9d 100644 --- a/arch/powerpc/lib/sstep.c +++ b/arch/powerpc/lib/sstep.c @@ -1222,12 +1222,18 @@ int __kprobes emulate_step(struct pt_regs *regs, unsigned int instr) } /* -* Following cases are for loads and stores, so bail out -* if we're in little-endian mode. +* Following cases are for loads and stores and this +* implementation does not support cross-endian. So +* bail out if this is the case. */ +#ifdef __BIG_ENDIAN__ if (regs->msr & MSR_LE) return 0; - +#endif +#ifdef __LITTLE_ENDIAN__ + if (!(regs->msr & MSR_LE)) + return 0; +#endif /* * Save register RA in case it's an update form load or store * and the access faults. -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[V2 PATCH 0/3] powerpc: Fix Little Endian Bugs in Single Step Code
From: Tom Musta This patch series addresses bugs in the PowerPC single-step emulation code (arch/powerpc/lib/sstep.c) pertaining to Little Endian. The existing code has a chicken switch for little endian. The first patch softens the restriction so that only cross-endian modes are not supported. There is a general problem with unaligned little endian loads and stores. This is addressed by the second patch. Finally, there is a problem with unaligned single precision floating point loads and stores which is addressed by the third patch. V2: fixed bug in MSR[LE] check identified by Andreas Schwab and Geert Uytterhoeven. Tom Musta (3): powerpc: Enable emulate_step In Little Endian Mode powerpc: Fix Unaligned Fixed Point Loads and Stores powerpc: Fix Unaligned LE Floating Point Loads and Stores arch/powerpc/lib/sstep.c | 109 +++-- 1 files changed, 94 insertions(+), 15 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[V2 PATCH 2/3] powerpc: Fix Unaligned Fixed Point Loads and Stores
From: Tom Musta
This patch modifies the unaligned access routines of the sstep.c
module so that it properly reverses the bytes of storage operands
in the little endian kernel kernel.
Signed-off-by: Tom Musta
---
arch/powerpc/lib/sstep.c | 45 +
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 7bfaa9d..c8743e1 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -212,11 +212,19 @@ static int __kprobes read_mem_unaligned(unsigned long
*dest, unsigned long ea,
{
int err;
unsigned long x, b, c;
+#ifdef __LITTLE_ENDIAN__
+ int len = nb; /* save a copy of the length for byte reversal */
+#endif
/* unaligned, do this in pieces */
x = 0;
for (; nb > 0; nb -= c) {
+#ifdef __LITTLE_ENDIAN__
+ c = 1;
+#endif
+#ifdef __BIG_ENDIAN__
c = max_align(ea);
+#endif
if (c > nb)
c = max_align(nb);
err = read_mem_aligned(&b, ea, c);
@@ -225,7 +233,24 @@ static int __kprobes read_mem_unaligned(unsigned long
*dest, unsigned long ea,
x = (x << (8 * c)) + b;
ea += c;
}
+#ifdef __LITTLE_ENDIAN__
+ switch (len) {
+ case 2:
+ *dest = byterev_2(x);
+ break;
+ case 4:
+ *dest = byterev_4(x);
+ break;
+#ifdef __powerpc64__
+ case 8:
+ *dest = byterev_8(x);
+ break;
+#endif
+ }
+#endif
+#ifdef __BIG_ENDIAN__
*dest = x;
+#endif
return 0;
}
@@ -273,9 +298,29 @@ static int __kprobes write_mem_unaligned(unsigned long
val, unsigned long ea,
int err;
unsigned long c;
+#ifdef __LITTLE_ENDIAN__
+ switch (nb) {
+ case 2:
+ val = byterev_2(val);
+ break;
+ case 4:
+ val = byterev_4(val);
+ break;
+#ifdef __powerpc64__
+ case 8:
+ val = byterev_8(val);
+ break;
+#endif
+ }
+#endif
/* unaligned or little-endian, do this in pieces */
for (; nb > 0; nb -= c) {
+#ifdef __LITTLE_ENDIAN__
+ c = 1;
+#endif
+#ifdef __BIG_ENDIAN__
c = max_align(ea);
+#endif
if (c > nb)
c = max_align(nb);
err = write_mem_aligned(val >> (nb - c) * 8, ea, c);
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[V2 PATCH 3/3] powerpc: Fix Unaligned LE Floating Point Loads and Stores
From: Tom Musta
This patch addresses unaligned single precision floating point loads
and stores in the single-step code. The old implementation
improperly treated an 8 byte structure as an array of two 4 byte
words, which is a classic little endian bug.
Signed-off-by: Tom Musta
---
arch/powerpc/lib/sstep.c | 52 +++--
1 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index c8743e1..1cfd150 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -355,22 +355,36 @@ static int __kprobes do_fp_load(int rn, int (*func)(int,
unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea & 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) &val[0];
+ ptr = (unsigned long) &data.ul;
if (sizeof(unsigned long) == 8 || nb == 4) {
- err = read_mem_unaligned(&val[0], ea, nb, regs);
- ptr += sizeof(unsigned long) - nb;
+ err = read_mem_unaligned(&data.ul[0], ea, nb, regs);
+ if (nb == 4)
+ ptr = (unsigned long)&(data.single.word);
} else {
/* reading a double on 32-bit */
- err = read_mem_unaligned(&val[0], ea, 4, regs);
+ err = read_mem_unaligned(&data.ul[0], ea, 4, regs);
if (!err)
- err = read_mem_unaligned(&val[1], ea + 4, 4, regs);
+ err = read_mem_unaligned(&data.ul[1], ea + 4, 4, regs);
}
if (err)
return err;
@@ -382,28 +396,42 @@ static int __kprobes do_fp_store(int rn, int (*func)(int,
unsigned long),
struct pt_regs *regs)
{
int err;
- unsigned long val[sizeof(double) / sizeof(long)];
+ union {
+ double dbl;
+ unsigned long ul[2];
+ struct {
+#ifdef __BIG_ENDIAN__
+ unsigned _pad_;
+ unsigned word;
+#endif
+#ifdef __LITTLE_ENDIAN__
+ unsigned word;
+ unsigned _pad_;
+#endif
+ } single;
+ } data;
unsigned long ptr;
if (!address_ok(regs, ea, nb))
return -EFAULT;
if ((ea & 3) == 0)
return (*func)(rn, ea);
- ptr = (unsigned long) &val[0];
+ ptr = (unsigned long) &data.ul[0];
if (sizeof(unsigned long) == 8 || nb == 4) {
- ptr += sizeof(unsigned long) - nb;
+ if (nb == 4)
+ ptr = (unsigned long)&(data.single.word);
err = (*func)(rn, ptr);
if (err)
return err;
- err = write_mem_unaligned(val[0], ea, nb, regs);
+ err = write_mem_unaligned(data.ul[0], ea, nb, regs);
} else {
/* writing a double on 32-bit */
err = (*func)(rn, ptr);
if (err)
return err;
- err = write_mem_unaligned(val[0], ea, 4, regs);
+ err = write_mem_unaligned(data.ul[0], ea, 4, regs);
if (!err)
- err = write_mem_unaligned(val[1], ea + 4, 4, regs);
+ err = write_mem_unaligned(data.ul[1], ea + 4, 4, regs);
}
return err;
}
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Suggestion] drivers: powercap: 'dev_attrs' has already removed from 'struct class'
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Suggestion] drivers: powercap: 'dev_attrs' has already removed from 'struct class'
On 11/01/2013 12:25 AM, Rafael J. Wysocki wrote: > 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. > OK, thanks. > Thanks, > Rafael > > > -- Chen Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the dt-rh tree with the powerpc tree
Hi Rob,
Today's linux-next merge of the dt-rh tree got a conflict in
arch/powerpc/include/asm/prom.h between commit a3e31b458844 ("of: Move
definition of of_find_next_cache_node into common code") from the powerpc
tree and commit 0c3f061c195c ("of: implement of_node_to_nid as a weak
function") from the dt-rh tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/powerpc/include/asm/prom.h
index bf09e5a065b8,7687f82a3217..
--- a/arch/powerpc/include/asm/prom.h
+++ b/arch/powerpc/include/asm/prom.h
@@@ -44,13 -39,9 +39,6 @@@ void of_parse_dma_window(struct device_
extern void kdump_move_device_tree(void);
- #ifdef CONFIG_NUMA
- extern int of_node_to_nid(struct device_node *device);
- #else
- static inline int of_node_to_nid(struct device_node *device) { return 0; }
- #endif
- #define of_node_to_nid of_node_to_nid
-/* cache lookup */
-struct device_node *of_find_next_cache_node(struct device_node *np);
--
extern void of_instantiate_rtc(void);
extern int of_get_ibm_chip_id(struct device_node *np);
pgpWv4h0HrExv.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the kvm-ppc tree with the tree
Hi Alexander,
Today's linux-next merge of the kvm-ppc tree got a conflict in
arch/powerpc/include/asm/processor.h between commit 51ae8d4a2b9e
("powerpc: move debug registers in a structure") from the powerpc tree
and commit 95791988fec6 ("powerpc: move debug registers in a structure")
from the kvm-ppc tree.
Different version of the same patch. I used the powerpc tree version
(there wer other changes there).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpnANmNKFlzW.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the leds tree with the powerpc tree
Hi Bryan,
Today's linux-next merge of the leds tree got a conflict in
include/linux/of.h between commit a3e31b458844 ("of: Move definition of
of_find_next_cache_node into common code") from the powerpc tree and
commit 954e04b9491a ("of: introduce of_get_available_child_count") from
the leds tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/linux/of.h
index 2567ccd32482,54c25606a997..
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@@ -228,8 -226,17 +228,19 @@@ static inline int of_get_child_count(co
return num;
}
+ static inline int of_get_available_child_count(const struct device_node *np)
+ {
+ struct device_node *child;
+ int num = 0;
+
+ for_each_available_child_of_node(np, child)
+ num++;
+
+ return num;
+ }
+
+/* cache lookup */
+extern struct device_node *of_find_next_cache_node(const struct device_node
*);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
#define for_each_node_with_property(dn, prop_name) \
pgpHPj1eNAwDd.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
