From patchwork Tue Feb 21 19:20:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thibault Saunier X-Patchwork-Id: 9585431 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AF924602A7 for ; Tue, 21 Feb 2017 19:22:10 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A27B02847E for ; Tue, 21 Feb 2017 19:22:10 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9779F285CA; Tue, 21 Feb 2017 19:22:10 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BEE42847E for ; Tue, 21 Feb 2017 19:22:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754415AbdBUTVa (ORCPT ); Tue, 21 Feb 2017 14:21:30 -0500 Received: from ec2-52-27-115-49.us-west-2.compute.amazonaws.com ([52.27.115.49]:40847 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932144AbdBUTVX (ORCPT ); Tue, 21 Feb 2017 14:21:23 -0500 Received: from localhost (localhost [127.0.0.1]) by osg.samsung.com (Postfix) with ESMTP id 8F92FA1311; Tue, 21 Feb 2017 19:21:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osg.samsung.com Received: from osg.samsung.com ([127.0.0.1]) by localhost (s-opensource.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJkNGvt2JZgu; Tue, 21 Feb 2017 19:21:42 +0000 (UTC) Received: from localhost.localdomain (pc-157-76-104-200.cm.vtr.net [200.104.76.157]) by osg.samsung.com (Postfix) with ESMTPSA id 93361A12FC; Tue, 21 Feb 2017 19:21:38 +0000 (UTC) From: Thibault Saunier To: linux-kernel@vger.kernel.org Cc: Mauro Carvalho Chehab , Marek Szyprowski , Kukjin Kim , Mauro Carvalho Chehab , Nicolas Dufresne , Andi Shyti , linux-media@vger.kernel.org, Shuah Khan , Javier Martinez Canillas , linux-samsung-soc@vger.kernel.org, Krzysztof Kozlowski , Inki Dae , Sylwester Nawrocki , Thibault Saunier , linux-arm-kernel@lists.infradead.org, Ulf Hansson , Hans Verkuil Subject: [PATCH v5 1/3] [media] exynos-gsc: Use user configured colorspace if provided Date: Tue, 21 Feb 2017 16:20:57 -0300 Message-Id: <20170221192059.29745-2-thibault.saunier@osg.samsung.com> X-Mailer: git-send-email 2.11.1 In-Reply-To: <20170221192059.29745-1-thibault.saunier@osg.samsung.com> References: <20170221192059.29745-1-thibault.saunier@osg.samsung.com> Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Use colorspace provided by the user as we are only doing scaling and color encoding conversion, we won't be able to transform the colorspace itself and the colorspace won't mater in that operation. Also always use output colorspace on the capture side. Start using 576p as a threashold to compute the colorspace. The media documentation says that the V4L2_COLORSPACE_SMPTE170M colorspace should be used for SDTV and V4L2_COLORSPACE_REC709 for HDTV. But drivers don't agree on the display resolution that should be used as a threshold. From EIA CEA 861B about colorimetry for various resolutions: - 5.1 480p, 480i, 576p, 576i, 240p, and 288p The color space used by the 480-line, 576-line, 240-line, and 288-line formats will likely be based on SMPTE 170M [1]. - 5.2 1080i, 1080p, and 720p The color space used by the high definition formats will likely be based on ITU-R BT.709-4 This indicates that in the case that userspace does not specify what colorspace should be used, we should use 576p as a threshold to set V4L2_COLORSPACE_REC709 instead of V4L2_COLORSPACE_SMPTE170M. Even if it is only 'likely' and not a requirement it is the best guess we can make. The stream should have been encoded with the information and userspace has to pass it to the driver if it is not the case, otherwise we won't be able to handle it properly anyhow. Also, check for the resolution in G_FMT instead unconditionally setting the V4L2_COLORSPACE_REC709 colorspace. Signed-off-by: Javier Martinez Canillas Signed-off-by: Thibault Saunier Reviewed-by: Andrzej Hajda --- Changes in v5: - Squash commit to always use output colorspace on the capture side inside this one - Fix typo in commit message Changes in v4: - Reword commit message to better back our assumptions on specifications Changes in v3: - Do not check values in the g_fmt functions as Andrzej explained in previous review - Added 'Reviewed-by: Andrzej Hajda ' Changes in v2: None drivers/media/platform/exynos-gsc/gsc-core.c | 20 +++++++++++++++----- drivers/media/platform/exynos-gsc/gsc-core.h | 1 + 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c b/drivers/media/platform/exynos-gsc/gsc-core.c index 59a634201830..772599de8c13 100644 --- a/drivers/media/platform/exynos-gsc/gsc-core.c +++ b/drivers/media/platform/exynos-gsc/gsc-core.c @@ -454,6 +454,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f) } else { min_w = variant->pix_min->target_rot_dis_w; min_h = variant->pix_min->target_rot_dis_h; + pix_mp->colorspace = ctx->out_colorspace; } pr_debug("mod_x: %d, mod_y: %d, max_w: %d, max_h = %d", @@ -472,10 +473,15 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f) pix_mp->num_planes = fmt->num_planes; - if (pix_mp->width >= 1280) /* HD */ - pix_mp->colorspace = V4L2_COLORSPACE_REC709; - else /* SD */ - pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M; + if (pix_mp->colorspace == V4L2_COLORSPACE_DEFAULT) { + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */ + pix_mp->colorspace = V4L2_COLORSPACE_REC709; + else /* SD */ + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M; + } + + if (V4L2_TYPE_IS_OUTPUT(f->type)) + ctx->out_colorspace = pix_mp->colorspace; for (i = 0; i < pix_mp->num_planes; ++i) { struct v4l2_plane_pix_format *plane_fmt = &pix_mp->plane_fmt[i]; @@ -519,9 +525,13 @@ int gsc_g_fmt_mplane(struct gsc_ctx *ctx, struct v4l2_format *f) pix_mp->height = frame->f_height; pix_mp->field = V4L2_FIELD_NONE; pix_mp->pixelformat = frame->fmt->pixelformat; - pix_mp->colorspace = V4L2_COLORSPACE_REC709; pix_mp->num_planes = frame->fmt->num_planes; + if (pix_mp->width > 720 && pix_mp->height > 576) /* HD */ + pix_mp->colorspace = V4L2_COLORSPACE_REC709; + else /* SD */ + pix_mp->colorspace = V4L2_COLORSPACE_SMPTE170M; + for (i = 0; i < pix_mp->num_planes; ++i) { pix_mp->plane_fmt[i].bytesperline = (frame->f_width * frame->fmt->depth[i]) / 8; diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h b/drivers/media/platform/exynos-gsc/gsc-core.h index 696217e9af66..715d9c9d8d30 100644 --- a/drivers/media/platform/exynos-gsc/gsc-core.h +++ b/drivers/media/platform/exynos-gsc/gsc-core.h @@ -376,6 +376,7 @@ struct gsc_ctx { struct v4l2_ctrl_handler ctrl_handler; struct gsc_ctrls gsc_ctrls; bool ctrls_rdy; + enum v4l2_colorspace out_colorspace; }; void gsc_set_prefbuf(struct gsc_dev *gsc, struct gsc_frame *frm);