On Wed, Jun 7, 2023 at 8:27 AM Adam Ford <aford173@xxxxxxxxx> wrote: > > 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. Another thing you could try would be this rounding patch that I'm experimenting with [1]. >From what I can see, some resolutions end up with math that end up rounding down, and this patch corrects the timings a bit to attempt to compensate. I haven't tested this extensively yet, but you can try it to see if it helps. adam [1] - https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 > > adam > > > > Thanks, > > Rasmus > >
