All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Sameer Pujar <spujar@nvidia.com>,
	tiwai@suse.com, broonie@kernel.org, lgirdwood@gmail.com,
	robh+dt@kernel.org, thierry.reding@gmail.com, perex@perex.cz
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	jonathanh@nvidia.com, linux-tegra@vger.kernel.org,
	mkumard@nvidia.com
Subject: Re: [PATCH v3 1/3] ALSA: hda/tegra: Fix Tegra194 HDA reset failure
Date: Wed, 22 Dec 2021 21:40:10 +0300	[thread overview]
Message-ID: <fb8cf33f-41fb-79c0-3134-524c290e4fc1@gmail.com> (raw)
In-Reply-To: <1640147751-4777-2-git-send-email-spujar@nvidia.com>

22.12.2021 07:35, Sameer Pujar пишет:
> HDA regression is recently reported on Tegra194 based platforms.
> This happens because "hda2codec_2x" reset does not really exist
> in Tegra194 and it causes probe failure. All the HDA based audio
> tests fail at the moment. This underlying issue is exposed by
> commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
> response") which now checks return code of BPMP command response.
> Fix this issue by skipping unavailable reset on Tegra194.
> 
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Cc: stable@vger.kernel.org
> Depends-on: 87f0e46e7559 ("ALSA: hda/tegra: Reset hardware")

Is "Depends-on" a valid tag? I can't find it in Documentation/.

> ---
>  sound/pci/hda/hda_tegra.c | 45 ++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 36 insertions(+), 9 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> index ea700395..7c3df54 100644
> --- a/sound/pci/hda/hda_tegra.c
> +++ b/sound/pci/hda/hda_tegra.c
> @@ -68,14 +68,20 @@
>   */
>  #define TEGRA194_NUM_SDO_LINES	  4
>  
> +struct hda_tegra_soc {
> +	bool has_hda2codec_2x_reset;
> +};
> +
>  struct hda_tegra {
>  	struct azx chip;
>  	struct device *dev;
> -	struct reset_control *reset;
> +	struct reset_control_bulk_data resets[3];
>  	struct clk_bulk_data clocks[3];
> +	unsigned int nresets;
>  	unsigned int nclocks;
>  	void __iomem *regs;
>  	struct work_struct probe_work;
> +	const struct hda_tegra_soc *data;
>  };
>  
>  #ifdef CONFIG_PM
> @@ -170,7 +176,7 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>  	int rc;
>  
>  	if (!chip->running) {
> -		rc = reset_control_assert(hda->reset);
> +		rc = reset_control_bulk_assert(hda->nresets, hda->resets);
>  		if (rc)
>  			return rc;
>  	}
> @@ -187,7 +193,7 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>  	} else {
>  		usleep_range(10, 100);
>  
> -		rc = reset_control_deassert(hda->reset);
> +		rc = reset_control_bulk_deassert(hda->nresets, hda->resets);
>  		if (rc)
>  			return rc;
>  	}
> @@ -427,9 +433,17 @@ static int hda_tegra_create(struct snd_card *card,
>  	return 0;
>  }
>  
> +static const struct hda_tegra_soc tegra30_data = {
> +	.has_hda2codec_2x_reset = true,
> +};
> +
> +static const struct hda_tegra_soc tegra194_data = {
> +	.has_hda2codec_2x_reset = false,
> +};
> +
>  static const struct of_device_id hda_tegra_match[] = {
> -	{ .compatible = "nvidia,tegra30-hda" },
> -	{ .compatible = "nvidia,tegra194-hda" },
> +	{ .compatible = "nvidia,tegra30-hda", .data = &tegra30_data },
> +	{ .compatible = "nvidia,tegra194-hda", .data = &tegra194_data },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, hda_tegra_match);
> @@ -449,6 +463,10 @@ static int hda_tegra_probe(struct platform_device *pdev)
>  	hda->dev = &pdev->dev;
>  	chip = &hda->chip;
>  
> +	hda->data = of_device_get_match_data(&pdev->dev);
> +	if (!hda->data)
> +		return -EINVAL;

hda->data can't ever be NULL because all hda_tegra_match[] compatibles
above have .data assigned. Technically this check is redundant.

Thierry suggested previously to name it "hda->soc", like we usually do
it in other drivers.

