Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Hui Wang <hui.wang@canonical.com>,
	broonie@kernel.org, srinivas.kandagatla@linaro.org,
	jank@cadence.com, slawomir.blauciak@intel.com,
	Sanyog Kale <sanyog.r.kale@intel.com>,
	Bard liao <yung-chuan.liao@linux.intel.com>,
	Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [PATCH 1/8] soundwire: bus_type: add master_device/driver support
Date: Wed, 11 Mar 2020 12:06:45 +0530	[thread overview]
Message-ID: <20200311063645.GH4885@vkoul-mobl> (raw)
In-Reply-To: <4fabb135-6fbb-106f-44fd-8155ea716c00@linux.intel.com>

On 06-03-20, 09:40, Pierre-Louis Bossart wrote:
> > > > Why do you need a extra driver for this. Do you have another set of
> > > > device object and driver for DSP code? But you do manage that, right?
> > > > I am proposing to simplify the device model here and have only one
> > > > device (SOF PCI) and driver (SOF PCI driver), which is created by actual
> > > > bus (PCI here) as you have in rest of the driver like HDA, DSP etc.
> > > > 
> > > > I have already recommended is to make the int-sdw a module which is
> > > > invoked by SOF PCI driver code (thereby all code uses SOF PCI device and
> > > > SOF PCI driver) directly. The DSP in my time for skl was a separate
> > > > module but used the parent objects.
> > > > 
> > > > The SOF sdw init (the place where sdw routines are invoked after DSP
> > > > load) can call sdw_probe and startup. Based on DSP sequencing you can
> > > > call these functions directly without waiting for extra device to be
> > > > probed etc.
> > > > 
> > > > I feel your flows will be greatly simplified as a result of this.
> > > 
> > > Not at all, no. This is not a simplification but an extremely invasive
> > > proposal.
> > > 
> > > The parent-child relationship is extremely useful for power management, and
> > > guarantees that the PCI device remains on while one or more of the masters
> > > are used, and conversely can suspend when all links are idle. I currently
> > > don't need to do anything, it's all taken care of by the framework.
> > > 
> > > If I have to do all the power management at the PCI device level, then I
> > > will need to keep track of which links are currently active. All these links
> > > are used independently, so it's racy as hell to keep track of the usage when
> > > the pm framework already does so quite elegantly. You really want to use the
> > > pm_runtime_get/put refcount for each master device, not manage them from the
> > > PCI level.
> > 
> > Not at all, you still can call pm_runtime_get/put() calls in sdw module
> > for PCI device. That doesn't change at all.
> > 
> > Only change is for suspend/resume you have callbacks from PCI driver
> > rather than pm core.
> There are two other related issues that you didn't mention.
> 
> the ASoC layer does require a driver with a 'name' for the components
> registered with the master device. So if you don't have a driver for the
> master device, the DAIs will be associated with the PCI device.
> 
> But the ASoC core does make pm_runtime calls on its own,
> 
> soc_pcm_open(struct snd_pcm_substream *substream)
> {
> ...
> 	for_each_rtd_components(rtd, i, component)
> 		pm_runtime_get_sync(component->dev);
> 
> and if the device that's associated with the DAI is the PCI device, then
> that will not result in the relevant master IP being activated, only the PCI
> device refcount will be increased - meaning there is no hook that would tell
> the PCI layer to turn on a specific link.
> 
> What you are recommending would be an all-or-nothing solution with all links
> on or all links off, which beats the purpose of having independent
> link-level power management.

Why can't you use dai .startup callback for this?

The ASoC core will do pm_runtime calls that will ensure PCI device is
up, DSP firmware downloaded and running.

You can use .startup() to turn on your link and .shutdown to turn off
the link.

-- 
~Vinod

  reply	other threads:[~2020-03-11  6:46 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 22:31 [PATCH 0/8] soundwire: remove platform devices, add SOF interfaces Pierre-Louis Bossart
2020-02-27 22:31 ` [PATCH 1/8] soundwire: bus_type: add master_device/driver support Pierre-Louis Bossart
2020-02-28  7:32   ` Greg KH
2020-02-28 15:53     ` Pierre-Louis Bossart
2020-03-03  5:41   ` Vinod Koul
2020-03-03 15:23     ` Pierre-Louis Bossart
2020-03-04  9:53       ` Vinod Koul
2020-03-04 15:17         ` Pierre-Louis Bossart
2020-03-04 16:28           ` Greg KH
2020-03-05  6:46             ` Vinod Koul
2020-03-05  6:36           ` Vinod Koul
2020-03-05 12:46             ` Pierre-Louis Bossart
2020-03-06  5:01               ` Vinod Koul
2020-03-06 15:40                 ` Pierre-Louis Bossart
2020-03-11  6:36                   ` Vinod Koul [this message]
2020-03-11 14:44                     ` Pierre-Louis Bossart
2020-03-13 11:50                       ` Vinod Koul
2020-03-13 16:54                         ` Pierre-Louis Bossart
2020-03-14  9:49                           ` Vinod Koul
2020-03-16 19:15                             ` Pierre-Louis Bossart
2020-03-20 15:33                               ` Vinod Koul
2020-03-20 16:36                                 ` Pierre-Louis Bossart
2020-03-23 12:16                                   ` Vinod Koul
2020-02-27 22:32 ` [PATCH 2/8] soundwire: intel: transition to sdw_master_device/driver support Pierre-Louis Bossart
2020-02-28  7:34   ` Greg KH
2020-02-28 16:01     ` Pierre-Louis Bossart
2020-03-03  6:05   ` Vinod Koul
2020-02-27 22:32 ` [PATCH 3/8] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 4/8] soundwire: intel_init: use EXPORT_SYMBOL_NS Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 5/8] soundwire: intel/cadence: merge Soundwire interrupt handlers/threads Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 6/8] soundwire: intel: add helpers for link power down and shim wake Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 7/8] soundwire: intel: add wake interrupt support Pierre-Louis Bossart
2020-02-27 22:32 ` [PATCH 8/8] soundwire: intel_init: save Slave(s) _ADR info in sdw_intel_ctx Pierre-Louis Bossart
2020-02-28  7:32 ` [PATCH 0/8] soundwire: remove platform devices, add SOF interfaces Greg KH

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=20200311063645.GH4885@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rander.wang@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sanyog.r.kale@intel.com \
    --cc=slawomir.blauciak@intel.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.de \
    --cc=yung-chuan.liao@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox