[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210210153808.GB4748@sirena.org.uk>
Date: Wed, 10 Feb 2021 15:38:08 +0000
From: Mark Brown <broonie@...nel.org>
To: Shengjiu Wang <shengjiu.wang@...il.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, alsa-devel@...a-project.org,
Timur Tabi <timur@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
linuxppc-dev@...ts.ozlabs.org, Xiubo Li <Xiubo.Lee@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Takashi Iwai <tiwai@...e.com>,
Nicolin Chen <nicoleotsuka@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Fabio Estevam <festevam@...il.com>
Subject: Re: [PATCH v2 2/7] ASoC: fsl_rpmsg: Add CPU DAI driver for audio
base on rpmsg
On Wed, Feb 10, 2021 at 02:35:29PM +0800, Shengjiu Wang wrote:
> On Wed, Feb 10, 2021 at 6:30 AM Mark Brown <broonie@...nel.org> wrote:
> > Like I say I'd actually recommend moving this control to DAPM.
> I may understand your point, you suggest to use the .set_bias_level
> interface. But in my case I need to enable the clock in earlier stage
> and keep the clock on when system go to suspend.
The device can be kept alive over system suspend if that's needed, or
possibly it sounds like runtime PM is a better fit? There's callbacks
in the core to keep the device runtime PM enabled while it's open which
is probably about the time range you're looking for.
> I am not sure .set_bias_level can met my requirement. we start
> the Chinese new year holiday now, so currently I can't do test for this
> recommendation.
> Maybe we can keep current implementation, can we?
> Later after I do the test, I can submit another patch for it.
Well, the current version is clearly going to leak clock enables with
valid userspace so
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists