mbox series

[v3,00/22] drm/rockchip: RK356x VOP2 support

Message ID 20211220110630.3521121-1-s.hauer@pengutronix.de (mailing list archive)
Headers show
Series drm/rockchip: RK356x VOP2 support | expand

Message

Sascha Hauer Dec. 20, 2021, 11:06 a.m. UTC
Third round of patches and last one for this year. I hopefully integrated
all review feedback. Additionally the driver is now fully converted to
regmap, so no struct vop_reg necessary anymore.

Sascha

Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion

Changes since v1:
- drop all unnecessary waiting for frames within atomic modeset and plane update
- Cluster subwin support removed
- gamma support removed
- unnecessary irq_lock removed
- interrupt handling simplified
- simplified zpos handling
- drop is_alpha_support(), use fb->format->has_alpha instead
- use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi regulators
- Use fixed number of planes per video port
- Drop homegrown regmap code from vop2 driver (not complete yet)
- Add separate include file for vop2 driver to not pollute the vop include

Andy Yan (1):
  drm: rockchip: Add VOP2 driver

Benjamin Gaignard (1):
  dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568
    HDMI

Michael Riesch (1):
  arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

Sascha Hauer (19):
  drm/rockchip: dw_hdmi: Do not leave clock enabled in error case
  drm/rockchip: dw_hdmi: rename vpll clock to reference clock
  drm/rockchip: dw_hdmi: add rk3568 support
  drm/rockchip: dw_hdmi: add regulator support
  drm/rockchip: dw_hdmi: Add support for hclk
  dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
  dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
  dt-bindings: display: rockchip: dw-hdmi: Add regulator support
  dt-bindings: display: rockchip: dw-hdmi: Add additional clock
  dt-bindings: display: rockchip: Add binding for VOP2
  arm64: dts: rockchip: rk3399: reorder hmdi clocks
  arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
  arm64: dts: rockchip: rk356x: Add VOP2 nodes
  arm64: dts: rockchip: rk356x: Add HDMI nodes
  arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
  clk: rk3568: drop CLK_SET_RATE_PARENT from dclk_vop*
  clk: rk3568: Add CLK_SET_RATE_PARENT to the HDMI reference clock
  drm/encoder: Add of_graph port to struct drm_encoder
  drm/rockchip: Make VOP driver optional

 .../display/rockchip/rockchip,dw-hdmi.yaml    |   28 +-
 .../display/rockchip/rockchip-vop2.yaml       |  146 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi      |    6 +-
 .../boot/dts/rockchip/rk3566-quartz64-a.dts   |   48 +
 arch/arm64/boot/dts/rockchip/rk3566.dtsi      |    4 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts     |   48 +
 arch/arm64/boot/dts/rockchip/rk3568.dtsi      |    4 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   85 +
 drivers/clk/rockchip/clk-rk3568.c             |    8 +-
 drivers/gpu/drm/rockchip/Kconfig              |   14 +
 drivers/gpu/drm/rockchip/Makefile             |    4 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c   |  125 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |    3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |    7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c    |    2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   15 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 2768 +++++++++++++++++
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h  |  480 +++
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c  |  285 ++
 include/drm/drm_encoder.h                     |    2 +
 include/dt-bindings/soc/rockchip,vop2.h       |   14 +
 21 files changed, 4063 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
 create mode 100644 include/dt-bindings/soc/rockchip,vop2.h

Comments

Nicolas Frattaroli Dec. 20, 2021, 11:51 a.m. UTC | #1
On Montag, 20. Dezember 2021 12:06:08 CET Sascha Hauer wrote:
> 
> Third round of patches and last one for this year. I hopefully integrated
> all review feedback. Additionally the driver is now fully converted to
> regmap, so no struct vop_reg necessary anymore.
> 
> Sascha
> 
> Changes since v2:
> - Add pin names to HDMI supply pin description
> - Add hclk support to HDMI driver
> - Dual license rockchip-vop2 binding, update binding
> - Add HDMI connector to board dts files
> - drop unnecessary gamma_lut registers from vop2
> - Update dclk_vop[012] clock handling, no longer hacks needed
> - Complete regmap conversion

Hi Sascha,

for future reference, you can add `-v 3` to your git format-patch
command line to mark the whole patch series as PATCH v3 and not
just the cover letter.

Thanks for your continued work on this,
Nicolas Frattaroli
Piotr Oniszczuk Jan. 19, 2022, 11:29 a.m. UTC | #2
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 20.12.2021, o godz. 12:06:
> 
> 
> Third round of patches and last one for this year. I hopefully integrated
> all review feedback. Additionally the driver is now fully converted to
> regmap, so no struct vop_reg necessary anymore.
> 
> Sascha
> 
> Changes since v2:
> - Add pin names to HDMI supply pin description
> - Add hclk support to HDMI driver
> - Dual license rockchip-vop2 binding, update binding
> - Add HDMI connector to board dts files
> - drop unnecessary gamma_lut registers from vop2
> - Update dclk_vop[012] clock handling, no longer hacks needed
> - Complete regmap conversion
> 