>  	err = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,
>  			   THIS_MODULE, 0, &card);
>  	if (err < 0) {
> @@ -456,11 +474,20 @@ static int hda_tegra_probe(struct platform_device *pdev)
>  		return err;
>  	}
>  
> -	hda->reset = devm_reset_control_array_get_exclusive(&pdev->dev);
> -	if (IS_ERR(hda->reset)) {
> -		err = PTR_ERR(hda->reset);
> +	hda->resets[hda->nresets++].id = "hda";
> +	hda->resets[hda->nresets++].id = "hda2hdmi";
> +	/*
> +	 * "hda2codec_2x" reset is not present on Tegra194. Though DT would
> +	 * be updated to reflect this, but to have backward compatibility
> +	 * below is necessary.
> +	 */
> +	if (hda->data->has_hda2codec_2x_reset)
> +		hda->resets[hda->nresets++].id = "hda2codec_2x";
> +
> +	err = devm_reset_control_bulk_get_exclusive(&pdev->dev, hda->nresets,
> +						    hda->resets);
> +	if (err)
>  		goto out_free;
> -	}
>  
>  	hda->clocks[hda->nclocks++].id = "hda";
>  	hda->clocks[hda->nclocks++].id = "hda2hdmi";
> 

Not sure whether the above nits worth making v4. I'll leave it up to you
and other reviewers to decide.

Overall this patch looks good to me, thank you.

Reviewed-by: Dmitry Osipenko <digetx@gmail.com>

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Sameer Pujar <spujar@nvidia.com>,
	tiwai@suse.com, broonie@kernel.org, lgirdwood@gmail.com,
	robh+dt@kernel.org, thierry.reding@gmail.com, perex@perex.cz
Cc: jonathanh@nvidia.com, mkumard@nvidia.com,
	alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v3 1/3] ALSA: hda/tegra: Fix Tegra194 HDA reset failure
Date: Wed, 22 Dec 2021 21:40:10 +0300	[thread overview]
Message-ID: <fb8cf33f-41fb-79c0-3134-524c290e4fc1@gmail.com> (raw)
In-Reply-To: <1640147751-4777-2-git-send-email-spujar@nvidia.com>

22.12.2021 07:35, Sameer Pujar пишет:
> HDA regression is recently reported on Tegra194 based platforms.
> This happens because "hda2codec_2x" reset does not really exist
> in Tegra194 and it causes probe failure. All the HDA based audio
> tests fail at the moment. This underlying issue is exposed by
> commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
> response") which now checks return code of BPMP command response.
> Fix this issue by skipping unavailable reset on Tegra194.
> 
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Cc: stable@vger.kernel.org
> Depends-on: 87f0e46e7559 ("ALSA: hda/tegra: Reset hardware")

Is "Depends-on" a valid tag? I can't find it in Documentation/.

> ---
>  sound/pci/hda/hda_tegra.c | 45 ++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 36 insertions(+), 9 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> index ea700395..7c3df54 100644
> --- a/sound/pci/hda/hda_tegra.c
> +++ b/sound/pci/hda/hda_tegra.c
> @@ -68,14 +68,20 @@
>   */
>  #define TEGRA194_NUM_SDO_LINES	  4
>  
> +struct hda_tegra_soc {
> +	bool has_hda2codec_2x_reset;
> +};
> +
>  struct hda_tegra {
>  	struct azx chip;
>  	struct device *dev;
> -	struct reset_control *reset;
> +	struct reset_control_bulk_data resets[3];
>  	struct clk_bulk_data clocks[3];
> +	unsigned int nresets;
>  	unsigned int nclocks;
>  	void __iomem *regs;
>  	struct work_struct probe_work;
> +	const struct hda_tegra_soc *data;
>  };
>  
>  #ifdef CONFIG_PM
> @@ -170,7 +176,7 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>  	int rc;
>  
>  	if (!chip->running) {
> -		rc = reset_control_assert(hda->reset);
> +		rc = reset_control_bulk_assert(hda->nresets, hda->resets);
>  		if (rc)
>  			return rc;
>  	}
> @@ -187,7 +193,7 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>  	} else {
>  		usleep_range(10, 100);
>  
> -		rc = reset_control_deassert(hda->reset);
> +		rc = reset_control_bulk_deassert(hda->nresets, hda->resets);
>  		if (rc)
>  			return rc;
>  	}
> @@ -427,9 +433,17 @@ static int hda_tegra_create(struct snd_card *card,
>  	return 0;
>  }
>  
> +static const struct hda_tegra_soc tegra30_data = {
> +	.has_hda2codec_2x_reset = true,
> +};
> +
> +static const struct hda_tegra_soc tegra194_data = {
> +	.has_hda2codec_2x_reset = false,
> +};
> +
>  static const struct of_device_id hda_tegra_match[] = {
> -	{ .compatible = "nvidia,tegra30-hda" },
> -	{ .compatible = "nvidia,tegra194-hda" },
> +	{ .compatible = "nvidia,tegra30-hda", .data = &tegra30_data },
> +	{ .compatible = "nvidia,tegra194-hda", .data = &tegra194_data },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, hda_tegra_match);
> @@ -449,6 +463,10 @@ static int hda_tegra_probe(struct platform_device *pdev)
>  	hda->dev = &pdev->dev;
>  	chip = &hda->chip;
>  
> +	hda->data = of_device_get_match_data(&pdev->dev);
> +	if (!hda->data)
> +		return -EINVAL;

