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 v
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 w
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
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'
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 u
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 regulators_re
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 it's
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
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, I
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
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
--- a/in
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 inser
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 won
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
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
>>> patches?
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
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
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
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 +++
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
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
>>
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 en
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 en
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 s
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 driver
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 d
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 :=
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
>
>
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 can use ACPI
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 enable/di
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 clock.
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: Aksh
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
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 l
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 of
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 and
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 +++
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 i
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 d
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 is
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 a
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.
>>
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
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:
>>>>
>>>&
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 by
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 enablement
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,
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
>> platf
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
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
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
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:
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, t
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
--- a/dr
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.
Signed-off-
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)
Sign
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 fch_clk_remove
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
--- a/dr
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,
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 o
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;
linux-ker
61 matches
Mail list logo
