All of 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 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.