[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201119162711.GE5554@sirena.org.uk>
Date: Thu, 19 Nov 2020 16:27:11 +0000
From: Mark Brown <broonie@...nel.org>
To: Viorel Suman <viorel.suman@....com>
Cc: "Viorel Suman (OSS)" <viorel.suman@....nxp.com>,
Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
"S.j. Wang" <shengjiu.wang@....com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@...com>,
Lee Jones <lee.jones@...aro.org>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio
On Thu, Nov 19, 2020 at 04:22:42PM +0000, Viorel Suman wrote:
> > Flip side of that then, how do we know when a reset has actually happened?
> I don't see how this can be achieved - I'd imagine some "shared" reset
> framework notification mechanism calling back all "listeners" in the moment
> the assert/deassert actually happened, there is no such mechanism currently
> implemented.
Yes, I'd expect some notification via callback or sometihng.
> In this specific case the GPIO purpose is to just to power on/off all codecs.
> In my view with this approach it's enough to know that all codecs will be
> powered on the first _deassert_ call and will be powered off on the last
> _assert_ call.
In general it can be useful to know if the device was actually reset
since then you can skip any reinitialization you might need to do due to
that in cases where the reset didn't actually end up happening. Not a
blocker but it would be useful.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists