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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 505FFEB64DA for ; Mon, 26 Jun 2023 13:55:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=bNFeWcLJAwgO5uMrSMS4CqGhObt2jGv7oRwFcCBb1OU=; b=kYuua/968hXJee AAODzxUiVvjfeTOI7dL6KzjmL0H2MJSRLTpXuF1P18C4UdzmUi5FNkwRMZbN09DvTCUAgInZ/ZBA0 Id2aYHRxQlvHsOpB2Yy7QB1mJqCOrW5Mozb+jBRPFD7Imo5b61NFV7scZFoWqjGi2y1gnMIO8hQje epMFXkLEBY2J9aAcwVqIG6gxdaNab6UinWg5hhokSNOFw8ZaD7wIJ99y4GNmL0pQUrYq8VXVOnJM8 7Jk6n5xrs6GXymRvpTdPeBlh03nELYdJB7At6TJJaOZrvSYg81pT9RrRHcv/JkzYJbEsgZKvhvVMl cgWDp6YLYi3gWlonK/oQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qDmfw-00AKoi-0q; Mon, 26 Jun 2023 13:54:40 +0000 Received: from madras.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e5ab]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qDmft-00AKmS-2a; Mon, 26 Jun 2023 13:54:39 +0000 Received: from notapiano (unknown [IPv6:2600:4041:5b1a:cd00:524d:e95d:1a9c:492a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nfraprado) by madras.collabora.co.uk (Postfix) with ESMTPSA id BD8396606EB0; Mon, 26 Jun 2023 14:54:24 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1687787666; bh=vPot9MUKkOYeQ5g+0bFfY2mVDK/SndwkrBQ4//H5fyE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dgDTgATTKt9HO2Xm0JijQcDuSDhcy8L3YmdOIqdi/oHgz0QaxxyCVebm7fFY5AxOX Dq0gLF3VQdMk+1Ve0O0rUVuroIdrK2MgT+oR+P4Mhp69LPby9e+AE9Cw2jOZhhwsnr kre/za8hZ7J1KKy+FiSLZ2HGwwJmBsDCogB7w6mA0XoGZJhT8lHjUZqygxuw2p15dk opJYENUzEhu4foEDuKKiLSszwqiGemP1+k6nDMjWCLlVhnTcMITlpygo3pB8QORHSj WHyooiY4qrcwshKSwwRYW1leKohGKYUEWaa3Ep40YkdiiG+62uua0oGagqXUnPDYDv YDd5RaZWtOzwg== Date: Mon, 26 Jun 2023 09:54:20 -0400 From: =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado To: Krzysztof Kozlowski Cc: Matthias Brugger , Hans Verkuil , AngeloGioacchino Del Regno , kernel@collabora.com, Andrew-CT Chen , Conor Dooley , Krzysztof Kozlowski , Mauro Carvalho Chehab , Rob Herring , Tiffany Lin , Yunfei Dong , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH v3 3/6] media: dt-bindings: mediatek,vcodec: Remove VDEC_SYS for mt8183 Message-ID: References: <20230620000349.2122191-1-nfraprado@collabora.com> <20230620000349.2122191-4-nfraprado@collabora.com> <8b5e4a9b-7496-02a1-d3b6-a0be8ea85798@linaro.org> <6b41c5e4-bae9-4c99-8a28-7272c8a598a3@notapiano> <9c36cdbb-7204-f9ca-6191-88e0f0f71915@linaro.org> <132ec056-2186-4be5-9770-4d8c4d07bd76@notapiano> <6af2faf2-8624-948b-6efa-3bf00695293b@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6af2faf2-8624-948b-6efa-3bf00695293b@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230626_065438_104164_78B0B722 X-CRM114-Status: GOOD ( 33.85 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 23, 2023 at 06:21:31PM +0200, Krzysztof Kozlowski wrote: > On 21/06/2023 20:00, N=EDcolas F. R. A. Prado wrote: > >> > >> But anyway this variant comes with some set of regs and reg-names. Oth= er > >> variant comes with different set. In all cases they should be defined, > >> even by "defined" means not allowed. > > = > > I'm not sure what you mean. Are you suggesting to disable reg-names on = mt8173? > = > That's one of the options if for some reason you don't want to define the= m. > = > > = > >> > >>> > >>> But in a separate series we could drop vdecsys from mt8173's reg as w= ell, > >>> passing it as a syscon instead, which would solve the warning on that= platform, > >>> though some more driver changes would be needed to be able to handle = it for that > >>> SoC. The newer SoCs like mt8192, mt8195, etc, should also get vdecsys= dropped > >>> from their regs to have a correct memory description. > >>> > >> > >> Sure, but I don't understand how does it affect defining and making > >> specific regs/reg-names or keeping them loose. > > = > > We need some way to tell in the driver whether the first reg is VDEC_SY= S or not. > > Since so far reg-names have not been used for the vcodec, the simplest,= and > > cleanest, way to do it, is to add reg-names when VDEC_SYS is not presen= t. When > > the other SoCs are updated to no longer have the first reg as VDEC_SYS,= they > > would also have reg-names added to their binding, to clearly indicate t= hat. > = > Don't use reg-names for that. The order of entries is anyway strict. Since the order of entries is strict, if I remove VDEC_SYS from mt8183, I a= lso need to remove it from mt8173, is that what you mean? I would still check f= or the presence of reg-names in the driver to differentiate whether the old or= new binding is used, you just don't want different reg-names between compatible= s in the binding? > = > > = > > For example, for mt8173 we currently have > > = > > vcodec_dec: vcodec@16000000 { > > compatible =3D "mediatek,mt8173-vcodec-dec"; > > reg =3D <0 0x16000000 0 0x100>, /* VDEC_SYS */ > > <0 0x16020000 0 0x1000>, /* VDEC_MISC */ > > <0 0x16021000 0 0x800>, /* VDEC_LD */ > > <0 0x16021800 0 0x800>, /* VDEC_TOP */ > > <0 0x16022000 0 0x1000>, /* VDEC_CM */ > > <0 0x16023000 0 0x1000>, /* VDEC_AD */ > > <0 0x16024000 0 0x1000>, /* VDEC_AV */ > > <0 0x16025000 0 0x1000>, /* VDEC_PP */ > > <0 0x16026800 0 0x800>, /* VDEC_HWD */ > > <0 0x16027000 0 0x800>, /* VDEC_HWQ */ > > <0 0x16027800 0 0x800>, /* VDEC_HWB */ > > <0 0x16028400 0 0x400>; /* VDEC_HWG */ > > = > > In a future series, when removing VDEC_SYS from it, it would become > > = > > vcodec_dec: vcodec@16020000 { > > compatible =3D "mediatek,mt8173-vcodec-dec"; > > reg =3D <0 0x16020000 0 0x1000>, /* VDEC_MISC */ > > <0 0x16021000 0 0x800>, /* VDEC_LD */ > > <0 0x16021800 0 0x800>, /* VDEC_TOP */ > > <0 0x16022000 0 0x1000>, /* VDEC_CM */ > > <0 0x16023000 0 0x1000>, /* VDEC_AD */ > > <0 0x16024000 0 0x1000>, /* VDEC_AV */ > > <0 0x16025000 0 0x1000>, /* VDEC_PP */ > > <0 0x16026800 0 0x800>, /* VDEC_HWD */ > > <0 0x16027000 0 0x800>, /* VDEC_HWQ */ > > <0 0x16027800 0 0x800>, /* VDEC_HWB */ > > <0 0x16028400 0 0x400>; /* VDEC_HWG */ > > reg-names =3D "misc", "ld", "top", "cm", "ad", "av", "pp", > > "hwd", "hwq", "hwb", "hwg"; > = > So you want to use reg-names to avoid ABI break. This is not the reason > not to define reg-names for other case. There will be an ABI break anyway when the first reg is removed (as shown above), I'm just trying to avoid churn: adding a reg-name that will be remo= ved later. Thanks, N=EDcolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel