All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Cc: alsa-devel@alsa-project.org, kai.vehmanen@linux.intel.com
Subject: Re: Question about hdac_ext_link ref_count management
Date: Fri, 22 Jan 2021 15:12:11 +0100	[thread overview]
Message-ID: <s5h1red83ic.wl-tiwai@suse.de> (raw)
In-Reply-To: <aca60b522335f3f916f9f8f204693365bfc32231.camel@linux.intel.com>

On Fri, 22 Jan 2021 00:23:53 +0100,
Ranjani Sridharan wrote:
> 
> Hi Takashi,
> 
> While exploring some power optimizations on Intel platforms, I noticed
> that the hdac_ext_link ref_count is incremented during codec probe
> in hdac_hda_codec_probe() and the ref_count is held until the codec
> device is removed. 
> 
> I was wondering if it would be possible to call the get/put for the
> hdac_ext_link in the codec runtime suspend/resume callbacks so that the
> link is powered up only when the link is in use. Are there any
> downsides to doing this? 

Wouldn't the  snd_hdac_ext_bus_link_power_up() / down() calls do the
runtime PM stuff?  Maybe we need to revisit those link power
management.  The ext stuff isn't well managed, I'm afraid.

The get() and put() are obviously for fully enabling and disabling the
device, hence it's not suitable for the runtime PM suspend/resume.
The power_up() / down() should be adjusted to fit with the runtime PM
call, if any.


thanks,

Takashi

  reply	other threads:[~2021-01-22 14:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21 23:23 Question about hdac_ext_link ref_count management Ranjani Sridharan
2021-01-22 14:12 ` Takashi Iwai [this message]
2021-01-22 16:40   ` Ranjani Sridharan
2021-01-22 16:50     ` Takashi Iwai
2021-01-22 17:24       ` Ranjani Sridharan
2021-01-22 22:04       ` Ranjani Sridharan

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=s5h1red83ic.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.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.