From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
Sameer Pujar <spujar@nvidia.com>,
Peter Geis <pgwipeout@gmail.com>,
Nicolas Chauvet <kwizart@gmail.com>,
Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
alsa-devel@alsa-project.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/5] ALSA: hda/tegra: Reset hardware
Date: Mon, 18 Jan 2021 02:39:37 +0300 [thread overview]
Message-ID: <e26bac65-7cde-439f-a353-3b960691096f@gmail.com> (raw)
In-Reply-To: <YAG2K4CjtCdSs6P2@ulmo>
15.01.2021 18:35, Thierry Reding пишет:
> On Tue, Jan 12, 2021 at 03:58:31PM +0300, Dmitry Osipenko wrote:
>> Reset hardware in order to bring it into a predictable state.
>>
>> Tested-by: Peter Geis <pgwipeout@gmail.com>
>> Tested-by: Nicolas Chauvet <kwizart@gmail.com>
>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>> ---
>> sound/pci/hda/hda_tegra.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
>> index 4c799661c2f6..e406b7980f31 100644
>> --- a/sound/pci/hda/hda_tegra.c
>> +++ b/sound/pci/hda/hda_tegra.c
>> @@ -17,6 +17,7 @@
>> #include <linux/moduleparam.h>
>> #include <linux/mutex.h>
>> #include <linux/of_device.h>
>> +#include <linux/reset.h>
>> #include <linux/slab.h>
>> #include <linux/time.h>
>> #include <linux/string.h>
>> @@ -70,6 +71,7 @@
>> struct hda_tegra {
>> struct azx chip;
>> struct device *dev;
>> + struct reset_control *reset;
>> struct clk_bulk_data clocks[3];
>> unsigned int nclocks;
>> void __iomem *regs;
>> @@ -167,6 +169,12 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>> struct hda_tegra *hda = container_of(chip, struct hda_tegra, chip);
>> int rc;
>>
>> + if (!(chip && chip->running)) {
>
> Isn't that check for !chip a bit redundant? If that pointer isn't valid,
> we're just going to go crash when dereferencing hda later on, so I think
> this can simply be:
>
> if (!chip->running)
>
> I guess you took this from the inverse check below, but I think we can
> also drop it from there, perhaps in a separate patch.
>
>> + rc = reset_control_assert(hda->reset);
>> + if (rc)
>> + return rc;
>> + }
>> +
>> rc = clk_bulk_prepare_enable(hda->nclocks, hda->clocks);
>> if (rc != 0)
>> return rc;
>> @@ -176,6 +184,10 @@ static int __maybe_unused hda_tegra_runtime_resume(struct device *dev)
>> /* disable controller wake up event*/
>> azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) &
>> ~STATESTS_INT_MASK);
>> + } else {
>> + rc = reset_control_reset(hda->reset);
>
> The "if (chip)" part definitely doesn't make sense after this anymore
> because now if chip == NULL, then we end up in here and dereference an
> invalid "hda" pointer.
Okay, I took a note for the v3.
> Also, why reset_control_reset() here? We'll reach this if we ran
> reset_control_assert() above, so this should just be
> reset_control_deassert() to undo that, right? I suppose it wouldn't hurt
> to put throw that standard usleep_range() in there as well that we use
> to wait between reset assert and deassert to make sure the clocks have
> stabilized and the reset has indeed propagated through the whole IP.
The reset_control_reset() does the delaying before the deassert, i.e. it
does assert -> udelay(1) -> deassert.
https://elixir.free-electrons.com/linux/v5.11-rc3/source/drivers/clk/tegra/clk.c#L133
The reset_control_reset() usage appears to be a bit more code-tidy
variant in comparison to delaying directly. But I don't mind to use
delay + reset_control_deassert() directly since it may not be obvious to
everyone what reset_control_reset() does.
I'll change it in v3.
next prev parent reply other threads:[~2021-01-17 23:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-12 12:58 [PATCH v1 0/5] Clock and reset improvements for Tegra ALSA drivers Dmitry Osipenko
2021-01-12 12:58 ` [PATCH v1 1/5] ALSA: hda/tegra: Use clk_bulk helpers Dmitry Osipenko
2021-01-15 15:22 ` Thierry Reding
2021-01-17 23:31 ` Dmitry Osipenko
2021-01-19 17:31 ` Thierry Reding
2021-01-12 12:58 ` [PATCH v1 2/5] ALSA: hda/tegra: Reset hardware Dmitry Osipenko
2021-01-15 15:35 ` Thierry Reding
2021-01-17 23:39 ` Dmitry Osipenko [this message]
2021-01-19 17:30 ` Thierry Reding
2021-01-12 12:58 ` [PATCH v1 3/5] ASoC: tegra: ahub: Use of_reset_control_array_get_exclusive() Dmitry Osipenko
2021-01-15 15:37 ` Thierry Reding
2021-01-17 23:57 ` Dmitry Osipenko
2021-01-12 12:58 ` [PATCH v1 4/5] ASoC: tegra: ahub: Use clk_bulk helpers Dmitry Osipenko
2021-01-15 15:38 ` Thierry Reding
2021-01-12 12:58 ` [PATCH v1 5/5] ASoC: tegra: ahub: Reset hardware properly Dmitry Osipenko
2021-01-15 13:02 ` Dmitry Osipenko
2021-01-15 15:44 ` Thierry Reding
2021-01-18 0:02 ` Dmitry Osipenko
2021-01-19 17:34 ` Thierry Reding
2021-01-15 10:18 ` [PATCH v1 0/5] Clock and reset improvements for Tegra ALSA drivers Takashi Iwai
2021-01-15 10:52 ` Ben Dooks
2021-01-15 12:59 ` Dmitry Osipenko
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=e26bac65-7cde-439f-a353-3b960691096f@gmail.com \
--to=digetx@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=jonathanh@nvidia.com \
--cc=kwizart@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=perex@perex.cz \
--cc=pgwipeout@gmail.com \
--cc=spujar@nvidia.com \
--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 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).