[PATCH 0/3] Fixes for AMD Stoney ACP audio

[PATCH 0/3] Fixes for AMD Stoney ACP audio

[Alex Deucher]

This patch set is just a couple fixes for the Audio CoProcessor (ACP)
on AMD Stoney platforms and a small general fix for the rt5645
codec driver.

The entire patch set can also be viewed here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=sound-for-next-stoney

Thanks!

Alex

Akshu Agrawal (2):
  ASoC: AMD: Make the driver name consistent across files
  ASoC: rt5645: Wait for 400msec before concluding on value of
    RT5645_VENDOR_ID2

Vijendar Mukunda (1):
  ASoC: amd: Report accurate hw_ptr during dma

 sound/soc/amd/Makefile      |  4 +--
 sound/soc/amd/acp-pcm-dma.c | 77 ++++++++++++++++++++++++++++-----------------
 sound/soc/amd/acp.h         | 10 ++++++
 sound/soc/codecs/rt5645.c   | 12 +++++++
 4 files changed, 73 insertions(+), 30 deletions(-)

-- 
2.5.5

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Alex Deucher]

From: Vijendar Mukunda <Vijendar.Mukunda@amd.com>

Using hw register to read transmitted byte count and report
accordingly the hw pointer.

BUG=b:63121716
TEST=
modprobe snd-soc-acp-pcm.ko
modprobe snd-soc-acp-rt5645.ko
aplay <file>

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Akshu Agrawal <Akshu.Agrawal@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/659699
Commit-Ready: Akshu Agrawal <akshu.agrawal@amd.com>
Tested-by: Akshu Agrawal <akshu.agrawal@amd.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676627
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 sound/soc/amd/acp-pcm-dma.c | 71 ++++++++++++++++++++++++++++-----------------
 sound/soc/amd/acp.h         | 10 +++++++
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee..e19f281 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -817,39 +817,48 @@ static int acp_dma_hw_free(struct snd_pcm_substream *substream)
 	return snd_pcm_lib_free_pages(substream);
 }
 
+static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+{
+	union acp_dma_count playback_dma_count;
+	union acp_dma_count capture_dma_count;
+	u64 bytescount = 0;
+
+	if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
+					mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
+		playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+					mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
+		bytescount = playback_dma_count.bytescount;
+	} else {
+		capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
+					mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
+		capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+					mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
+		bytescount = capture_dma_count.bytescount;
+	}
+	return bytescount;
+}
+
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
 {
-	u16 dscr;
-	u32 mul, dma_config, period_bytes;
+	u32 buffersize;
 	u32 pos = 0;
+	u64 bytescount = 0;
 
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct audio_substream_data *rtd = runtime->private_data;
 
-	period_bytes = frames_to_bytes(runtime, runtime->period_size);
-	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-		dscr = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CUR_DSCR_13);
+	buffersize = frames_to_bytes(runtime, runtime->buffer_size);
+	bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
 
-		if (dscr == PLAYBACK_START_DMA_DESCR_CH13)
-			mul = 0;
-		else
-			mul = 1;
-		pos =  (mul * period_bytes);
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		if (bytescount > rtd->renderbytescount)
+			bytescount = bytescount - rtd->renderbytescount;
+		pos =  bytescount % buffersize;
 	} else {
-		dma_config = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CNTL_14);
-		if (dma_config != 0) {
-			dscr = acp_reg_read(rtd->acp_mmio,
-						mmACP_DMA_CUR_DSCR_14);
-			if (dscr == CAPTURE_START_DMA_DESCR_CH14)
-				mul = 1;
-			else
-				mul = 2;
-			pos = (mul * period_bytes);
-		}
-
-		if (pos >= (2 * period_bytes))
-			pos = 0;
-
+		if (bytescount > rtd->capturebytescount)
+			bytescount = bytescount - rtd->capturebytescount;
+		pos = bytescount % buffersize;
 	}
 	return bytes_to_frames(runtime, pos);
 }
