On 6/4/24 1:12 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Montag, 3. Juni 2024, 23:25:43 CEST schrieb Marek Vasut:
On 6/3/24 2:18 PM, Alexander Stein wrote:
Hi Marek,
Hi,
Am Freitag, 31. Mai 2024, 22:39:49 CEST schrieb Marek Vasut:
This line_pixel_subtract is no longer needed now that the bridge can
request and obtain specific pixel clock on input to the bridge, with
clock frequency that matches the Pixel PLL frequency.
The line_pixel_subtract is now always 0, so drop it entirely.
The line_pixel_subtract was not reliable as it never worked when the
Pixel PLL and input clock were off just so that the required amount
of pixels to subtract would not be whole integer.
I think this is based on [1], no?
It is.
Thanks for confirmation.
I was wondering because it was not stated.
I thought [1] was already applied, but it seems it was only RBd.
I can either apply [1] and then add this on top, so the two commits can
be reverted separately if this one breaks something, or squash [1] into
this patch and send V2. Which one do you prefer ?
The [1] fixes a real nasty issue with DPI output which causes visible
image corruption, so I would like to have [1] in, but it is obviously
not perfect.
I can't use DPI anyway, but if [1] actually fixes something for DPI
I'm okay with having [1] in, which gets mostly reverted in this series.
But that's up to the maintainers.
It is the FRMSYNC enablement (as suggested by the TC9595 datasheet)
which fixes the issue. This just makes FRMSYNC work well with other modes.
