From: "Lu, Brent" <brent.lu@intel.com> To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>, "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org> Cc: Support Opensource <Support.Opensource@diasemi.com>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "cychiang@google.com" <cychiang@google.com>, "Chiang, Mac" <mac.chiang@intel.com> Subject: RE: [PATCH] ASoC: da7219: check SRM lock in trigger callback Date: Tue, 11 Feb 2020 10:08:15 +0000 [thread overview] Message-ID: <SN6PR11MB26702B2E7E5F705425517F4897180@SN6PR11MB2670.namprd11.prod.outlook.com> (raw) In-Reply-To: <AM6PR10MB2263F302A86B17C95B16361280190@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM> > > Could ensure? This change seems specific to Intel DSP based systems, at > least from the description. Having looked through the core, the trigger code > for a codec is seemingly always called before the trigger for the CPU. How will > this work for other platforms, assuming their clocks are enabled in the CPU > DAI trigger function by default? > > Can we always guarantee the CPU side isn't going to send anything other > than 0s until after SRM has locked? > I think the patch is for those systems which enable I2S clocks in pcm_start instead of pcm_prepare. It has no effect on systems already be able to turn on clocks in supply widgets or set_bias_level() function. If the trigger type in the DAI link is TRIGGER_PRE, then the trigger function of FE port (component or CPU DAI) will be called before codec driver's trigger function. In this case we will be able to turn on the clock in time. However, if the trigger type is TRIGGER_POST, then the patch does not help because just like what you said, codec driver's trigger function is called first. In my experiment with the patch, the SRM is locked in the second read and cost 50ms to wait. > > I was under the impression that 'trigger()' was atomic? We'd have to have > some kind of workqueue to do all of this, which means we'd almost certainly > lose some PCM data at the start of a stream. >
WARNING: multiple messages have this Message-ID (diff)
From: "Lu, Brent" <brent.lu@intel.com> To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>, "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org> Cc: Support Opensource <Support.Opensource@diasemi.com>, Liam Girdwood <lgirdwood@gmail.com>, Takashi Iwai <tiwai@suse.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "Chiang, Mac" <mac.chiang@intel.com>, Mark Brown <broonie@kernel.org>, "cychiang@google.com" <cychiang@google.com> Subject: Re: [alsa-devel] [PATCH] ASoC: da7219: check SRM lock in trigger callback Date: Tue, 11 Feb 2020 10:08:15 +0000 [thread overview] Message-ID: <SN6PR11MB26702B2E7E5F705425517F4897180@SN6PR11MB2670.namprd11.prod.outlook.com> (raw) In-Reply-To: <AM6PR10MB2263F302A86B17C95B16361280190@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM> > > Could ensure? This change seems specific to Intel DSP based systems, at > least from the description. Having looked through the core, the trigger code > for a codec is seemingly always called before the trigger for the CPU. How will > this work for other platforms, assuming their clocks are enabled in the CPU > DAI trigger function by default? > > Can we always guarantee the CPU side isn't going to send anything other > than 0s until after SRM has locked? > I think the patch is for those systems which enable I2S clocks in pcm_start instead of pcm_prepare. It has no effect on systems already be able to turn on clocks in supply widgets or set_bias_level() function. If the trigger type in the DAI link is TRIGGER_PRE, then the trigger function of FE port (component or CPU DAI) will be called before codec driver's trigger function. In this case we will be able to turn on the clock in time. However, if the trigger type is TRIGGER_POST, then the patch does not help because just like what you said, codec driver's trigger function is called first. In my experiment with the patch, the SRM is locked in the second read and cost 50ms to wait. > > I was under the impression that 'trigger()' was atomic? We'd have to have > some kind of workqueue to do all of this, which means we'd almost certainly > lose some PCM data at the start of a stream. > _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2020-02-11 10:08 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-10 8:16 [PATCH] ASoC: da7219: check SRM lock in trigger callback Brent Lu 2020-02-10 8:16 ` [alsa-devel] " Brent Lu 2020-02-10 14:18 ` Pierre-Louis Bossart 2020-02-10 14:18 ` Pierre-Louis Bossart 2020-02-10 15:44 ` Curtis Malainey 2020-02-10 16:07 ` Pierre-Louis Bossart 2020-02-10 16:07 ` Pierre-Louis Bossart 2020-02-10 16:18 ` Curtis Malainey 2020-02-11 4:00 ` Fletcher Woodruff 2020-02-11 4:00 ` Fletcher Woodruff 2020-02-10 14:32 ` Adam Thomson 2020-02-10 14:32 ` [alsa-devel] " Adam Thomson 2020-02-11 10:08 ` Lu, Brent [this message] 2020-02-11 10:08 ` Lu, Brent 2020-02-11 16:30 ` Pierre-Louis Bossart 2020-02-11 16:30 ` Pierre-Louis Bossart 2020-02-11 20:37 ` Sridharan, Ranjani 2020-02-11 21:12 ` Pierre-Louis Bossart 2020-02-11 21:12 ` Pierre-Louis Bossart 2020-02-11 21:37 ` Sridharan, Ranjani 2020-02-11 21:49 ` Pierre-Louis Bossart 2020-02-11 21:49 ` Pierre-Louis Bossart 2020-02-12 10:16 ` Adam Thomson 2020-02-12 10:16 ` Adam Thomson 2020-02-12 11:59 ` Mark Brown 2020-02-12 11:59 ` Mark Brown 2020-02-12 15:48 ` Pierre-Louis Bossart 2020-02-12 15:48 ` Pierre-Louis Bossart 2020-02-12 17:01 ` Adam Thomson 2020-02-12 17:01 ` Adam Thomson 2020-02-19 5:57 ` Lu, Brent 2020-02-19 10:05 ` Adam Thomson 2020-02-10 18:59 ` Mark Brown 2020-02-10 18:59 ` [alsa-devel] " Mark Brown 2020-02-11 10:19 ` Lu, Brent 2020-02-11 10:19 ` [alsa-devel] " Lu, Brent
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=SN6PR11MB26702B2E7E5F705425517F4897180@SN6PR11MB2670.namprd11.prod.outlook.com \ --to=brent.lu@intel.com \ --cc=Adam.Thomson.Opensource@diasemi.com \ --cc=Support.Opensource@diasemi.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=cychiang@google.com \ --cc=lgirdwood@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=mac.chiang@intel.com \ --cc=perex@perex.cz \ --cc=tiwai@suse.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: linkBe 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.