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
next prev parent 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