All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Daniele Castagna <dcastagna@chromium.org>,
	dri-devel@lists.freedesktop.org, Tomasz Figa <tfiga@chromium.org>,
	linux-rockchip@lists.infradead.org,
	Sean Paul <seanpaul@chromium.org>,
	kernel@collabora.com
Subject: Re: [PATCH v2] drm/rockchip: Fix YUV buffers color rendering
Date: Mon, 07 Jan 2019 14:26:03 +0100	[thread overview]
Message-ID: <3215325.nePTtMV2FM@phil> (raw)
In-Reply-To: <20181214162920.20361-1-ezequiel@collabora.com>

Hi,

sorry, only now got to test this on actual hardware,

Am Freitag, 14. Dezember 2018, 17:29:20 CET schrieb Ezequiel Garcia:
> From: Daniele Castagna <dcastagna@chromium.org>
> 
> Currently, YUV hardware overlays are converted to RGB using
> a color space conversion different than BT.601.
> 
> The result is that colors of e.g. NV12 buffers don't match
> colors of YUV hardware overlays.
> 
> In order to fix this, enable YUV2YUV and set appropriate coefficients
> for formats such as NV12 to be displayed correctly.
> 
> This commit was tested using modetest, gstreamer and chromeos (hardware
> accelerated video playback). Before the commit, tests rendering
> with NV12 format resulted in colors not displayed correctly.
> 
> Test examples (RK3399 Ficus board connected to HDMI monitor):
> 
>   $ modetest 39@32:1920x1080@NV12
>   $ gst-launch-1.0 videotestrc ! video/x-raw,format=NV12 ! kmssink
> 
> Signed-off-by: Daniele Castagna <dcastagna@chromium.org>
> [ezequiel: rebase on linux-next and massage commit log]
> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
> ---
> v2:
>   * Addressed feedback from Sean Paul
>   * Rebased on linux-next
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 41 ++++++++++++++++++++-
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 13 +++++++
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 36 ++++++++++++++++++
>  3 files changed, 89 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb70fb486fbf..78c7f63a60c0 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -52,6 +52,18 @@
>  		vop_reg_set(vop, &win->phy->scl->ext->name, \
>  			    win->base, ~0, v, #name)
>  
> +#define VOP_WIN_YUV2YUV_SET(x, win_yuv2yuv, name, v) \
> +	do { \
> +		if (win_yuv2yuv->name.mask) \
> +			vop_reg_set(vop, &win_yuv2yuv->name, 0, ~0, v, #name); \
> +	} while (0)
> +
> +#define VOP_WIN_YUV2YUV_COEFFICIENT_SET(x, win_yuv2yuv, name, v) \
> +	do { \
> +		if (win_yuv2yuv->phy->name.mask) \
> +			vop_reg_set(vop, &win_yuv2yuv->phy->name, win_yuv2yuv->base, ~0, v, #name); \
> +	} while (0)
> +

While this seems to work on rk3399, it hangs both my rk3328 (rock64)
and rk3288 (google-pinky) during rockchip-drm probe.

Making this something like

	if (win_yuv2yuv && win_yuv2yuv->phy->name.mask) \

aka testing for existence of win_yuv2yuv first, makes them boot again,
so I guess I ran into a (for whatever reason) silent null-ptr-dereference.


> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 08fc40af52c8..fe752df4e038 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -637,6 +637,34 @@ static const struct vop_output rk3399_output = {
>  	.mipi_dual_channel_en = VOP_REG(RK3288_SYS_CTRL, 0x1, 3),
>  };
>  
> +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win01_data = {
> +	.y2r_coefficients = {
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0xffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 0, 0xffff, 16),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0xffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 4, 0xffff, 16),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0xffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 8, 0xffff, 16),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0xffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 12, 0xffff, 16),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 16, 0xffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 20, 0xffffffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 24, 0xffffffff, 0),
> +		VOP_REG(RK3399_WIN0_YUV2YUV_Y2R + 28, 0xffffffff, 0),
> +	},
> +};
> +
> +static const struct vop_yuv2yuv_phy rk3399_yuv2yuv_win23_data = { };

