Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Nelson <eric.nelson@boundarydevices.com>
To: Mark Brown <broonie@kernel.org>
Cc: fabio.estevam@freescale.com, alsa-devel@alsa-project.org,
	lars@metafoo.de, tiwai@suse.de, lgirdwood@gmail.com,
	rmk+kernel@arm.linux.org.uk, jean-michel.hautbois@vodalys.com,
	troy.kisky@boundarydevices.com
Subject: Re: [RFC PATCH 2/6] ASoC: sgtl5000: write all default registers
Date: Fri, 06 Mar 2015 15:24:53 -0700	[thread overview]
Message-ID: <54FA2935.6090701@boundarydevices.com> (raw)
In-Reply-To: <20150306201406.GY21293@sirena.org.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,

On 03/06/2015 01:14 PM, Mark Brown wrote:
> On Thu, Feb 26, 2015 at 03:54:29PM -0700, Eric Nelson wrote:
>> If an error occurs writing defaults, produce an error message
>> but continue writing other registers. The failure of a single
>> write should not cause catastrophic device failure.
>> 
>> In at least one occurrence, I2C writes of CHIP_ANA_POWER was
>> nacked, though continuing allowed the device to operate
>> properly.
> 
> I'm a bit nervous about this.  Generally problems physically
> writing to the device are pretty bad and lead to followon hard to
> debug problems as the chip state drifts from the state the software
> thinks it has.  If this is a good idea I'd really like to see more
> analysis as to why this is expected to happen and why it's OK.
> 

I included this patch in the set because I found that the driver
would fail through a soft re-boot until I found the dependencies
of CHIP_CLK_CTRL and LINREG_CTRL in setting the initial value for
ANA_POWER.

By ignoring the failed register write, I found that I had functioning
audio.

Which begs the question: should we force complete failure on what may
be an intermittent problem.

My preference is no.

This is really un-related to the rest of the patch set.

Regards,


Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU+ik1AAoJEFUqXmm9AiVrRxYIAKvfJooQbhFu0um3bcX2e4sj
0AcBhn8P1brHv9gGkq68iEpQUA7E4nzSeOlmjlE6wLiC2tzHPdRsUFfHpAtrIMk5
CSdw3Qs9ti7jZkj0bRPVo0yINO7PxtCujvClfXETPNuyn78xy9lFK5PTX1sjZEso
Apeiz7smduItcFfBAGlcARK29b86cqJApKGNkzLL6J+NpmQptvrl3ijgohEPMB1/
4ubyt4K/0dCGON1UqFyMr5LKAlTjG2ctMM+10O7b2JpULwQqUpXSrobvT1syPSKZ
haa16ir8AYD5IWYMsUy/vWKDTrN2Vj+7pYdrpnW3ermVyqnSY7B0jx73REnjbbY=
=gk5O
-----END PGP SIGNATURE-----

  reply	other threads:[~2015-03-06 22:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-26 22:54 [PATCH RFC 0/6] ASoC: sgtl5000: fix use of regulators and internal LDO Eric Nelson
2015-02-26 22:54 ` [RFC PATCH 1/6] ASoC: sgtl5000: fix regulator support Eric Nelson
2015-03-06 20:04   ` Mark Brown
2015-03-06 21:09     ` Eric Nelson
2015-03-07  9:59       ` Mark Brown
2015-02-26 22:54 ` [RFC PATCH 2/6] ASoC: sgtl5000: write all default registers Eric Nelson
2015-03-06 20:14   ` Mark Brown
2015-03-06 22:24     ` Eric Nelson [this message]
2016-06-15 14:38   ` Applied "ASoC: sgtl5000: Write all default registers" to the asoc tree Mark Brown
2015-02-26 22:54 ` [RFC PATCH 3/6] ASoC: sgtl5000: initialize CHIP_ANA_POWER to power-on defaults Eric Nelson
2015-03-06 20:12   ` Mark Brown
2015-03-06 22:14     ` Eric Nelson
2015-03-07 10:28       ` Mark Brown
2015-02-26 22:54 ` [RFC PATCH 4/6] ASoC: sgtl5000: check return values Eric Nelson
2015-02-26 22:54 ` [RFC PATCH 5/6] ASoC: sgtl5000: disable internal PLL early Eric Nelson
2015-03-06 20:15   ` Mark Brown
2015-03-06 22:16     ` Eric Nelson
2016-06-15 14:38   ` Applied "ASoC: sgtl5000: Disable internal PLL early" to the asoc tree Mark Brown
2015-02-26 22:54 ` [RFC PATCH 6/6] ASoC: sgtl5000: Don't disable regulators in SND_SOC_BIAS_OFF Eric Nelson
2015-03-06 20:16   ` Mark Brown
2015-03-06 22:35     ` Eric Nelson
2015-03-07 10:41       ` Mark Brown
2015-03-06 22:49 ` [PATCH RFC 0/6] ASoC: sgtl5000: fix use of regulators and internal LDO Eric Nelson
2015-03-06 22:53   ` Russell King - ARM Linux
2015-03-06 22:58     ` Eric Nelson
2015-03-06 23:16       ` Eric Nelson
2015-03-06 23:24         ` Russell King - ARM Linux
2015-03-06 23:31           ` Eric Nelson
2015-03-07 10:45   ` 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=54FA2935.6090701@boundarydevices.com \
    --to=eric.nelson@boundarydevices.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=fabio.estevam@freescale.com \
    --cc=jean-michel.hautbois@vodalys.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=tiwai@suse.de \
    --cc=troy.kisky@boundarydevices.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox