[PATCH] drm: mxsfb: Clear FIFO_CLEAR bit

[Marek Vasut]

On 6/24/21 2:01 PM, Lucas Stach wrote:
> Am Dienstag, dem 22.06.2021 um 11:33 +0200 schrieb Marek Vasut:
>> On 6/22/21 9:28 AM, Lucas Stach wrote:
>>> Am Montag, dem 21.06.2021 um 18:30 +0200 schrieb Marek Vasut:
>>>> On 6/21/21 2:14 PM, Lucas Stach wrote:
>>>>
>>>> [...]
>>>>
>>>>>> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>>>> index 98d8ba0bae84..22cb749fc9bc 100644
>>>>>> --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>>>> +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
>>>>>> @@ -241,6 +241,9 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb,
>>>>>>     
>>>>>>     	/* Clear the FIFOs */
>>>>>>     	writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
>>>>>> +	readl(mxsfb->base + LCDC_CTRL1);
>>>>>
>>>>> Do you really need those readbacks? As both writes are targeting the
>>>>> same slave interface, the memory barrier in the clear write should push
>>>>> the set write.
>>>>
>>>> What would push the clear write then ? We can drop one of the readl()s,
>>>> but not the last one.
>>>
>>> There are a lot of more writes with barriers to the controller slave
>>> interface in that function after clearing the FIFO. I don't see why
>>> this readback would be required.
>>
>> Because you really do want to make sure the fifo is cleared before you
>> start doing any of those other writes or configuring the controller in
>> any way.
> 
> I still don't see the reason. What additional properties do you think
> the readback provides that isn't already provided by the barriers in
> the following writes?

See the paragraph above -- we have to make sure the writes that trigger 
the FIFO clearing really take place before any other writes do.