This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
and 8QXP). Following, are the new features added and fixes from this
patch-set:
1. Add support for drm_bridge
On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
display connector, where an LCD panel can be attached, but instead it is
connected to DSI controller. Since this DSI stands between the display
controller (eLCDIF) and the physical connector, the DSI can be implemented
as a DRM bridge. So, in order to be able to connect the mxsfb driver to
the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
driver (the actual driver for the eLCDIF block).
2. Add support for additional pixel formats
Some of the pixel formats needed by Android were not implemented in this
driver, but they were actually supported. So, add support for them.
3. Add support for horizontal stride
Having support for horizontal stride allows the use of eLCDIF with a GPU
(for example) that can only output resolution sizes multiple of a power of
8. For example, 1080 is not a power of 16, so in order to support 1920x1080
output from GPUs that can produce linear buffers only in sizes multiple to 16,
this feature is needed.
3. Few minor features and bug-fixing
The addition of max-res DT property was actually needed in order to limit
the bandwidth usage of the eLCDIF block. This is need on systems where
multiple display controllers are presend and the memory bandwidth is not
enough to handle all of them at maximum capacity (like it is the case on
8MQ, where there are two display controllers: DCSS and eLCDIF).
The rest of the patches are bug-fixes.
v3:
- Removed the max-res property patches and added support for
max-memory-bandwidth property, as it is also implemented in other drivers
- Removed unnecessary drm_vblank_off in probe
v2:
- Collected Tested-by from Guido
- Split the first patch, which added more than one feature into relevant
patches, explaining each feature added
- Also split the second patch into more patches, to differentiate between
the feature itself (additional pixel formats support) and the cleanup
of the register definitions for a better representation (guido)
- Included a patch submitted by Guido, while he was testing my patch-set
Guido Günther (1):
drm/mxsfb: Read bus flags from bridge if present
Mirela Rabulea (1):
drm/mxsfb: Signal mode changed when bpp changed
Robert Chiras (13):
drm/mxsfb: Update mxsfb to support a bridge
drm/mxsfb: Add defines for the rest of registers
drm/mxsfb: Reset vital registers for a proper initialization
drm/mxsfb: Update register definitions using bit manipulation defines
drm/mxsfb: Update mxsfb with additional pixel formats
drm/mxsfb: Fix the vblank events
drm/mxsfb: Add max-memory-bandwidth property for MXSFB
dt-bindings: display: Add max-memory-bandwidth property for mxsfb
drm/mxsfb: Update mxsfb to support LCD reset
drm/mxsfb: Improve the axi clock usage
drm/mxsfb: Clear OUTSTANDING_REQS bits
drm/mxsfb: Add support for horizontal stride
drm/mxsfb: Add support for live pixel format change
.../devicetree/bindings/display/mxsfb.txt | 5 +
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
6 files changed, 589 insertions(+), 137 deletions(-)
--
2.7.4
Some of the registers, like LCDC_CTRL, CTRL2_OUTSTANDING_REQS and
CTRL1_RECOVERY_ON_UNDERFLOW needs to be properly cleared/initialized
for a better start and stop routine.
Signed-off-by: Robert Chiras <[email protected]>
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index b69ace8..5e44f57 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -127,6 +127,10 @@ static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
+ if (mxsfb->devdata->ipversion >= 4)
+ writel(CTRL2_OUTSTANDING_REQS(REQ_16),
+ mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
+
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
@@ -136,12 +140,19 @@ static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
writel(reg, mxsfb->base + LCDC_VDCTRL4);
writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_SET);
+ writel(CTRL1_RECOVERY_ON_UNDERFLOW, mxsfb->base + LCDC_CTRL1 + REG_SET);
}
static void mxsfb_disable_controller(struct mxsfb_drm_private *mxsfb)
{
u32 reg;
+ if (mxsfb->devdata->ipversion >= 4)
+ writel(CTRL2_OUTSTANDING_REQS(0x7),
+ mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
+
+ writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_CLR);
+
/*
* Even if we disable the controller here, it will still continue
* until its FIFOs are running out of data
@@ -295,6 +306,7 @@ void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
dma_addr_t paddr;
mxsfb_enable_axi_clk(mxsfb);
+ writel(0, mxsfb->base + LCDC_CTRL);
mxsfb_crtc_mode_set_nofb(mxsfb);
/* Write cur_buf as well to avoid an initial corrupt frame */
--
2.7.4
This IP requires full stop and re-start when changing display timings,
but we can change the pixel format while running.
Signed-off-by: Robert Chiras <[email protected]>
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 317575e..5607fc0 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -494,6 +494,7 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_crtc *crtc = &pipe->crtc;
struct drm_plane_state *new_state = pipe->plane.state;
struct drm_framebuffer *fb = pipe->plane.state->fb;
+ struct drm_framebuffer *old_fb = state->fb;
struct drm_pending_vblank_event *event;
u32 fb_addr, src_off, src_w, stride, cpp = 0;
@@ -510,7 +511,7 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
}
spin_unlock_irq(&crtc->dev->event_lock);
- if (!fb)
+ if (!fb || !old_fb)
return;
fb_addr = mxsfb_get_fb_paddr(mxsfb);
@@ -533,4 +534,17 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
src_w = new_state->src_w >> 16;
mxsfb_set_fb_hcrop(mxsfb, src_w, stride);
}
+
+ if (old_fb->format->format != fb->format->format) {
+ struct drm_format_name_buf old_fmt_buf;
+ struct drm_format_name_buf new_fmt_buf;
+
+ DRM_DEV_DEBUG_DRIVER(crtc->dev->dev,
+ "Switching pixel format: %s -> %s\n",
+ drm_get_format_name(old_fb->format->format,
+ &old_fmt_buf),
+ drm_get_format_name(fb->format->format,
+ &new_fmt_buf));
+ mxsfb_set_pixel_fmt(mxsfb, true);
+ }
}
--
2.7.4
Hi,
On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
> and 8QXP). Following, are the new features added and fixes from this
> patch-set:
I've applied this whole series on top of my NWL work and it looks good
with a DSI panel. Applying the whole series also fixes an issue where
after unblank the output was sometimes shifted about half a screen width
to the right (which didn't happen with DCSS). So at least from the parts
I could test:
Tested-by: Guido G?nther <[email protected]>
for the whole thing.
Cheers,
-- Guido
>
> 1. Add support for drm_bridge
> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
> display connector, where an LCD panel can be attached, but instead it is
> connected to DSI controller. Since this DSI stands between the display
> controller (eLCDIF) and the physical connector, the DSI can be implemented
> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
> driver (the actual driver for the eLCDIF block).
>
> 2. Add support for additional pixel formats
> Some of the pixel formats needed by Android were not implemented in this
> driver, but they were actually supported. So, add support for them.
>
> 3. Add support for horizontal stride
> Having support for horizontal stride allows the use of eLCDIF with a GPU
> (for example) that can only output resolution sizes multiple of a power of
> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
> output from GPUs that can produce linear buffers only in sizes multiple to 16,
> this feature is needed.
>
> 3. Few minor features and bug-fixing
> The addition of max-res DT property was actually needed in order to limit
> the bandwidth usage of the eLCDIF block. This is need on systems where
> multiple display controllers are presend and the memory bandwidth is not
> enough to handle all of them at maximum capacity (like it is the case on
> 8MQ, where there are two display controllers: DCSS and eLCDIF).
> The rest of the patches are bug-fixes.
>
> v3:
> - Removed the max-res property patches and added support for
> max-memory-bandwidth property, as it is also implemented in other drivers
> - Removed unnecessary drm_vblank_off in probe
>
> v2:
> - Collected Tested-by from Guido
> - Split the first patch, which added more than one feature into relevant
> patches, explaining each feature added
> - Also split the second patch into more patches, to differentiate between
> the feature itself (additional pixel formats support) and the cleanup
> of the register definitions for a better representation (guido)
> - Included a patch submitted by Guido, while he was testing my patch-set
>
> Guido G?nther (1):
> drm/mxsfb: Read bus flags from bridge if present
>
> Mirela Rabulea (1):
> drm/mxsfb: Signal mode changed when bpp changed
>
> Robert Chiras (13):
> drm/mxsfb: Update mxsfb to support a bridge
> drm/mxsfb: Add defines for the rest of registers
> drm/mxsfb: Reset vital registers for a proper initialization
> drm/mxsfb: Update register definitions using bit manipulation defines
> drm/mxsfb: Update mxsfb with additional pixel formats
> drm/mxsfb: Fix the vblank events
> drm/mxsfb: Add max-memory-bandwidth property for MXSFB
> dt-bindings: display: Add max-memory-bandwidth property for mxsfb
> drm/mxsfb: Update mxsfb to support LCD reset
> drm/mxsfb: Improve the axi clock usage
> drm/mxsfb: Clear OUTSTANDING_REQS bits
> drm/mxsfb: Add support for horizontal stride
> drm/mxsfb: Add support for live pixel format change
>
> .../devicetree/bindings/display/mxsfb.txt | 5 +
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
> 6 files changed, 589 insertions(+), 137 deletions(-)
>
> --
> 2.7.4
>
Hi,
On Mon, Aug 26, 2019 at 04:35:10PM +0200, Stefan Agner wrote:
> On 2019-08-26 14:05, Guido G?nther wrote:
> > Hi,
> > On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> >> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
> >> and 8QXP). Following, are the new features added and fixes from this
> >> patch-set:
> >
> > I've applied this whole series on top of my NWL work and it looks good
> > with a DSI panel. Applying the whole series also fixes an issue where
> > after unblank the output was sometimes shifted about half a screen width
> > to the right (which didn't happen with DCSS). So at least from the parts
> > I could test:
> >
> > Tested-by: Guido G?nther <[email protected]>
> >
> > for the whole thing.
>
> Thanks for testing! What SoC did you use? I think it would be good to
> also give this a try on i.MX 7 or i.MX 6ULL before merging.
This was on i.MX8MQ. I don't have hardware to test mxsfb on anything
else over here atm.
Cheers,
-- Guido
>
> --
> Stefan
>
>
> > Cheers,
> > -- Guido
> >>
> >> 1. Add support for drm_bridge
> >> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
> >> display connector, where an LCD panel can be attached, but instead it is
> >> connected to DSI controller. Since this DSI stands between the display
> >> controller (eLCDIF) and the physical connector, the DSI can be implemented
> >> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
> >> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
> >> driver (the actual driver for the eLCDIF block).
> >>
> >> 2. Add support for additional pixel formats
> >> Some of the pixel formats needed by Android were not implemented in this
> >> driver, but they were actually supported. So, add support for them.
> >>
> >> 3. Add support for horizontal stride
> >> Having support for horizontal stride allows the use of eLCDIF with a GPU
> >> (for example) that can only output resolution sizes multiple of a power of
> >> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
> >> output from GPUs that can produce linear buffers only in sizes multiple to 16,
> >> this feature is needed.
> >>
> >> 3. Few minor features and bug-fixing
> >> The addition of max-res DT property was actually needed in order to limit
> >> the bandwidth usage of the eLCDIF block. This is need on systems where
> >> multiple display controllers are presend and the memory bandwidth is not
> >> enough to handle all of them at maximum capacity (like it is the case on
> >> 8MQ, where there are two display controllers: DCSS and eLCDIF).
> >> The rest of the patches are bug-fixes.
> >>
> >> v3:
> >> - Removed the max-res property patches and added support for
> >> max-memory-bandwidth property, as it is also implemented in other drivers
> >> - Removed unnecessary drm_vblank_off in probe
> >>
> >> v2:
> >> - Collected Tested-by from Guido
> >> - Split the first patch, which added more than one feature into relevant
> >> patches, explaining each feature added
> >> - Also split the second patch into more patches, to differentiate between
> >> the feature itself (additional pixel formats support) and the cleanup
> >> of the register definitions for a better representation (guido)
> >> - Included a patch submitted by Guido, while he was testing my patch-set
> >>
> >> Guido G?nther (1):
> >> drm/mxsfb: Read bus flags from bridge if present
> >>
> >> Mirela Rabulea (1):
> >> drm/mxsfb: Signal mode changed when bpp changed
> >>
> >> Robert Chiras (13):
> >> drm/mxsfb: Update mxsfb to support a bridge
> >> drm/mxsfb: Add defines for the rest of registers
> >> drm/mxsfb: Reset vital registers for a proper initialization
> >> drm/mxsfb: Update register definitions using bit manipulation defines
> >> drm/mxsfb: Update mxsfb with additional pixel formats
> >> drm/mxsfb: Fix the vblank events
> >> drm/mxsfb: Add max-memory-bandwidth property for MXSFB
> >> dt-bindings: display: Add max-memory-bandwidth property for mxsfb
> >> drm/mxsfb: Update mxsfb to support LCD reset
> >> drm/mxsfb: Improve the axi clock usage
> >> drm/mxsfb: Clear OUTSTANDING_REQS bits
> >> drm/mxsfb: Add support for horizontal stride
> >> drm/mxsfb: Add support for live pixel format change
> >>
> >> .../devicetree/bindings/display/mxsfb.txt | 5 +
> >> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
> >> drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
> >> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
> >> 6 files changed, 589 insertions(+), 137 deletions(-)
> >>
> >> --
> >> 2.7.4
> >>
>
On 2019-08-26 14:05, Guido Günther wrote:
> Hi,
> On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
>> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
>> and 8QXP). Following, are the new features added and fixes from this
>> patch-set:
>
> I've applied this whole series on top of my NWL work and it looks good
> with a DSI panel. Applying the whole series also fixes an issue where
> after unblank the output was sometimes shifted about half a screen width
> to the right (which didn't happen with DCSS). So at least from the parts
> I could test:
>
> Tested-by: Guido Günther <[email protected]>
>
> for the whole thing.
Thanks for testing! What SoC did you use? I think it would be good to
also give this a try on i.MX 7 or i.MX 6ULL before merging.
--
Stefan
> Cheers,
> -- Guido
>>
>> 1. Add support for drm_bridge
>> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
>> display connector, where an LCD panel can be attached, but instead it is
>> connected to DSI controller. Since this DSI stands between the display
>> controller (eLCDIF) and the physical connector, the DSI can be implemented
>> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
>> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
>> driver (the actual driver for the eLCDIF block).
>>
>> 2. Add support for additional pixel formats
>> Some of the pixel formats needed by Android were not implemented in this
>> driver, but they were actually supported. So, add support for them.
>>
>> 3. Add support for horizontal stride
>> Having support for horizontal stride allows the use of eLCDIF with a GPU
>> (for example) that can only output resolution sizes multiple of a power of
>> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
>> output from GPUs that can produce linear buffers only in sizes multiple to 16,
>> this feature is needed.
>>
>> 3. Few minor features and bug-fixing
>> The addition of max-res DT property was actually needed in order to limit
>> the bandwidth usage of the eLCDIF block. This is need on systems where
>> multiple display controllers are presend and the memory bandwidth is not
>> enough to handle all of them at maximum capacity (like it is the case on
>> 8MQ, where there are two display controllers: DCSS and eLCDIF).
>> The rest of the patches are bug-fixes.
>>
>> v3:
>> - Removed the max-res property patches and added support for
>> max-memory-bandwidth property, as it is also implemented in other drivers
>> - Removed unnecessary drm_vblank_off in probe
>>
>> v2:
>> - Collected Tested-by from Guido
>> - Split the first patch, which added more than one feature into relevant
>> patches, explaining each feature added
>> - Also split the second patch into more patches, to differentiate between
>> the feature itself (additional pixel formats support) and the cleanup
>> of the register definitions for a better representation (guido)
>> - Included a patch submitted by Guido, while he was testing my patch-set
>>
>> Guido Günther (1):
>> drm/mxsfb: Read bus flags from bridge if present
>>
>> Mirela Rabulea (1):
>> drm/mxsfb: Signal mode changed when bpp changed
>>
>> Robert Chiras (13):
>> drm/mxsfb: Update mxsfb to support a bridge
>> drm/mxsfb: Add defines for the rest of registers
>> drm/mxsfb: Reset vital registers for a proper initialization
>> drm/mxsfb: Update register definitions using bit manipulation defines
>> drm/mxsfb: Update mxsfb with additional pixel formats
>> drm/mxsfb: Fix the vblank events
>> drm/mxsfb: Add max-memory-bandwidth property for MXSFB
>> dt-bindings: display: Add max-memory-bandwidth property for mxsfb
>> drm/mxsfb: Update mxsfb to support LCD reset
>> drm/mxsfb: Improve the axi clock usage
>> drm/mxsfb: Clear OUTSTANDING_REQS bits
>> drm/mxsfb: Add support for horizontal stride
>> drm/mxsfb: Add support for live pixel format change
>>
>> .../devicetree/bindings/display/mxsfb.txt | 5 +
>> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
>> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
>> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
>> drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
>> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
>> 6 files changed, 589 insertions(+), 137 deletions(-)
>>
>> --
>> 2.7.4
>>
On 26.08.2019 17:35, Stefan Agner wrote:
> On 2019-08-26 14:05, Guido G?nther wrote:
>> Hi,
>> On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
>>> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
>>> and 8QXP). Following, are the new features added and fixes from this
>>> patch-set:
>>
>> I've applied this whole series on top of my NWL work and it looks good
>> with a DSI panel. Applying the whole series also fixes an issue where
>> after unblank the output was sometimes shifted about half a screen width
>> to the right (which didn't happen with DCSS). So at least from the parts
>> I could test:
>>
>> Tested-by: Guido G?nther <[email protected]>
>>
>> for the whole thing.
>
> Thanks for testing! What SoC did you use? I think it would be good to
> also give this a try on i.MX 7 or i.MX 6ULL before merging.
I did a quick test on imx6sx-sdb and it seems that [PATCH 07/15]
"drm/mxsfb: Fix the vblank events" causes a hang on boot, even without a
panel.
If I revert that particular patch it seems to be fine: the new pixel
formats seem to work in modetest (checked with sii,43wvf1g panel).
--
Regards,
Leonard
Hi Leonard,
On Lu, 2019-08-26 at 19:19 +0000, Leonard Crestez wrote:
> On 26.08.2019 17:35, Stefan Agner wrote:
> >
> > On 2019-08-26 14:05, Guido Günther wrote:
> > >
> > > Hi,
> > > On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> > > >
> > > > This patch-set improves the use of eLCDIF block on iMX 8 SoCs
> > > > (like 8MQ, 8MM
> > > > and 8QXP). Following, are the new features added and fixes from
> > > > this
> > > > patch-set:
> > > I've applied this whole series on top of my NWL work and it looks
> > > good
> > > with a DSI panel. Applying the whole series also fixes an issue
> > > where
> > > after unblank the output was sometimes shifted about half a
> > > screen width
> > > to the right (which didn't happen with DCSS). So at least from
> > > the parts
> > > I could test:
> > >
> > > Tested-by: Guido Günther <[email protected]>
> > >
> > > for the whole thing.
> > Thanks for testing! What SoC did you use? I think it would be good
> > to
> > also give this a try on i.MX 7 or i.MX 6ULL before merging.
> I did a quick test on imx6sx-sdb and it seems that [PATCH 07/15]
> "drm/mxsfb: Fix the vblank events" causes a hang on boot, even
> without a
> panel.
>
> If I revert that particular patch it seems to be fine: the new pixel
> formats seem to work in modetest (checked with sii,43wvf1g panel).
Thanks for feedback. I tested this and, indeed there are issues on 6SX
with this particular patch. It seems that there is a race-condition
caused by the vblank_on call in enable and IRQ routine. Since this is
not happening on any of i.MX8 SoC, I suspect the axi clock usage.
I think I will just remove this patch from the patch-set and handle
this case separately.
>
> --
> Regards,
> Leonard
Regards,
Robert