lkml.org 
[lkml]   [2022]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v4 01/11] ASoC: jz4740-i2s: Handle independent FIFO flush bits
Date

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

\
 
 \ /
  Last update: 2022-10-22 17:45    [W:0.660 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site