Re: [PATCH] ASoC: AMD: Clean kernel log from deferred probe error messages

On 8/26/2020 4:54 PM, Mark Brown wrote: On Wed, Aug 26, 2020 at 04:48:05PM +0530, Akshu Agrawal wrote: While the driver waits for DAIs to be probed and retries probing, avoid printing error messages. This means that if there is a problem with deferred probe no diagnostics will be available,

Re: [v2 1/4] ACPI: APD: Change name from ST to FCH

On 7/31/2020 4:44 PM, Rafael J. Wysocki wrote: On Fri, Jul 31, 2020 at 2:44 AM Agrawal, Akshu wrote: On 7/29/2020 6:56 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-28 01:28:53) AMD SoC general pupose clk is present in new platforms with same MMIO mappings. We can reuse the same

Re: [v2 1/4] ACPI: APD: Change name from ST to FCH

On 7/29/2020 6:56 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-28 01:28:53) AMD SoC general pupose clk is present in new platforms with same MMIO mappings. We can reuse the same clk handler support for other platforms. Hence, changing name from ST(SoC) to FCH(IP) Signed-off-by:

Re: [PATCH 2/4] clk: x86: Change name from ST to FCH

On 7/21/2020 1:36 PM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-19 22:04:57) diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-fch.c similarity index 73% rename from drivers/clk/x86/clk-st.c rename to drivers/clk/x86/clk-fch.c index 25d4b97aff9b..b252f0cf0628 100644 ---

Re: [v2 4/4] clk: x86: Support RV architecture

On 7/21/2020 1:35 PM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-19 22:04:59) diff --git a/drivers/clk/x86/clk-fch.c b/drivers/clk/x86/clk-fch.c index b252f0cf0628..d68bca7b213f 100644 --- a/drivers/clk/x86/clk-fch.c +++ b/drivers/clk/x86/clk-fch.c [...] static int

Re: [PATCH 1/4] ACPI: APD: Change name from ST to FCH

On 7/27/2020 6:58 PM, Rafael J. Wysocki wrote: On Mon, Jul 20, 2020 at 7:06 AM Akshu Agrawal wrote: AMD SoC general pupose clk is present in new platforms with same MMIO mappings. We can reuse the same clk handler support for other platforms. Hence, changing name from ST(SoC) to FCH(IP)

Re: [PATCH 2/5] clk: x86: Change name from ST to FCH

On 7/16/2020 6:12 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-12 17:59:50) diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-fch.c similarity index 73% rename from drivers/clk/x86/clk-st.c rename to drivers/clk/x86/clk-fch.c index 25d4b97aff9b..b252f0cf0628 100644 ---

Re: [PATCH 4/5] clk: x86: Support RV architecture

On 7/16/2020 6:33 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2020-07-12 17:59:52) There is minor difference between previous family of SoC and the current one. Which is the there is only 48Mh fixed clk. There is no mux and no option to select another freq as there in previous.

Re: [PATCH] ASoC: rt5682: Add fmw property to get name of mclk

On 7/7/2020 4:00 PM, Mark Brown wrote: On Tue, Jul 07, 2020 at 03:38:25PM +0530, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk. Thus add fmw property mclk-name to get the name of the system clk and link it to rt5682 mclk. ACPI doesn't support clocks at all,

Re: [PATCH] ASoC: rt5682: Register clocks even when mclk is NULL

On 6/12/2020 10:04 PM, Mark Brown wrote: On Fri, Jun 12, 2020 at 10:01:11PM +0530, Akshu Agrawal wrote: Fixes kernel crash on platforms which do not have mclk exposed in CCF framework. For these platforms have mclk as NULL and continue to register clocks. Derek already submitted this:

Re: [PATCH] ASoC: AMD: Use mixer control to switch between DMICs

On 5/27/2020 4:57 PM, Mark Brown wrote: On Wed, May 27, 2020 at 07:10:16AM +0530, Akshu Agrawal wrote: + SOC_SINGLE_BOOL_EXT("Front Mic", 0, front_mic_get, front_mic_set), This should probably be a mux with two labelled options, or if it's a boolean control it should end in Switch. A

Re: [alsa-devel] [PATCH] ASoC: DA7219: Fix failure in hw_params by not letting set_rate error out

