From: Peter Rosin <peda@axentia.se>
To: "Péter Ujfalusi" <peter.ujfalusi@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Takashi Iwai <tiwai@suse.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Kirill Marinushkin <kmarinushkin@birdec.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] ASoC: pcm512x: Mend accesses to the I2S_1 and I2S_2 registers
Date: Tue, 21 Sep 2021 08:52:23 +0200 [thread overview]
Message-ID: <d9850534-df41-a6b3-48e2-34823f5866e9@axentia.se> (raw)
In-Reply-To: <7537b141-0ef1-fb44-7e02-27b4dd1e772b@gmail.com>
On 2021-09-21 06:20, Péter Ujfalusi wrote:
> Hi Peter.
>
> On 20/09/2021 22:37, Peter Rosin wrote:
>
>> Nope, MODE1/2 are wired for I2C -> FMT is just the last I2C address
>> bit. So, nothing to do with I2S. And I can't see how that would explain
>> the same problem with the I2S_2 register?
>
> true, but worth the question ;)
Right :-)
>>>> This fix is not 100% correct. The datasheet of at least the pcm5142
>>>> states that four bits (0xcc) in the I2S_1 register are "RSV"
>>>> ("Reserved. Do not access.") and no hint is given as to what theHi
>>>> initial values are supposed to be. So, specifying defaults for
>>>> these bits is wrong. But perhaps better than a broken driver?
>>>
>>> The default of 0x02 (AFMT = 00b - I2S, ALEN = 10b - 24bits) is correct
>>> for I2S_1 and the 0 is the default of I2S_2.
>>>
>>> The failure happens when updating the AFMT (bit4-5) and when regmap is
>>> doing a i2c read since the default is not specified.
>>>
>>> It would be interesting to see what it is reading... Out of interest:
>>> can you mar the I2S_1 and I2S_2 as volatile and read / print the value
>>> just before the afmt and alen update?
>>
>> My first attempt was to mark the register volatile, and then read and
>> compare if the update was needed at all. But marking volatile wasn't
>> enough.
>
> If the value is not provided in the defaults then the first read is reading out to the chip anyways.
Yeah, but why is accessing I2S_1/2 returning -EBUSY when accessing e.g.
the PCM512x_MASTER_MODE register is not?
>> I also tried to set both a default and mark as volatile,
>
> Volatile always skips the cache, default would be ignored.
>
>> but it seems every read fails with -16 (EBUSY). I don't get why, to me
>> it almost feels like a regmap issue of some sort (probably the regmap
>> config is bad in some way), but I'm not fluent in regmap...
>
> Or most likely the chip is not powered at pcm512x_set_fmt() time?
The chip is always powered, at least externally. Are you hinting that
relevant parts of the chip may be powered down internally when
pcm512x_set_fmt() executes and that this is the -EBUSY cause? Why does
that only happen to me in that case?
>> So, since I can't read, I can't get to the initial values of the four
>> reserved bits. So, I winged them as zero.
>
> The value of the reserved bits are don't care.
>
> Can you try the attached patch w/o without the defaults for i2s_1/2?
> Not even compile tested...
[added a couple of underscores]
I get this early during boot/probe
[ 1.506291] pcm512x 0-004c: pcm512x_set_fmt: failed to read I2S_1: -16
[ 1.512905] pcm512x 0-004c: pcm512x_set_fmt: failed to read PLL_EN: -16
[ 1.519517] pcm512x 0-004c: Failed to set data format: -16
[ 1.525045] pcm512x 0-004c: Failed to set data offset: -16
and then this later, triggered from userspace when an app opens
the device
[ 14.620344] pcm512x 0-004c: pcm512x_hw_params: I2S_1: 0x2
So, reading *can* work.
Cheers,
Peter
next prev parent reply other threads:[~2021-09-21 6:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 14:49 Peter Rosin
[not found] ` <ae4b25f1-2b2c-d937-e23d-0f7d23bdf0c4@gmail.com>
2021-09-20 19:37 ` Peter Rosin
2021-09-20 21:29 ` Mark Brown
2021-09-21 6:37 ` Peter Rosin
2021-09-21 11:11 ` Mark Brown
2021-09-21 4:20 ` Péter Ujfalusi
2021-09-21 6:52 ` Peter Rosin [this message]
2021-09-21 8:10 ` Peter Rosin
2021-09-21 8:48 ` Peter Rosin
2021-09-21 12:01 ` Mark Brown
2021-09-21 13:30 ` Peter Rosin
2021-09-21 15:25 ` 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=d9850534-df41-a6b3-48e2-34823f5866e9@axentia.se \
--to=peda@axentia.se \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=kmarinushkin@birdec.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.ujfalusi@gmail.com \
--cc=tiwai@suse.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
all inboxes | Powered by JetHome®