04:12 <sravn> marex: thanks!

09:18 <marex> lynxeye: you around ?

09:22 <lynxeye> marex: yes

09:30 <marex> lynxeye: have you ever seen wraparound with lcdif ?

09:31 <marex> lynxeye: like the image , say |12345| becomes |45123|, like that

09:31 <marex> lynxeye: I talked to mntmn recently and he said he saw it on mx8mq

09:31 <marex> lynxeye: I saw it on mx6sx too per the comments in the driver

09:31 <marex> and it also seems to be the case on mx7s per Laurents very foggy recolection

09:36 <lynxeye> marex: No, but I also didn't do much with the eLCDIF yet. All the projects I'm working on with the mx8mq are using the DCSS. With 8mm I haven't really done enough to find corner case issues.

09:37 <lynxeye> But wraparound sounds a lot like FIFO underflow.

09:37 <marex> lynxeye: you think ? :)

09:37 <marex> lynxeye: that's where all the mxsfb patches came from

09:37 <marex> lynxeye: but I think there is still one more thing left

09:38 <marex> since I see it on 6sx, it means it is lcdif specific

09:38 <marex> not specific to any of the other imx glue around it

09:39 <lynxeye> Yea, if the fifo underflows without any compensation in hardware the next scanout lines will be shifted by the missed dma bursts.

09:39 <marex> lynxeye: except this bit 24 should turn that compensation on, and the increase in open transactions should also prevent the underflow (which it does btw)

09:40 <marex> but I think there is something more

09:40 <marex> possibly a glitch when updating the frame, like if there is a write into the next buf register while at the same time, the hardware does flip the buffers

09:40 <marex> or something weird like that

09:40 <lynxeye> marex: This bit says it's compensating on the next frame. Is the corruption persistent even after your patches?

09:40 <marex> lynxeye: it is extremely sporadic

09:41 <marex> lynxeye: the patches I posted solve part of it, but I think there is still one more thing left