On 4/22/2019 1:09 PM, Cheng-yi Chiang wrote: > Hi Akshu, > > > On Mon, Apr 22, 2019 at 2:15 PM Agrawal, Akshu wrote: >> >> We need to set minimum bclk 64x of wclk as this is hw constraint in one >> of the component used. >> Since, clk_set_rate

[PATCH] ASoC: DA7219: Fix failure in hw_params by not letting set_rate error out

We need to set minimum bclk 64x of wclk as this is hw constraint in one of the component used. Since, clk_set_rate and clk is enabled in machine driver the clk_set_rate in hw_params of da7219 fails and errors out and when it tries to override the value. In cases like these not only clk_set_rate

[v3] ASoC: AMD: Configure wclk and bclk of master codec

With CCF support in da7219, we can now set the correct rate of wclk and bclk. Signed-off-by: Akshu Agrawal --- v2: Removed clk set rate and enable/disable from da7219 ops as da7219 codec takes care of them internally. Clock configuration kept for those codecs where da7219 acts as master of

[v2] ASoC: AMD: Configure wclk and bclk of master codec

With CCF support in da7219, we can now set the correct rate of wclk and bclk. Setting bclk at lower rate at 1.53Mhz from its earlier default rate of 3Mhz, also fixes noise issue observed on some dmics. v2: Removed clk set rate and enable/disable from da7219 ops as da7219 codec takes care of them

[PATCH] ASoC: AMD: Configure wclk and bclk of master codec

With CCF support in da7219, we can now set the correct rate of wclk and bclk. Setting bclk at lower rate at 1.53Mhz from its earlier default rate of 3Mhz, also fixes noise issue observed on some dmics. Signed-off-by: Akshu Agrawal --- sound/soc/amd/acp-da7219-max98357a.c | 40

[PATCH] ASoC: AMD: Configure master codec on all playback/capture cases

In the system design da7219 is the master codec and clocks are generated by it. Bclk is to be generated at the required rate for other codecs used when da7219 is acting only as clock master. For this call hw_params of da7219 during playback/capture on non da7219 codecs. Being able to set bclk at

[PATCH] ASoC: ADAU7002: Add optional delay before start of capture

On capture through some of dmic we observe a glitch at the start of record. This is because we start capturing even before dmic is ready to send out data. The optional delay will be applied after enabling the mic. Signed-off-by: Akshu Agrawal --- sound/soc/codecs/adau7002.c | 45

Re: [PATCH] ASoC: AMD: Add delay before starting to capture

On 1/4/2019 5:57 PM, Mark Brown wrote: > On Thu, Jan 03, 2019 at 10:18:13AM +0000, Agrawal, Akshu wrote: >> On capture through dmic we observe a glitch at the start of record. >> This is because we start capturing even before dmic is ready to send >> out data. The glitch

[PATCH] ASoC: AMD: Add delay before starting to capture

On capture through dmic we observe a glitch at the start of record. This is because we start capturing even before dmic is ready to send out data. The glitch seen last for ~20msec. Signed-off-by: Akshu Agrawal Signed-off-by: Daniel Kurtz --- sound/soc/amd/acp-da7219-max98357a.c | 28

Re: [PATCH v3] ASoC: AMD: Fix race condition between register access

On 11/5/2018 4:45 PM, Mark Brown wrote: > On Wed, Oct 31, 2018 at 09:24:10PM +0000, Agrawal, Akshu wrote: > >> +/* Lock to protect access to registers */ >> +static DEFINE_SPINLOCK(lock); >> + > > Why is this a global variable and not a part of the dri

[PATCH v2] ASoC: DA7219: Implement error check on reg read and write

Failed i2c transaction can lead to failure in reg read or write. Need to have error check for each read write operation. Signed-off-by: Akshu Agrawal --- v2: replaced snd_soc_component_read32 by snd_soc_component_read Since, snd_soc_component_read32 implementation has error, in coming patches we

[PATCH v2] ASoC: DA7219: Implement error check on reg read and write

Failed i2c transaction can lead to failure in reg read or write. Need to have error check for each read write operation. Signed-off-by: Akshu Agrawal --- v2: replaced snd_soc_component_read32 by snd_soc_component_read Since, snd_soc_component_read32 implementation has error, in coming patches we

Re: [PATCH 2/2] ASoC: DA7219: Implement error check on reg read and write

On 12/5/2018 2:46 AM, Adam Thomson wrote: > On 04 December 2018 18:36, Akshu Agrawal wrote: > >> Failed i2c transaction can lead to failure in reg read or write. >> Need to have error check for each read write operation. >> > > I'm not really clear what this gains you. If I2C is broken this

