[RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio

Mark Brown broonie at kernel.org
Thu Nov 19 17:27:11 CET 2020


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20201119/7d4164c3/attachment.sig>


More information about the Alsa-devel mailing list