From: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
To: Paul Cercueil <paul@crapouillou.net>
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
tiwai@suse.com, broonie@kernel.org
Subject: Re: [PATCH v4 01/11] ASoC: jz4740-i2s: Handle independent FIFO flush bits
Date: Sat, 22 Oct 2022 16:43:07 +0100 [thread overview]
Message-ID: <xDY1t3w8XLey5GcrHHg3gEH9kOIC7xq6@localhost> (raw)
In-Reply-To: <Q58DFR.835FR3DH8BFV@crapouillou.net>
Paul Cercueil <paul@crapouillou.net> writes:
> Hi Aidan,
>
> Le mer., juil. 20 2022 at 15:43:06 +0100, Aidan MacDonald
> <aidanmacdonald.0x0@gmail.com> a écrit :
>> Paul Cercueil <paul@crapouillou.net> writes:
>>
>> According to the JZ4740 programming manual JZ_AIC_CTRL_FLUSH flushes
>> both FIFOs, so it's not equivalent JZ4760_AIC_CTRL_TFLUSH. I don't
>> think it's a good idea to confuse the two, or we'd need comments to
>> explain why JZ4740 uses TFLUSH but not RFLUSH.
>
> "shared_fifo_flush" is pretty much self-explanatory though. It then becomes
> obvious looking at the code that when this flag is set, TFLUSH flushes both
> FIFOs.
>
> If you prefer... you can #define JZ_AIC_CTRL_FLUSH JZ_AIC_CTRL_TFLUSH. I don't
> like the JZ4760 prefix, this is in no way specific to the JZ4760.
>
Makes sense, I'll stick with TFLUSH / RFLUSH only.
>>
>>>> +
>>>> #define JZ_AIC_CTRL_OUTPUT_SAMPLE_SIZE_OFFSET 19
>>>> #define JZ_AIC_CTRL_INPUT_SAMPLE_SIZE_OFFSET 16
>>>> @@ -90,6 +93,8 @@ enum jz47xx_i2s_version {
>>>> struct i2s_soc_info {
>>>> enum jz47xx_i2s_version version;
>>>> struct snd_soc_dai_driver *dai;
>>>> +
>>>> + bool shared_fifo_flush;
>>>> };
>>>> struct jz4740_i2s {
>>>> @@ -124,12 +129,33 @@ static int jz4740_i2s_startup(struct
>>>> snd_pcm_substream
>>>> *substream,
>>>> uint32_t conf, ctrl;
>>>> int ret;
>>>> + /*
>>>> + * When we can flush FIFOs independently, only flush the
>>>> + * FIFO that is starting up.
>>>> + */
>>>> + if (!i2s->soc_info->shared_fifo_flush) {
>>>> + ctrl = jz4740_i2s_read(i2s, JZ_REG_AIC_CTRL);
>>>> +
>>>> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
>>>> + ctrl |= JZ4760_AIC_CTRL_TFLUSH;
>>>> + else
>>>> + ctrl |= JZ4760_AIC_CTRL_RFLUSH;
>>>> +
>>>> + jz4740_i2s_write(i2s, JZ_REG_AIC_CTRL, ctrl);
>>>> + }
>>> Wouldn't it be simpler to do one single if/else? And hy is one checked
>>> before
>>> the (snd_soc_dai_active(dai)) check, and the other is checked after?
>> snd_soc_dai_active() is essentially checking if there's an active
>> substream. Eg. if no streams are open and you start playback, then
>> the DAI will be inactive. If you then start capture while playback is
>> running, the DAI is already active.
>> With a shared flush bit we can only flush if there are no other active
>> substreams (because we don't want to disturb the active stream by
>> flushing the FIFO) so it goes after the snd_soc_dai_active() check.
>> When the FIFOs can be separately flushed, flushing can be done before
>> the check because it won't disturb any active substream.
>
> Ok. It makes sense then. Please add some info about this in the commit message,
> because it really wasn't obvious to me.
It wasn't that obvious to me either :)
I've added code comments too since it seems likely to trip people up
if you're only taking a casual glance.
> You should maybe factorize the read-modify-write into its own function. I know
> this gets eventually modified by [03/11], but this [01/11] is a bugfix so it
> will be applied to older kernels, and I'd rather not have duplicated code
> there.
>
> Cheers,
> -Paul
And I've factored out the r-m-w helper as requested.
Regards,
Aidan
next prev parent reply other threads:[~2022-10-22 15:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-08 16:02 [PATCH v4 00/11] ASoC: cleanups and improvements for jz4740-i2s Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 01/11] ASoC: jz4740-i2s: Handle independent FIFO flush bits Aidan MacDonald
2022-07-20 11:44 ` Paul Cercueil
2022-07-20 14:43 ` Aidan MacDonald
2022-07-21 10:08 ` Paul Cercueil
2022-10-22 15:43 ` Aidan MacDonald [this message]
2022-07-08 16:02 ` [PATCH v4 02/11] ASoC: jz4740-i2s: Remove unused 'mem' resource Aidan MacDonald
2022-07-20 11:44 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 03/11] ASoC: jz4740-i2s: Convert to regmap API Aidan MacDonald
2022-07-20 12:05 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 04/11] ASoC: jz4740-i2s: Simplify using regmap fields Aidan MacDonald
2022-07-20 11:50 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 05/11] ASoC: jz4740-i2s: Use FIELD_PREP() macros in hw_params callback Aidan MacDonald
2022-07-20 11:52 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 06/11] ASoC: jz4740-i2s: Align macro values and sort includes Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 07/11] ASoC: jz4740-i2s: Make the PLL clock name SoC-specific Aidan MacDonald
2022-07-13 14:33 ` Zhou Yanjie
2022-07-13 15:07 ` Paul Cercueil
2022-07-13 15:29 ` Zhou Yanjie
2022-10-22 17:15 ` Aidan MacDonald
2022-10-22 20:03 ` Paul Cercueil
2022-10-23 13:29 ` Aidan MacDonald
2022-10-24 13:06 ` Paul Cercueil
2022-10-25 9:20 ` Aidan MacDonald
2022-07-20 11:53 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 08/11] ASoC: jz4740-i2s: Support S20_LE and S24_LE sample formats Aidan MacDonald
2022-07-20 11:56 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 09/11] ASoC: jz4740-i2s: Support continuous sample rate Aidan MacDonald
2022-07-08 16:02 ` [PATCH v4 10/11] ASoC: jz4740-i2s: Move component functions near the component driver Aidan MacDonald
2022-07-20 11:58 ` Paul Cercueil
2022-07-08 16:02 ` [PATCH v4 11/11] ASoC: jz4740-i2s: Refactor DAI probe/remove ops as component ops Aidan MacDonald
2022-07-20 12:04 ` Paul Cercueil
2022-07-20 23:12 ` (subset) [PATCH v4 00/11] ASoC: cleanups and improvements for jz4740-i2s 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=xDY1t3w8XLey5GcrHHg3gEH9kOIC7xq6@localhost \
--to=aidanmacdonald.0x0@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=paul@crapouillou.net \
--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;
as well as URLs for NNTP newsgroup(s).