[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180423154411.GK19834@sirena.org.uk>
Date: Mon, 23 Apr 2018 16:44:12 +0100
From: Mark Brown <broonie@...nel.org>
To: Jean-Jacques Hiblot <jjhiblot@...com>
Cc: robh+dt@...nel.org, mark.rutland@....com, perex@...ex.cz,
tiwai@...e.com, dannenberg@...com, afd@...com,
alsa-devel@...a-project.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ASoC: tas6424: Allow disabling auto diagnostics for
faster power-on
On Fri, Apr 20, 2018 at 12:04:42PM +0200, Jean-Jacques Hiblot wrote:
> The TAS6424 incorporates both DC-load and AC-load diagnostics which are
> used to determine the status of the load. The DC diagnostics runs when any
> channel is directed to leave the Hi-Z state and enter the MUTE or PLAY
> state.
> The DC diagnostics are turned on by default but if a fast startup without
> diagnostics is required the DC diagnostics can be bypassed by adding the
> property "disable-auto-diagnostics".
This is making me think we should be smarter here and either only run
the diagnostics once during boot or provide a user control for the
diagnostics. It seems like something that is more of a runtime software
decision than something that's fixed in hardware design, is there
anything about the hardware design that'd make it impossible to run
diagnostics?
> + if (tas6424->no_auto_diags) {
> + /*
> + * Disable DC auto-diagnostics to save time when channel leave
> + * Hi-Z state
> + */
> + ret = regmap_update_bits(tas6424->regmap,
> + TAS6424_DC_DIAG_CTRL1,
> + 0xff, TAS6424_LDGBYPASS);
This could just be exposed to userspace as a simple switch control
couldn't it? I do note that it masks more bits than it sets though...
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists