From: Takashi Iwai <tiwai@suse.de>
To: Sameer Pujar <spujar@nvidia.com>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org
Subject: Re: [PATCH 6/7] ALSA: hda/tegra: fix kernel panic
Date: Tue, 22 Jan 2019 07:24:57 +0100 [thread overview]
Message-ID: <s5hh8e1xl8m.wl-tiwai@suse.de> (raw)
In-Reply-To: <3f222d50-67eb-c96f-7c0c-b47468cd1b00@nvidia.com>
On Tue, 22 Jan 2019 04:41:16 +0100,
Sameer Pujar wrote:
>
>
> On 1/22/2019 2:58 AM, Takashi Iwai wrote:
> > On Mon, 21 Jan 2019 18:41:36 +0100,
> > Sameer Pujar wrote:
> >> Kernel panic is seen during device boot. It appears that before the
> >> probe completes, runtime callbacks happen and the device setup is not
> >> done yet. This could be initiated from framework through exposed
> >> callbacks. This issue can be fixed by having a flag to indicate
> >> completion of device probe. Hence 'probed' flag is introduced to notify
> >> completion of probe and runtime callbacks can check this flag before
> >> doing any device access.
> > Such a fix should be rather folded into the previous, especially if
> > you know it's already broken :)
> Ok, I will meld this with previous commit.
> >
> > And, IMO, it's better to put such a check into runtime_idle callback
> > instead of doing in each (runtime_)suspend/resume callback.
> Check in runtime_idle would take care of suspend path. But how the check in
> runtime_resume can be avoided? Kernel panic happened during
> runtime_resume().
Hm, right, we need the check in both places, since runtime PM is
called from the system PM, too.
BTW, I guess we can check chip->running instead of adding a new flag.
thanks,
Takashi
next prev parent reply other threads:[~2019-01-22 6:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 17:41 [PATCH 0/7] Runtime PM support (hda/tegra) Sameer Pujar
2019-01-21 17:41 ` [PATCH 1/7] ALSA: hda/tegra: runtime power management support Sameer Pujar
2019-01-21 17:41 ` [PATCH 2/7] ALSA: hda/tegra: get clock handles early in probe Sameer Pujar
2019-01-21 17:41 ` [PATCH 3/7] ALSA: hda/tegra: add runtime PM callbacks Sameer Pujar
2019-01-21 17:41 ` [PATCH 4/7] ALSA: hda/tegra: remove redundant clock enable API Sameer Pujar
2019-01-21 17:41 ` [PATCH 5/7] ALSA: hda/tegra: implement runtime suspend/resume Sameer Pujar
2019-01-21 17:41 ` [PATCH 6/7] ALSA: hda/tegra: fix kernel panic Sameer Pujar
2019-01-21 21:28 ` Takashi Iwai
2019-01-22 3:41 ` Sameer Pujar
2019-01-22 6:24 ` Takashi Iwai [this message]
2019-01-21 17:41 ` [PATCH 7/7] ALSA: hda/tegra: add driver flag for runtime PM Sameer Pujar
2019-01-21 21:31 ` Takashi Iwai
2019-01-22 2:04 ` Sameer Pujar
2019-01-22 6:31 ` Takashi Iwai
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=s5hh8e1xl8m.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=spujar@nvidia.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