hda->data can't ever be NULL because all hda_tegra_match[] compatibles
above have .data assigned. Technically this check is redundant.

Thierry suggested previously to name it "hda->soc", like we usually do
it in other drivers.

>  	err = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,
>  			   THIS_MODULE, 0, &card);
>  	if (err < 0) {
> @@ -456,11 +474,20 @@ static int hda_tegra_probe(struct platform_device *pdev)
>  		return err;
>  	}
>  
> -	hda->reset = devm_reset_control_array_get_exclusive(&pdev->dev);
> -	if (IS_ERR(hda->reset)) {
> -		err = PTR_ERR(hda->reset);
> +	hda->resets[hda->nresets++].id = "hda";
> +	hda->resets[hda->nresets++].id = "hda2hdmi";
> +	/*
> +	 * "hda2codec_2x" reset is not present on Tegra194. Though DT would
> +	 * be updated to reflect this, but to have backward compatibility
> +	 * below is necessary.
> +	 */
> +	if (hda->data->has_hda2codec_2x_reset)
> +		hda->resets[hda->nresets++].id = "hda2codec_2x";
> +
> +	err = devm_reset_control_bulk_get_exclusive(&pdev->dev, hda->nresets,
> +						    hda->resets);
> +	if (err)
>  		goto out_free;
> -	}
>  
>  	hda->clocks[hda->nclocks++].id = "hda";
>  	hda->clocks[hda->nclocks++].id = "hda2hdmi";
> 

Not sure whether the above nits worth making v4. I'll leave it up to you
and other reviewers to decide.

Overall this patch looks good to me, thank you.

Reviewed-by: Dmitry Osipenko <digetx@gmail.com>

  reply	other threads:[~2021-12-22 18:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22  4:35 [PATCH v3 0/3] Fix Tegra194 HDA regression Sameer Pujar
2021-12-22  4:35 ` Sameer Pujar
2021-12-22  4:35 ` [PATCH v3 1/3] ALSA: hda/tegra: Fix Tegra194 HDA reset failure Sameer Pujar
2021-12-22  4:35   ` Sameer Pujar
2021-12-22 18:40   ` Dmitry Osipenko [this message]
2021-12-22 18:40     ` Dmitry Osipenko
2021-12-23  4:34     ` Sameer Pujar
2021-12-23  4:34       ` Sameer Pujar
2021-12-23  7:16       ` Greg KH
2021-12-23  7:16         ` Greg KH
2021-12-23 11:24         ` Sameer Pujar
2021-12-23 11:24           ` Sameer Pujar
2021-12-22  4:35 ` [PATCH v3 2/3] dt-bindings: sound: tegra: Update HDA resets Sameer Pujar
2021-12-22  4:35   ` Sameer Pujar
2021-12-22 19:37   ` Rob Herring
2021-12-22 19:37     ` Rob Herring
2021-12-22  4:35 ` [PATCH v3 3/3] arm64: tegra: Remove non existent Tegra194 reset Sameer Pujar
2021-12-22  4:35   ` Sameer Pujar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fb8cf33f-41fb-79c0-3134-524c290e4fc1@gmail.com \
    --to=digetx@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mkumard@nvidia.com \
    --cc=perex@perex.cz \
    --cc=robh+dt@kernel.org \
    --cc=spujar@nvidia.com \
    --cc=stable@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.