@@ -904,6 +913,7 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 {
 	int ret;
 	u32 loops = 1000;
+	u64 bytescount = 0;
 
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct snd_soc_pcm_runtime *prtd = substream->private_data;
@@ -915,7 +925,11 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 	case SNDRV_PCM_TRIGGER_START:
 	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 	case SNDRV_PCM_TRIGGER_RESUME:
+		bytescount = acp_get_byte_count(rtd->acp_mmio,
+						substream->stream);
 		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+			if (rtd->renderbytescount == 0)
+				rtd->renderbytescount = bytescount;
 			acp_dma_start(rtd->acp_mmio,
 						SYSRAM_TO_ACP_CH_NUM, false);
 			while (acp_reg_read(rtd->acp_mmio, mmACP_DMA_CH_STS) &
@@ -932,6 +946,8 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 					ACP_TO_I2S_DMA_CH_NUM, true);
 
 		} else {
+			if (rtd->capturebytescount == 0)
+				rtd->capturebytescount = bytescount;
 			acp_dma_start(rtd->acp_mmio,
 					    I2S_TO_ACP_DMA_CH_NUM, true);
 		}
@@ -945,12 +961,15 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 		 * channels will stopped automatically after its transfer
 		 * completes : SYSRAM_TO_ACP_CH_NUM / ACP_TO_SYSRAM_CH_NUM
 		 */
-		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 			ret = acp_dma_stop(rtd->acp_mmio,
 					ACP_TO_I2S_DMA_CH_NUM);
-		else
+			rtd->renderbytescount = 0;
+		} else {
 			ret = acp_dma_stop(rtd->acp_mmio,
 					I2S_TO_ACP_DMA_CH_NUM);
+			rtd->capturebytescount = 0;
+		}
 		break;
 	default:
 		ret = -EINVAL;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index a330a99..de08ff0 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -83,6 +83,8 @@ struct audio_substream_data {
 	u16 num_of_pages;
 	u16 direction;
 	uint64_t size;
+	u64 renderbytescount;
+	u64 capturebytescount;
 	void __iomem *acp_mmio;
 };
 
@@ -93,6 +95,14 @@ struct audio_drv_data {
 	u32 asic_type;
 };
 
+union acp_dma_count {
+	struct {
+	u32 low;
+	u32 high;
+	} bcount;
+	u64 bytescount;
+};
+
 enum {
 	ACP_TILE_P1 = 0,
 	ACP_TILE_P2,
-- 
2.5.5

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 564 bytes --]

On Fri, Nov 03, 2017 at 04:35:43PM -0400, Alex Deucher wrote:

> Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
> Signed-off-by: Akshu Agrawal <Akshu.Agrawal@amd.com>
> Reviewed-on: https://chromium-review.googlesource.com/659699
> Commit-Ready: Akshu Agrawal <akshu.agrawal@amd.com>
> Tested-by: Akshu Agrawal <akshu.agrawal@amd.com>
> Reviewed-by: Jason Clinton <jclinton@chromium.org>
> Reviewed-on: https://chromium-review.googlesource.com/676627

These two URLs are different, what was being reviewed here?  What is
Commit-Ready supposed to mean?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mukunda,Vijendar]

Removing URL links and commit-ready description in v2.


On Monday 06 November 2017 09:18 PM, Mark Brown wrote:
> On Fri, Nov 03, 2017 at 04:35:43PM -0400, Alex Deucher wrote:
>
>> Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
>> Signed-off-by: Akshu Agrawal <Akshu.Agrawal@amd.com>
>> Reviewed-on: https://chromium-review.googlesource.com/659699
>> Commit-Ready: Akshu Agrawal <akshu.agrawal@amd.com>
>> Tested-by: Akshu Agrawal <akshu.agrawal@amd.com>
>> Reviewed-by: Jason Clinton <jclinton@chromium.org>
>> Reviewed-on: https://chromium-review.googlesource.com/676627
> These two URLs are different, what was being reviewed here?  What is
> Commit-Ready supposed to mean?

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 514 bytes --]

