Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5950624ybp; Tue, 15 Oct 2019 07:27:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEKCULKxc3BUt4XW+1llrwOFKzv65QJ/+DUUPDgTT2VihKM0szqnY3x1LsRFeon5+YIvxp X-Received: by 2002:a17:906:19cf:: with SMTP id h15mr35554598ejd.184.1571149648681; Tue, 15 Oct 2019 07:27:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571149648; cv=none; d=google.com; s=arc-20160816; b=QKIGCIaRjPBCM/xq50w9j6whEStgdXzNdnwDiKRRlOQhsKony8wMlE1FJRbLS9xjau 7hiwgX2S0sR4HuVJmedNcm2x8oEZAAye19INhKI3gj244GFQc2u1NNiM7lR1xV2FOuub rL9WNU691n6tisfFSF17jTLpzsqh1UsKFNhsYnphN6rHVfQxH4ROW+7TFEMrw1kdarWB 7inry3VfIyeG3NppRZ/NimOlUMVn3eCkEOUXntUX1E8n0qmId6cu0L313YeTC1W20mkj 9uI0VEl84JApgZi9kSNQlKmOTVrTJzBlUGPxMrU92LYlQJDIzKjgxBfoefFJDiKhlrhJ Ibng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject:reply-to :dkim-signature; bh=9tXTwlFELrVofkNqVE0d61tX0ooEtZmvmRVGGVVOKu4=; b=qVY+pHEZsgsYI5SkLP6Au6yRG1VDgOxZGZLsPtX0nbijhk6ib5Sxe3UiHIX679YZUp y7mNRHsXw70Qu2EmAhDWQ+o5v4FfiqIwXHNt7JyN6vt/n+H7fgB//n72L0V4ti/YoUos g0Kd4m3SDuYTZrrYC4ztmh7p9RG49DSJIMjjE3rqMQ3BdxLKduyQ/YMmk7onMs/gXGJG rcNSuiCv2KEAJ4FVyTwU6ypWoimTwrmSS4XR/6RmbDHz+09EfKoh+T/Q9P6I3EU6WRoU FvLoGC4gclCpkj27YB5YgR0GMbkSGxspRasf0iaJ87XQ06vrx+QZ/z5pG4FlqsY//BxM yKjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=mEDe4FAh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j4si13504574edl.192.2019.10.15.07.27.03; Tue, 15 Oct 2019 07:27:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=mEDe4FAh; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732667AbfJOO0l (ORCPT + 99 others); Tue, 15 Oct 2019 10:26:41 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:55748 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732050AbfJOO0k (ORCPT ); Tue, 15 Oct 2019 10:26:40 -0400 Received: from [192.168.0.20] (cpc89242-aztw30-2-0-cust488.18-1.cable.virginm.net [86.31.129.233]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 6066B324; Tue, 15 Oct 2019 16:26:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1571149598; bh=hSdNGSSn5zc6mkejUmeqIoT8CVOAQ/twmh0YdLHeH+o=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mEDe4FAheoUDNwti7vv8FKUNaowQCfW1YFt/S+SvDJtxZOPsbMHfBKWw3G+DMAI01 rpFSW2xzRslhHapJtvtGno4nMPinthakiNafukrcXzCkhp65xy2pph3khkkI+rJgS5 t0nzccfeMmxoU7me05bt9PnE4edElreGkhEmqRaw= Reply-To: kieran.bingham+renesas@ideasonboard.com Subject: Re: [PATCH v5 3/8] drm: rcar-du: Add support for CMM To: Jacopo Mondi Cc: Jacopo Mondi , laurent.pinchart@ideasonboard.com, geert@linux-m68k.org, horms@verge.net.au, uli+renesas@fpond.eu, VenkataRajesh.Kalakodima@in.bosch.com, airlied@linux.ie, daniel@ffwll.ch, koji.matsuoka.xm@renesas.com, muroya@ksk.co.jp, Harsha.ManjulaMallikarjun@in.bosch.com, ezequiel@collabora.com, seanpaul@chromium.org, linux-renesas-soc@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20191015104621.62514-1-jacopo+renesas@jmondi.org> <20191015104621.62514-4-jacopo+renesas@jmondi.org> <2aefe646-45db-aafa-b22b-e1cf9616259d@ideasonboard.com> <20191015133320.uj4y5twxfkyopqi5@uno.localdomain> From: Kieran Bingham Organization: Ideas on Board Message-ID: <2e6e5e8d-e502-5957-5708-4e4d7ef84d8e@ideasonboard.com> Date: Tue, 15 Oct 2019 15:26:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191015133320.uj4y5twxfkyopqi5@uno.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/10/2019 14:33, Jacopo Mondi wrote: > Hi Kieran, thanks for review >>> +config DRM_RCAR_CMM >>> + bool "R-Car DU Color Management Module (CMM) Support" >>> + depends on DRM && OF >>> + depends on DRM_RCAR_DU >> >> >> DRM_RCAR_DU already depends on both DRM && OF, so I wonder if those are >> needed to be specified explicitly. >> >> Doesn't hurt of course, but I see DRM_RCAR_DW_HDMI does the same, and so >> does DRM_RCAR_LVDS, so I don't think you need to remove it. >> > > I did the same as it is done for HDMI and LVDS here. The extra > dependencies could be dropped yes, I chose to be consistent. Consistent is fine with me. >>> +struct rcar_cmm { >>> + void __iomem *base; >>> + >>> + /* >>> + * @lut: 1D-LUT status >>> + * @lut.enabled: 1D-LUT enabled flag >>> + */ >>> + struct { >>> + bool enabled; >>> + } lut; >> >> This used to be a more complex structure in an earlier version storing a >> cached version of the table. Now that the cached entry is removed, does >> this need to be such a complex structure rather than just say, a bool >> lut_enabled? >> >> (We will soon add an equivalent clu_enabled too, but I don't know what >> other per-table options we'll need.) >> >> In fact, we'll potentially have other options specific to the HGO, and >> CSC at some point in the future - so grouping by entity is indeed a good >> thing IMO. > > You are right, I pondered a bit it this was worth it, but I assume the > other CMM functions would have required some more complex fields so I > chose to keep it separate. I have no problem to make this a > lut_enabled, but I fear as soon as we support say, double buffering > for the lut, having a dedicated struct would be nice. > > Is it ok if I keep this the way it is? Certainly fine for me. (That's what I tried to imply with "so grouping by entity is indeed a good thing IMO.") -- Kieran