| Message ID | 20230818-samsung-dsim-v1-0-b39716db6b7a@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/bridge: samsung-dsim: fix various modes with ADV7535 bridge | expand |
On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter <m.tretter@pengutronix.de> wrote: > > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > modes were working, but in many modes my monitor stayed dark. > > This series fixes the Samsung DSIM bridge driver to bring up a few more > modes: > > The driver read the rate of the PLL ref clock only during probe. > However, if the clock is re-parented to the VIDEO_PLL, changes to the > pixel clock have an effect on the PLL ref clock. Therefore, the driver > must read and potentially update the PLL ref clock on every modeset. > > I also found that the rounding mode of the porches and active area has > an effect on the working modes. If the driver rounds up instead of > rounding down and be calculates them in Hz instead of kHz, more modes > start to work. > > The following table shows the modes that were working in my test without > this patch set and the modes that are working now: > > | Mode | Before | Now | > | 1920x1080-60.00 | X | X | > | 1920x1080-59.94 | | X | > | 1920x1080-50.00 | | X | > | 1920x1080-30.00 | | X | > | 1920x1080-29.97 | | X | > | 1920x1080-25.00 | | X | > | 1920x1080-24.00 | | | > | 1920x1080-23.98 | | | > | 1680x1050-59.88 | | X | > | 1280x1024-75.03 | X | X | > | 1280x1024-60.02 | X | X | > | 1200x960-59.99 | | X | > | 1152x864-75.00 | X | X | > | 1280x720-60.00 | | | > | 1280x720-59.94 | | | > | 1280x720-50.00 | | X | > | 1024x768-75.03 | | X | > | 1024x768-60.00 | | X | > | 800x600-75.00 | X | X | > | 800x600-60.32 | X | X | > | 720x576-50.00 | X | X | > | 720x480-60.00 | | | > | 720x480-59.94 | X | | > | 640x480-75.00 | X | X | > | 640x480-60.00 | | X | > | 640x480-59.94 | | X | > | 720x400-70.08 | | | > Nice! > Interestingly, the 720x480-59.94 mode stopped working. However, I am > able to bring up the 720x480 modes by manually hacking the active area > (hsa) to 40 and carefully adjusting the clocks, but something still > seems to be off. Checkout my branch: https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 I found that certain resolutions don't properly round, and it seemed to be related to the size of HFP. HFP of 110 when divded between 4 lanes, required a round-up, but then I had to recalculate the rest of the horizontal timings to compensate. I was going to push that as an RFC, but I will investigate your patch series first. With my small rounding correction, I am able to get 720x480 and 720p on my imx8mp, but not my mini/nano, so I am hoping your patch series fixes that issue for me. > > Unfortunately, a few more modes are still not working at all. The NXP > downstream kernel has some quirks to handle some of the modes especially > wrt. to the porches, but I cannot figure out, what the driver should > actually do in these cases. Maybe there is still an error in the > calculation of the porches and someone at NXP can chime in. Hopefully the comment in my above patch explains how the calculation is corrected and adjusted to get some of the missing resolutions. > Michael > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> I'll try to reivew this week and respond with my feedback. adam > --- > Marco Felsch (1): > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > Michael Tretter (4): > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > drm/bridge: samsung-dsim: update PLL reference clock > drm/bridge: samsung-dsim: adjust porches by rounding up > drm/bridge: samsung-dsim: calculate porches in Hz > > drivers/gpu/drm/bridge/samsung-dsim.c | 42 +++++++++++++++++++++++++---------- > include/drm/bridge/samsung-dsim.h | 1 + > 2 files changed, 31 insertions(+), 12 deletions(-) > --- > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c > change-id: 20230818-samsung-dsim-42346444bce5 > > Best regards, > -- > Michael Tretter <m.tretter@pengutronix.de> >
On 23-08-28, Michael Tretter wrote: > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > modes were working, but in many modes my monitor stayed dark. > > This series fixes the Samsung DSIM bridge driver to bring up a few more > modes: > > The driver read the rate of the PLL ref clock only during probe. > However, if the clock is re-parented to the VIDEO_PLL, changes to the > pixel clock have an effect on the PLL ref clock. Therefore, the driver > must read and potentially update the PLL ref clock on every modeset. > > I also found that the rounding mode of the porches and active area has > an effect on the working modes. If the driver rounds up instead of > rounding down and be calculates them in Hz instead of kHz, more modes > start to work. > > The following table shows the modes that were working in my test without > this patch set and the modes that are working now: > > | Mode | Before | Now | > | 1920x1080-60.00 | X | X | > | 1920x1080-59.94 | | X | > | 1920x1080-50.00 | | X | > | 1920x1080-30.00 | | X | > | 1920x1080-29.97 | | X | > | 1920x1080-25.00 | | X | > | 1920x1080-24.00 | | | > | 1920x1080-23.98 | | | > | 1680x1050-59.88 | | X | > | 1280x1024-75.03 | X | X | > | 1280x1024-60.02 | X | X | > | 1200x960-59.99 | | X | > | 1152x864-75.00 | X | X | > | 1280x720-60.00 | | | > | 1280x720-59.94 | | | > | 1280x720-50.00 | | X | > | 1024x768-75.03 | | X | > | 1024x768-60.00 | | X | > | 800x600-75.00 | X | X | > | 800x600-60.32 | X | X | > | 720x576-50.00 | X | X | > | 720x480-60.00 | | | > | 720x480-59.94 | X | | > | 640x480-75.00 | X | X | > | 640x480-60.00 | | X | > | 640x480-59.94 | | X | > | 720x400-70.08 | | | > > Interestingly, the 720x480-59.94 mode stopped working. However, I am > able to bring up the 720x480 modes by manually hacking the active area > (hsa) to 40 and carefully adjusting the clocks, but something still > seems to be off. > > Unfortunately, a few more modes are still not working at all. The NXP > downstream kernel has some quirks to handle some of the modes especially > wrt. to the porches, but I cannot figure out, what the driver should > actually do in these cases. Maybe there is still an error in the > calculation of the porches and someone at NXP can chime in. > > Michael > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> > --- > Marco Felsch (1): > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > Michael Tretter (4): > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > drm/bridge: samsung-dsim: update PLL reference clock > drm/bridge: samsung-dsim: adjust porches by rounding up > drm/bridge: samsung-dsim: calculate porches in Hz Feel free to add my r-b for your patches. Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
On Mon, Aug 28, 2023 at 11:13 AM Adam Ford <aford173@gmail.com> wrote: > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter > <m.tretter@pengutronix.de> wrote: > > > > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > > modes were working, but in many modes my monitor stayed dark. > > > > This series fixes the Samsung DSIM bridge driver to bring up a few more > > modes: > > > > The driver read the rate of the PLL ref clock only during probe. > > However, if the clock is re-parented to the VIDEO_PLL, changes to the > > pixel clock have an effect on the PLL ref clock. Therefore, the driver > > must read and potentially update the PLL ref clock on every modeset. > > > > I also found that the rounding mode of the porches and active area has > > an effect on the working modes. If the driver rounds up instead of > > rounding down and be calculates them in Hz instead of kHz, more modes > > start to work. > > > > The following table shows the modes that were working in my test without > > this patch set and the modes that are working now: > > > > | Mode | Before | Now | > > | 1920x1080-60.00 | X | X | > > | 1920x1080-59.94 | | X | > > | 1920x1080-50.00 | | X | > > | 1920x1080-30.00 | | X | > > | 1920x1080-29.97 | | X | > > | 1920x1080-25.00 | | X | > > | 1920x1080-24.00 | | | > > | 1920x1080-23.98 | | | > > | 1680x1050-59.88 | | X | > > | 1280x1024-75.03 | X | X | > > | 1280x1024-60.02 | X | X | > > | 1200x960-59.99 | | X | > > | 1152x864-75.00 | X | X | > > | 1280x720-60.00 | | | > > | 1280x720-59.94 | | | > > | 1280x720-50.00 | | X | > > | 1024x768-75.03 | | X | > > | 1024x768-60.00 | | X | > > | 800x600-75.00 | X | X | > > | 800x600-60.32 | X | X | > > | 720x576-50.00 | X | X | > > | 720x480-60.00 | | | > > | 720x480-59.94 | X | | > > | 640x480-75.00 | X | X | > > | 640x480-60.00 | | X | > > | 640x480-59.94 | | X | > > | 720x400-70.08 | | | > > > > Nice! > > > Interestingly, the 720x480-59.94 mode stopped working. However, I am > > able to bring up the 720x480 modes by manually hacking the active area > > (hsa) to 40 and carefully adjusting the clocks, but something still > > seems to be off. > > Checkout my > > branch: https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 > > I found that certain resolutions don't properly round, and it seemed > to be related to the size of HFP. HFP of 110 when divded between 4 > lanes, required a round-up, but then I had to recalculate the rest of > the horizontal timings to compensate. > > I was going to push that as an RFC, but I will investigate your patch > series first. With my small rounding correction, I am able to get > 720x480 and 720p on my imx8mp, but not my mini/nano, so I am hoping > your patch series fixes that issue for me. > > > > > Unfortunately, a few more modes are still not working at all. The NXP > > downstream kernel has some quirks to handle some of the modes especially > > wrt. to the porches, but I cannot figure out, what the driver should > > actually do in these cases. Maybe there is still an error in the > > calculation of the porches and someone at NXP can chime in. > > Hopefully the comment in my above patch explains how the calculation > is corrected and adjusted to get some of the missing resolutions. I tested my above patch and it works to sync 720p-60 on my imx8mp, but it doesn't seem to sync on my imx8mm using the same monitor and HDMI cable. I don't have a DSI analyzer, so I might still send out a modified version of my patch as an RFC once this gets approved. adam > > > Michael > > > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> > > I'll try to reivew this week and respond with my feedback. > > adam > > > --- > > Marco Felsch (1): > > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > > > Michael Tretter (4): > > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > > drm/bridge: samsung-dsim: update PLL reference clock > > drm/bridge: samsung-dsim: adjust porches by rounding up > > drm/bridge: samsung-dsim: calculate porches in Hz > > > > drivers/gpu/drm/bridge/samsung-dsim.c | 42 +++++++++++++++++++++++++---------- > > include/drm/bridge/samsung-dsim.h | 1 + > > 2 files changed, 31 insertions(+), 12 deletions(-) > > --- > > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c > > change-id: 20230818-samsung-dsim-42346444bce5 > > > > Best regards, > > -- > > Michael Tretter <m.tretter@pengutronix.de> > >
On Mon, 28 Aug 2023 18:07:08 -0500, Adam Ford wrote: > On Mon, Aug 28, 2023 at 11:13 AM Adam Ford <aford173@gmail.com> wrote: > > > > On Mon, Aug 28, 2023 at 10:59 AM Michael Tretter > > <m.tretter@pengutronix.de> wrote: > > > > > > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > > > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > > > modes were working, but in many modes my monitor stayed dark. > > > > > > This series fixes the Samsung DSIM bridge driver to bring up a few more > > > modes: > > > > > > The driver read the rate of the PLL ref clock only during probe. > > > However, if the clock is re-parented to the VIDEO_PLL, changes to the > > > pixel clock have an effect on the PLL ref clock. Therefore, the driver > > > must read and potentially update the PLL ref clock on every modeset. > > > > > > I also found that the rounding mode of the porches and active area has > > > an effect on the working modes. If the driver rounds up instead of > > > rounding down and be calculates them in Hz instead of kHz, more modes > > > start to work. > > > > > > The following table shows the modes that were working in my test without > > > this patch set and the modes that are working now: > > > > > > | Mode | Before | Now | > > > | 1920x1080-60.00 | X | X | > > > | 1920x1080-59.94 | | X | > > > | 1920x1080-50.00 | | X | > > > | 1920x1080-30.00 | | X | > > > | 1920x1080-29.97 | | X | > > > | 1920x1080-25.00 | | X | > > > | 1920x1080-24.00 | | | > > > | 1920x1080-23.98 | | | > > > | 1680x1050-59.88 | | X | > > > | 1280x1024-75.03 | X | X | > > > | 1280x1024-60.02 | X | X | > > > | 1200x960-59.99 | | X | > > > | 1152x864-75.00 | X | X | > > > | 1280x720-60.00 | | | > > > | 1280x720-59.94 | | | > > > | 1280x720-50.00 | | X | > > > | 1024x768-75.03 | | X | > > > | 1024x768-60.00 | | X | > > > | 800x600-75.00 | X | X | > > > | 800x600-60.32 | X | X | > > > | 720x576-50.00 | X | X | > > > | 720x480-60.00 | | | > > > | 720x480-59.94 | X | | > > > | 640x480-75.00 | X | X | > > > | 640x480-60.00 | | X | > > > | 640x480-59.94 | | X | > > > | 720x400-70.08 | | | > > > > > > > Nice! > > > > > Interestingly, the 720x480-59.94 mode stopped working. However, I am > > > able to bring up the 720x480 modes by manually hacking the active area > > > (hsa) to 40 and carefully adjusting the clocks, but something still > > > seems to be off. > > > > Checkout my > > > > branch: https://github.com/aford173/linux/commit/183cf6d154afeb9b0300500b09d7b8ec53047a12 Thanks for the pointer. > > > > I found that certain resolutions don't properly round, and it seemed > > to be related to the size of HFP. HFP of 110 when divded between 4 > > lanes, required a round-up, but then I had to recalculate the rest of > > the horizontal timings to compensate. > > > > I was going to push that as an RFC, but I will investigate your patch > > series first. With my small rounding correction, I am able to get > > 720x480 and 720p on my imx8mp, but not my mini/nano, so I am hoping > > your patch series fixes that issue for me. > > > > > > > > Unfortunately, a few more modes are still not working at all. The NXP > > > downstream kernel has some quirks to handle some of the modes especially > > > wrt. to the porches, but I cannot figure out, what the driver should > > > actually do in these cases. Maybe there is still an error in the > > > calculation of the porches and someone at NXP can chime in. > > > > Hopefully the comment in my above patch explains how the calculation > > is corrected and adjusted to get some of the missing resolutions. > > I tested my above patch and it works to sync 720p-60 on my imx8mp, but > it doesn't seem to sync on my imx8mm using the same monitor and HDMI > cable. I don't have a DSI analyzer, so I might still send out a > modified version of my patch as an RFC once this gets approved. I tested your patch with all modes of my monitor. 720p-60 doesn't work on my imx8mn either. The results are the same for DIV_ROUND_CLOSEST and DIV64_U64_ROUND_UP, but I didn't check for differences in the actually calculated HFP, yet. Michael > > adam > > > > > Michael > > > > > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> > > > > I'll try to reivew this week and respond with my feedback. > > > > adam > > > > > --- > > > Marco Felsch (1): > > > drm/bridge: samsung-dsim: add more mipi-dsi device debug information > > > > > > Michael Tretter (4): > > > drm/bridge: samsung-dsim: reread ref clock before configuring PLL > > > drm/bridge: samsung-dsim: update PLL reference clock > > > drm/bridge: samsung-dsim: adjust porches by rounding up > > > drm/bridge: samsung-dsim: calculate porches in Hz > > > > > > drivers/gpu/drm/bridge/samsung-dsim.c | 42 +++++++++++++++++++++++++---------- > > > include/drm/bridge/samsung-dsim.h | 1 + > > > 2 files changed, 31 insertions(+), 12 deletions(-) > > > --- > > > base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c > > > change-id: 20230818-samsung-dsim-42346444bce5 > > > > > > Best regards, > > > -- > > > Michael Tretter <m.tretter@pengutronix.de> > > > >
Hi Michael, On 28.08.23 17:59, Michael Tretter wrote: > I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > modes were working, but in many modes my monitor stayed dark. > > This series fixes the Samsung DSIM bridge driver to bring up a few more > modes: > > The driver read the rate of the PLL ref clock only during probe. > However, if the clock is re-parented to the VIDEO_PLL, changes to the > pixel clock have an effect on the PLL ref clock. Therefore, the driver > must read and potentially update the PLL ref clock on every modeset. > > I also found that the rounding mode of the porches and active area has > an effect on the working modes. If the driver rounds up instead of > rounding down and be calculates them in Hz instead of kHz, more modes > start to work. > > The following table shows the modes that were working in my test without > this patch set and the modes that are working now: > > | Mode | Before | Now | > | 1920x1080-60.00 | X | X | > | 1920x1080-59.94 | | X | > | 1920x1080-50.00 | | X | > | 1920x1080-30.00 | | X | > | 1920x1080-29.97 | | X | > | 1920x1080-25.00 | | X | > | 1920x1080-24.00 | | | > | 1920x1080-23.98 | | | > | 1680x1050-59.88 | | X | > | 1280x1024-75.03 | X | X | > | 1280x1024-60.02 | X | X | > | 1200x960-59.99 | | X | > | 1152x864-75.00 | X | X | > | 1280x720-60.00 | | | > | 1280x720-59.94 | | | > | 1280x720-50.00 | | X | > | 1024x768-75.03 | | X | > | 1024x768-60.00 | | X | > | 800x600-75.00 | X | X | > | 800x600-60.32 | X | X | > | 720x576-50.00 | X | X | > | 720x480-60.00 | | | > | 720x480-59.94 | X | | > | 640x480-75.00 | X | X | > | 640x480-60.00 | | X | > | 640x480-59.94 | | X | > | 720x400-70.08 | | | > > Interestingly, the 720x480-59.94 mode stopped working. However, I am > able to bring up the 720x480 modes by manually hacking the active area > (hsa) to 40 and carefully adjusting the clocks, but something still > seems to be off. > > Unfortunately, a few more modes are still not working at all. The NXP > downstream kernel has some quirks to handle some of the modes especially > wrt. to the porches, but I cannot figure out, what the driver should > actually do in these cases. Maybe there is still an error in the > calculation of the porches and someone at NXP can chime in. Thanks for working on this! We tested these patches with our Kontron BL i.MX8MM board and a "10.1inch HDMI LCD (E)" display from Waveshare [1]. Without this series we don't get an image with the default mode of the display (1024x600). With this series applied, it's now working. For the whole series: Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL i.MX8MM + Waveshare 10.1inch HDMI LCD (E) Thanks Frieder [1] https://www.waveshare.com/10.1inch-hdmi-lcd-e.htm
On 04.09.23 16:02, Frieder Schrempf wrote: > Hi Michael, > > On 28.08.23 17:59, Michael Tretter wrote: >> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, >> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few >> modes were working, but in many modes my monitor stayed dark. >> >> This series fixes the Samsung DSIM bridge driver to bring up a few more >> modes: >> >> The driver read the rate of the PLL ref clock only during probe. >> However, if the clock is re-parented to the VIDEO_PLL, changes to the >> pixel clock have an effect on the PLL ref clock. Therefore, the driver >> must read and potentially update the PLL ref clock on every modeset. >> >> I also found that the rounding mode of the porches and active area has >> an effect on the working modes. If the driver rounds up instead of >> rounding down and be calculates them in Hz instead of kHz, more modes >> start to work. >> >> The following table shows the modes that were working in my test without >> this patch set and the modes that are working now: >> >> | Mode | Before | Now | >> | 1920x1080-60.00 | X | X | >> | 1920x1080-59.94 | | X | >> | 1920x1080-50.00 | | X | >> | 1920x1080-30.00 | | X | >> | 1920x1080-29.97 | | X | >> | 1920x1080-25.00 | | X | >> | 1920x1080-24.00 | | | >> | 1920x1080-23.98 | | | >> | 1680x1050-59.88 | | X | >> | 1280x1024-75.03 | X | X | >> | 1280x1024-60.02 | X | X | >> | 1200x960-59.99 | | X | >> | 1152x864-75.00 | X | X | >> | 1280x720-60.00 | | | >> | 1280x720-59.94 | | | >> | 1280x720-50.00 | | X | >> | 1024x768-75.03 | | X | >> | 1024x768-60.00 | | X | >> | 800x600-75.00 | X | X | >> | 800x600-60.32 | X | X | >> | 720x576-50.00 | X | X | >> | 720x480-60.00 | | | >> | 720x480-59.94 | X | | >> | 640x480-75.00 | X | X | >> | 640x480-60.00 | | X | >> | 640x480-59.94 | | X | >> | 720x400-70.08 | | | >> >> Interestingly, the 720x480-59.94 mode stopped working. However, I am >> able to bring up the 720x480 modes by manually hacking the active area >> (hsa) to 40 and carefully adjusting the clocks, but something still >> seems to be off. >> >> Unfortunately, a few more modes are still not working at all. The NXP >> downstream kernel has some quirks to handle some of the modes especially >> wrt. to the porches, but I cannot figure out, what the driver should >> actually do in these cases. Maybe there is still an error in the >> calculation of the porches and someone at NXP can chime in. > > Thanks for working on this! We tested these patches with our Kontron BL > i.MX8MM board and a "10.1inch HDMI LCD (E)" display from Waveshare [1]. > > Without this series we don't get an image with the default mode of the > display (1024x600). With this series applied, it's now working. Minor correction: The display does work, but there is some flickering and occasional black screens if you let it run for some time. So there is still some sync issue. Anyway it's better than not working at all. > > For the whole series: > > Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL > i.MX8MM + Waveshare 10.1inch HDMI LCD (E) > > Thanks > Frieder > > [1] https://www.waveshare.com/10.1inch-hdmi-lcd-e.htm
Hi Frieder, On Wed, 06 Sep 2023 11:31:45 +0200, Frieder Schrempf wrote: > On 04.09.23 16:02, Frieder Schrempf wrote: > > On 28.08.23 17:59, Michael Tretter wrote: > >> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, > >> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few > >> modes were working, but in many modes my monitor stayed dark. > >> > >> This series fixes the Samsung DSIM bridge driver to bring up a few more > >> modes: > >> > >> The driver read the rate of the PLL ref clock only during probe. > >> However, if the clock is re-parented to the VIDEO_PLL, changes to the > >> pixel clock have an effect on the PLL ref clock. Therefore, the driver > >> must read and potentially update the PLL ref clock on every modeset. > >> > >> I also found that the rounding mode of the porches and active area has > >> an effect on the working modes. If the driver rounds up instead of > >> rounding down and be calculates them in Hz instead of kHz, more modes > >> start to work. > >> > >> The following table shows the modes that were working in my test without > >> this patch set and the modes that are working now: > >> > >> | Mode | Before | Now | > >> | 1920x1080-60.00 | X | X | > >> | 1920x1080-59.94 | | X | > >> | 1920x1080-50.00 | | X | > >> | 1920x1080-30.00 | | X | > >> | 1920x1080-29.97 | | X | > >> | 1920x1080-25.00 | | X | > >> | 1920x1080-24.00 | | | > >> | 1920x1080-23.98 | | | > >> | 1680x1050-59.88 | | X | > >> | 1280x1024-75.03 | X | X | > >> | 1280x1024-60.02 | X | X | > >> | 1200x960-59.99 | | X | > >> | 1152x864-75.00 | X | X | > >> | 1280x720-60.00 | | | > >> | 1280x720-59.94 | | | > >> | 1280x720-50.00 | | X | > >> | 1024x768-75.03 | | X | > >> | 1024x768-60.00 | | X | > >> | 800x600-75.00 | X | X | > >> | 800x600-60.32 | X | X | > >> | 720x576-50.00 | X | X | > >> | 720x480-60.00 | | | > >> | 720x480-59.94 | X | | > >> | 640x480-75.00 | X | X | > >> | 640x480-60.00 | | X | > >> | 640x480-59.94 | | X | > >> | 720x400-70.08 | | | > >> > >> Interestingly, the 720x480-59.94 mode stopped working. However, I am > >> able to bring up the 720x480 modes by manually hacking the active area > >> (hsa) to 40 and carefully adjusting the clocks, but something still > >> seems to be off. > >> > >> Unfortunately, a few more modes are still not working at all. The NXP > >> downstream kernel has some quirks to handle some of the modes especially > >> wrt. to the porches, but I cannot figure out, what the driver should > >> actually do in these cases. Maybe there is still an error in the > >> calculation of the porches and someone at NXP can chime in. > > > > Thanks for working on this! We tested these patches with our Kontron BL > > i.MX8MM board and a "10.1inch HDMI LCD (E)" display from Waveshare [1]. > > > > Without this series we don't get an image with the default mode of the > > display (1024x600). With this series applied, it's now working. > > Minor correction: The display does work, but there is some flickering > and occasional black screens if you let it run for some time. So there > is still some sync issue. What is the parent of the dsi_phy_ref clock in your test case? Make sure that the lcdif_pixel and dsi_phy_ref clocks are driven by the same PLL. I saw occasional black screens, if the lcdif_pixel and dsi_phy_ref clock had different parents, and fixed it by changing the assigned-parent of IMX8MN_CLK_DSI_PHY_REF to IMX8MN_VIDEO_PLL1_OUT in the device tree. If the clocks are not in sync, it seems that the ADV3575 has issues correctly reconstructing the pixel clock and HDMI monitors loose sync. This is something that must be configured in the board device tree, though. Michael > > Anyway it's better than not working at all. > > > > > For the whole series: > > > > Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> # Kontron BL > > i.MX8MM + Waveshare 10.1inch HDMI LCD (E) > > > > Thanks > > Frieder > > > > [1] https://www.waveshare.com/10.1inch-hdmi-lcd-e.htm >
Hi Michael, On 06.09.23 11:56, Michael Tretter wrote: > Hi Frieder, > > On Wed, 06 Sep 2023 11:31:45 +0200, Frieder Schrempf wrote: >> On 04.09.23 16:02, Frieder Schrempf wrote: >>> On 28.08.23 17:59, Michael Tretter wrote: >>>> I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, >>>> which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few >>>> modes were working, but in many modes my monitor stayed dark. >>>> >>>> This series fixes the Samsung DSIM bridge driver to bring up a few more >>>> modes: >>>> >>>> The driver read the rate of the PLL ref clock only during probe. >>>> However, if the clock is re-parented to the VIDEO_PLL, changes to the >>>> pixel clock have an effect on the PLL ref clock. Therefore, the driver >>>> must read and potentially update the PLL ref clock on every modeset. >>>> >>>> I also found that the rounding mode of the porches and active area has >>>> an effect on the working modes. If the driver rounds up instead of >>>> rounding down and be calculates them in Hz instead of kHz, more modes >>>> start to work. >>>> >>>> The following table shows the modes that were working in my test without >>>> this patch set and the modes that are working now: >>>> >>>> | Mode | Before | Now | >>>> | 1920x1080-60.00 | X | X | >>>> | 1920x1080-59.94 | | X | >>>> | 1920x1080-50.00 | | X | >>>> | 1920x1080-30.00 | | X | >>>> | 1920x1080-29.97 | | X | >>>> | 1920x1080-25.00 | | X | >>>> | 1920x1080-24.00 | | | >>>> | 1920x1080-23.98 | | | >>>> | 1680x1050-59.88 | | X | >>>> | 1280x1024-75.03 | X | X | >>>> | 1280x1024-60.02 | X | X | >>>> | 1200x960-59.99 | | X | >>>> | 1152x864-75.00 | X | X | >>>> | 1280x720-60.00 | | | >>>> | 1280x720-59.94 | | | >>>> | 1280x720-50.00 | | X | >>>> | 1024x768-75.03 | | X | >>>> | 1024x768-60.00 | | X | >>>> | 800x600-75.00 | X | X | >>>> | 800x600-60.32 | X | X | >>>> | 720x576-50.00 | X | X | >>>> | 720x480-60.00 | | | >>>> | 720x480-59.94 | X | | >>>> | 640x480-75.00 | X | X | >>>> | 640x480-60.00 | | X | >>>> | 640x480-59.94 | | X | >>>> | 720x400-70.08 | | | >>>> >>>> Interestingly, the 720x480-59.94 mode stopped working. However, I am >>>> able to bring up the 720x480 modes by manually hacking the active area >>>> (hsa) to 40 and carefully adjusting the clocks, but something still >>>> seems to be off. >>>> >>>> Unfortunately, a few more modes are still not working at all. The NXP >>>> downstream kernel has some quirks to handle some of the modes especially >>>> wrt. to the porches, but I cannot figure out, what the driver should >>>> actually do in these cases. Maybe there is still an error in the >>>> calculation of the porches and someone at NXP can chime in. >>> >>> Thanks for working on this! We tested these patches with our Kontron BL >>> i.MX8MM board and a "10.1inch HDMI LCD (E)" display from Waveshare [1]. >>> >>> Without this series we don't get an image with the default mode of the >>> display (1024x600). With this series applied, it's now working. >> >> Minor correction: The display does work, but there is some flickering >> and occasional black screens if you let it run for some time. So there >> is still some sync issue. > > What is the parent of the dsi_phy_ref clock in your test case? It's the IMX8MM_CLK_24M default from imx8mm.dtsi. > Make sure that > the lcdif_pixel and dsi_phy_ref clocks are driven by the same PLL. > > I saw occasional black screens, if the lcdif_pixel and dsi_phy_ref clock had > different parents, and fixed it by changing the assigned-parent of > IMX8MN_CLK_DSI_PHY_REF to IMX8MN_VIDEO_PLL1_OUT in the device tree. If the > clocks are not in sync, it seems that the ADV3575 has issues correctly > reconstructing the pixel clock and HDMI monitors loose sync. > > This is something that must be configured in the board device tree, though. Ok, I tried to set the parent of IMX8MM_CLK_DSI_PHY_REF to IMX8MM_VIDEO_PLL1_OUT. I also noticed, that I forgot to remove the samsung,pll-clock-frequency from the mipi_dsi node in imx8mm.dtsi. This is necessary to make use of your PLL input clock improvements. Otherwise I get 23.76 MHz for the DSIM PLL input (derived from IMX8MM_VIDEO_PLL1_OUT) which results in a HS clock of 300.96 MHz while the display requests 301.5 MHz (50.25 MHz pixel clock). This is too low and the display doesn't work at all. Unfortunately all of this doesn't result in a more stable image on the 10" Waveshare display. It seems like the display turns black whenever the Qt app does a lot of framebuffer updates, e. g. during animations, etc. Anyway, thanks for the help! Best regards Frieder
I tested the i.MX8M Nano EVK with the NXP supplied MIPI-DSI adapter, which uses an ADV7535 MIPI-DSI to HDMI converter. I found that a few modes were working, but in many modes my monitor stayed dark. This series fixes the Samsung DSIM bridge driver to bring up a few more modes: The driver read the rate of the PLL ref clock only during probe. However, if the clock is re-parented to the VIDEO_PLL, changes to the pixel clock have an effect on the PLL ref clock. Therefore, the driver must read and potentially update the PLL ref clock on every modeset. I also found that the rounding mode of the porches and active area has an effect on the working modes. If the driver rounds up instead of rounding down and be calculates them in Hz instead of kHz, more modes start to work. The following table shows the modes that were working in my test without this patch set and the modes that are working now: | Mode | Before | Now | | 1920x1080-60.00 | X | X | | 1920x1080-59.94 | | X | | 1920x1080-50.00 | | X | | 1920x1080-30.00 | | X | | 1920x1080-29.97 | | X | | 1920x1080-25.00 | | X | | 1920x1080-24.00 | | | | 1920x1080-23.98 | | | | 1680x1050-59.88 | | X | | 1280x1024-75.03 | X | X | | 1280x1024-60.02 | X | X | | 1200x960-59.99 | | X | | 1152x864-75.00 | X | X | | 1280x720-60.00 | | | | 1280x720-59.94 | | | | 1280x720-50.00 | | X | | 1024x768-75.03 | | X | | 1024x768-60.00 | | X | | 800x600-75.00 | X | X | | 800x600-60.32 | X | X | | 720x576-50.00 | X | X | | 720x480-60.00 | | | | 720x480-59.94 | X | | | 640x480-75.00 | X | X | | 640x480-60.00 | | X | | 640x480-59.94 | | X | | 720x400-70.08 | | | Interestingly, the 720x480-59.94 mode stopped working. However, I am able to bring up the 720x480 modes by manually hacking the active area (hsa) to 40 and carefully adjusting the clocks, but something still seems to be off. Unfortunately, a few more modes are still not working at all. The NXP downstream kernel has some quirks to handle some of the modes especially wrt. to the porches, but I cannot figure out, what the driver should actually do in these cases. Maybe there is still an error in the calculation of the porches and someone at NXP can chime in. Michael Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> --- Marco Felsch (1): drm/bridge: samsung-dsim: add more mipi-dsi device debug information Michael Tretter (4): drm/bridge: samsung-dsim: reread ref clock before configuring PLL drm/bridge: samsung-dsim: update PLL reference clock drm/bridge: samsung-dsim: adjust porches by rounding up drm/bridge: samsung-dsim: calculate porches in Hz drivers/gpu/drm/bridge/samsung-dsim.c | 42 +++++++++++++++++++++++++---------- include/drm/bridge/samsung-dsim.h | 1 + 2 files changed, 31 insertions(+), 12 deletions(-) --- base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c change-id: 20230818-samsung-dsim-42346444bce5 Best regards,