Changelog
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 in one single branch. Otherwise,
* ! it would break currect branches.
Nicolin Chen (3):
dma: imx-sdma: Add ssi dual fifo script support
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 | 6 +++++-
include/linux/platform_data/dma-imx-sdma.h | 2 ++
include/linux/platform_data/dma-imx.h | 1 +
sound/soc/fsl/fsl_ssi.c | 24 +++++++++++++++++++++-
9 files changed, 48 insertions(+), 18 deletions(-)
--
1.8.4
There's a script for SSI missing in current sdma script list. Thus add it.
This script would allow SSI use its dual fifo mode to transimit/receive
data without occasional hardware underrun/overrun.
This patch also fixed a counting error for total number of scripts.
Signed-off-by: Nicolin Chen <redacted>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
drivers/dma/imx-sdma.c | 6 +++++-
include/linux/platform_data/dma-imx-sdma.h | 2 ++
include/linux/platform_data/dma-imx.h | 1 +
4 files changed, 9 insertions(+), 1 deletion(-)
@@ -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 The third cell specifies the transfer priority as below.
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 <redacted>
---
sound/soc/fsl/fsl_ssi.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
@@ -416,6 +417,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);+}+return0;}
@@ -952,7 +963,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")){-u32dma_events[2];+u32dma_events[2],dmas[4];ssi_private->ssi_on_imx=true;ssi_private->clk=devm_clk_get(&pdev->dev,NULL);
@@ -1006,6 +1017,17 @@ 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+*asevennumbersduetodmascriptlimitation.+*/+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;+}}elseif(ssi_private->use_dma){/* The 'name' should not have any slashes in it. */ret=devm_request_irq(&pdev->dev,ssi_private->irq,
From: Timur Tabi <hidden> Date: 2013-10-29 12:42:45
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.
Have you measured any real performance gain with this patch? I
considered adding dual-FIFO support when I originally wrote this driver,
but it didn't appear to have any real benefit, but it used twice as many
DMA channels.
I'm concerned that this is another patch that just enables a useless
feature.
Without dual fifo support, handware underrun would occasionally occur and =
then two audio channels would physically swap. This could be easily reprodu=
ced in low bus frequency situation, while it would be better if we enable d=
ual fifo.
Sent by Android device.
Timur Tabi [off-list ref] wrote:
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.
Have you measured any real performance gain with this patch? I
considered adding dual-FIFO support when I originally wrote this driver,
but it didn't appear to have any real benefit, but it used twice as many
DMA channels.
I'm concerned that this is another patch that just enables a useless
feature.
From: Timur Tabi <hidden> Date: 2013-10-29 13:00:48
Chen Guangyu-B42378 wrote:
Without dual fifo support, handware underrun would occasionally
occur and then two audio channels would physically swap. This could
be easily reproduced in low bus frequency situation, while it would
be better if we enable dual fifo.
Thank you, sir. And sorry for taking your time.
Sent by Android device.
Timur Tabi [off-list ref] wrote:
Chen Guangyu-B42378 wrote:
Without dual fifo support, handware underrun would occasionally
occur and then two audio channels would physically swap. This could
be easily reproduced in low bus frequency situation, while it would
be better if we enable dual fifo.
On Tue, Oct 29, 2013 at 08:33:15PM +0800, Nicolin Chen wrote:
There's a script for SSI missing in current sdma script list. Thus add it.
This script would allow SSI use its dual fifo mode to transimit/receive
data without occasional hardware underrun/overrun.
This patch also fixed a counting error for total number of scripts.
Look at drivers/dma/imx-sdma.c:
/**
* struct sdma_firmware_header - Layout of the firmware image
*
* @magic "SDMA"
* @version_major increased whenever layout of struct
* sdma_script_start_addrs
* changes.
Can you image why this firmware has a version field? Right, it's because
it encodes the layout of struct sdma_script_start_addrs.
As the comment clearly states you have to *increase this field* when you
add scripts.
Obviously you missed that, as the firmware on lkml posted recently
shows:
And no, this is not a bug. It's your firmware header that is buggy.
What you need is:
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 37
You (you as a company, not you as a person) knew that it was me who
created this firmware format. So it was absolutely unnecessary to create
an incompatible firmware instead of dropping me a short note.
Please add a version check to the driver as necessary and provide a proper
firmware.
Sascha
--
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-5555 |
@@ -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
=20
The third cell specifies the transfer priority as below.
For the DT-Binding portion:
Acked-by: Kumar Gala <redacted>
- k
--=20
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, =
hosted by The Linux Foundation
Hi Sascha,
On Tue, Oct 29, 2013 at 02:51:43PM +0100, Sascha Hauer wrote:
Look at drivers/dma/imx-sdma.c:
quoted
/**
* struct sdma_firmware_header - Layout of the firmware image
*
* @magic "SDMA"
* @version_major increased whenever layout of struct
* sdma_script_start_addrs
* changes.
Can you image why this firmware has a version field? Right, it's because
it encodes the layout of struct sdma_script_start_addrs.
As the comment clearly states you have to *increase this field* when you
add scripts.
Obviously you missed that, as the firmware on lkml posted recently
shows:
And no, this is not a bug. It's your firmware header that is buggy.
I wasn't aware that the problem is far more complicated than I thought.
And thank you for telling me all this.
What you need is:
#define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V2 37
You (you as a company, not you as a person) knew that it was me who
created this firmware format. So it was absolutely unnecessary to create
an incompatible firmware instead of dropping me a short note.
Please add a version check to the driver as necessary and provide a proper
firmware.
Just currently it's not easy for me to create a new proper firmware,
and I's been told that besides this version number, it also lacks a
decent license info. So may I just refine this patch as you suggested
to add a version check and add those new scripts first?
Thank you,
Nicolin Chen
Sascha
--
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-5555 |