Re: [PATCH 2/2] ASoC: DA7219: Implement error check on reg read and write

On 12/5/2018 2:46 AM, Adam Thomson wrote: > On 04 December 2018 18:36, Akshu Agrawal wrote: > >> Failed i2c transaction can lead to failure in reg read or write. >> Need to have error check for each read write operation. >> > > I'm not really clear what this gains you. If I2C is broken this

[PATCH 2/2] ASoC: DA7219: Implement error check on reg read and write

Failed i2c transaction can lead to failure in reg read or write. Need to have error check for each read write operation. Signed-off-by: Akshu Agrawal --- sound/soc/codecs/da7219.c | 323 +++--- sound/soc/codecs/da7219.h | 2 +- 2 files changed, 247

[PATCH 2/2] ASoC: DA7219: Implement error check on reg read and write

Failed i2c transaction can lead to failure in reg read or write. Need to have error check for each read write operation. Signed-off-by: Akshu Agrawal --- sound/soc/codecs/da7219.c | 323 +++--- sound/soc/codecs/da7219.h | 2 +- 2 files changed, 247

[PATCH 1/2] ASoC: Fix function return type

Function returns -1 on error and the return type should be int. Signed-off-by: Akshu Agrawal --- include/sound/soc.h | 2 +- sound/soc/soc-io.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 8ec1de8..591d743 100644 ---

[PATCH 1/2] ASoC: Fix function return type

Function returns -1 on error and the return type should be int. Signed-off-by: Akshu Agrawal --- include/sound/soc.h | 2 +- sound/soc/soc-io.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 8ec1de8..591d743 100644 ---

[PATCH v3] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- v2: Added 2 helper functions, removed locking in ch

[PATCH v3] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- v2: Added 2 helper functions, removed locking in ch

[PATCH v2] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- v2: Added 2 helper functions, removed locking in ch

[PATCH v2] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- v2: Added 2 helper functions, removed locking in ch

Re: [PATCH] ASoC: AMD: Fix race condition between register access

On 10/30/2018 7:02 AM, Daniel Kurtz wrote: > Hi Akshu, > > > On Mon, Oct 29, 2018 at 1:39 AM Agrawal, Akshu wrote: >> >> During simultaneous running of playback and capture, we >> got hit by incorrect value write on common register. This was due >>

Re: [PATCH] ASoC: AMD: Fix race condition between register access

On 10/30/2018 7:02 AM, Daniel Kurtz wrote: > Hi Akshu, > > > On Mon, Oct 29, 2018 at 1:39 AM Agrawal, Akshu wrote: >> >> During simultaneous running of playback and capture, we >> got hit by incorrect value write on common register. This was due >>

[PATCH] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- sound/soc/amd/acp-pcm-dma.c | 29

[PATCH] ASoC: AMD: Fix race condition between register access

During simultaneous running of playback and capture, we got hit by incorrect value write on common register. This was due to race condition between 2 streams. Fixing this by locking the common register access. Signed-off-by: Akshu Agrawal --- sound/soc/amd/acp-pcm-dma.c | 29

Re: [PATCH 1/2] ASoC: AMD: Fix simultaneous playback and capture on different channel

On 9/10/2018 5:08 PM, Mark Brown wrote: > On Mon, Sep 10, 2018 at 01:36:29PM +0530, Akshu Agrawal wrote: >> If capture and playback are started on different channel (I2S/BT) >> there is a possibilty that channel information passed from machine driver >> is overwritten before the configuration

Re: [PATCH 1/2] ASoC: AMD: Fix simultaneous playback and capture on different channel

On 9/10/2018 5:08 PM, Mark Brown wrote: > On Mon, Sep 10, 2018 at 01:36:29PM +0530, Akshu Agrawal wrote: >> If capture and playback are started on different channel (I2S/BT) >> there is a possibilty that channel information passed from machine driver >> is overwritten before the configuration

Re: [PATCH AUTOSEL 4.18 043/131] ASoC: soc-pcm: Use delay set in component pointer function

On 9/7/2018 5:53 AM, Sasha Levin wrote: > On Mon, Sep 03, 2018 at 12:16:26PM +0100, Mark Brown wrote: >> On Sun, Sep 02, 2018 at 01:03:55PM +, Sasha Levin wrote: >>> From: Akshu Agrawal >>> >>> [ Upstream commit 9fb4c2bf130b922c77c16a8368732699799c40de ] >>> >>> Take into account the base

