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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 4D412C4363A for ; Wed, 21 Oct 2020 21:42:20 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B2F9A223C7 for ; Wed, 21 Oct 2020 21:42:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BWdu2Txo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B2F9A223C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=n1A+S9s2UKiFv8wJnpzRc/IwykpboXQgIA4nJ71qgzI=; b=BWdu2TxoL6+BV3n9qoqN3ldpT KRXqWQZuh6Z5fIYcmt5giZhqOeTpzn1718boWrGvZrBgB3A9Ul2E/1K0beHdOEj8AlfeU8+6GRKSi nVBscQCCwMNSSUsjK2SKHWV45sbsytuCfTG6t4LbK8HEaj+25BGrvRK228yMDGuAptKnbwPLeN4Dm 0nSANCR4xthqk9wP2P6nPhCSowftS4SjoRSqU0o3kU2ZygR2dxiFVJVGoyFE3NlvdGIoWnXinoynF wHUcUZ1Yg0qskvBeOmMcdCUqExg/bfBoIZngR1DCOdekTpjshZUxW3oHE9Z6NybGOMwAsBOVImGzT I5OzUMclQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVLr4-00025E-GP; Wed, 21 Oct 2020 21:41:10 +0000 Received: from mga09.intel.com ([134.134.136.24]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVLr1-00023j-67 for linux-arm-kernel@lists.infradead.org; Wed, 21 Oct 2020 21:41:09 +0000 IronPort-SDR: 8K3C8x5eFHejy5O4ipP0B0XdEA3W5if+W1AajKaFraNxdV+SHj/eDQ7zz2BIT/pdbJ3TQRwSTQ Dxuiq1nXzBvA== X-IronPort-AV: E=McAfee;i="6000,8403,9781"; a="167558714" X-IronPort-AV: E=Sophos;i="5.77,402,1596524400"; d="scan'208";a="167558714" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 14:41:05 -0700 IronPort-SDR: PAoDCxdHU0d23K3I4PsydeIL0k1YJM+cza2tMcFM0R/hIMaekgzpZ4j+tb9gKWXugqKueZTl4b 1evJguTXcycw== X-IronPort-AV: E=Sophos;i="5.77,402,1596524400"; d="scan'208";a="359031374" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Oct 2020 14:41:00 -0700 Received: by paasikivi.fi.intel.com (Postfix, from userid 1000) id 660D7209D9; Thu, 22 Oct 2020 00:40:58 +0300 (EEST) Date: Thu, 22 Oct 2020 00:40:58 +0300 From: Sakari Ailus To: Hugues FRUCHET Subject: Re: [PATCH v4 2/2] media: dt-bindings: media: st,stm32-dcmi: Add support of BT656 Message-ID: <20201021214058.GJ2703@paasikivi.fi.intel.com> References: <1603188889-23664-1-git-send-email-hugues.fruchet@st.com> <1603188889-23664-3-git-send-email-hugues.fruchet@st.com> <20201021130033.GI2703@paasikivi.fi.intel.com> <657634eb-690a-53a6-2ac1-de3c06a1cec4@st.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <657634eb-690a-53a6-2ac1-de3c06a1cec4@st.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201021_174107_392403_247EEB95 X-CRM114-Status: GOOD ( 38.00 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , Alexandre TORGUE , "linux-kernel@vger.kernel.org" , Philippe CORNU , Hans Verkuil , Alain VOLMAT , Rob Herring , Yannick FERTRE , Mauro Carvalho Chehab , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Hugues, On Wed, Oct 21, 2020 at 02:24:08PM +0000, Hugues FRUCHET wrote: > Hi Sakari, > > On 10/21/20 3:00 PM, Sakari Ailus wrote: > > Hi Hugues, > > > > On Tue, Oct 20, 2020 at 12:14:49PM +0200, Hugues Fruchet wrote: > >> Add support of BT656 parallel bus mode in DCMI. > >> This mode is enabled when hsync-active & vsync-active > >> fields are not specified. > >> > >> Signed-off-by: Hugues Fruchet > >> --- > >> .../devicetree/bindings/media/st,stm32-dcmi.yaml | 30 ++++++++++++++++++++++ > >> 1 file changed, 30 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > >> index 3fe778c..1ee521a 100644 > >> --- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > >> +++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml > >> @@ -44,6 +44,36 @@ properties: > >> bindings defined in > >> Documentation/devicetree/bindings/media/video-interfaces.txt. > >> > >> + properties: > >> + endpoint: > >> + type: object > >> + > >> + properties: > >> + bus-width: true > >> + > >> + hsync-active: > >> + description: > >> + If both HSYNC and VSYNC polarities are not specified, BT656 > >> + embedded synchronization is selected. > >> + default: 0 > >> + > >> + vsync-active: > >> + description: > >> + If both HSYNC and VSYNC polarities are not specified, BT656 > >> + embedded synchronization is selected. > >> + default: 0 > > > > Should I understand this as if the polarities were not specified, BT.656 > > will be used? > > Yes, this is what is documented in video-interfaces.txt: > " > Note, that if HSYNC and VSYNC polarities are not specified, embedded > synchronization may be required, where supported. > " > and > " > /* If hsync-active/vsync-active are missing, > embedded BT.656 sync is used */ > hsync-active = <0>; /* Active low */ > vsync-active = <0>; /* Active low */ > " > and I found also this in > Documentation/devicetree/bindings/media/renesas,vin.yaml > " > hsync-active: > description: > If both HSYNC and VSYNC polarities are not specified, > embedded > synchronization is selected. > default: 1 > > vsync-active: > description: > If both HSYNC and VSYNC polarities are not specified, > embedded > synchronization is selected. > default: 1 Having the defaults leads to somewhat weird behaviour: specifying the default value on either property changes the bus type. > " > > In the other hand I've found few occurences of "bus-type" > (marvell,mmp2-ccic.yaml), it is why I asked you if "bus-type" is the new > way to go versus previous way to signal BT656 (without hsync/vsync) ? > As explained previously, I prefer this last way for backward compatibility. If you have a default for bus-type (BT.601), this won't be a problem. The old DT bindings were somewhat, well, opportunistic. The v4l2-of framework-let did its best and sometimes it worked. The behaviour is still supported but not encouraged in new bindings. > > > The bindings previously documented BT.601 (parallel) only, so > > it was somewhat ambigious to begin with. Is there a risk of interpreting > > old BT.601 bindings as BT.656? > I don't think so. > > With bus-type property, I believe you could > > avoid at least that risk. > yes but as explained, I'll prefer not to amend current boards device > tree files. I don't think it matters from this point of view --- you can have a default bus-type. > > > > > Also not specifying at least one of the default values leads to BT.656 > > without bus-type. That could be addressed by removing the defaults. > > > I'm new to yaml, I've taken that from renesas,vin.yaml. Should I just > drop the "default: 1" lines ? That's one option, yes. Then you have to have those for BT.601 and it's no longer ambiguous. -- Regards, Sakari Ailus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel