alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: "Liao, Bard" <bard.liao@intel.com>
Cc: "pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"tiwai@suse.de" <tiwai@suse.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ranjani.sridharan@linux.intel.com"
	<ranjani.sridharan@linux.intel.com>,
	"hui.wang@canonical.com" <hui.wang@canonical.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"srinivas.kandagatla@linaro.org" <srinivas.kandagatla@linaro.org>,
	"jank@cadence.com" <jank@cadence.com>,
	"Lin, Mengdong" <mengdong.lin@intel.com>,
	"Kale, Sanyog R" <sanyog.r.kale@intel.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	"rander.wang@linux.intel.com" <rander.wang@linux.intel.com>
Subject: Re: [PATCH 07/11] soundwire: intel: Only call sdw stream APIs for the first cpu_dai
Date: Fri, 28 Aug 2020 13:15:44 +0530	[thread overview]
Message-ID: <20200828074544.GM2639@vkoul-mobl> (raw)
In-Reply-To: <DM6PR11MB407494AEF6D05EFF627CFAFBFF520@DM6PR11MB4074.namprd11.prod.outlook.com>

On 28-08-20, 01:47, Liao, Bard wrote:
> > snd_pcm_substream *substream,
> > >  			goto err;
> > >  	}
> > >
> > > -	ret = sdw_prepare_stream(dma->stream);
> > > +	/*
> > > +	 * All cpu dais belong to a stream. To ensure sdw_prepare_stream
> > > +	 * is called once per stream, we should call it only when
> > > +	 * dai = first_cpu_dai.
> > > +	 */
> > > +	if (first_cpu_dai == dai)
> > > +		ret = sdw_prepare_stream(dma->stream);
> > 
> > Hmmm why not use the one place which is unique in the card to call this,
> > hint machine dais are only called once.
> 
> Yes, we can call it in machine driver. But, shouldn't it belong to platform
> level? The point is that if we move the stuff to machine driver, it will
> force people to implement these stuff on their own Intel machine driver.

nothing stops anyone from doing that right! machine driver is another
component so it can be moved there as well

-- 
~Vinod

  reply	other threads:[~2020-08-28  7:46 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  2:41 [PATCH 00/11] soundwire: intel: add multi-link support Bard Liao
2020-08-18  2:41 ` [PATCH 01/11] soundwire: intel: disable shim wake on suspend Bard Liao
2020-08-18  2:41 ` [PATCH 02/11] soundwire: intel: ignore software command retries Bard Liao
2020-08-18  2:41 ` [PATCH 03/11] soundwire: intel: add multi-link support Bard Liao
2020-08-18  2:41 ` [PATCH 04/11] soundwire: intel: add missing support for all clock stop modes Bard Liao
2020-08-18  2:41 ` [PATCH 05/11] soundwire: bus: update multi-link definition with hw sync details Bard Liao
2020-08-26  9:44   ` Vinod Koul
2020-08-26 14:09     ` Pierre-Louis Bossart
2020-08-28  7:27       ` Vinod Koul
2020-08-18  2:41 ` [PATCH 06/11] soundwire: intel: add multi-link hw_synchronization information Bard Liao
2020-08-18  2:41 ` [PATCH 07/11] soundwire: intel: Only call sdw stream APIs for the first cpu_dai Bard Liao
2020-08-26  9:46   ` Vinod Koul
2020-08-26 14:35     ` Pierre-Louis Bossart
2020-08-28  7:49       ` Vinod Koul
2020-08-28  1:47     ` Liao, Bard
2020-08-28  7:45       ` Vinod Koul [this message]
2020-08-28 15:07         ` Pierre-Louis Bossart
2020-08-18  2:41 ` [PATCH 08/11] soundwire: stream: enable hw_sync as needed by hardware Bard Liao
2020-08-18  2:41 ` [PATCH 09/11] soundwire: intel: add dynamic debug trace for clock-stop invalid configs Bard Liao
2020-08-26  9:48   ` Vinod Koul
2020-08-26 14:38     ` Pierre-Louis Bossart
2020-08-28  7:49       ` Vinod Koul
2020-08-28 14:54         ` Pierre-Louis Bossart
2020-08-29 11:00   ` Vinod Koul
2020-08-31 15:15     ` Pierre-Louis Bossart
2020-09-01 11:07       ` Vinod Koul
2020-09-01 13:31         ` Pierre-Louis Bossart
2020-08-18  2:41 ` [PATCH 10/11] soundwire: intel: pass link_mask information to each master Bard Liao
2020-08-18  2:41 ` [PATCH 11/11] soundwire: intel: don't manage link power individually Bard Liao

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=20200828074544.GM2639@vkoul-mobl \
    --to=vkoul@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=bard.liao@intel.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hui.wang@canonical.com \
    --cc=jank@cadence.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mengdong.lin@intel.com \
    --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=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;
as well as URLs for NNTP newsgroup(s).