On Tue, Nov 07, 2017 at 07:26:03PM +0530, Mukunda,Vijendar wrote:
> Removing URL links and commit-ready description in v2.

This doesn't really answer my question:

> > These two URLs are different, what was being reviewed here?  What is
> > Commit-Ready supposed to mean?

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Agrawal, Akshu]

On 11/7/2017 5:07 PM, Mark Brown wrote:
> On Tue, Nov 07, 2017 at 07:26:03PM +0530, Mukunda,Vijendar wrote:
>> Removing URL links and commit-ready description in v2.
> 
> This doesn't really answer my question:
> 
>>> These two URLs are different, what was being reviewed here?  What is
>>> Commit-Ready supposed to mean?

Same patch is reviewed, once on 4.4 kernel (659699) and then on 4.12 
kernel (672267).
Commit-ready is to get it merged on tree after receiving a +2.

> 
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.
> 

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 546 bytes --]

On Tue, Nov 07, 2017 at 09:34:35PM +0530, Agrawal, Akshu wrote:
> On 11/7/2017 5:07 PM, Mark Brown wrote:

> > > > These two URLs are different, what was being reviewed here?  What is
> > > > Commit-Ready supposed to mean?

> Same patch is reviewed, once on 4.4 kernel (659699) and then on 4.12 kernel
> (672267).
> Commit-ready is to get it merged on tree after receiving a +2.

OK, that's not unreasonable but probably best to mention if the review
was in the context of a very old kernel, sometimes upstream changes can
invalidate the review.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Applied "ASoC: amd: Report accurate hw_ptr during dma" to the asoc tree

[Mark Brown]

The patch

   ASoC: amd: Report accurate hw_ptr during dma

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 61add8147942d23519b91f0edc30980d7c14482c Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Date: Fri, 3 Nov 2017 16:35:43 -0400
Subject: [PATCH] ASoC: amd: Report accurate hw_ptr during dma

Using hw register to read transmitted byte count and report
accordingly the hw pointer.

TEST=
modprobe snd-soc-acp-pcm.ko
modprobe snd-soc-acp-rt5645.ko
aplay <file>

Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Signed-off-by: Akshu Agrawal <Akshu.Agrawal@amd.com>
Tested-by: Akshu Agrawal <akshu.agrawal@amd.com>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/amd/acp-pcm-dma.c | 71 ++++++++++++++++++++++++++++-----------------
 sound/soc/amd/acp.h         | 10 +++++++
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee00383..e19f281afeaa 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -817,39 +817,48 @@ static int acp_dma_hw_free(struct snd_pcm_substream *substream)
 	return snd_pcm_lib_free_pages(substream);
 }
 
+static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+{
+	union acp_dma_count playback_dma_count;
+	union acp_dma_count capture_dma_count;
+	u64 bytescount = 0;
+
+	if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
+					mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
+		playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+					mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
+		bytescount = playback_dma_count.bytescount;
+	} else {
+		capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
+					mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
+		capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+					mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
+		bytescount = capture_dma_count.bytescount;
+	}
+	return bytescount;
+}
+
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
 {
-	u16 dscr;
-	u32 mul, dma_config, period_bytes;
+	u32 buffersize;
 	u32 pos = 0;
+	u64 bytescount = 0;
 
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct audio_substream_data *rtd = runtime->private_data;
 
-	period_bytes = frames_to_bytes(runtime, runtime->period_size);
-	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-		dscr = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CUR_DSCR_13);
+	buffersize = frames_to_bytes(runtime, runtime->buffer_size);
+	bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
 
