From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4C3FBECDFD0 for ; Fri, 14 Sep 2018 14:00:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED6192146E for ; Fri, 14 Sep 2018 14:00:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="OXrmVEoV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED6192146E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ideasonboard.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728089AbeINTPK (ORCPT ); Fri, 14 Sep 2018 15:15:10 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:36460 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727013AbeINTPK (ORCPT ); Fri, 14 Sep 2018 15:15:10 -0400 Received: from avalon.localnet (unknown [IPv6:2a02:a03f:44f6:3500:d929:375b:d608:66c7]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id D2C97CE; Fri, 14 Sep 2018 16:00:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1536933630; bh=R5FIxCn7qs28aGR7md6Iz7EejI3r0BllKliJsZ8pcFU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OXrmVEoVww3K2VQSuS4pprNbJNKUV89MXB9W+4n5zsDvuK22IVfDc76GgwqmT6V6y TubjJzXRHilTFo9E+w8Q4Lzre1OpR2dm7dWPoDIBQu48RgdzroDjPxpwsH+c87V9XN UQAxvbz40aJ04Mrnq6sJ+kiIOv3IFMz5WeJPdz7k= From: Laurent Pinchart To: kieran.bingham+renesas@ideasonboard.com Cc: David Airlie , dri-devel@lists.freedesktop.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm: rcar-du: Remove packed VYUY support Date: Fri, 14 Sep 2018 17:00:43 +0300 Message-ID: <2071986.YnXjGQr2Jv@avalon> Organization: Ideas on Board Oy In-Reply-To: <7d2740f2-923c-4b5d-0d1e-c24fb4a8bceb@ideasonboard.com> References: <20180914132149.26354-1-kieran.bingham+renesas@ideasonboard.com> <1759929.4apJ9N5u4E@avalon> <7d2740f2-923c-4b5d-0d1e-c24fb4a8bceb@ideasonboard.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kieran, On Friday, 14 September 2018 16:55:38 EEST Kieran Bingham wrote: > On 14/09/18 14:51, Laurent Pinchart wrote: > > On Friday, 14 September 2018 16:21:49 EEST Kieran Bingham wrote: > >> The Gen3 VSP used by the DU for display does not support packed the VYUY > >> pixel format. Gen2 VSP hardware is able to process this format, but it > >> is not officially supported there either and thus it's output can not be > >> guaranteed. > > > > I think we could guarantee proper operation on Gen2, but as DU + VSP > > operation isn't enabled in the drivers by default, and as the VYUY format > > isn't a strategic target, I think we can ignore that. > > > > How about updating the commit message as follows ? > > > > "The Gen3 VSP used by the DU for display does not support packed the VYUY > > s/packed the/the packed/ > > Which was a fault in my original text :) > > > pixel format. Gen2 VSP hardware is able to process this format, but DU + > > VSP operation isn't enabled on Gen2, and VYUY isn't a strategic format, > > so it can be ignored." > > That sounds fine to me, though I don't think we would even need to state > that 'VYUY isn't a strategic format' once it's simply not available on > the only platform that is enabled to use the VSP. But I don't object to > stating it otherwise. It could be enabled in the drivers (I have out-of-tree patches for testing purpose), so the fact that we don't need the format is still important I think. > >> Remove the format from the capabilities of the DU driver. > >> > >> Signed-off-by: Kieran Bingham > > > > Reviewed-by: Laurent Pinchart > > > >> --- > >> > >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > >> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4480243813ec..4576119e7777 > >> 100644 > >> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > >> @@ -126,7 +126,6 @@ static const u32 formats_kms[] = { > >> DRM_FORMAT_ARGB8888, > >> DRM_FORMAT_XRGB8888, > >> DRM_FORMAT_UYVY, > >> - DRM_FORMAT_VYUY, > >> DRM_FORMAT_YUYV, > >> DRM_FORMAT_YVYU, > >> DRM_FORMAT_NV12, > >> @@ -155,7 +154,6 @@ static const u32 formats_v4l2[] = { > >> V4L2_PIX_FMT_ABGR32, > >> V4L2_PIX_FMT_XBGR32, > >> V4L2_PIX_FMT_UYVY, > >> - V4L2_PIX_FMT_VYUY, > >> V4L2_PIX_FMT_YUYV, > >> V4L2_PIX_FMT_YVYU, > >> V4L2_PIX_FMT_NV12M, -- Regards, Laurent Pinchart