devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Sameer Pujar <spujar@nvidia.com>
Cc: tiwai@suse.com, broonie@kernel.org, lgirdwood@gmail.com,
	robh+dt@kernel.org, perex@perex.cz, jonathanh@nvidia.com,
	digetx@gmail.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 1/3] ALSA: hda/tegra: Skip reset on BPMP devices
Date: Tue, 7 Dec 2021 09:16:43 +0100	[thread overview]
Message-ID: <Ya8Ya2en5Tm5Ol2u@orome.fritz.box> (raw)
In-Reply-To: <1638858770-22594-2-git-send-email-spujar@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

On Tue, Dec 07, 2021 at 12:02:48PM +0530, Sameer Pujar wrote:
> 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.
> 
> The failure can be fixed by avoiding above reset in the driver,
> but the explicit reset is not necessary for Tegra devices which
> depend on BPMP. On such devices, BPMP ensures reset application
> during unpowergate calls. Hence skip reset on these devices
> which is applicable for Tegra186 and later.
> 
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> Cc: stable@vger.kernel.org
> Depends-on: 87f0e46e7559 ("ALSA: hda/tegra: Reset hardware")
> ---
>  sound/pci/hda/hda_tegra.c | 24 +++++++++++++++++++-----
>  1 file changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> index ea700395..862141e 100644
> --- a/sound/pci/hda/hda_tegra.c
> +++ b/sound/pci/hda/hda_tegra.c
> @@ -68,6 +68,10 @@
>   */
>  #define TEGRA194_NUM_SDO_LINES	  4
>  
> +struct hda_data {
> +	unsigned int do_reset:1;
> +};

I suppose this could also be a bool. Not sure if we need to care about
packing optimizations at this point.

It may also be useful to rename this to something less generic to avoid
potential clashes with other data structures in the future. We've often
used the _soc suffix in other drivers to mark this kind of SoC-specific
data. In this case it would be struct hda_tegra_soc.

If Takashi is fine with this as-is, I don't have any strong objections,
though.

> +
>  struct hda_tegra {
>  	struct azx chip;
>  	struct device *dev;
> @@ -76,6 +80,7 @@ struct hda_tegra {
>  	unsigned int nclocks;
>  	void __iomem *regs;
>  	struct work_struct probe_work;
> +	const struct hda_data *data;
>  };
>  
>  #ifdef CONFIG_PM
> @@ -427,8 +432,13 @@ static int hda_tegra_create(struct snd_card *card,
>  	return 0;
>  }
>  
> +static const struct hda_data tegra30_data = {
> +	.do_reset = 1,
> +};
> +
>  static const struct of_device_id hda_tegra_match[] = {
> -	{ .compatible = "nvidia,tegra30-hda" },
> +	{ .compatible = "nvidia,tegra30-hda", .data = &tegra30_data },
> +	{ .compatible = "nvidia,tegra186-hda" },
>  	{ .compatible = "nvidia,tegra194-hda" },
>  	{},
>  };

One other thing we've done in the past is to explicitly pass these
structures for each compatible string. That simplifies things a bit
because we don't have to keep checking for non-NULL pointers and instead
rely on the fact that there's always a valid pointer.

To do so, you'd basically add:

	static const struct hda_data tegra186_data = {
		.do_reset = 0,
	};

And reference that for both the Tegra186 and Tegra194 entries. Again,
not strictly necessary and since we have only one occurrence where we
need to check this, it seems fine as-is, so:

Acked-by: Thierry Reding <treding@nvidia.com>

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

  reply	other threads:[~2021-12-07  8:16 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-07  6:32 [PATCH 0/3] Fix Tegra194 HDA regression Sameer Pujar
2021-12-07  6:32 ` [PATCH 1/3] ALSA: hda/tegra: Skip reset on BPMP devices Sameer Pujar
2021-12-07  8:16   ` Thierry Reding [this message]
2021-12-07  8:36     ` Takashi Iwai
2021-12-07  9:09       ` Sameer Pujar
2021-12-07 10:22   ` Dmitry Osipenko
2021-12-07 10:44     ` Dmitry Osipenko
2021-12-07 10:58       ` Dmitry Osipenko
2021-12-07 11:02         ` Jon Hunter
2021-12-07 11:57           ` Dmitry Osipenko
2021-12-07 15:07             ` Jon Hunter
2021-12-07 12:00     ` Sameer Pujar
2021-12-07 12:05       ` Dmitry Osipenko
2021-12-07 12:40         ` Sameer Pujar
2021-12-07 14:07           ` Dmitry Osipenko
2021-12-07 14:49             ` Sameer Pujar
2021-12-07 15:35               ` Dmitry Osipenko
2021-12-07 17:37                 ` Sameer Pujar
2021-12-07 18:02                   ` Dmitry Osipenko
2021-12-08  5:22                     ` Sameer Pujar
2021-12-08 12:05                       ` Dmitry Osipenko
2021-12-14  6:02                         ` Sameer Pujar
2021-12-14  6:09                           ` Dmitry Osipenko
2021-12-14  6:15                             ` Dmitry Osipenko
2021-12-14  7:22                             ` Sameer Pujar
2021-12-14 13:56                               ` Dmitry Osipenko
2021-12-14 14:29                                 ` Takashi Iwai
2021-12-14 15:34                                   ` Dmitry Osipenko
2021-12-20 10:32                                 ` Sameer Pujar
2021-12-07  6:32 ` [PATCH 2/3] dt-bindings: sound: tegra: Update HDA resets Sameer Pujar
2021-12-07  8:18   ` Thierry Reding
2021-12-07  9:27     ` Sameer Pujar
2021-12-07 10:14   ` Dmitry Osipenko
2021-12-07 11:04     ` Sameer Pujar
2021-12-07 12:02       ` Dmitry Osipenko
2021-12-07 12:22         ` Sameer Pujar
2021-12-07  6:32 ` [PATCH 3/3] arm64: tegra: Remove non existent Tegra194 reset Sameer Pujar
2021-12-07  8:04 ` [PATCH 0/3] Fix Tegra194 HDA regression Takashi Iwai
2021-12-07  8:21   ` Thierry Reding

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=Ya8Ya2en5Tm5Ol2u@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=robh+dt@kernel.org \
    --cc=spujar@nvidia.com \
    --cc=stable@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).