mbox series

[v3,0/3] drm/rockchip: Add driver for the new DSI2 controller

Message ID 20241203165450.1501219-1-heiko@sntech.de (mailing list archive)
Headers show
Series drm/rockchip: Add driver for the new DSI2 controller | expand

Message

Heiko Stuebner Dec. 3, 2024, 4:54 p.m. UTC
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.

changes in v3:
- remove double-empty line in bridge part (Neil)
- add bitfield.h to both bridge and glue for FIELD_PROP
  (reported by kernel test robot)
- add Neil's Reviewed-by to bridge part
- add Rob's Reviewed-by to binding

changes in v2:
- clean up includes (Diederik)
- fix Kconfig description (Diederik)
- constant naming (Diederik)
- binding fixes (paths, sorting, labels) (Rob)
- move to use regmap
- drop custom UPDATE macro and use FIELD_PREP instead
- use dev_err instead of DRM_DEV_ERROR

Heiko Stuebner (3):
  drm/bridge/synopsys: Add MIPI DSI2 host controller bridge
  dt-bindings: display: rockchip: Add schema for RK3588 DW DSI2
    controller
  drm/rockchip: Add MIPI DSI2 glue driver for RK3588

 .../rockchip/rockchip,rk3588-mipi-dsi2.yaml   |  119 ++
 drivers/gpu/drm/bridge/synopsys/Kconfig       |    6 +
 drivers/gpu/drm/bridge/synopsys/Makefile      |    1 +
 .../gpu/drm/bridge/synopsys/dw-mipi-dsi2.c    | 1030 +++++++++++++++++
 drivers/gpu/drm/rockchip/Kconfig              |   10 +
 drivers/gpu/drm/rockchip/Makefile             |    1 +
 .../gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c  |  524 +++++++++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |    2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |    1 +
 include/drm/bridge/dw_mipi_dsi2.h             |   95 ++
 10 files changed, 1789 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-mipi-dsi2.yaml
 create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi2.h

Comments

Dmitry Yashin Dec. 5, 2024, 9:06 a.m. UTC | #1
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>
Daniel Semkowicz Dec. 9, 2024, 3:06 p.m. UTC | #2
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
Diederik de Haas Dec. 9, 2024, 4:11 p.m. UTC | #3
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
Heiko Stuebner Dec. 9, 2024, 11:12 p.m. UTC | #4
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
>
Andy Yan Dec. 10, 2024, 12:50 a.m. UTC | #5
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
>> 
>
>
>
Dmitry Baryshkov Dec. 10, 2024, 1:01 a.m. UTC | #6
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.

> 
> 
>
Andy Yan Dec. 10, 2024, 1:21 a.m. UTC | #7
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
Dmitry Baryshkov Dec. 10, 2024, 1:45 a.m. UTC | #8
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
Andy Yan Dec. 10, 2024, 1:54 a.m. UTC | #9
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
Heiko Stuebner Dec. 10, 2024, 10:01 a.m. UTC | #10
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
Dmitry Baryshkov Dec. 10, 2024, 12:32 p.m. UTC | #11
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
Andy Yan Dec. 10, 2024, 12:48 p.m. UTC | #12
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
Heiko Stuebner Dec. 10, 2024, 2:36 p.m. UTC | #13
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