looking at the rk3399 TRM it seems that win2+3 also have yuv2rgb
coefficient registers. I didn't check in depth but are they so different
that they cannot be supported?

Aka what is the difference between win0/1 and win2/3 ?


Heiko


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2019-01-07 13:26 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15  5:32 [PATCH 00/10] drm: Add plane color matrix on rockchip Daniele Castagna
2018-02-15  5:32 ` [PATCH 01/10] drm/rockchip: YUV overlays BT.601 color conversion Daniele Castagna
2018-02-16 17:55   ` kbuild test robot
2018-02-27 15:03   ` Sean Paul
2018-12-14 16:29   ` [PATCH v2] drm/rockchip: Fix YUV buffers color rendering Ezequiel Garcia
2019-01-03 16:28     ` Ezequiel Garcia
2019-01-07 13:26     ` Heiko Stuebner [this message]
2019-01-07 20:07       ` Ezequiel Garcia
2019-01-08 17:17         ` Ezequiel Garcia
2019-01-08 21:46     ` [PATCH v3] " Ezequiel Garcia
2019-01-10 22:55       ` Heiko Stuebner
2018-02-15  5:32 ` [PATCH 02/10] drm: Add Plane Degamma properties Daniele Castagna
2018-02-16 19:38   ` kbuild test robot
2018-02-19 15:15   ` Daniel Vetter
2018-02-27 15:13   ` Sean Paul
2018-02-28 14:54     ` Shankar, Uma
2018-02-15  5:32 ` [PATCH 03/10] drm: Add Plane CTM property Daniele Castagna
2018-02-27 15:22   ` Sean Paul
2018-02-28 14:55     ` Shankar, Uma
2018-02-15  5:32 ` [PATCH 04/10] drm: Add Plane Gamma properties Daniele Castagna
2018-02-15 19:29   ` Harry Wentland
2018-02-15 19:45     ` Daniele Castagna
2018-02-16 20:10       ` Ville Syrjälä
2018-02-16 21:36         ` Harry Wentland
2018-02-18  6:43           ` Shankar, Uma
2018-02-19 15:14   ` Daniel Vetter
2018-02-27 15:26   ` Sean Paul
2018-02-27 16:52     ` Ville Syrjälä
2018-02-15  5:32 ` [PATCH 05/10] drm: Define helper function for plane color enabling Daniele Castagna
2018-02-27 15:28   ` Sean Paul
2018-02-28 14:57     ` Shankar, Uma
2018-02-15  5:32 ` [PATCH 06/10] drm: Define helper to set legacy gamma table size Daniele Castagna
2018-02-16 22:17   ` kbuild test robot
2018-02-27 15:35   ` Sean Paul
2018-02-27 16:20   ` Emil Velikov
2018-02-15  5:32 ` [PATCH 07/10] drm/rockchip: Add yuv2yuv registers to vop_lit Daniele Castagna
2018-02-27 15:36   ` Sean Paul
2018-02-15  5:32 ` [PATCH 08/10] drm/rockchip: Add R2R registers Daniele Castagna
2018-02-27 15:41   ` Sean Paul
2018-02-15  5:32 ` [PATCH 09/10] drm/rockchip: Implement drm plane->ctm property Daniele Castagna
2018-02-27 16:09   ` Sean Paul
2018-02-15  5:33 ` [PATCH 10/10] drm/rockchip: Enable 'PLANE_CTM' drm property Daniele Castagna
2018-02-27 16:10   ` Sean Paul
2018-02-19 15:16 ` [PATCH 00/10] drm: Add plane color matrix on rockchip Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3215325.nePTtMV2FM@phil \
    --to=heiko@sntech.de \
    --cc=dcastagna@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ezequiel@collabora.com \
    --cc=kernel@collabora.com \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=seanpaul@chromium.org \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.