Message ID | 20231004091552.3531659-4-hugues.fruchet@foss.st.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6359:6f87:b0:13f:353d:d1ed with SMTP id tl7csp2488171rwb; Wed, 4 Oct 2023 02:17:09 -0700 (PDT) X-Google-Smtp-Source: AGHT+IETU/NYTdYVnQEsBmqFnyL2mfQRuAVJW8gDjiEhFWs7SDY8dLxEtpSXNDGY6s8uzousQRGH X-Received: by 2002:a17:902:e5c3:b0:1c6:1733:fb3f with SMTP id u3-20020a170902e5c300b001c61733fb3fmr1418559plf.49.1696411029369; Wed, 04 Oct 2023 02:17:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696411029; cv=none; d=google.com; s=arc-20160816; b=g8NpqCJjpwX+Pd77NXSJpcTk7brlOFziLeHDNwKaBydrORKf3JO6ovJxtx1XlYSzRD bQ1P6S4q/L3GLOx8pZUxTwTBpANkbMV9HcCHslmTXWHboP7NbLlkf3qOioETN0+BQV6b hEeSHNCe0b4FzrLFkuQTHfWiV/APcA7tTPzIms2wJB2OUbI5Xox9PtLzHOstR5HVtcKn SWB90sk+c83yNoJLeqKB5/NVGZgA9gZUAJVKwRHV3XK+mTpgJHL5YYYpL8nELN6FCjXI xSg/4RzNeJgXB4zDJxY1dgOt03UvmRGlZTv3csIH7vwzaIZEnQBf4hAYBsVj2K4A+J1G Kjbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=tN8WihHZ8UtI7rsXlOoBMNAknU2jMb2LP7lJZaLwYH8=; fh=ItXiUQa06G5NtzfQ6MBP/cGHELTOauPzcHi5SmTT7Sw=; b=UgrMLcLY0h3ZqvT4Ipk3nxexwL1l6aeIUb9Pe/YJmTibDgkGNRzoGWDsc2gEW4sG6e i9AX/P0SBQ+amGPnvab3f/Vm55gjol87CcTZLjhZKe9kNdhrpiVpBRYOQO1RmD4l8T+5 FwuOe8eWJehkTfzvDBxQmPyFtbecJgTEfxRqK8IcZWIHDQL2Q1Sz8+rAWONdNwFBtGuE i8qzeB73pZ3WSWClRMd3g7AgPHn3FjB8SfXOTiHnd6Jze2v3qk3+UYNfZXTvavNa8c1P iHDZpsTu0VSyxVa7r3/8qfwBnGHf4BYnWx4eG1YanmhP+I/qmur/cuOQOHk5J1A1/R43 bkmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=OOsEZgJ9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id f1-20020a170902ce8100b001c75540d9fesi3614553plg.587.2023.10.04.02.17.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 02:17:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@foss.st.com header.s=selector1 header.b=OOsEZgJ9; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=foss.st.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 46B4281F3328; Wed, 4 Oct 2023 02:16:55 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241982AbjJDJQf (ORCPT <rfc822;pusanteemu@gmail.com> + 18 others); Wed, 4 Oct 2023 05:16:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242065AbjJDJQc (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 4 Oct 2023 05:16:32 -0400 Received: from mx08-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDF2698; Wed, 4 Oct 2023 02:16:28 -0700 (PDT) Received: from pps.filterd (m0369457.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.22/8.17.1.22) with ESMTP id 3945aC2J021867; Wed, 4 Oct 2023 11:16:02 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s= selector1; bh=tN8WihHZ8UtI7rsXlOoBMNAknU2jMb2LP7lJZaLwYH8=; b=OO sEZgJ9bL5gYQUKt35WoI2CeLx0DyXR46fGkH6nM8/uc5Y4xWaU5KC/GHE/mGCtTG XUR/sIwBMq0R+dw4nKqQ//Py2ewHi1H/e4Z7r2vrhaRzHS42dOCw1Y29CwJupKyY xGJzrgDuqi6TF87eo4u3boz8cLz4EdNLmfTtlq+ZUvvbjXDosRAZHW1j00neT3+5 C/4jsUHZC8aLpiAKvy5eS0m/3XJj6NaZtudXELFeNXGVwemvuhxUM3ROoREvHtMR /GV/BZrfuwGR9o98Q1lYAXX1Ryna+/FUHhxtTo3D1DvYN3VJkcxR6U1JFH03mscu 6urohqVTzpUfYCs5lUKQ== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3texmj5utb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Oct 2023 11:16:01 +0200 (MEST) Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 487CE100063; Wed, 4 Oct 2023 11:16:01 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node1.st.com [10.75.129.69]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 40F4E22A6DD; Wed, 4 Oct 2023 11:16:01 +0200 (CEST) Received: from localhost (10.201.20.120) by SHFDAG1NODE1.st.com (10.75.129.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 4 Oct 2023 11:16:00 +0200 From: Hugues Fruchet <hugues.fruchet@foss.st.com> To: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>, Philipp Zabel <p.zabel@pengutronix.de>, Mauro Carvalho Chehab <mchehab@kernel.org>, Hans Verkuil <hverkuil@xs4all.nl>, <linux-media@vger.kernel.org>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, <linux-stm32@st-md-mailman.stormreply.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, <devicetree@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-rockchip@lists.infradead.org> CC: Hugues Fruchet <hugues.fruchet@foss.st.com>, Andrzej Pietrasiewicz <andrzej.p@collabora.com> Subject: [PATCH 3/7] dt-bindings: media: Document STM32MP25 VENC video encoder Date: Wed, 4 Oct 2023 11:15:48 +0200 Message-ID: <20231004091552.3531659-4-hugues.fruchet@foss.st.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20231004091552.3531659-1-hugues.fruchet@foss.st.com> References: <20231004091552.3531659-1-hugues.fruchet@foss.st.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.201.20.120] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE1.st.com (10.75.129.69) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-10-04_01,2023-10-02_01,2023-05-22_02 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 04 Oct 2023 02:16:55 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778815891170037758 X-GMAIL-MSGID: 1778815891170037758 |
Series |
Add support for video hardware codec of STMicroelectronics STM32 SoC series
|
|
Commit Message
Hugues Fruchet
Oct. 4, 2023, 9:15 a.m. UTC
Add STM32MP25 VENC video encoder bindings.
Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com>
---
.../bindings/media/st,stm32mp25-venc.yaml | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml
Comments
On Wed, Oct 4, 2023 at 4:16 AM Hugues Fruchet <hugues.fruchet@foss.st.com> wrote: > > Add STM32MP25 VENC video encoder bindings. > > Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> > --- > .../bindings/media/st,stm32mp25-venc.yaml | 56 +++++++++++++++++++ > 1 file changed, 56 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > > diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > new file mode 100644 > index 000000000000..c69e0a34f675 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > @@ -0,0 +1,56 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > + > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/st,stm32mp25-venc.yaml# Can this dt-binding be made more generic, like something like hantro-h1 or VC8000NanoE? I think there will be more boards that may incorporate the Hantro-H1 or a VC8000 in the future, because I don't think this IP is unique to the STM32MP25. adam > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: STMicroelectronics STM32MP25 VENC video encoder > + > +maintainers: > + - Hugues Fruchet <hugues.fruchet@foss.st.com> > + > +description: > + The STMicroelectronics STM32MP25 SOCs embeds a VENC video hardware encoder > + peripheral based on Verisilicon VC8000NanoE IP (former Hantro H1). > + > +properties: > + compatible: > + const: st,stm32mp25-venc > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > + interrupt-names: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > + clock-names: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + - interrupts > + - interrupt-names > + - clocks > + - clock-names > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + venc: venc@580e0000 { > + compatible = "st,stm32mp25-venc"; > + reg = <0x580e0000 0x800>; > + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "venc"; Is the interrupt-names needed if there is only one? > + clocks = <&ck_icn_p_venc>; > + clock-names = "venc-clk"; Same thing for the clock. if there is only one clock, doe they need names? adam > + }; > -- > 2.25.1 >
Hi Adam, Thanks for review, On 10/5/23 01:41, Adam Ford wrote: > On Wed, Oct 4, 2023 at 4:16 AM Hugues Fruchet > <hugues.fruchet@foss.st.com> wrote: >> >> Add STM32MP25 VENC video encoder bindings. >> >> Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> >> --- >> .../bindings/media/st,stm32mp25-venc.yaml | 56 +++++++++++++++++++ >> 1 file changed, 56 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >> >> diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >> new file mode 100644 >> index 000000000000..c69e0a34f675 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >> @@ -0,0 +1,56 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> + >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/st,stm32mp25-venc.yaml# > > Can this dt-binding be made more generic, like something like > hantro-h1 or VC8000NanoE? > > I think there will be more boards that may incorporate the Hantro-H1 > or a VC8000 in the future, because I don't think this IP is unique to > the STM32MP25. This is already the case, check variants in hantro_drv.c. Several SoCs are sharing this IP but each IP slightly differs because of supported resolution, codec, preprocessing features, ... There are also some differences on how clock, interrupt, reset are hardware mapped: shared or not by decoder and encoder for ex. > > adam > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: STMicroelectronics STM32MP25 VENC video encoder >> + >> +maintainers: >> + - Hugues Fruchet <hugues.fruchet@foss.st.com> >> + >> +description: >> + The STMicroelectronics STM32MP25 SOCs embeds a VENC video hardware encoder >> + peripheral based on Verisilicon VC8000NanoE IP (former Hantro H1). >> + >> +properties: >> + compatible: >> + const: st,stm32mp25-venc >> + >> + reg: >> + maxItems: 1 >> + >> + interrupts: >> + maxItems: 1 >> + >> + interrupt-names: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> + clock-names: >> + maxItems: 1 >> + >> +required: >> + - compatible >> + - reg >> + - interrupts >> + - interrupt-names >> + - clocks >> + - clock-names >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/interrupt-controller/arm-gic.h> >> + venc: venc@580e0000 { >> + compatible = "st,stm32mp25-venc"; >> + reg = <0x580e0000 0x800>; >> + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>; >> + interrupt-names = "venc"; > > > Is the interrupt-names needed if there is only one? > Not really, could be dropped. >> + clocks = <&ck_icn_p_venc>; >> + clock-names = "venc-clk"; > > Same thing for the clock. if there is only one clock, doe they need names? > Not really, could be dropped. > adam >> + }; >> -- >> 2.25.1 >> BR, Hugues.
On 04/10/2023 11:15, Hugues Fruchet wrote: > Add STM32MP25 VENC video encoder bindings. > I don't understand why this binding is separate from video decoder. Merge them. Best regards, Krzysztof
On Wed, Oct 04, 2023 at 06:41:09PM -0500, Adam Ford wrote: > On Wed, Oct 4, 2023 at 4:16 AM Hugues Fruchet > <hugues.fruchet@foss.st.com> wrote: > > > > Add STM32MP25 VENC video encoder bindings. > > > > Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> > > --- > > .../bindings/media/st,stm32mp25-venc.yaml | 56 +++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > > > > diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > > new file mode 100644 > > index 000000000000..c69e0a34f675 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml > > @@ -0,0 +1,56 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > + > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/media/st,stm32mp25-venc.yaml# > > Can this dt-binding be made more generic, like something like > hantro-h1 or VC8000NanoE? > > I think there will be more boards that may incorporate the Hantro-H1 > or a VC8000 in the future, because I don't think this IP is unique to > the STM32MP25. Unless the underlying IP is well documented (i.e. public), then it's kind of pointless. Everyone will just invent their own numbers and names of clocks, resets, etc. unless someone can enforce not doing that. Rob
Hi Rob, On 10/6/23 18:27, Rob Herring wrote: > On Wed, Oct 04, 2023 at 06:41:09PM -0500, Adam Ford wrote: >> On Wed, Oct 4, 2023 at 4:16 AM Hugues Fruchet >> <hugues.fruchet@foss.st.com> wrote: >>> >>> Add STM32MP25 VENC video encoder bindings. >>> >>> Signed-off-by: Hugues Fruchet <hugues.fruchet@foss.st.com> >>> --- >>> .../bindings/media/st,stm32mp25-venc.yaml | 56 +++++++++++++++++++ >>> 1 file changed, 56 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >>> new file mode 100644 >>> index 000000000000..c69e0a34f675 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml >>> @@ -0,0 +1,56 @@ >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>> + >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/media/st,stm32mp25-venc.yaml# >> >> Can this dt-binding be made more generic, like something like >> hantro-h1 or VC8000NanoE? >> >> I think there will be more boards that may incorporate the Hantro-H1 >> or a VC8000 in the future, because I don't think this IP is unique to >> the STM32MP25. > > Unless the underlying IP is well documented (i.e. public), then it's > kind of pointless. Everyone will just invent their own numbers and names > of clocks, resets, etc. unless someone can enforce not doing that. Unfortunately the IP documentation is not public, there are no documents provided publicly by Verisilicon for the time being. > > Rob BR, Hugues
Hi Krzysztof, On 10/5/23 21:45, Krzysztof Kozlowski wrote: > On 04/10/2023 11:15, Hugues Fruchet wrote: >> Add STM32MP25 VENC video encoder bindings. >> > > I don't understand why this binding is separate from video decoder. > Merge them. VDEC and VENC are two independent IPs with their own clock, reset, interrupt & register set, they have their own access to APB/AXI bus. Moreover future chipsets may embed only VENC or VDEC. Hoping that this clarifies the reason of two different bindings. > > Best regards, > Krzysztof > Br, Hugues.
On 09/10/2023 15:49, Hugues FRUCHET wrote: > Hi Krzysztof, > > On 10/5/23 21:45, Krzysztof Kozlowski wrote: >> On 04/10/2023 11:15, Hugues Fruchet wrote: >>> Add STM32MP25 VENC video encoder bindings. >>> >> >> I don't understand why this binding is separate from video decoder. >> Merge them. > VDEC and VENC are two independent IPs with their own clock, reset, > interrupt & register set, they have their own access to APB/AXI bus. > Moreover future chipsets may embed only VENC or VDEC. > > Hoping that this clarifies the reason of two different bindings. No, it does not. These are no reasons to have independent bindings, except when having actual impact on the bindings. The bindings look identical. What are the differences? Best regards, Krzysztof
Hi Krzysztof, On 10/9/23 15:56, Krzysztof Kozlowski wrote: > On 09/10/2023 15:49, Hugues FRUCHET wrote: >> Hi Krzysztof, >> >> On 10/5/23 21:45, Krzysztof Kozlowski wrote: >>> On 04/10/2023 11:15, Hugues Fruchet wrote: >>>> Add STM32MP25 VENC video encoder bindings. >>>> >>> >>> I don't understand why this binding is separate from video decoder. >>> Merge them. >> VDEC and VENC are two independent IPs with their own clock, reset, >> interrupt & register set, they have their own access to APB/AXI bus. >> Moreover future chipsets may embed only VENC or VDEC. >> >> Hoping that this clarifies the reason of two different bindings. > > No, it does not. These are no reasons to have independent bindings, > except when having actual impact on the bindings. The bindings look > identical. What are the differences? I'm sorry but I really don't understand your point, these are two different IPs with very different registers in it, so why should I share that in a single binding ? > > Best regards, > Krzysztof > BR, Hugues.
On 09/10/2023 16:24, Hugues FRUCHET wrote: > Hi Krzysztof, > > On 10/9/23 15:56, Krzysztof Kozlowski wrote: >> On 09/10/2023 15:49, Hugues FRUCHET wrote: >>> Hi Krzysztof, >>> >>> On 10/5/23 21:45, Krzysztof Kozlowski wrote: >>>> On 04/10/2023 11:15, Hugues Fruchet wrote: >>>>> Add STM32MP25 VENC video encoder bindings. >>>>> >>>> >>>> I don't understand why this binding is separate from video decoder. >>>> Merge them. >>> VDEC and VENC are two independent IPs with their own clock, reset, >>> interrupt & register set, they have their own access to APB/AXI bus. >>> Moreover future chipsets may embed only VENC or VDEC. >>> >>> Hoping that this clarifies the reason of two different bindings. >> >> No, it does not. These are no reasons to have independent bindings, >> except when having actual impact on the bindings. The bindings look >> identical. What are the differences? > I'm sorry but I really don't understand your point, these are two > different IPs with very different registers in it, so why should > I share that in a single binding ? Because the binding is identical. If not, maybe I missed something, so please point me to differences in the binding. Best regards, Krzysztof
Hi Krzysztof, On 10/9/23 16:28, Krzysztof Kozlowski wrote: > On 09/10/2023 16:24, Hugues FRUCHET wrote: >> Hi Krzysztof, >> >> On 10/9/23 15:56, Krzysztof Kozlowski wrote: >>> On 09/10/2023 15:49, Hugues FRUCHET wrote: >>>> Hi Krzysztof, >>>> >>>> On 10/5/23 21:45, Krzysztof Kozlowski wrote: >>>>> On 04/10/2023 11:15, Hugues Fruchet wrote: >>>>>> Add STM32MP25 VENC video encoder bindings. >>>>>> >>>>> >>>>> I don't understand why this binding is separate from video decoder. >>>>> Merge them. >>>> VDEC and VENC are two independent IPs with their own clock, reset, >>>> interrupt & register set, they have their own access to APB/AXI bus. >>>> Moreover future chipsets may embed only VENC or VDEC. >>>> >>>> Hoping that this clarifies the reason of two different bindings. >>> >>> No, it does not. These are no reasons to have independent bindings, >>> except when having actual impact on the bindings. The bindings look >>> identical. What are the differences? >> I'm sorry but I really don't understand your point, these are two >> different IPs with very different registers in it, so why should >> I share that in a single binding ? > > Because the binding is identical. If not, maybe I missed something, so > please point me to differences in the binding. OK, currently they are identical so I will merge into a single one even if I disagree on that. I hope that in future this will not change otherwise I'll need to revisit that and make separate bindings as initially proposed... I'll so push a v2 with merged version proposal. > > Best regards, > Krzysztof > BR, Hugues.
diff --git a/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml new file mode 100644 index 000000000000..c69e0a34f675 --- /dev/null +++ b/Documentation/devicetree/bindings/media/st,stm32mp25-venc.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/st,stm32mp25-venc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32MP25 VENC video encoder + +maintainers: + - Hugues Fruchet <hugues.fruchet@foss.st.com> + +description: + The STMicroelectronics STM32MP25 SOCs embeds a VENC video hardware encoder + peripheral based on Verisilicon VC8000NanoE IP (former Hantro H1). + +properties: + compatible: + const: st,stm32mp25-venc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + venc: venc@580e0000 { + compatible = "st,stm32mp25-venc"; + reg = <0x580e0000 0x800>; + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "venc"; + clocks = <&ck_icn_p_venc>; + clock-names = "venc-clk"; + };