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-----
next prev parent 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