All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Preston <thomas.preston@codethink.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
	Charles Keepax <ckeepax@opensource.cirrus.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Kirill Marinushkin <kmarinushkin@birdec.tech>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Marco Felsch <m.felsch@pengutronix.de>,
	Annaliese McDermond <nh6z@nh6z.net>,
	Takashi Iwai <tiwai@suse.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Vinod Koul <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Jerome Brunet <jbrunet@baylibre.com>,
	linux-kernel@vger.kernel.org,
	Cheng-Yi Chiang <cychiang@chromium.org>
Subject: Re: [alsa-devel] [PATCH v2 3/3] ASoC: TDA7802: Add turn-on diagnostic routine
Date: Fri, 2 Aug 2019 15:51:09 +0100	[thread overview]
Message-ID: <ab0a2d14-90c0-6c28-2c80-351fccd85e68@codethink.co.uk> (raw)
In-Reply-To: <20190802111036.GB5387@sirena.org.uk>

On 02/08/2019 12:10, Mark Brown wrote:
> On Fri, Aug 02, 2019 at 09:32:17AM +0100, Thomas Preston wrote:
>> On 02/08/2019 00:42, Mark Brown wrote:
> 
>>> Yes, that's definitely doable - we've got some other drivers with
>>> similar things like calibration triggers exposed that way.
> 
>> One problem with using a kcontrol as a trigger for the turn-on diagnostic
>> is that the diagnostic routine has a "return value".
> 
> You can use a read only control for the readback, or just have it be
> triggered by overwriting the readback value.  You can cache the result.
> 

Keeping the trigger and result together like that would be better I think,
although the routine isn't supposed to run mid way through playback. If
we're mid playback the debugfs routine has to turn off AMP_ON, take the
device back to a known state, run diagnostics, then restore. Which causes
a gap in the audible sound.

>> Hm, maybe a better idea is to have the turn on diagnostic only run on
>> device probe (as its name suggests!), and print something to dmesg:
> 
>> 	modprobe tda7802 turn_on_diagnostic=1
> 
>> 	tda7802-codec i2c-TDA7802:00: Turn on diagnostic 04 04 04 04
> 
>> Kirill Marinushkin mentioned this in the first review [0], it just didn't
>> really sink in until now!
> 
> You could do that too, yeah.  Depends on what this is diagnosing and if
> that'd be useful.
> 

The diagnostic status bits describe situations such as:
- open load (no speaker connected)
- short to GND
- short to VCC
- etc

The intention is to test if all the speakers are connected. So, one might 
have a self test which runs the diagnostic and verifies it outputs:

	00 00 00 00

For example, on my test rig there is only one speaker connected. So it
reads:

	04 04 00 04

Where the second bit is "open load". So this would fail the test.

So in the kcontrol case the test would be something like:

	amixer sset "AMP1 turn on diagnostic" on
	amixer sget "AMP1 diagnostic"

And the module parameter case:

	rmmod tda7802
	modprobe tda7802 turn_on_diagnostic=1
	dmesg | grep "Turn on diagnostic 04 04 04 04"
	rmmod tda7802
	modprobe tda7802

I think the module parameter method is more appropriate for a
"Turn-on diagnostic", even though I don't really like grepping dmesg
for the result. I'll go ahead and implement that unless anyone has a
particular preference for the kcontrol-trigger.

Thanks

  reply	other threads:[~2019-08-02 14:51 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 12:09 [PATCH v2 0/3] ASoC: Codecs: Add TDA7802 codec Thomas Preston
2019-07-30 12:09 ` Thomas Preston
2019-07-30 12:09 ` [PATCH v2 1/3] dt-bindings: ASoC: Add TDA7802 amplifier Thomas Preston
2019-07-30 12:09   ` Thomas Preston
2019-07-30 12:27   ` Charles Keepax
2019-07-30 12:27     ` Charles Keepax
2019-07-30 13:12     ` Marco Felsch
2019-07-30 13:12       ` Marco Felsch
2019-07-30 14:12       ` [alsa-devel] " Thomas Preston
2019-07-30 14:33         ` Mark Brown
2019-07-30 14:10     ` Thomas Preston
2019-07-30 12:09 ` [PATCH v2 2/3] ASoC: Add codec driver for ST TDA7802 Thomas Preston
2019-07-30 12:09   ` Thomas Preston
2019-07-30 12:38   ` Charles Keepax
2019-07-30 12:38     ` Charles Keepax
2019-07-30 15:49     ` [alsa-devel] " Thomas Preston
2019-07-30 14:58   ` Mark Brown
2019-07-30 14:58     ` Mark Brown
2019-07-30 17:26     ` [alsa-devel] " Thomas Preston
2019-07-31  6:06       ` Marco Felsch
2019-07-31  8:57         ` Thomas Preston
2019-07-30 12:09 ` [PATCH v2 3/3] ASoC: TDA7802: Add turn-on diagnostic routine Thomas Preston
2019-07-30 12:09   ` Thomas Preston
2019-07-30 12:41   ` Charles Keepax
2019-07-30 12:41     ` Charles Keepax
2019-07-30 14:04     ` [alsa-devel] " Thomas Preston
2019-07-30 14:18       ` Charles Keepax
2019-07-30 14:18         ` Charles Keepax
2019-07-30 14:20       ` [alsa-devel] " Mark Brown
2019-07-30 15:27         ` Thomas Preston
2019-07-30 14:19   ` Mark Brown
2019-07-30 14:19     ` Mark Brown
2019-07-30 15:25     ` [alsa-devel] " Thomas Preston
2019-07-30 15:50       ` Mark Brown
2019-07-30 16:28         ` Thomas Preston
2019-07-31  8:03           ` Charles Keepax
2019-07-31  8:03             ` Charles Keepax
2019-08-01 23:42           ` Mark Brown
2019-08-02  8:32             ` Thomas Preston
2019-08-02 11:10               ` Mark Brown
2019-08-02 14:51                 ` Thomas Preston [this message]
2019-08-02 17:27                   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab0a2d14-90c0-6c28-2c80-351fccd85e68@codethink.co.uk \
    --to=thomas.preston@codethink.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=cychiang@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=kmarinushkin@birdec.tech \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=mark.rutland@arm.com \
    --cc=nh6z@nh6z.net \
    --cc=paul@crapouillou.net \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.