On Wed, Jun 7, 2023 at 8:15 AM Rasmus Villemoes <rasmus.villemoes@xxxxxxxxx> wrote: > > On 26/05/2023 05.05, Adam Ford wrote: > > This series fixes the blanking pack size and the PMS calculation. It then > > adds support to allows the DSIM to dynamically DPHY clocks, and support > > non-burst mode while allowing the removal of the hard-coded clock values > > for the PLL for imx8m mini/nano/plus, and it allows the removal of the > > burst-clock device tree entry when burst-mode isn't supported by connected > > devices like an HDMI brige. In that event, the HS clock is set to the > > value requested by the bridge chip. > > > > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should > > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various > > Exynos boards. > > Hi all > > We're testing this on top of v6.4-rc4 on our imx8mp board, which has a > ti-sn65dsi86 DSI -> DisplayPort bridge. We do get an image at > 1920x1200, but the monitor says it's only at 58Hz, and measuring on the > DSI signals does seem to confirm that the update frequency is about 57.7 > or 57.8Hz (it's pretty hard to get a good measurement). It looks like > it's the lines that are too long, by a time that corresponds to about 80 > pixels. But all the frontporch/backporch/hsync values look sane and > completely standard for that resolution. > > Setting samsung,burst-clock-frequency explicitly to something large > enough or letting it be derived from the 154MHz pixel clock makes no > difference. > > Any ideas? What refresh rate are you trying to achieve? It seems like 57.7 or 57.8 is really close to the 58 the Monitor states. I would expect the refresh to be driven by whatever the monitor states it can handle. Have you tried using modetest to see what refresh rates are available? When I was doing this driver work, I would use modetest to determine the connector ID, then use modetest -s <connector-id>:<resolution>-<refresh> to display various resolutions and refresh rates. The 8MP shares the video-pll clock with both disp1 and disp2 clocks, and the imx-lcdif driver, which sends the display signals to the DSI, uses the disp clock, so the video-pll needs to be an exact multiple of the pixel clock or the output won't sink. Modetest should also show you the desired pixel clock for a given resolution and refresh. My displays didn't show 19200x1200 as an option, so I wasn't able to test that configuration. adam > > Thanks, > Rasmus >
