Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4361039ybl; Tue, 20 Aug 2019 10:42:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLhUIefuB+JaNOIcqZ2Gpz+pmBUtU4XWXdKVNlFcZxOM/rmlGPRtdyb0WFE0s7694rWObX X-Received: by 2002:a63:2b0c:: with SMTP id r12mr25669993pgr.206.1566322968304; Tue, 20 Aug 2019 10:42:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566322968; cv=none; d=google.com; s=arc-20160816; b=CdE/L6Ul9uVRN6fBdl3LRJeboTpyo4sc8j31nxaxG5GxixNLO7nOSNe7c7M/j+cVGm 337XGVT0XYT6NPEOPRgJjBSz5dSluLSdgtkL+nJpIjVqPbVJKKoBQPs3X6DL1T0XR6LR t+Jy08qIl02YtKyf+8btoSeuF7MXbixwWWQpzpcXGepr17mTJVqbTwyk5BfNzIacWNiw ynpkCTTilulKLxd0LjTAFy5yHeClakLgWxP8vqCAqjDVhRgMTK6Ti0MJIuz40XZJIYEH hdmBJenFC0k7FDDjWEEmNnYwuhBytuYem1tptrViFcEsYGsIs/2QEjtgJ2xLqhdNGAx8 iLZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CKQ+RxDnP00jk7zcwRffDth25lOIejq5EcK6dTP6kr4=; b=VqHGA24HxHSCCqRK0IDITQGSMoxqUlK5RVqRaR3HR6fcsCaC1SZCABgy6sMPBJDQDW zBEqqJpzlRnIwfQqc3EHbkRKjA4XUADNFx4d+8frbaqNVxiqOFBMcbnW0DZyL+SvWTbb BJZH4MGwX75Qo78FQrKFbNbRGI6QRZ0FsJCutMu4kN75gwqBXp7twT0rejn8nPCDB6lt Huzmco5dTYviqGerk2v9MufZu1kK+qnfa2qxXP+iw5gaRQZbHAIMGM981FNKkWmA0CWT 7WG3j3gu69SH1fVIuf1t4SgoMJKzHd/m89lym0Nzt5YUCK7WJzSCAig2OMRVmjYKr4aN FE+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b="oTJV/F9u"; 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 f1si12357220pgn.149.2019.08.20.10.42.33; Tue, 20 Aug 2019 10:42:48 -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="oTJV/F9u"; 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 S1730795AbfHTRld (ORCPT + 99 others); Tue, 20 Aug 2019 13:41:33 -0400 Received: from perceval.ideasonboard.com ([213.167.242.64]:42164 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730680AbfHTRlS (ORCPT ); Tue, 20 Aug 2019 13:41:18 -0400 Received: from pendragon.ideasonboard.com (dfj612yhrgyx302h3jwwy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:ce28:277f:58d7:3ca4]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 925D533D; Tue, 20 Aug 2019 19:41:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1566322876; bh=8TSAbOc99oaocNanYpIuNSjuJymG5rkFZtxYVVqu2wU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oTJV/F9uYWNZIyTdvp2beSi864kYUk09+Kil83mxRJqLnCUfKp6GLjFjFhe+0qzGK j1kpG8z5++Fhw2CUBIXfW/mSDmYrqPfUYpadGJVMau+4lBA6pj6N/V1xvjNsiENKFi XuoF6BLOH+sSnElD/PbT4xEU5K10CwPnYsKDQHMQ= Date: Tue, 20 Aug 2019 20:41:10 +0300 From: Laurent Pinchart To: Geert Uytterhoeven Cc: Jacopo Mondi , Jacopo Mondi , Kieran Bingham , David Airlie , Daniel Vetter , Koji Matsuoka , muroya@ksk.co.jp, VenkataRajesh.Kalakodima@in.bosch.com, Harsha.ManjulaMallikarjun@in.bosch.com, Linux-Renesas , DRI Development , Linux Kernel Mailing List Subject: Re: [PATCH v2 01/19] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation Message-ID: <20190820174110.GH10820@pendragon.ideasonboard.com> References: <20190706140746.29132-1-jacopo+renesas@jmondi.org> <20190706140746.29132-2-jacopo+renesas@jmondi.org> <20190820074826.5rdzeqyk6ylpjr7o@uno.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On Tue, Aug 20, 2019 at 09:53:44AM +0200, Geert Uytterhoeven wrote: > On Tue, Aug 20, 2019 at 9:47 AM Jacopo Mondi wrote: > > On Mon, Aug 19, 2019 at 03:45:54PM +0200, Geert Uytterhoeven wrote: > >> On Mon, Jul 8, 2019 at 9:58 AM Geert Uytterhoeven wrote: > >>> On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote: > >>>> Add device tree bindings documentation for the Renesas R-Car Display > >>>> Unit Color Management Module. > >>>> > >>>> CMM is the image enhancement module available on each R-Car DU video > >>>> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded). > >>>> > >>>> Signed-off-by: Jacopo Mondi > >>>> Reviewed-by: Laurent Pinchart > >>> > >>> Thanks for your patch! > >>> > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/display/renesas,cmm.txt > >>>> @@ -0,0 +1,25 @@ > >>>> +* Renesas R-Car Color Management Module (CMM) > >>>> + > >>>> +Renesas R-Car image enhancement module connected to R-Car DU video channels. > >>>> + > >>>> +Required properties: > >>>> + - compatible: shall be one of: > >>>> + - "renesas,rcar-gen3-cmm" > >>>> + - "renesas,rcar-gen2-cmm" > >>> > >>> Why do you think you do not need SoC-specific compatible values? > >>> What if you discover a different across the R-Car Gen3 line tomorrow? > >>> Does the IP block have a version register? > >> > >> Do you have an answer to these questions? > > > > It does not seem to me that CMM has any version register, nor there > > are differences between the different Gen3 SoCs.. > > > > However, even if we now define a single compatible property for > > gen3/gen2 and we later find out one of the SoC needs a soc-specific > > property we can safely add it and keep the generic gen3/gen2 one as > > fallback.. Does it work for you? > > Unfortunately that won't work, as the existing DTBs won't have the > soc-specific compatible value. > You could still resort to soc_device_match(), but it is better to avoid that. We've had the same discussion over and over for quite a long time :-) I wonder, now that we have implemented SoC-specific compatible values for many IP cores, how many of them have actually benefited from it ? I'm not considering IP cores where we knew from the start that each SoC was different (such as pinctrl or clocks for instance), but IP cores where we though all SoCs would be handled in the same way. I also wouldn't count ES-specific differences, as those are handled by soc_device_match() anyway. -- Regards, Laurent Pinchart