Re: [PATCH AUTOSEL 4.18 043/131] ASoC: soc-pcm: Use delay set in component pointer function

On 9/7/2018 5:53 AM, Sasha Levin wrote: > On Mon, Sep 03, 2018 at 12:16:26PM +0100, Mark Brown wrote: >> On Sun, Sep 02, 2018 at 01:03:55PM +, Sasha Levin wrote: >>> From: Akshu Agrawal >>> >>> [ Upstream commit 9fb4c2bf130b922c77c16a8368732699799c40de ] >>> >>> Take into account the base

Re: [PATCH] clk: x86: Set default parent to 48Mhz

On 8/29/2018 3:59 AM, Stephen Boyd wrote: > Quoting Akshu Agrawal (2018-08-20 23:51:57) >> System clk provided in ST soc can be set to: >> 48Mhz, non-spread >> 25Mhz, spread >> To get accurate rate, we need it to set it at non-spread >> option which is 48Mhz. >> >> Signed-off-by: Akshu Agrawal

Re: [PATCH] clk: x86: Set default parent to 48Mhz

On 8/29/2018 3:59 AM, Stephen Boyd wrote: > Quoting Akshu Agrawal (2018-08-20 23:51:57) >> System clk provided in ST soc can be set to: >> 48Mhz, non-spread >> 25Mhz, spread >> To get accurate rate, we need it to set it at non-spread >> option which is 48Mhz. >> >> Signed-off-by: Akshu Agrawal

Re: [PATCH 1/3] ASoC: AMD: Make ACP->SYSMEM DMA non circular

On 8/2/2018 3:26 PM, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:11:54PM +0530, Akshu Agrawal wrote: >> In capture case we don't want ACP to SYSMEM dma >> to be circular. This is because if an in place DSP >> filter is applied to captured output then circular DMA >> can overwrite the filter

Re: [PATCH 1/3] ASoC: AMD: Make ACP->SYSMEM DMA non circular

On 8/2/2018 3:26 PM, Mark Brown wrote: > On Thu, Aug 02, 2018 at 12:11:54PM +0530, Akshu Agrawal wrote: >> In capture case we don't want ACP to SYSMEM dma >> to be circular. This is because if an in place DSP >> filter is applied to captured output then circular DMA >> can overwrite the filter

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/31/2018 8:10 PM, Mark Brown wrote: > On Tue, Jul 31, 2018 at 03:56:52PM +0200, Takashi Iwai wrote: >> Mark Brown wrote: > >>> Yes. I'm saying that if the CPU DAI thinks it can figure out the base >>> delay something is confused. > >> Then basically Akshu's patch does the correct thing,

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/31/2018 8:10 PM, Mark Brown wrote: > On Tue, Jul 31, 2018 at 03:56:52PM +0200, Takashi Iwai wrote: >> Mark Brown wrote: > >>> Yes. I'm saying that if the CPU DAI thinks it can figure out the base >>> delay something is confused. > >> Then basically Akshu's patch does the correct thing,

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/31/2018 11:00 AM, Takashi Iwai wrote: > On Tue, 31 Jul 2018 03:25:06 +0200, > Agrawal, Akshu wrote: >> >> >> >> On 7/30/2018 9:20 PM, Mark Brown wrote: >>> On Mon, Jul 30, 2018 at 05:32:21PM +0200, Takashi Iwai wrote: >>> >>>> Tha

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/31/2018 11:00 AM, Takashi Iwai wrote: > On Tue, 31 Jul 2018 03:25:06 +0200, > Agrawal, Akshu wrote: >> >> >> >> On 7/30/2018 9:20 PM, Mark Brown wrote: >>> On Mon, Jul 30, 2018 at 05:32:21PM +0200, Takashi Iwai wrote: >>> >>>> Tha

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/30/2018 9:20 PM, Mark Brown wrote: > On Mon, Jul 30, 2018 at 05:32:21PM +0200, Takashi Iwai wrote: > >> That said, if delay callback of CPU dai provides the additional delay, >> the patch does correct thing. OTOH, if CPU dai provides the base >> delay instead, we need to clarify that

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/30/2018 9:20 PM, Mark Brown wrote: > On Mon, Jul 30, 2018 at 05:32:21PM +0200, Takashi Iwai wrote: > >> That said, if delay callback of CPU dai provides the additional delay, >> the patch does correct thing. OTOH, if CPU dai provides the base >> delay instead, we need to clarify that

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/27/2018 8:39 PM, Pierre-Louis Bossart wrote: > On 7/27/18 5:13 AM, Akshu Agrawal wrote: >> There are cases where a pointer function populates >> runtime->delay, such as: >> ./sound/pci/hda/hda_controller.c >> ./sound/soc/intel/atom/sst-mfld-platform-pcm.c >> >> Also, in some cases cpu dai

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function

