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.