Sascha

I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.

I have just few questions:

1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?

2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
I have issue however with app. rendering to DRM planes (GUI is DRM plane1, video is DRM pane2). 
My ppp starts/works without any errors in log - but screen stays with kernel messages content.
(it looks to me like i.e. app renders to DRM plane but DRM display driver not pass it to CRTC. just wild guess here...).

3. in kernel dmesg I have many:

"rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".

It comes from MESA i think - but i suspect because VOP2 provides unknown/wrong DRM modifier to mesa?.
I'm not sure how to progress with this (talk to you or involve MESA devs or wait for VOP2 v4)?

Again: great work with VOP2 on rk356x!
Sascha Hauer Jan. 21, 2022, 10:32 a.m. UTC | #3
Hi Piotr,

On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
> 
> 
> > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 20.12.2021, o godz. 12:06:
> > 
> > 
> > Third round of patches and last one for this year. I hopefully integrated
> > all review feedback. Additionally the driver is now fully converted to
> > regmap, so no struct vop_reg necessary anymore.
> > 
> > Sascha
> > 
> > Changes since v2:
> > - Add pin names to HDMI supply pin description
> > - Add hclk support to HDMI driver
> > - Dual license rockchip-vop2 binding, update binding
> > - Add HDMI connector to board dts files
> > - drop unnecessary gamma_lut registers from vop2
> > - Update dclk_vop[012] clock handling, no longer hacks needed
> > - Complete regmap conversion
> > 
> 
> Sascha
> 
> I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
> 
> I have just few questions:
> 
> 1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?

I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.

> 
> 2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
> I have issue however with app. rendering to DRM planes (GUI is DRM plane1, video is DRM pane2). 
> My ppp starts/works without any errors in log - but screen stays with kernel messages content.
> (it looks to me like i.e. app renders to DRM plane but DRM display driver not pass it to CRTC. just wild guess here...).

You enabled the panfrost driver with other patches, right?

> 
> 3. in kernel dmesg I have many:
> 
> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".

This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl.  By default this uses DRM_FORMAT_XRGB8888
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA. In
panfrost_afbc_format() we have:

        /* Don't allow swizzled formats on v7 */
        switch (format) {
        case PIPE_FORMAT_B8G8R8A8_UNORM:
        case PIPE_FORMAT_B8G8R8X8_UNORM:
        case PIPE_FORMAT_A8R8G8B8_UNORM:
        case PIPE_FORMAT_X8R8G8B8_UNORM:
        case PIPE_FORMAT_X8B8G8R8_UNORM:
        case PIPE_FORMAT_A8B8G8R8_UNORM:
        case PIPE_FORMAT_B8G8R8_UNORM:
        case PIPE_FORMAT_B5G6R5_UNORM:
                if (dev->arch >= 7)
                        return PIPE_FORMAT_NONE;

                break;
        default:
                break;
        }

This means the driver won't do AFBC with that format and picks
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED instead. Now weston is
clever enough to not pass that into the VOP2 driver, apparently your
application is not and as a result you see that message.

In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.

> 
> It comes from MESA i think - but i suspect because VOP2 provides
> unknown/wrong DRM modifier to mesa?

Nope, the modifiers the VOP2 driver propagates are correct. It doesn't
claim to support DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED.

Sascha
Piotr Oniszczuk Jan. 21, 2022, 3:43 p.m. UTC | #4
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 21.01.2022, o godz. 11:32:
> 
>> 
>> 1. how support for CEC looks/prospects (plans for future, not in this code, expecting others should implement, etc)?
> 
> I had to google what CEC actually is. We don't have plans supporting it.
> It looks like this is a matter of the HDMI driver supporting this and
> not bound to the rockchip driver.

Ah ok. sure. got it!
(I asked as Rockchip hdmi driver already well supports CEC - so i was thinking on rk3566 this is more of enabling than writing support code).

> You enabled the panfrost driver with other patches, right?

Oh - i wasn't aware any patches are needed for Mesa for rk3566....
If so - may you pls point me for latest/correct patches for rk3566? 

> 
>> 
>> 3. in kernel dmesg I have many:
>> 
>> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier 0x810000000000001".
> 
> This message is correct. This corresponds to
> DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
> support this. I have a similar problem here with
> weston-simple-dmabuf-egl.  By default this uses DRM_FORMAT_XRGB8888
> which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA.

Ah ok. Clear now.

Thx!

btw: i added support for argb8888 in my app and now all is ok. 
no anymore errors in dmesg :-)

so summarising:
your vop2 code works for me in all supported video pipeline variants:

-x11/Glamour
-Wayland-EGL
-EGLFS/EGL-dmabuf
-EGLFS/DRM Planes 

Your vop2 work is impressive!

btw:
you mention:

> In weston-simple-dmabuf-egl I can pass a suitable format on the command
> line, in my case I use DRM_FORMAT_ABGR8888 (which becomes
> PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
> which then can be rendered in the VOP2 cluster window overlay.

is this mean that: when my app is using ARGB8888 format - then I have AFBC on rk3566?