On 7/27/2018 8:39 PM, Pierre-Louis Bossart wrote: > On 7/27/18 5:13 AM, Akshu Agrawal wrote: >> There are cases where a pointer function populates >> runtime->delay, such as: >> ./sound/pci/hda/hda_controller.c >> ./sound/soc/intel/atom/sst-mfld-platform-pcm.c >> >> Also, in some cases cpu dai

Re: linux-next: build warning after merge of the sound-asoc tree

On 7/26/2018 7:49 AM, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe': > sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret'

Re: linux-next: build warning after merge of the sound-asoc tree

On 7/26/2018 7:49 AM, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_probe': > sound/soc/amd/acp-da7219-max98357a.c:367:3: warning: 'ret'

Re: [PATCH] ASoC: AMD: Add a fix voltage regulator for DA7219 and ADAU7002

On 7/24/2018 10:44 PM, Mark Brown wrote: > On Mon, Jul 23, 2018 at 10:56:44AM +0530, Agrawal, Akshu wrote: > >> This approach shows inconsistencies and in some boot cycles da7219 fails >> to get regulator. Form the logs (below) it shows time gap between t

Re: [PATCH] ASoC: AMD: Add a fix voltage regulator for DA7219 and ADAU7002

On 7/24/2018 10:44 PM, Mark Brown wrote: > On Mon, Jul 23, 2018 at 10:56:44AM +0530, Agrawal, Akshu wrote: > >> This approach shows inconsistencies and in some boot cycles da7219 fails >> to get regulator. Form the logs (below) it shows time gap between t

Re: [PATCH] ASoC: AMD: Add a fix voltage regulator for DA7219 and ADAU7002

