Message ID | 20241203165450.1501219-1-heiko@sntech.de (mailing list archive) |
---|---|
Headers | show |
Series | drm/rockchip: Add driver for the new DSI2 controller | expand |
Hello Heiko, On 03.12.24 21:54, Heiko Stuebner wrote: > This series adds a bridge and glue driver for the DSI2 controller found > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > > As the manual states: > The Display Serial Interface 2 (DSI-2) is part of a group of communication > protocols defined by the MIPI Alliance. The MIPI DSI-2 Host Controller is > a digital core that implements all protocol functions defined in the > MIPI DSI-2 Specification. > > > While the driver structure is very similar to the previous DSI controller, > the programming model of the core is quite different, with a completely > new register set. > > Another notable difference is that the phy interface is variable now too > in its width and some other settings. Thanks for the series. I was able to get output on my Radxa's Rock 5B (dsi1) + Radxa's 10FHD Display setup. Works smoothly with multiple DE's, rotation and display on/off. Tested-by: Dmitry Yashin <dmt.yashin@gmail.com>
Hello Heiko, On 03.12.24 21:54, Heiko Stuebner wrote: > This series adds a bridge and glue driver for the DSI2 controller found > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > > As the manual states: > The Display Serial Interface 2 (DSI-2) is part of a group of communication > protocols defined by the MIPI Alliance. The MIPI DSI-2 Host Controller is > a digital core that implements all protocol functions defined in the > MIPI DSI-2 Specification. > > > While the driver structure is very similar to the previous DSI controller, > the programming model of the core is quite different, with a completely > new register set. > > Another notable difference is that the phy interface is variable now too > in its width and some other settings. > I did more tests with different LVDS displays. I tested following configurations with DSI/LVDS bridge: - 1024x600@60.01 - 1024x768@60.02 - 1280x800@60.07 - 1366x768@60.06 All of them worked without issues, except 1366x768. With this resolution, video is blurry, and offset incorrectly to the left. There are also repeating errors on the console: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 In correct operation with other resolutions, there is no error. I am not sure if this is a problem in your series or rather in VOP2 driver. I tried to track down the problem, and it seems to be a generic issue when horizontal line width is not divisible by 4. Lowering line width to 1364px fixes the issue, but of course I have two vertical lines of black pixels on the right. I also made some tests with 720x1280 DSI display. Lowering horizontal line to 718px shows the same problem. With 720px and 716px it works correctly. Kind regards Daniel
Hi, On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > On 03.12.24 21:54, Heiko Stuebner wrote: > > This series adds a bridge and glue driver for the DSI2 controller found > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > > > > I did more tests with different LVDS displays. I tested following > configurations with DSI/LVDS bridge: > - 1024x600@60.01 > - 1024x768@60.02 > - 1280x800@60.07 > - 1366x768@60.06 > > All of them worked without issues, except 1366x768. > With this resolution, video is blurry, and offset incorrectly > to the left. There are also repeating errors on the console: > > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > > In correct operation with other resolutions, there is no error. > I am not sure if this is a problem in your series or rather in VOP2 > driver. On my PineTab2 I got similar messages about 2 weeks ago: rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp1 Preceding those, I got several panfrost related errors: panfrost fde60000.gpu: get clock failed -517 panfrost fde60000.gpu: clk init failed -517 platform fde60000.gpu: deferred probe pending: (reason unknown) platform cpufreq-dt: deferred probe pending: (reason unknown) vdd_gpu_npu: disabling But can also be that the PineTab2 (likely) needs regulator-always-on and regulator-boot-on in its vdd_gpu_npu node. > I tried to track down the problem, and it seems to be a generic issue > when horizontal line width is not divisible by 4. > Lowering line width to 1364px fixes the issue, but of course I have two > vertical lines of black pixels on the right. > I also made some tests with 720x1280 DSI display. Lowering horizontal > line to 718px shows the same problem. With 720px and 716px it works > correctly. I haven't look further into it, but the PT2 has a 1280x800 resolution. HTH, Diederik
Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > Hi, > > On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > > On 03.12.24 21:54, Heiko Stuebner wrote: > > > This series adds a bridge and glue driver for the DSI2 controller found > > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > > > > > > > I did more tests with different LVDS displays. I tested following > > configurations with DSI/LVDS bridge: > > - 1024x600@60.01 > > - 1024x768@60.02 > > - 1280x800@60.07 > > - 1366x768@60.06 > > > > All of them worked without issues, except 1366x768. > > With this resolution, video is blurry, and offset incorrectly > > to the left. There are also repeating errors on the console: > > > > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > > > > In correct operation with other resolutions, there is no error. > > I am not sure if this is a problem in your series or rather in VOP2 > > driver. This really sounds like something is wrong on the vop side. The interrupt is part of the vop, the divisable by 4 things likely too. Heiko > > On my PineTab2 I got similar messages about 2 weeks ago: > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp1 > > Preceding those, I got several panfrost related errors: > > panfrost fde60000.gpu: get clock failed -517 > panfrost fde60000.gpu: clk init failed -517 > platform fde60000.gpu: deferred probe pending: (reason unknown) > platform cpufreq-dt: deferred probe pending: (reason unknown) > vdd_gpu_npu: disabling > > But can also be that the PineTab2 (likely) needs regulator-always-on > and regulator-boot-on in its vdd_gpu_npu node. > > > I tried to track down the problem, and it seems to be a generic issue > > when horizontal line width is not divisible by 4. > > Lowering line width to 1364px fixes the issue, but of course I have two > > vertical lines of black pixels on the right. > > I also made some tests with 720x1280 DSI display. Lowering horizontal > > line to 718px shows the same problem. With 720px and 716px it works > > correctly. > > I haven't look further into it, but the PT2 has a 1280x800 resolution. > > HTH, > Diederik >
Hi, At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: >> Hi, >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: >> > On 03.12.24 21:54, Heiko Stuebner wrote: >> > > This series adds a bridge and glue driver for the DSI2 controller found >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. >> > > >> > >> > I did more tests with different LVDS displays. I tested following >> > configurations with DSI/LVDS bridge: >> > - 1024x600@60.01 >> > - 1024x768@60.02 >> > - 1280x800@60.07 >> > - 1366x768@60.06 >> > >> > All of them worked without issues, except 1366x768. >> > With this resolution, video is blurry, and offset incorrectly >> > to the left. There are also repeating errors on the console: >> > >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 >> > >> > In correct operation with other resolutions, there is no error. >> > I am not sure if this is a problem in your series or rather in VOP2 >> > driver. > >This really sounds like something is wrong on the vop side. >The interrupt is part of the vop, the divisable by 4 things likely too. This is a hardware limitation on vop side: The horizontal resolution must be 4 pixel aligned. > > >Heiko > > >> >> On my PineTab2 I got similar messages about 2 weeks ago: >> rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp1 >> >> Preceding those, I got several panfrost related errors: >> >> panfrost fde60000.gpu: get clock failed -517 >> panfrost fde60000.gpu: clk init failed -517 >> platform fde60000.gpu: deferred probe pending: (reason unknown) >> platform cpufreq-dt: deferred probe pending: (reason unknown) >> vdd_gpu_npu: disabling >> >> But can also be that the PineTab2 (likely) needs regulator-always-on >> and regulator-boot-on in its vdd_gpu_npu node. >> >> > I tried to track down the problem, and it seems to be a generic issue >> > when horizontal line width is not divisible by 4. >> > Lowering line width to 1364px fixes the issue, but of course I have two >> > vertical lines of black pixels on the right. >> > I also made some tests with 720x1280 DSI display. Lowering horizontal >> > line to 718px shows the same problem. With 720px and 716px it works >> > correctly. >> >> I haven't look further into it, but the PT2 has a 1280x800 resolution. >> >> HTH, >> Diederik >> > > >
On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: > > > Hi, > > At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: > >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > >> Hi, > >> > >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > >> > On 03.12.24 21:54, Heiko Stuebner wrote: > >> > > This series adds a bridge and glue driver for the DSI2 controller found > >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > >> > > > >> > > >> > I did more tests with different LVDS displays. I tested following > >> > configurations with DSI/LVDS bridge: > >> > - 1024x600@60.01 > >> > - 1024x768@60.02 > >> > - 1280x800@60.07 > >> > - 1366x768@60.06 > >> > > >> > All of them worked without issues, except 1366x768. > >> > With this resolution, video is blurry, and offset incorrectly > >> > to the left. There are also repeating errors on the console: > >> > > >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > >> > > >> > In correct operation with other resolutions, there is no error. > >> > I am not sure if this is a problem in your series or rather in VOP2 > >> > driver. > > > >This really sounds like something is wrong on the vop side. > >The interrupt is part of the vop, the divisable by 4 things likely too. > > This is a hardware limitation on vop side: > The horizontal resolution must be 4 pixel aligned. Then mode_valid() and atomic_check() must reject modes that don't fit. > > >
Hi Dmitry, 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: >> >> >> Hi, >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: >> >> Hi, >> >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: >> >> > > This series adds a bridge and glue driver for the DSI2 controller found >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. >> >> > > >> >> > >> >> > I did more tests with different LVDS displays. I tested following >> >> > configurations with DSI/LVDS bridge: >> >> > - 1024x600@60.01 >> >> > - 1024x768@60.02 >> >> > - 1280x800@60.07 >> >> > - 1366x768@60.06 >> >> > >> >> > All of them worked without issues, except 1366x768. >> >> > With this resolution, video is blurry, and offset incorrectly >> >> > to the left. There are also repeating errors on the console: >> >> > >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 >> >> > >> >> > In correct operation with other resolutions, there is no error. >> >> > I am not sure if this is a problem in your series or rather in VOP2 >> >> > driver. >> > >> >This really sounds like something is wrong on the vop side. >> >The interrupt is part of the vop, the divisable by 4 things likely too. >> >> This is a hardware limitation on vop side: >> The horizontal resolution must be 4 pixel aligned. > >Then mode_valid() and atomic_check() must reject modes that don't fit. We round down to 4 pixel aligned in mode_fixup in our bsp kernel, because sometimes, some boards do indeed choose a screen that is not 4 pixel aligned > >> >> >> > >-- >With best wishes >Dmitry
On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: > > > Hi Dmitry, > > 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: > >> > >> > >> Hi, > >> > >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: > >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > >> >> Hi, > >> >> > >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: > >> >> > > This series adds a bridge and glue driver for the DSI2 controller found > >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > >> >> > > > >> >> > > >> >> > I did more tests with different LVDS displays. I tested following > >> >> > configurations with DSI/LVDS bridge: > >> >> > - 1024x600@60.01 > >> >> > - 1024x768@60.02 > >> >> > - 1280x800@60.07 > >> >> > - 1366x768@60.06 > >> >> > > >> >> > All of them worked without issues, except 1366x768. > >> >> > With this resolution, video is blurry, and offset incorrectly > >> >> > to the left. There are also repeating errors on the console: > >> >> > > >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > >> >> > > >> >> > In correct operation with other resolutions, there is no error. > >> >> > I am not sure if this is a problem in your series or rather in VOP2 > >> >> > driver. > >> > > >> >This really sounds like something is wrong on the vop side. > >> >The interrupt is part of the vop, the divisable by 4 things likely too. > >> > >> This is a hardware limitation on vop side: > >> The horizontal resolution must be 4 pixel aligned. > > > >Then mode_valid() and atomic_check() must reject modes that don't fit. > > We round down to 4 pixel aligned in mode_fixup in our bsp kernel, What is meant by the "bsp kernel" here? I don't see it being present in the mainline kernel. So, if the mode is unsupported, it should be rejected. > because sometimes, some boards do indeed choose a screen that is not 4 pixel aligned > > > >> > >> > >> > > > >-- > >With best wishes > >Dmitry
Hi Dmitry, 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: >> >> >> Hi Dmitry, >> >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: >> >> >> >> >> >> Hi, >> >> >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: >> >> >> Hi, >> >> >> >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: >> >> >> > > This series adds a bridge and glue driver for the DSI2 controller found >> >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. >> >> >> > > >> >> >> > >> >> >> > I did more tests with different LVDS displays. I tested following >> >> >> > configurations with DSI/LVDS bridge: >> >> >> > - 1024x600@60.01 >> >> >> > - 1024x768@60.02 >> >> >> > - 1280x800@60.07 >> >> >> > - 1366x768@60.06 >> >> >> > >> >> >> > All of them worked without issues, except 1366x768. >> >> >> > With this resolution, video is blurry, and offset incorrectly >> >> >> > to the left. There are also repeating errors on the console: >> >> >> > >> >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 >> >> >> > >> >> >> > In correct operation with other resolutions, there is no error. >> >> >> > I am not sure if this is a problem in your series or rather in VOP2 >> >> >> > driver. >> >> > >> >> >This really sounds like something is wrong on the vop side. >> >> >The interrupt is part of the vop, the divisable by 4 things likely too. >> >> >> >> This is a hardware limitation on vop side: >> >> The horizontal resolution must be 4 pixel aligned. >> > >> >Then mode_valid() and atomic_check() must reject modes that don't fit. >> >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel, > >What is meant by the "bsp kernel" here? I don't see it being present bsp kernel means downstream vendor kernel. >in the mainline kernel. So, if the mode is unsupported, it should be Will it be acceptable to add this round down in the mainline mode_fixup? >rejected. > >> because sometimes, some boards do indeed choose a screen that is not 4 pixel aligned >> > >> >> >> >> >> >> >> > >> >-- >> >With best wishes >> >Dmitry > > > >-- >With best wishes >Dmitry
Am Dienstag, 10. Dezember 2024, 02:54:09 CET schrieb Andy Yan: > > Hi Dmitry, > > 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: > >> > >> > >> Hi Dmitry, > >> > >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: > >> >> > >> >> > >> >> Hi, > >> >> > >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: > >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > >> >> >> Hi, > >> >> >> > >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: > >> >> >> > > This series adds a bridge and glue driver for the DSI2 controller found > >> >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > >> >> >> > > > >> >> >> > > >> >> >> > I did more tests with different LVDS displays. I tested following > >> >> >> > configurations with DSI/LVDS bridge: > >> >> >> > - 1024x600@60.01 > >> >> >> > - 1024x768@60.02 > >> >> >> > - 1280x800@60.07 > >> >> >> > - 1366x768@60.06 > >> >> >> > > >> >> >> > All of them worked without issues, except 1366x768. > >> >> >> > With this resolution, video is blurry, and offset incorrectly > >> >> >> > to the left. There are also repeating errors on the console: > >> >> >> > > >> >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > >> >> >> > > >> >> >> > In correct operation with other resolutions, there is no error. > >> >> >> > I am not sure if this is a problem in your series or rather in VOP2 > >> >> >> > driver. > >> >> > > >> >> >This really sounds like something is wrong on the vop side. > >> >> >The interrupt is part of the vop, the divisable by 4 things likely too. > >> >> > >> >> This is a hardware limitation on vop side: > >> >> The horizontal resolution must be 4 pixel aligned. > >> > > >> >Then mode_valid() and atomic_check() must reject modes that don't fit. > >> > >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel, > > > >What is meant by the "bsp kernel" here? I don't see it being present > > bsp kernel means downstream vendor kernel. > > >in the mainline kernel. So, if the mode is unsupported, it should be > > Will it be acceptable to add this round down in the mainline mode_fixup? personally I'd like that. I.e. the thing in the examoke above is an LVDS display, so has essentially fixed resolution. So adapting the resolution may or may not be possible (some for DSI or whatever) . Doing that rounding-down AND emitting a dev_warn about that fact would be preferrable to me personally, though I don't know if there is some different precedent in other parts of DRM. Heiko
On Tue, Dec 10, 2024 at 09:54:09AM +0800, Andy Yan wrote: > > Hi Dmitry, > > 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: > >> > >> > >> Hi Dmitry, > >> > >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: > >> >> > >> >> > >> >> Hi, > >> >> > >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: > >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > >> >> >> Hi, > >> >> >> > >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: > >> >> >> > > This series adds a bridge and glue driver for the DSI2 controller found > >> >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. > >> >> >> > > > >> >> >> > > >> >> >> > I did more tests with different LVDS displays. I tested following > >> >> >> > configurations with DSI/LVDS bridge: > >> >> >> > - 1024x600@60.01 > >> >> >> > - 1024x768@60.02 > >> >> >> > - 1280x800@60.07 > >> >> >> > - 1366x768@60.06 > >> >> >> > > >> >> >> > All of them worked without issues, except 1366x768. > >> >> >> > With this resolution, video is blurry, and offset incorrectly > >> >> >> > to the left. There are also repeating errors on the console: > >> >> >> > > >> >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 > >> >> >> > > >> >> >> > In correct operation with other resolutions, there is no error. > >> >> >> > I am not sure if this is a problem in your series or rather in VOP2 > >> >> >> > driver. > >> >> > > >> >> >This really sounds like something is wrong on the vop side. > >> >> >The interrupt is part of the vop, the divisable by 4 things likely too. > >> >> > >> >> This is a hardware limitation on vop side: > >> >> The horizontal resolution must be 4 pixel aligned. > >> > > >> >Then mode_valid() and atomic_check() must reject modes that don't fit. > >> > >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel, > > > >What is meant by the "bsp kernel" here? I don't see it being present > > bsp kernel means downstream vendor kernel. > > >in the mainline kernel. So, if the mode is unsupported, it should be > > Will it be acceptable to add this round down in the mainline mode_fixup? I think so. > > >rejected. > > > >> because sometimes, some boards do indeed choose a screen that is not 4 pixel aligned
Hi All, 在 2024-12-10 20:32:03,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >On Tue, Dec 10, 2024 at 09:54:09AM +0800, Andy Yan wrote: >> >> Hi Dmitry, >> >> 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >> >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: >> >> >> >> >> >> Hi Dmitry, >> >> >> >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: >> >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: >> >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: >> >> >> >> Hi, >> >> >> >> >> >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: >> >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: >> >> >> >> > > This series adds a bridge and glue driver for the DSI2 controller found >> >> >> >> > > in the rk3588 soc from Rockchip, that is based on a Synopsis IP block. >> >> >> >> > > >> >> >> >> > >> >> >> >> > I did more tests with different LVDS displays. I tested following >> >> >> >> > configurations with DSI/LVDS bridge: >> >> >> >> > - 1024x600@60.01 >> >> >> >> > - 1024x768@60.02 >> >> >> >> > - 1280x800@60.07 >> >> >> >> > - 1366x768@60.06 >> >> >> >> > >> >> >> >> > All of them worked without issues, except 1366x768. >> >> >> >> > With this resolution, video is blurry, and offset incorrectly >> >> >> >> > to the left. There are also repeating errors on the console: >> >> >> >> > >> >> >> >> > rockchip-drm display-subsystem: [drm] *ERROR* POST_BUF_EMPTY irq err at vp3 >> >> >> >> > >> >> >> >> > In correct operation with other resolutions, there is no error. >> >> >> >> > I am not sure if this is a problem in your series or rather in VOP2 >> >> >> >> > driver. >> >> >> > >> >> >> >This really sounds like something is wrong on the vop side. >> >> >> >The interrupt is part of the vop, the divisable by 4 things likely too. >> >> >> >> >> >> This is a hardware limitation on vop side: >> >> >> The horizontal resolution must be 4 pixel aligned. >> >> > >> >> >Then mode_valid() and atomic_check() must reject modes that don't fit. >> >> >> >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel, >> > >> >What is meant by the "bsp kernel" here? I don't see it being present >> >> bsp kernel means downstream vendor kernel. >> >> >in the mainline kernel. So, if the mode is unsupported, it should be >> >> Will it be acceptable to add this round down in the mainline mode_fixup? > >I think so. Then I can write a patch for it. > >> >> >rejected. >> > >> >> because sometimes, some boards do indeed choose a screen that is not 4 pixel aligned > >-- >With best wishes >Dmitry
Hi Andy, Am Dienstag, 10. Dezember 2024, 13:48:12 CET schrieb Andy Yan: > 在 2024-12-10 20:32:03,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >On Tue, Dec 10, 2024 at 09:54:09AM +0800, Andy Yan wrote: > >> 在 2024-12-10 09:45:11,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >> >On Tue, 10 Dec 2024 at 03:22, Andy Yan <andyshrk@163.com> wrote: > >> >> 在 2024-12-10 09:01:38,"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org> 写道: > >> >> >On Tue, Dec 10, 2024 at 08:50:51AM +0800, Andy Yan wrote: > >> >> >> At 2024-12-10 07:12:26, "Heiko Stübner" <heiko@sntech.de> wrote: > >> >> >> >Am Montag, 9. Dezember 2024, 17:11:03 CET schrieb Diederik de Haas: > >> >> >> >> On Mon Dec 9, 2024 at 4:06 PM CET, Daniel Semkowicz wrote: > >> >> >> >> > On 03.12.24 21:54, Heiko Stuebner wrote: > >> >> >> >This really sounds like something is wrong on the vop side. > >> >> >> >The interrupt is part of the vop, the divisable by 4 things likely too. > >> >> >> > >> >> >> This is a hardware limitation on vop side: > >> >> >> The horizontal resolution must be 4 pixel aligned. > >> >> > > >> >> >Then mode_valid() and atomic_check() must reject modes that don't fit. > >> >> > >> >> We round down to 4 pixel aligned in mode_fixup in our bsp kernel, > >> > > >> >What is meant by the "bsp kernel" here? I don't see it being present > >> > >> bsp kernel means downstream vendor kernel. > >> > >> >in the mainline kernel. So, if the mode is unsupported, it should be > >> > >> Will it be acceptable to add this round down in the mainline mode_fixup? > > > >I think so. > > Then I can write a patch for it. thanks a lot for looking into that :-) Heiko