This patch set is to add support for playback recover after hard suspend and resume.
It includes:
1. Reverting part of previous commit, which is for handling registers invalid state
after hard suspend.
2. Adding pm ops in component driver and do regcache sync.
Srinivasa Rao Mandadapu (2):
Partially revert ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF
invalid state
ASoC: qcom: Add support for playback recover after resume
sound/soc/qcom/lpass-cpu.c | 20 ++----------------
sound/soc/qcom/lpass-platform.c | 46 +++++++++++++++++++++++++++++++----------
2 files changed, 37 insertions(+), 29 deletions(-)
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
This reverts part of commit b1824968221c
("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state")
To identify LPAIF invalid state after device suspend and resume,
made I2S and DMA control registers not volatile, which is not necessary.
Instead invalid reg state can be handled with regcache APIs.
The BCLK ref count is necessary to enable clock only it's in disable state.
Signed-off-by: V Sujith Kumar Reddy <[email protected]>
Signed-off-by: Srinivasa Rao Mandadapu <[email protected]>
---
sound/soc/qcom/lpass-cpu.c | 20 ++------------------
sound/soc/qcom/lpass-platform.c | 11 -----------
2 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index af684fd..c5e99c2 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -270,18 +270,6 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream,
struct lpaif_i2sctl *i2sctl = drvdata->i2sctl;
unsigned int id = dai->driver->id;
int ret = -EINVAL;
- unsigned int val = 0;
-
- ret = regmap_read(drvdata->lpaif_map,
- LPAIF_I2SCTL_REG(drvdata->variant, dai->driver->id), &val);
- if (ret) {
- dev_err(dai->dev, "error reading from i2sctl reg: %d\n", ret);
- return ret;
- }
- if (val == LPAIF_I2SCTL_RESET_STATE) {
- dev_err(dai->dev, "error in i2sctl register state\n");
- return -ENOTRECOVERABLE;
- }
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -454,20 +442,16 @@ static bool lpass_cpu_regmap_volatile(struct device *dev, unsigned int reg)
struct lpass_variant *v = drvdata->variant;
int i;
- for (i = 0; i < v->i2s_ports; ++i)
- if (reg == LPAIF_I2SCTL_REG(v, i))
- return true;
for (i = 0; i < v->irq_ports; ++i)
if (reg == LPAIF_IRQSTAT_REG(v, i))
return true;
for (i = 0; i < v->rdma_channels; ++i)
- if (reg == LPAIF_RDMACURR_REG(v, i) || reg == LPAIF_RDMACTL_REG(v, i))
+ if (reg == LPAIF_RDMACURR_REG(v, i))
return true;
for (i = 0; i < v->wrdma_channels; ++i)
- if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start) ||
- reg == LPAIF_WRDMACTL_REG(v, i + v->wrdma_channel_start))
+ if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start))
return true;
return false;
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 80b09de..0e71899 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -452,7 +452,6 @@ static int lpass_platform_pcmops_trigger(struct snd_soc_component *component,
unsigned int reg_irqclr = 0, val_irqclr = 0;
unsigned int reg_irqen = 0, val_irqen = 0, val_mask = 0;
unsigned int dai_id = cpu_dai->driver->id;
- unsigned int dma_ctrl_reg = 0;
ch = pcm_data->dma_ch;
if (dir == SNDRV_PCM_STREAM_PLAYBACK) {
@@ -469,17 +468,7 @@ static int lpass_platform_pcmops_trigger(struct snd_soc_component *component,
id = pcm_data->dma_ch - v->wrdma_channel_start;
map = drvdata->lpaif_map;
}
- ret = regmap_read(map, LPAIF_DMACTL_REG(v, ch, dir, dai_id), &dma_ctrl_reg);
- if (ret) {
- dev_err(soc_runtime->dev, "error reading from rdmactl reg: %d\n", ret);
- return ret;
- }
- if (dma_ctrl_reg == LPAIF_DMACTL_RESET_STATE ||
- dma_ctrl_reg == LPAIF_DMACTL_RESET_STATE + 1) {
- dev_err(soc_runtime->dev, "error in rdmactl register state\n");
- return -ENOTRECOVERABLE;
- }
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
On 28/11/2020 04:59, Srinivasa Rao Mandadapu wrote:
> This reverts part of commit b1824968221c
> ("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state")
This should probably go to Fixes tag!
>
> To identify LPAIF invalid state after device suspend and resume,
> made I2S and DMA control registers not volatile, which is not necessary.
This comment is bit confusing!
Basically it should be something like
"DMA control registers are not volatile, so remove these from volatile
registers list"
--srini
> Instead invalid reg state can be handled with regcache APIs.
> The BCLK ref count is necessary to enable clock only it's in disable state.
>
> Signed-off-by: V Sujith Kumar Reddy <[email protected]>
> Signed-off-by: Srinivasa Rao Mandadapu <[email protected]>
> ---
> sound/soc/qcom/lpass-cpu.c | 20 ++------------------
> sound/soc/qcom/lpass-platform.c | 11 -----------
> 2 files changed, 2 insertions(+), 29 deletions(-)
>
> diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
> index af684fd..c5e99c2 100644
> --- a/sound/soc/qcom/lpass-cpu.c
> +++ b/sound/soc/qcom/lpass-cpu.c
> @@ -270,18 +270,6 @@ static int lpass_cpu_daiops_trigger(struct snd_pcm_substream *substream,
> struct lpaif_i2sctl *i2sctl = drvdata->i2sctl;
> unsigned int id = dai->driver->id;
> int ret = -EINVAL;
> - unsigned int val = 0;
> -
> - ret = regmap_read(drvdata->lpaif_map,
> - LPAIF_I2SCTL_REG(drvdata->variant, dai->driver->id), &val);
> - if (ret) {
> - dev_err(dai->dev, "error reading from i2sctl reg: %d\n", ret);
> - return ret;
> - }
> - if (val == LPAIF_I2SCTL_RESET_STATE) {
> - dev_err(dai->dev, "error in i2sctl register state\n");
> - return -ENOTRECOVERABLE;
> - }
>
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> @@ -454,20 +442,16 @@ static bool lpass_cpu_regmap_volatile(struct device *dev, unsigned int reg)
> struct lpass_variant *v = drvdata->variant;
> int i;
>
> - for (i = 0; i < v->i2s_ports; ++i)
> - if (reg == LPAIF_I2SCTL_REG(v, i))
> - return true;
> for (i = 0; i < v->irq_ports; ++i)
> if (reg == LPAIF_IRQSTAT_REG(v, i))
> return true;
>
> for (i = 0; i < v->rdma_channels; ++i)
> - if (reg == LPAIF_RDMACURR_REG(v, i) || reg == LPAIF_RDMACTL_REG(v, i))
> + if (reg == LPAIF_RDMACURR_REG(v, i))
> return true;
>
> for (i = 0; i < v->wrdma_channels; ++i)
> - if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start) ||
> - reg == LPAIF_WRDMACTL_REG(v, i + v->wrdma_channel_start))
> + if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start))
> return true;
>
> return false;
> diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
> index 80b09de..0e71899 100644
> --- a/sound/soc/qcom/lpass-platform.c
> +++ b/sound/soc/qcom/lpass-platform.c
> @@ -452,7 +452,6 @@ static int lpass_platform_pcmops_trigger(struct snd_soc_component *component,
> unsigned int reg_irqclr = 0, val_irqclr = 0;
> unsigned int reg_irqen = 0, val_irqen = 0, val_mask = 0;
> unsigned int dai_id = cpu_dai->driver->id;
> - unsigned int dma_ctrl_reg = 0;
>
> ch = pcm_data->dma_ch;
> if (dir == SNDRV_PCM_STREAM_PLAYBACK) {
> @@ -469,17 +468,7 @@ static int lpass_platform_pcmops_trigger(struct snd_soc_component *component,
> id = pcm_data->dma_ch - v->wrdma_channel_start;
> map = drvdata->lpaif_map;
> }
> - ret = regmap_read(map, LPAIF_DMACTL_REG(v, ch, dir, dai_id), &dma_ctrl_reg);
> - if (ret) {
> - dev_err(soc_runtime->dev, "error reading from rdmactl reg: %d\n", ret);
> - return ret;
> - }
>
> - if (dma_ctrl_reg == LPAIF_DMACTL_RESET_STATE ||
> - dma_ctrl_reg == LPAIF_DMACTL_RESET_STATE + 1) {
> - dev_err(soc_runtime->dev, "error in rdmactl register state\n");
> - return -ENOTRECOVERABLE;
> - }
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> case SNDRV_PCM_TRIGGER_RESUME:
>
On Sat, Nov 28, 2020 at 10:29:18AM +0530, Srinivasa Rao Mandadapu wrote:
> This reverts part of commit b1824968221c
> ("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state")
>
> To identify LPAIF invalid state after device suspend and resume,
> made I2S and DMA control registers not volatile, which is not necessary.
> Instead invalid reg state can be handled with regcache APIs.
> The BCLK ref count is necessary to enable clock only it's in disable state.
Part of this commit message says that the problem was making the registers
non-volatile but both the change and the rest of the commit message say
that the issue was that the registers were made volatile. I'm also
still unclear as to what the issue is either way - how does reading the
state of the registers from the hardware instead of the cache affect
things?
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
Thanks Mark for your time!!!
On 11/30/2020 6:16 PM, Mark Brown wrote:
> On Sat, Nov 28, 2020 at 10:29:18AM +0530, Srinivasa Rao Mandadapu wrote:
>> This reverts part of commit b1824968221c
>> ("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state")
>>
>> To identify LPAIF invalid state after device suspend and resume,
>> made I2S and DMA control registers not volatile, which is not necessary.
>> Instead invalid reg state can be handled with regcache APIs.
>> The BCLK ref count is necessary to enable clock only it's in disable state.
> Part of this commit message says that the problem was making the registers
> non-volatile but both the change and the rest of the commit message say
> that the issue was that the registers were made volatile. I'm also
> still unclear as to what the issue is either way - how does reading the
> state of the registers from the hardware instead of the cache affect
> things?
Initial problem was, during playback if device suspended, I2S and DMA
control registers
are getting reset and unable to recover playback after resume.
As these registers were non volatile registers, driver is not getting
actual register value
and unable to report error state to application. Due to this application
keeps on polling for HW current pointer state and not exited from PCM
running state.
To handle this scenario I made registers volatile and if they are in
reset state, reported error
to application(commit b1824968221c).
Later from review comments by Srinivas kandagatla, I got to know
about regcache sync APIs, which can be used? to sync cache after resume and
HW registers can be updated with? original values. With that playback
can be continued.
So is the reason, I am reverting partial changes in the commit b1824968221c.
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
On Tue, Dec 01, 2020 at 11:01:21PM +0530, Srinivasa Rao Mandadapu wrote:
> On 11/30/2020 6:16 PM, Mark Brown wrote:
> > Part of this commit message says that the problem was making the registers
> > non-volatile but both the change and the rest of the commit message say
> > that the issue was that the registers were made volatile. I'm also
> > still unclear as to what the issue is either way - how does reading the
> > state of the registers from the hardware instead of the cache affect
> > things?
> Initial problem was, during playback if device suspended, I2S and DMA
> control registers
> are getting reset and unable to recover playback after resume.
> As these registers were non volatile registers, driver is not getting actual
> register value
> and unable to report error state to application. Due to this application
> keeps on polling for HW current pointer state and not exited from PCM
> running state.
> Later from review comments by Srinivas kandagatla, I got to know
>
> about regcache sync APIs, which can be used? to sync cache after resume and
>
> HW registers can be updated with? original values. With that playback can be
> continued.
>
> So is the reason, I am reverting partial changes in the commit b1824968221c.
I don't understand why a fix for the register cache not being in sync
with the hardware doesn't involve syncing the register cache with the
hardware.
Thanks Mark for Your time!!!
On 12/1/2020 11:21 PM, Mark Brown wrote:
> On Tue, Dec 01, 2020 at 11:01:21PM +0530, Srinivasa Rao Mandadapu wrote:
>> On 11/30/2020 6:16 PM, Mark Brown wrote:
>>> Part of this commit message says that the problem was making the registers
>>> non-volatile but both the change and the rest of the commit message say
>>> that the issue was that the registers were made volatile. I'm also
>>> still unclear as to what the issue is either way - how does reading the
>>> state of the registers from the hardware instead of the cache affect
>>> things?
>> Initial problem was, during playback if device suspended, I2S and DMA
>> control registers
>> are getting reset and unable to recover playback after resume.
>> As these registers were non volatile registers, driver is not getting actual
>> register value
>> and unable to report error state to application. Due to this application
>> keeps on polling for HW current pointer state and not exited from PCM
>> running state.
>> Later from review comments by Srinivas kandagatla, I got to know
>>
>> about regcache sync APIs, which can be used? to sync cache after resume and
>>
>> HW registers can be updated with? original values. With that playback can be
>> continued.
>>
>> So is the reason, I am reverting partial changes in the commit b1824968221c.
> I don't understand why a fix for the register cache not being in sync
> with the hardware doesn't involve syncing the register cache with the
> hardware.
I am sorry I couldn't understand your point. Could you please elaborate
your query?
Actually I posted V5 version based on review comments.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Thanks Mark for your Time!!!
On 12/14/2020 11:20 PM, Mark Brown wrote:
> On Mon, Dec 14, 2020 at 06:13:22PM +0530, Srinivasa Rao Mandadapu wrote:
>> On 12/1/2020 11:21 PM, Mark Brown wrote:
>>>> Later from review comments by Srinivas kandagatla, I got to know
>>>>
>>>> about regcache sync APIs, which can be used? to sync cache after resume and
>>>>
>>>> HW registers can be updated with? original values. With that playback can be
>>>> continued.
>>>> So is the reason, I am reverting partial changes in the commit b1824968221c.
>>> I don't understand why a fix for the register cache not being in sync
>>> with the hardware doesn't involve syncing the register cache with the
>>> hardware.
>> I am sorry I couldn't understand your point. Could you please elaborate your
>> query?
> Your changelog talks about syncing the cache but neither the driver nor
> your change actually does that.
Yeah.. Now I posted v6 patch
(https://lore.kernel.org/patchwork/patch/1354638/)
with subject lines explaining actual changes.
could you please check? the same.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Thanks Mark for your Time!!!
On 12/14/2020 11:20 PM, Mark Brown wrote:
> On Mon, Dec 14, 2020 at 06:13:22PM +0530, Srinivasa Rao Mandadapu wrote:
>> On 12/1/2020 11:21 PM, Mark Brown wrote:
>>>> Later from review comments by Srinivas kandagatla, I got to know
>>>>
>>>> about regcache sync APIs, which can be used? to sync cache after resume and
>>>>
>>>> HW registers can be updated with? original values. With that playback can be
>>>> continued.
>>>> So is the reason, I am reverting partial changes in the commit b1824968221c.
>>> I don't understand why a fix for the register cache not being in sync
>>> with the hardware doesn't involve syncing the register cache with the
>>> hardware.
>> I am sorry I couldn't understand your point. Could you please elaborate your
>> query?
> Your changelog talks about syncing the cache but neither the driver nor
> your change actually does that.
Okay. Now I posted v6 patch
(https://lore.kernel.org/patchwork/patch/1354638/)
with subject lines explaining actual changes.
could you please check? the same.
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.