On 7/20/2018 5:48 PM, Mark Brown wrote: > On Fri, Jul 20, 2018 at 02:38:11PM +0800, Akshu Agrawal wrote: > >> static int cz_probe(struct platform_device *pdev) >> { >> int ret; >> struct snd_soc_card *card; >> struct acp_platform_info *machine; >> +static bool

Re: [PATCH] ASoC: AMD: Add a fix voltage regulator for DA7219 and ADAU7002

On 7/20/2018 5:48 PM, Mark Brown wrote: > On Fri, Jul 20, 2018 at 02:38:11PM +0800, Akshu Agrawal wrote: > >> static int cz_probe(struct platform_device *pdev) >> { >> int ret; >> struct snd_soc_card *card; >> struct acp_platform_info *machine; >> +static bool

Re: [PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

Was this patch ever picked up? I can't find it in agd5f/linux. >>> >>> >>> It wasn't applied. I don't see 51f7415039d4 ("drm/amd/amdgpu: >>> creating two I2S instances for stoney/cz") upstream yet either. >>> Daniel, Vijendar, which ones do you want applied? Can you send me the >>>

Re: [PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

Was this patch ever picked up? I can't find it in agd5f/linux. >>> >>> >>> It wasn't applied. I don't see 51f7415039d4 ("drm/amd/amdgpu: >>> creating two I2S instances for stoney/cz") upstream yet either. >>> Daniel, Vijendar, which ones do you want applied? Can you send me the >>>

Re: [v2, 2/2] ASoC: AMD: Configure channel 1 or channel 0 for capture

On 6/20/2018 7:32 PM, Mark Brown wrote: > On Thu, Jun 07, 2018 at 02:48:44PM +0800, Akshu Agrawal wrote: > >> This patch is dependent on ASoC: AMD: Change codec to channel link as per >> hardware redesign >> https://patchwork.kernel.org/patch/10388099/ > > Can you please send a patch series

Re: [v2, 2/2] ASoC: AMD: Configure channel 1 or channel 0 for capture

On 6/20/2018 7:32 PM, Mark Brown wrote: > On Thu, Jun 07, 2018 at 02:48:44PM +0800, Akshu Agrawal wrote: > >> This patch is dependent on ASoC: AMD: Change codec to channel link as per >> hardware redesign >> https://patchwork.kernel.org/patch/10388099/ > > Can you please send a patch series

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/7/2018 12:09 PM, Daniel Kurtz wrote: > On Sun, May 6, 2018 at 10:50 PM Agrawal, Akshu <akshu.agra...@amd.com> > wrote: > > > >> On 5/4/2018 2:45 PM, Adam Thomson wrote: >>> On 03 May 2018 08:59, Akshu Agrawal wrote: >>> >>>> No

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/7/2018 12:09 PM, Daniel Kurtz wrote: > On Sun, May 6, 2018 at 10:50 PM Agrawal, Akshu > wrote: > > > >> On 5/4/2018 2:45 PM, Adam Thomson wrote: >>> On 03 May 2018 08:59, Akshu Agrawal wrote: >>> >>>> Non-dts based systems c

Re: [PATCH v5 1/2] clk: x86: Add ST oscout platform clock

On 5/15/2018 3:02 PM, Rafael J. Wysocki wrote: > On Wednesday, May 9, 2018 11:59:00 AM CEST Akshu Agrawal wrote: >> Stoney SoC provides oscout clock. This clock can support 25Mhz and >> 48Mhz of frequency. >> The clock is available for general system use. >> >> Signed-off-by: Akshu Agrawal

Re: [PATCH v5 1/2] clk: x86: Add ST oscout platform clock

On 5/15/2018 3:02 PM, Rafael J. Wysocki wrote: > On Wednesday, May 9, 2018 11:59:00 AM CEST Akshu Agrawal wrote: >> Stoney SoC provides oscout clock. This clock can support 25Mhz and >> 48Mhz of frequency. >> The clock is available for general system use. >> >> Signed-off-by: Akshu Agrawal > >

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

On 5/8/2018 9:08 PM, Deucher, Alexander wrote: >> -Original Message- >> From: Agrawal, Akshu >> Sent: Tuesday, May 8, 2018 12:04 AM >> To: Deucher, Alexander <alexander.deuc...@amd.com> >> Cc: djku...@chromium.org; mturque...@baylibre.com; sb

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

On 5/8/2018 9:08 PM, Deucher, Alexander wrote: >> -Original Message- >> From: Agrawal, Akshu >> Sent: Tuesday, May 8, 2018 12:04 AM >> To: Deucher, Alexander >> Cc: djku...@chromium.org; mturque...@baylibre.com; sb...@kernel.org; >> Koenig,

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

On 5/8/2018 3:14 AM, Deucher, Alexander wrote: >> -Original Message- >> From: Agrawal, Akshu >> Sent: Monday, May 7, 2018 6:14 AM >> Cc: djku...@chromium.org; Agrawal, Akshu <akshu.agra...@amd.com>; >> Deucher, Alexander <alexander.deuc...@a

Re: [PATCH v4 1/2] clk: x86: Add ST oscout platform clock

On 5/8/2018 3:14 AM, Deucher, Alexander wrote: >> -Original Message- >> From: Agrawal, Akshu >> Sent: Monday, May 7, 2018 6:14 AM >> Cc: djku...@chromium.org; Agrawal, Akshu ; >> Deucher, Alexander ; >> mturque...@baylibre.com; sb...@kernel.org; Koeni

Re: [PATCH v2] clk: x86: Add ST oscout platform clock

On 5/5/2018 7:56 AM, Stephen Boyd wrote: > Quoting Akshu Agrawal (2018-05-03 01:30:26) >> diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile >> index 1367afb..2aee002 100644 >> --- a/drivers/clk/x86/Makefile >> +++ b/drivers/clk/x86/Makefile >> @@ -1,3 +1,4 @@ >> clk-x86-lpss-objs

Re: [PATCH v2] clk: x86: Add ST oscout platform clock

On 5/5/2018 7:56 AM, Stephen Boyd wrote: > Quoting Akshu Agrawal (2018-05-03 01:30:26) >> diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile >> index 1367afb..2aee002 100644 >> --- a/drivers/clk/x86/Makefile >> +++ b/drivers/clk/x86/Makefile >> @@ -1,3 +1,4 @@ >> clk-x86-lpss-objs

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/4/2018 2:45 PM, Adam Thomson wrote: > On 03 May 2018 08:59, Akshu Agrawal wrote: > >> Non-dts based systems can use ACPI DSDT to pass on the mclk >> to da7219. >> This enables da7219 mclk to be linked to system clock. >> Enable/Disable of the mclk is already handled in the codec so >>

Re: [PATCH v3] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/4/2018 2:45 PM, Adam Thomson wrote: > On 03 May 2018 08:59, Akshu Agrawal wrote: > >> Non-dts based systems can use ACPI DSDT to pass on the mclk >> to da7219. >> This enables da7219 mclk to be linked to system clock. >> Enable/Disable of the mclk is already handled in the codec so >>

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 4:37 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:23 PM, Agrawal, Akshu <akshu.agra...@amd.com> wrote: >> >> >> On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: >>> On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu <akshu.agra...@amd.com&

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 4:37 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:23 PM, Agrawal, Akshu wrote: >> >> >> On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: >>> On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu >>> wrote: >>>> >

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu <akshu.agra...@amd.com> wrote: >> >> >> On 5/4/2018 3:36 PM, Rafael J. Wysocki wrote: >>> On Friday, May 4, 2018 10:34:44 AM CEST Akshu Agrawal wrote: >>&g

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 3:45 PM, Rafael J. Wysocki wrote: > On Fri, May 4, 2018 at 12:09 PM, Agrawal, Akshu wrote: >> >> >> On 5/4/2018 3:36 PM, Rafael J. Wysocki wrote: >>> On Friday, May 4, 2018 10:34:44 AM CEST Akshu Agrawal wrote: >>>> AMD SoC expose

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 3:36 PM, Rafael J. Wysocki wrote: > On Friday, May 4, 2018 10:34:44 AM CEST Akshu Agrawal wrote: >> AMD SoC exposes clock for general purpose use. The clock registration >> is done in clk-st driver. The MMIO mapping are passed on to the >> clock driver for accessing the registers. >>

Re: [PATCH v2 2/2] ACPI: APD: Add AMD misc clock handler support

On 5/4/2018 3:36 PM, Rafael J. Wysocki wrote: > On Friday, May 4, 2018 10:34:44 AM CEST Akshu Agrawal wrote: >> AMD SoC exposes clock for general purpose use. The clock registration >> is done in clk-st driver. The MMIO mapping are passed on to the >> clock driver for accessing the registers. >>

Re: [PATCH V3 10/10] ASoC: amd: dma driver changes for bt i2s instance

On 5/3/2018 10:10 PM, Daniel Kurtz wrote: On Thu, May 3, 2018 at 1:33 AM Mukunda,Vijendar wrote: On Thursday 03 May 2018 11:13 AM, Daniel Kurtz wrote: Some checkpatch nits below... On Tue, May 1, 2018 at 2:53 PM Vijendar Mukunda < vijendar.muku...@amd.com>

Re: [PATCH V3 10/10] ASoC: amd: dma driver changes for bt i2s instance

On 5/3/2018 10:10 PM, Daniel Kurtz wrote: On Thu, May 3, 2018 at 1:33 AM Mukunda,Vijendar wrote: On Thursday 03 May 2018 11:13 AM, Daniel Kurtz wrote: Some checkpatch nits below... On Tue, May 1, 2018 at 2:53 PM Vijendar Mukunda < vijendar.muku...@amd.com> wrote: With in ACP, There

Re: [PATCH] clk: x86: Add ST oscout platform clock

On 5/2/2018 3:28 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2018-04-30 00:06:53) diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile index 1367afb..f7ebae1 100644 --- a/drivers/clk/x86/Makefile +++ b/drivers/clk/x86/Makefile @@ -1,3 +1,4 @@ clk-x86-lpss-objs :=

Re: [PATCH] clk: x86: Add ST oscout platform clock

On 5/2/2018 3:28 AM, Stephen Boyd wrote: Quoting Akshu Agrawal (2018-04-30 00:06:53) diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile index 1367afb..f7ebae1 100644 --- a/drivers/clk/x86/Makefile +++ b/drivers/clk/x86/Makefile @@ -1,3 +1,4 @@ clk-x86-lpss-objs :=

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/1/2018 12:35 AM, Adam Thomson wrote: On 30 April 2018 10:23, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform drivers

Re: [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 5/1/2018 12:35 AM, Adam Thomson wrote: On 30 April 2018 10:23, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform drivers

Re: [alsa-devel] [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 4/30/2018 9:54 PM, Pierre-Louis Bossart wrote: On 4/30/18 4:23 AM, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform

Re: [alsa-devel] [PATCH v2] ASoC: da7219: read fmw property to get mclk for non-dts systems

On 4/30/2018 9:54 PM, Pierre-Louis Bossart wrote: On 4/30/18 4:23 AM, Akshu Agrawal wrote: Non-dts based systems can use ACPI DSDT to pass on the mclk to da7219. This enables da7219 mclk to be linked to system clock. Enable/Disable of the mclk is already handled in the codec so platform

Re: [PATCH] ACPI: APD: Add AMD misc clock handler support

On 4/30/2018 2:23 PM, kbuild test robot wrote: Hi Akshu, Thank you for the patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.17-rc3 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH] ACPI: APD: Add AMD misc clock handler support

On 4/30/2018 2:23 PM, kbuild test robot wrote: Hi Akshu, Thank you for the patch! Yet something to improve: [auto build test ERROR on pm/linux-next] [also build test ERROR on v4.17-rc3 next-20180426] [if your patch is applied to the wrong git tree, please drop us a note to help improve the

Re: [PATCH 2/3] ASoC: AMD: Move clk enable from hw_params/free to startup/shutdown

On 4/24/2018 10:06 PM, Daniel Kurtz wrote: On Mon, Apr 23, 2018 at 9:03 PM Vijendar Mukunda wrote: From: Akshu Agrawal hw_param can be called multiple times and thus we can have more clk enable. The clk may not get diabled due to

Re: [PATCH 2/3] ASoC: AMD: Move clk enable from hw_params/free to startup/shutdown

On 4/24/2018 10:06 PM, Daniel Kurtz wrote: On Mon, Apr 23, 2018 at 9:03 PM Vijendar Mukunda wrote: From: Akshu Agrawal hw_param can be called multiple times and thus we can have more clk enable. The clk may not get diabled due to refcounting. startup/shutdown ensures single clk

Re: [PATCH 4/4] ASoC: amd: enabling bt i2s config after acp reset

On 4/17/2018 10:29 AM, Vijendar Mukunda wrote: On ST/CZ based platforms, for specific platform bt uart mux to be defined for bt i2s. By default, these pins will be used for uart. After acp reset , it requires to reprogram bt i2s config mux pins to enable bt i2s instance. added bt i2s

Re: [PATCH 4/4] ASoC: amd: enabling bt i2s config after acp reset

On 4/17/2018 10:29 AM, Vijendar Mukunda wrote: On ST/CZ based platforms, for specific platform bt uart mux to be defined for bt i2s. By default, these pins will be used for uart. After acp reset , it requires to reprogram bt i2s config mux pins to enable bt i2s instance. added bt i2s

Re: [PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

On 4/13/2018 9:45 PM, Daniel Kurtz wrote: Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for stoney/cz") added support for the "BT_I2S" ACP i2s channel. As part of this change, one additional acp resource was added, but the "num_resource" count was accidentally incremented

Re: [PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

On 4/13/2018 9:45 PM, Daniel Kurtz wrote: Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for stoney/cz") added support for the "BT_I2S" ACP i2s channel. As part of this change, one additional acp resource was added, but the "num_resource" count was accidentally incremented

Re: linux-next: build failure after merge of the sound-asoc tree

On 2/19/2018 5:02 AM, Stephen Rothwell wrote: Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) failed like this: sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_da7219_init': sound/soc/amd/acp-da7219-max98357a.c:79:22: error: passing argument 1

Re: linux-next: build failure after merge of the sound-asoc tree

On 2/19/2018 5:02 AM, Stephen Rothwell wrote: Hi all, After merging the sound-asoc tree, today's linux-next build (x86_64 allmodconfig) failed like this: sound/soc/amd/acp-da7219-max98357a.c: In function 'cz_da7219_init': sound/soc/amd/acp-da7219-max98357a.c:79:22: error: passing argument 1

Re: [PATCH] ASoC: amd: Add error checking to probe function

On 11/21/2017 10:17 AM, Deucher, Alexander wrote: -Original Message- From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck Sent: Monday, November 20, 2017 11:28 PM To: Liam Girdwood Cc: Mark Brown; Jaroslav Kysela; Takashi Iwai; alsa-de...@alsa-project.org;

  1   2   >