[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201117173901.GH5142@sirena.org.uk>
Date: Tue, 17 Nov 2020 17:39:01 +0000
From: Mark Brown <broonie@...nel.org>
To: "Viorel Suman (OSS)" <viorel.suman@....nxp.com>
Cc: 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>,
Shengjiu Wang <shengjiu.wang@....com>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Peter Ujfalusi <peter.ujfalusi@...com>,
Viorel Suman <viorel.suman@....com>,
Lee Jones <lee.jones@...aro.org>, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio
On Tue, Nov 17, 2020 at 12:20:36AM +0200, Viorel Suman (OSS) wrote:
> static void ak4458_power_off(struct ak4458_priv *ak4458)
> {
> - if (ak4458->reset_gpiod) {
> - gpiod_set_value_cansleep(ak4458->reset_gpiod, 0);
> - usleep_range(1000, 2000);
> + if (ak4458->reset) {
> + reset_control_assert(ak4458->reset);
> + msleep(20);
We should really leave the support for doing this via GPIO in place for
backwards compatibility I think, we could mark it as deprecated in the
binding document. Otherwise this makes sense to me and solves a real
problem we have with the handling of resets so we should look into doing
this for new bindings.
One thing I'm not clear on is if there's some way to ensure that we
don't have different instances of the device resetting each other
without them noticing? Shouldn't be an issue in practice for the use
here.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists