Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
Thread-Topic: [PATCH] ASoC: da7219: check SRM lock in trigger callback
Thread-Index: AQHV3+tuqX6FpQoz5UK6Rt5tUMk2f6gUfeSAgAE8rrA=
Date:   Tue, 11 Feb 2020 10:08:15 +0000
Message-ID: <SN6PR11MB26702B2E7E5F705425517F4897180@SN6PR11MB2670.namprd11.prod.outlook.com>
References: <1581322611-25695-1-git-send-email-brent.lu@intel.com>
 <AM6PR10MB2263F302A86B17C95B16361280190@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <AM6PR10MB2263F302A86B17C95B16361280190@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.2.0.6
dlp-product: dlpe-windows
dlp-reaction: no-action
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f04bdcf-fc5d-4839-a702-08d7aeda4f57
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2020 10:08:15.1453
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rLkUdEdmfJUolACqmCVB1uhWBQUMHZsOSNw3RRXQYQFhDoYtzFmo2nDvKRBwzVg9+0rTJh445tlFTXRXi8zhwA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2573
X-OriginatorOrg: intel.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>=20
> Could ensure? This change seems specific to Intel DSP based systems, at
> least from the description. Having looked through the core, the trigger c=
ode
> for a codec is seemingly always called before the trigger for the CPU. Ho=
w will
> this work for other platforms, assuming their clocks are enabled in the C=
PU
> DAI trigger function by default?
>=20
> Can we always guarantee the CPU side isn't going to send anything other
> than 0s until after SRM has locked?
>=20

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 cloc=
ks in
supply widgets or set_bias_level() function.

If the trigger type in the DAI link is TRIGGER_PRE, then the trigger functi=
on of FE port
(component or CPU DAI) will be called before codec driver's trigger functio=
n. 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 c=
ost
50ms to wait.

>=20
> 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 certain=
ly
> lose some PCM data at the start of a stream.
>=20