Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp166381rdb; Thu, 21 Dec 2023 06:03:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IHpTJ9Mq8QoaLiNFwXBE17/57Mvqvy2gjie5qvLKpWcnRYOptGk02+2Zc5i/BitsPrsGE7H X-Received: by 2002:a05:6358:9889:b0:174:c5ee:46d with SMTP id q9-20020a056358988900b00174c5ee046dmr252673rwa.57.1703167407292; Thu, 21 Dec 2023 06:03:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703167407; cv=none; d=google.com; s=arc-20160816; b=YBcEtCF5xdTI8h0+pMjysBm3Ub4f2Mi5r3twpCmDZh6nFAsCV6kFWKoo1CPPFpYSw1 BZUbyNGE7MMBcH8zFkuYnw+wRpJd6aON7IcztGsNaC725UySnkgHVCzm/j1obUTilESS h/jLyB6O2rYY29O/GM2LujI1EQWge64D583f3M/tyVTVkWNnkfvOVLjVTqs0OHPiEe4o n4604ZjSMom0D2PrFtG+fbCfoXs9Uci33vXrL2CBiUhWGKYejMGVVuU8xXHinUw6G6xQ lfI7x1xIMh2tBklYPB4/7LhetT3e/EMtymzsnDfSxg3Spmy3/Idb+opevfwhyn3ZEVu7 PVYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=d1tAZ8GdByb8q0+1M5iM8QIUCHX6alVx7yOZ8zoIeaQ=; fh=hT9/IBXjh2QDNqhcci0kuEq486RnPHYnJ+y+eQGQBcA=; b=OtgEmewIza6/h9pbXcDu9q4skkvueg+kN9B2R/mUFjGYX6pj3jIAIQQSX+P8I3zX+z 9BfyxzmlKg5V3fGz5EFYL8t9nVskAFIZ+pCplscc06n5uzfsS6Z2+atliMcDCrgRd06Y 7Lf57PUYluAXKTtWLzYfRQmwE9SV7u4v+PjKAMI79LemHyU5IICg7mE8Onxv0RrfTaL1 OMCJX41Tsos8ZgsVbCt26RjSUMrTFWsCYwi+NmgeIN1nlG8yKV3wu5qwG3Yrkmny1bzA q0A8kBSEH4nPHc3348MsAKgnBc913/89Iz8bTiIkHtm3ii/FO4KPN0NKr1ZD01uVNHsy tO4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=i3kZuJfC; spf=pass (google.com: domain of linux-kernel+bounces-8520-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8520-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id bn3-20020a056a02030300b005cd98356ccfsi1685224pgb.760.2023.12.21.06.03.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Dec 2023 06:03:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-8520-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=i3kZuJfC; spf=pass (google.com: domain of linux-kernel+bounces-8520-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8520-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id A0F2528BE13 for ; Thu, 21 Dec 2023 13:57:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0F7256280E; Thu, 21 Dec 2023 13:47:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="i3kZuJfC" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92E2058227; Thu, 21 Dec 2023 13:46:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-54c77e0835bso1036086a12.2; Thu, 21 Dec 2023 05:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703166418; x=1703771218; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=d1tAZ8GdByb8q0+1M5iM8QIUCHX6alVx7yOZ8zoIeaQ=; b=i3kZuJfCn3yhFaazQkbPcbHhrgHajoXjf2+yNM4z9ldlmVZ5QV4tVZ01IsJl+D0TCr NtTuth/AvRz/6rzUhH5RILWlkz2HKCeV9Nyp+hBqd9NmBUZ2fq0klg1ZmntWtc+QOU9u JyLwv4SdzadD/X1e+nYNFNfgU5ws1hvYaSuWsSXRdTvIZx/fd9PFtUlBwxiCXpZdoHcv MX070QgUA2PRpjW6CNLVGWEwCWw6o4eeKvEbo5jpqoS93GnMa0yibmW0yVZhzw+XfxE0 bNVgAECy4mp5NfbyEYsRyKDfJO+8ovUvpKKD73fd5/Tb/9aWFsqXgG/CkuRLsgmU55ia ksBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703166418; x=1703771218; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d1tAZ8GdByb8q0+1M5iM8QIUCHX6alVx7yOZ8zoIeaQ=; b=GaBERB5x5obPL7XALxxRDK5uILBQmADjYMON4h9ipoGEaAcYU2W5nYIRvvVWpi+pAn QYq2xi/aRsX4NQ795u7Kh7sBTIBjcWfSoY/s5R2TD3m04oLUOxqKzRPAwCkzh3LcLhvn xl63fzocqRzGDxB8pypDtBQj9cdyqQ6Yf52z3Tb9HM8mWSDBiXuxrozCfDf65NjtTZ4m 0+hVauWFkWv0khwPqX5SUwFo2AyPPfiMdayKk/xiouLKmO3LXh7namd8vwjVpTtJbQlV czSNx2tNyWmRkL6ILdWuSa8ZAsfll+MKyy0oWoBx9Bu+QXC4JvGyxG+S1dHYZU6EWf+N A/lQ== X-Gm-Message-State: AOJu0YyhiVHzL/5NauobS+bZ2zHyOwRY6VtcidYLel3+UkTGUStVKbr+ cdIYO4M7AKChk9MCqvo0Hg== X-Received: by 2002:a50:8e17:0:b0:553:68b2:31e3 with SMTP id 23-20020a508e17000000b0055368b231e3mr3672745edw.30.1703166417679; Thu, 21 Dec 2023 05:46:57 -0800 (PST) Received: from ?IPV6:2a02:810b:f40:4300:1c49:5d1e:f6f3:77a0? ([2a02:810b:f40:4300:1c49:5d1e:f6f3:77a0]) by smtp.gmail.com with ESMTPSA id i21-20020a0564020f1500b0055344b92fb6sm1185290eda.75.2023.12.21.05.46.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 Dec 2023 05:46:57 -0800 (PST) Message-ID: Date: Thu, 21 Dec 2023 14:46:56 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 0/5] Add support for video hardware codec of STMicroelectronics STM32 SoC series Content-Language: en-US, de-DE To: Adam Ford Cc: Hugues FRUCHET , Nicolas Dufresne , Marco Felsch , Philipp Zabel , Andrzej Pietrasiewicz , Sakari Ailus , Benjamin Gaignard , Laurent Pinchart , Benjamin Mugnier , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, Daniel Almeida , Heiko Stuebner , Hans Verkuil , Rob Herring , Conor Dooley , linux-stm32@st-md-mailman.stormreply.com, Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org, Maxime Coquelin , linux-media@vger.kernel.org, Alexandre Torgue , Ezequiel Garcia References: <20231221084723.2152034-1-hugues.fruchet@foss.st.com> <769a1510-f8d2-4095-9879-42f413141dee@gmail.com> From: Alex Bee In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Am 21.12.23 um 14:38 schrieb Adam Ford: > On Thu, Dec 21, 2023 at 7:31 AM Alex Bee wrote: >> Hi Hugues, >> >> Am 21.12.23 um 14:08 schrieb Hugues FRUCHET: >>> Hi Alex, >>> >>> This is because VDEC and VENC are two separated IPs with their own >>> hardware resources and no links between both. >>> On future SoCs, VDEC can ship on its own, same for VENC. >>> >> I think that's what the driver is/was designed for :) >> >> I don't think there _has_ to be a link between variants in the same file. >> For Rockchip we only had the issue that there _is_ a link (shared >> resources) between encoder and decoder and they had (for that reason) to be >> defined has a _single_ variant. And there is no reason you can ship decoder >> and encoder seperated when you have two variants (with different >> compatibles). >> For Rockchip and iMX those files are even containing variants for completly >> different generations / different SoCs. I had to cleanup this mess for > The i.MX8M Mini and Plus have different power domains for encoder and > decoders as well as different clocks. Keeping them separate would > almost be necessary. I guess there is missunderstanding: I didn't say the two STM variants should be merged in one variant, but the two variants should be within the same _file_, like the other platforms are doing :) > adam > >> Rockchip once - and it was no fun :) Anyways: It's up to the maintainers I >> guess - I just wanted to ask if I missunderstand something here. >> >> Greetings, >> >> Alex >> >>> Hoping that this clarify. >>> >>> Best regards, >>> Hugues. >>> >>> On 12/21/23 13:40, Alex Bee wrote: >>>> Hi Hugues, Hi Nicolas, >>>> >>>> is there any specific reason I'm not understanding / seeing why this >>>> is added in two seperate vdec* / venc* files and not a single vpu* >>>> file? Is it only for the seperate clocks (-names) / irqs (-names) / >>>> callbacks? Those are defined per variant and perfectly fit in a >>>> single file holding one vdec and one venc variant. >>>> >>>> Alex >>>> >>>> Am 21.12.23 um 09:47 schrieb Hugues Fruchet: >>>>> This patchset introduces support for VDEC video hardware decoder >>>>> and VENC video hardware encoder of STMicroelectronics STM32MP25 >>>>> SoC series. >>>>> >>>>> This initial support implements H264 decoding, VP8 decoding and >>>>> JPEG encoding. >>>>> >>>>> This has been tested on STM32MP257F-EV1 evaluation board. >>>>> >>>>> =========== >>>>> = history = >>>>> =========== >>>>> version 5: >>>>> - Precise that video decoding as been successfully tested up to >>>>> full HD >>>>> - Add Nicolas Dufresne reviewed-by >>>>> >>>>> version 4: >>>>> - Fix comments from Nicolas about dropping encoder raw steps >>>>> >>>>> version 3: >>>>> - Fix remarks from Krzysztof Kozlowski: >>>>> - drop "items", we keep simple enum in such case >>>>> - drop second example - it is the same as the first >>>>> - Drop unused node labels as suggested by Conor Dooley >>>>> - Revisit min/max resolutions as suggested by Nicolas Dufresne >>>>> >>>>> version 2: >>>>> - Fix remarks from Krzysztof Kozlowski on v1: >>>>> - single video-codec binding for both VDEC/VENC >>>>> - get rid of "-names" >>>>> - use of generic node name "video-codec" >>>>> >>>>> version 1: >>>>> - Initial submission >>>>> >>>>> Hugues Fruchet (5): >>>>> dt-bindings: media: Document STM32MP25 VDEC & VENC video codecs >>>>> media: hantro: add support for STM32MP25 VDEC >>>>> media: hantro: add support for STM32MP25 VENC >>>>> arm64: dts: st: add video decoder support to stm32mp255 >>>>> arm64: dts: st: add video encoder support to stm32mp255 >>>>> >>>>> .../media/st,stm32mp25-video-codec.yaml | 50 ++++++++ >>>>> arch/arm64/boot/dts/st/stm32mp251.dtsi | 12 ++ >>>>> arch/arm64/boot/dts/st/stm32mp255.dtsi | 17 +++ >>>>> drivers/media/platform/verisilicon/Kconfig | 14 ++- >>>>> drivers/media/platform/verisilicon/Makefile | 4 + >>>>> .../media/platform/verisilicon/hantro_drv.c | 4 + >>>>> .../media/platform/verisilicon/hantro_hw.h | 2 + >>>>> .../platform/verisilicon/stm32mp25_vdec_hw.c | 92 ++++++++++++++ >>>>> .../platform/verisilicon/stm32mp25_venc_hw.c | 115 >>>>> ++++++++++++++++++ >>>>> 9 files changed, 307 insertions(+), 3 deletions(-) >>>>> create mode 100644 >>>>> Documentation/devicetree/bindings/media/st,stm32mp25-video-codec.yaml >>>>> create mode 100644 >>>>> drivers/media/platform/verisilicon/stm32mp25_vdec_hw.c >>>>> create mode 100644 >>>>> drivers/media/platform/verisilicon/stm32mp25_venc_hw.c >>>>>