Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut marex@denx.de Cc: Daniel Abrecht public@danielabrecht.ch Cc: Emil Velikov emil.l.velikov@gmail.com Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Stefan Agner stefan@agner.ch --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 3 +++ 1 file changed, 3 insertions(+)
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); + writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR); + readl(mxsfb->base + LCDC_CTRL1);
if (mxsfb->devdata->has_overlay) writel(0, mxsfb->base + LCDC_AS_CTRL);
Am Montag, dem 21.06.2021 um 00:49 +0200 schrieb Marek Vasut:
Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut marex@denx.de Cc: Daniel Abrecht public@danielabrecht.ch Cc: Emil Velikov emil.l.velikov@gmail.com Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Stefan Agner stefan@agner.ch
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 3 +++ 1 file changed, 3 insertions(+)
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.
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
readl(mxsfb->base + LCDC_CTRL1);
if (mxsfb->devdata->has_overlay) writel(0, mxsfb->base + LCDC_AS_CTRL);
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.
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.
Regards, Lucas
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.
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?
Regards, Lucas
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.
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb 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.
And they do, as there are write barriers prepended to the writes following the FIFO clear. The readback just lets the CPU wait until the write reached the peripheral, which I don't see a reason to do here. The ordering of the writes from the perspective of the peripheral is completely the same with or without the readback. The later writes can not overtake the FIFO clear writes due to the barriers.
I'm strongly against adding stuff because it "might have an effect", if it isn't required by architectural rules. It clutters the code and some months/years down the line nobody dares to cleanup/remove this stuff anymore, because everyone assumes that there was a good reason for adding those things.
Regards, Lucas
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb 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.
And they do, as there are write barriers prepended to the writes following the FIFO clear. The readback just lets the CPU wait until the write reached the peripheral, which I don't see a reason to do here. The ordering of the writes from the perspective of the peripheral is completely the same with or without the readback. The later writes can not overtake the FIFO clear writes due to the barriers.
I'm strongly against adding stuff because it "might have an effect", if it isn't required by architectural rules. It clutters the code and some months/years down the line nobody dares to cleanup/remove this stuff anymore, because everyone assumes that there was a good reason for adding those things.
Since there is no RTL for any of the iMXes or their IPs, how do you propose anyone except NXP can validate what is and what is not required ?
This patch helps with a problem where I sporadically observe shifted image on boot on mx8mm.
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb 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.
And they do, as there are write barriers prepended to the writes following the FIFO clear. The readback just lets the CPU wait until the write reached the peripheral, which I don't see a reason to do here. The ordering of the writes from the perspective of the peripheral is completely the same with or without the readback. The later writes can not overtake the FIFO clear writes due to the barriers.
I'm strongly against adding stuff because it "might have an effect", if it isn't required by architectural rules. It clutters the code and some months/years down the line nobody dares to cleanup/remove this stuff anymore, because everyone assumes that there was a good reason for adding those things.
Since there is no RTL for any of the iMXes or their IPs, how do you propose anyone except NXP can validate what is and what is not required ?
This patch helps with a problem where I sporadically observe shifted image on boot on mx8mm.
The order of writes to a device mapped region are defined by the ARM architecture and the AMBA bus standard, not the peripheral. I'm not saying this patch isn't needed. I'm saying the readbacks look bogus.
Have you checked that just adding the write to the REG_CLR doesn't fix your issue?
Regards, Lucas
On 6/29/21 10:02 AM, Lucas Stach wrote:
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb 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.
And they do, as there are write barriers prepended to the writes following the FIFO clear. The readback just lets the CPU wait until the write reached the peripheral, which I don't see a reason to do here. The ordering of the writes from the perspective of the peripheral is completely the same with or without the readback. The later writes can not overtake the FIFO clear writes due to the barriers.
I'm strongly against adding stuff because it "might have an effect", if it isn't required by architectural rules. It clutters the code and some months/years down the line nobody dares to cleanup/remove this stuff anymore, because everyone assumes that there was a good reason for adding those things.
Since there is no RTL for any of the iMXes or their IPs, how do you propose anyone except NXP can validate what is and what is not required ?
This patch helps with a problem where I sporadically observe shifted image on boot on mx8mm.
The order of writes to a device mapped region are defined by the ARM architecture and the AMBA bus standard, not the peripheral. I'm not saying this patch isn't needed. I'm saying the readbacks look bogus.
Have you checked that just adding the write to the REG_CLR doesn't fix your issue?
No, it does not help with the issue.
Am Donnerstag, dem 01.07.2021 um 00:50 +0200 schrieb Marek Vasut:
On 6/29/21 10:02 AM, Lucas Stach wrote:
Am Dienstag, dem 29.06.2021 um 05:04 +0200 schrieb Marek Vasut:
On 6/28/21 10:09 AM, Lucas Stach wrote:
Am Samstag, dem 26.06.2021 um 20:15 +0200 schrieb 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.
And they do, as there are write barriers prepended to the writes following the FIFO clear. The readback just lets the CPU wait until the write reached the peripheral, which I don't see a reason to do here. The ordering of the writes from the perspective of the peripheral is completely the same with or without the readback. The later writes can not overtake the FIFO clear writes due to the barriers.
I'm strongly against adding stuff because it "might have an effect", if it isn't required by architectural rules. It clutters the code and some months/years down the line nobody dares to cleanup/remove this stuff anymore, because everyone assumes that there was a good reason for adding those things.
Since there is no RTL for any of the iMXes or their IPs, how do you propose anyone except NXP can validate what is and what is not required ?
This patch helps with a problem where I sporadically observe shifted image on boot on mx8mm.
The order of writes to a device mapped region are defined by the ARM architecture and the AMBA bus standard, not the peripheral. I'm not saying this patch isn't needed. I'm saying the readbacks look bogus.
Have you checked that just adding the write to the REG_CLR doesn't fix your issue?
No, it does not help with the issue.
Okay, i don't want to hold up this patch over technicalities if it fixes the issue, in which case the readbacks probably provide just the right amount of delay for the FIFO clear to happen in hardware. FWIW:
Acked-by: Lucas Stach l.stach@pengutronix.de
Regards, Lucas
On Mon, Jun 21, 2021 at 4:19 AM Marek Vasut marex@denx.de wrote:
Make sure the FIFO_CLEAR bit is latched in when configuring the controller, so that the FIFO is really cleared. And then clear the FIFO_CLEAR bit, since it is not self-clearing.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut marex@denx.de Cc: Daniel Abrecht public@danielabrecht.ch Cc: Emil Velikov emil.l.velikov@gmail.com Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lucas Stach l.stach@pengutronix.de Cc: Stefan Agner stefan@agner.ch
Reviewed-by: Jagan Teki jagan@amarulasolutions.com Tested-by: Jagan Teki jagan@amarulasolutions.com # i.Core MX8MM
dri-devel@lists.freedesktop.org
-
Jagan Teki -
Lucas Stach -
Marek Vasut