-		if (dscr == PLAYBACK_START_DMA_DESCR_CH13)
-			mul = 0;
-		else
-			mul = 1;
-		pos =  (mul * period_bytes);
+	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+		if (bytescount > rtd->renderbytescount)
+			bytescount = bytescount - rtd->renderbytescount;
+		pos =  bytescount % buffersize;
 	} else {
-		dma_config = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CNTL_14);
-		if (dma_config != 0) {
-			dscr = acp_reg_read(rtd->acp_mmio,
-						mmACP_DMA_CUR_DSCR_14);
-			if (dscr == CAPTURE_START_DMA_DESCR_CH14)
-				mul = 1;
-			else
-				mul = 2;
-			pos = (mul * period_bytes);
-		}
-
-		if (pos >= (2 * period_bytes))
-			pos = 0;
-
+		if (bytescount > rtd->capturebytescount)
+			bytescount = bytescount - rtd->capturebytescount;
+		pos = bytescount % buffersize;
 	}
 	return bytes_to_frames(runtime, pos);
 }
@@ -904,6 +913,7 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 {
 	int ret;
 	u32 loops = 1000;
+	u64 bytescount = 0;
 
 	struct snd_pcm_runtime *runtime = substream->runtime;
 	struct snd_soc_pcm_runtime *prtd = substream->private_data;
@@ -915,7 +925,11 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 	case SNDRV_PCM_TRIGGER_START:
 	case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 	case SNDRV_PCM_TRIGGER_RESUME:
+		bytescount = acp_get_byte_count(rtd->acp_mmio,
+						substream->stream);
 		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+			if (rtd->renderbytescount == 0)
+				rtd->renderbytescount = bytescount;
 			acp_dma_start(rtd->acp_mmio,
 						SYSRAM_TO_ACP_CH_NUM, false);
 			while (acp_reg_read(rtd->acp_mmio, mmACP_DMA_CH_STS) &
@@ -932,6 +946,8 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 					ACP_TO_I2S_DMA_CH_NUM, true);
 
 		} else {
+			if (rtd->capturebytescount == 0)
+				rtd->capturebytescount = bytescount;
 			acp_dma_start(rtd->acp_mmio,
 					    I2S_TO_ACP_DMA_CH_NUM, true);
 		}
@@ -945,12 +961,15 @@ static int acp_dma_trigger(struct snd_pcm_substream *substream, int cmd)
 		 * channels will stopped automatically after its transfer
 		 * completes : SYSRAM_TO_ACP_CH_NUM / ACP_TO_SYSRAM_CH_NUM
 		 */
-		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
 			ret = acp_dma_stop(rtd->acp_mmio,
 					ACP_TO_I2S_DMA_CH_NUM);
-		else
+			rtd->renderbytescount = 0;
+		} else {
 			ret = acp_dma_stop(rtd->acp_mmio,
 					I2S_TO_ACP_DMA_CH_NUM);
+			rtd->capturebytescount = 0;
+		}
 		break;
 	default:
 		ret = -EINVAL;
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index a330a99bfff8..de08ff077ac7 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -83,6 +83,8 @@ struct audio_substream_data {
 	u16 num_of_pages;
 	u16 direction;
 	uint64_t size;
+	u64 renderbytescount;
+	u64 capturebytescount;
 	void __iomem *acp_mmio;
 };
 
@@ -93,6 +95,14 @@ struct audio_drv_data {
 	u32 asic_type;
 };
 
+union acp_dma_count {
+	struct {
+	u32 low;
+	u32 high;
+	} bcount;
+	u64 bytescount;
+};
+
 enum {
 	ACP_TILE_P1 = 0,
 	ACP_TILE_P2,
-- 
2.15.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] ASoC: AMD: Make the driver name consistent across files

[Alex Deucher]

From: Akshu Agrawal <akshu.agrawal@amd.com>

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci0000:00/0000:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 sound/soc/amd/Makefile      | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff..f07fd2e 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs	:= acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281..13d040a 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
 	.info = SNDRV_PCM_INFO_INTERLEAVED |
 		SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
 	.probe = acp_audio_probe,
 	.remove = acp_audio_remove,
 	.driver = {
-		.name = "acp_audio_dma",
+		.name = DRV_NAME,
 		.pm = &acp_pm_ops,
 	},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("Vijendar.Mukunda@amd.com");
 MODULE_AUTHOR("Maruthi.Bayyavarapu@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.5.5

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Applied "ASoC: amd: Make the driver name consistent across files" to the asoc tree

[Mark Brown]

The patch

   ASoC: amd: Make the driver name consistent across files

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From bdd2a858afd55cc11723df9dd2841241a4c49ce5 Mon Sep 17 00:00:00 2001
From: Akshu Agrawal <akshu.agrawal@amd.com>
Date: Wed, 8 Nov 2017 12:24:02 -0500
Subject: [PATCH] ASoC: amd: Make the driver name consistent across files

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci0000:00/0000:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

TEST=boot and check for device in lsmod

[Removed yet more ChromeOS crap from the changelog -- broonie]

Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/amd/Makefile      | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs	:= acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281afeaa..13d040a4d26f 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
 	.info = SNDRV_PCM_INFO_INTERLEAVED |
 		SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
 	.probe = acp_audio_probe,
 	.remove = acp_audio_remove,
 	.driver = {
-		.name = "acp_audio_dma",
+		.name = DRV_NAME,
 		.pm = &acp_pm_ops,
 	},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("Vijendar.Mukunda@amd.com");
 MODULE_AUTHOR("Maruthi.Bayyavarapu@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.15.0

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Applied "ASoC: AMD: Make the driver name consistent across files" to the asoc tree

[Mark Brown]

The patch

   ASoC: AMD: Make the driver name consistent across files

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From a76d7f5454c688b52dc849e832cc4c6dd0975723 Mon Sep 17 00:00:00 2001
From: Akshu Agrawal <akshu.agrawal@amd.com>
Date: Fri, 3 Nov 2017 16:35:44 -0400
Subject: [PATCH] ASoC: AMD: Make the driver name consistent across files

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci0000:00/0000:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Jason Clinton <jclinton@chromium.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 sound/soc/amd/Makefile      | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 ++++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs	:= acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee00383..95c61ecdd1dd 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
 	.info = SNDRV_PCM_INFO_INTERLEAVED |
 		SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1170,7 +1172,7 @@ static struct platform_driver acp_dma_driver = {
 	.probe = acp_audio_probe,
 	.remove = acp_audio_remove,
 	.driver = {
-		.name = "acp_audio_dma",
+		.name = DRV_NAME,
 		.pm = &acp_pm_ops,
 	},
 };
@@ -1181,4 +1183,4 @@ MODULE_AUTHOR("Vijendar.Mukunda@amd.com");
 MODULE_AUTHOR("Maruthi.Bayyavarapu@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.14.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

[Alex Deucher]

From: Akshu Agrawal <akshu.agrawal@amd.com>

Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait and attempt
before erroring out.

BUG=b:66978383
TEST=Cold boot the device and check for sound device.

Signed-off-by: Akshu Agrawal <akshu.agrawal@amd.com>
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 sound/soc/codecs/rt5645.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 23cc2cb..2da0b33 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -55,6 +55,8 @@ MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
 #define RT5645_HWEQ_NUM 57
 
+#define TIME_TO_POWER_MS 400
+
 static const struct regmap_range_cfg rt5645_ranges[] = {
 	{
 		.name = "PR",
@@ -3712,6 +3714,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
 	int ret, i;
 	unsigned int val;
 	struct regmap *regmap;
+	int timeout = TIME_TO_POWER_MS;
 
 	rt5645 = devm_kzalloc(&i2c->dev, sizeof(struct rt5645_priv),
 				GFP_KERNEL);
@@ -3786,6 +3789,15 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
 	}
 	regmap_read(regmap, RT5645_VENDOR_ID2, &val);
 
+	/*
+	 * Read for 400msec, as it is the interval required between
+	 * read and power On.
+	 */
+	while (val != RT5645_DEVICE_ID && val != RT5650_DEVICE_ID && --timeout) {
+		msleep(1);
+		regmap_read(regmap, RT5645_VENDOR_ID2, &val);
+	}
+
 	switch (val) {
 	case RT5645_DEVICE_ID:
 		rt5645->regmap = devm_regmap_init_i2c(i2c, &rt5645_regmap);
-- 
2.5.5

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1452 bytes --]

On Fri, Nov 03, 2017 at 04:35:45PM -0400, Alex Deucher wrote:

> Minimum time required between power On of codec and read
> of RT5645_VENDOR_ID2 is 400msec. We should wait and attempt
> before erroring out.

So the description says we have to wait 400ms before attempting a
read...

> BUG=b:66978383

What does this mean?

> @@ -3786,6 +3789,15 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
>  	}
>  	regmap_read(regmap, RT5645_VENDOR_ID2, &val);
>  
> +	/*
> +	 * Read for 400msec, as it is the interval required between
> +	 * read and power On.
> +	 */
> +	while (val != RT5645_DEVICE_ID && val != RT5650_DEVICE_ID && --timeout) {
> +		msleep(1);
> +		regmap_read(regmap, RT5645_VENDOR_ID2, &val);
> +	}
> +

...but what we actually do is try to read up to 400 times starting well
before that 400ms is up.  This directly contradicts what the commit
message said we needed, may take a lot longer if the chip misbehaves on
the I2C bus while it's not ready (which wouldn't be that much of a
surprise), might lead to us reporting before the chip is really stable
(if the read happens to work while the chip isn't yet stable) and could
cause lots of noise on the console if the I2C controller gets upset.
What are we actually waiting for here?

If we really need 400ms of dead reckoning time (which is a lot for a
modern chip, that feels more like a VMID ramp) then it's going to be
safer to just do that.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

[Agrawal, Akshu]

On 11/6/2017 9:54 PM, Mark Brown wrote:
> On Fri, Nov 03, 2017 at 04:35:45PM -0400, Alex Deucher wrote:
> 
>> Minimum time required between power On of codec and read
>> of RT5645_VENDOR_ID2 is 400msec. We should wait and attempt
>> before erroring out.
> 
> So the description says we have to wait 400ms before attempting a
> read...

Yes, that's true.

> 
>> BUG=b:66978383
> 
> What does this mean?

A bug ID. Removing it in V2.

> 
>> @@ -3786,6 +3789,15 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
>>   	}
>>   	regmap_read(regmap, RT5645_VENDOR_ID2, &val);
>>   
>> +	/*
>> +	 * Read for 400msec, as it is the interval required between
>> +	 * read and power On.
>> +	 */
>> +	while (val != RT5645_DEVICE_ID && val != RT5650_DEVICE_ID && --timeout) {
>> +		msleep(1);
>> +		regmap_read(regmap, RT5645_VENDOR_ID2, &val);
>> +	}
>> +
> 
> ...but what we actually do is try to read up to 400 times starting well
> before that 400ms is up.  This directly contradicts what the commit
> message said we needed, may take a lot longer if the chip misbehaves on
> the I2C bus while it's not ready (which wouldn't be that much of a
> surprise), might lead to us reporting before the chip is really stable
> (if the read happens to work while the chip isn't yet stable) and could
> cause lots of noise on the console if the I2C controller gets upset.
> What are we actually waiting for here?
> 

In my understanding if we get RT5645 or RT5650 DEVICE ID from register 
RT5645_VENDOR_ID2 then that means the chip is stable.

> If we really need 400ms of dead reckoning time (which is a lot for a
> modern chip, that feels more like a VMID ramp) then it's going to be
> safer to just do that.
> 

Agreed, will just sleep for 400ms before reading the register value.