From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [85.220.165.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88BCB2CA6 for ; Tue, 7 Dec 2021 14:16:54 +0000 (UTC) Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mubGp-0001MK-F4; Tue, 07 Dec 2021 15:16:39 +0100 Message-ID: <3723dba86bc8c4ac4147d766787c926af486103f.camel@pengutronix.de> Subject: Re: [RFC V2 5/6] media: hantro: split i.MX8MQ G1 and G2 code From: Lucas Stach To: Adam Ford Cc: Ezequiel Garcia , linux-media , Chris Healy , Benjamin Gaignard , Hans Verkuil , Philipp Zabel , Mauro Carvalho Chehab , Rob Herring , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Greg Kroah-Hartman , "open list:HANTRO VPU CODEC DRIVER" , devicetree , arm-soc , Linux Kernel Mailing List , "open list:STAGING SUBSYSTEM" Date: Tue, 07 Dec 2021 15:16:37 +0100 In-Reply-To: References: <20211207015446.1250854-1-aford173@gmail.com> <20211207015446.1250854-6-aford173@gmail.com> <6e41beec102951ea057ba1af02ef4aaad40bd0dc.camel@pengutronix.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-staging@lists.linux.dev Am Dienstag, dem 07.12.2021 um 08:07 -0600 schrieb Adam Ford: > > > > > > [...] > > > > > > I think it's important to clarify that you are breaking support > > > > > > for the previous device-tree binding. Not only because of the compatible > > > > > > string change, but because the binding is now quite different. > > > > > > > > > > > > Note that in the past Benjamin tried to avoid this. > > > > > > IIRC, his proposal was backwards compatible. > > > > > > > > > > I was looking at how to do this, but the stand-alone vpu bindings did > > > > > the reset and the fuses manually, it causes issues. When the block > > > > > control is enabled those memory locations for the resets and fuses are > > > > > assigned to the blk-ctrl driver, so attempting to access them from a > > > > > different driver was a violation. > > > > > > > > > > When I started looking at this, the stand-alone VPU was trying to be > > > > > both G1 and G2, but when I was testing it before I made changes, I > > > > > didn't see the G2 function at all. When I was done the G2 seemed to > > > > > work, so it seems like this is an improvement. If you want me to keep > > > > > the previous compatible flag, I could rename the nxp,imx8mq-vpu-g1 > > > > > back to nxp,imx8mq-vpu and remove the reset/fuse controls, but I'd > > > > > have to add the blk-ctrl reference, so it seemed to me like a better > > > > > alternative to deprecate the old binding/driver and replace it with > > > > > the new one because of the significant changes. Since I'd like to > > > > > rebase the i.MX8M Mini I did on this work, it seemed weird to have > > > > > nxp,imx8mq-vpu, nxp,imx8mq-vpu-g2, nxp,imx8mm-vpu-g1, and > > > > > nxp,imx8mm-vpu-g2 where the only one without a Gx name was the > > > > > original 8MQ binding but limited to G1 functionality and the G2 > > > > > stripped out. > > > > > > > > I would very much appreciate if we could keep the driver code for the > > > > old binding. It does not need to have any new additional functionality, > > > > but just keep the existing G1 h.264 decode when booted on a old DT with > > > > the old VPU description and no blk-ctrl, so we don't regress > > > > functionality when a new kernel is booted with a old DT. > > > > > > > > New functionality with the G2 can depend on the new VPU binding and the > > > > blk-ctrl driver. > > > > > > How does that work when both the original VPU and the blk-ctrl attempt > > > to manipulate the reset and clock lines? The original binding for the > > > vpu was assigned: > > > > > > reg = <0x38300000 0x10000>, > > > <0x38310000 0x10000>, > > > <0x38320000 0x10000>; > > > reg-names = "g1", "g2", "ctrl"; > > > > > > If G2 is going to run from 38310000 and vpu-blk-ctrl run from > > > 38320000, they'll collide. > > > > > It's not going to work, but it also doesn't have to. Either you have a > > old DT where the VPU driver will poke the blk-ctrl registers, but no > > blk-ctrl driver, or you have a new DT where the VPU driver leaves the > > blk-ctrl region alone and the blk-ctrl driver needs to handle it. > > > > Just don't support mixing the old VPU DT binding with the new blk-ctrl > > way of doing things. The only thing that needs to keep working is a > > unchannged old DT, where the VPU uses the old binding, but no blk-ctrl > > is present as a separate node. > > I think I understand. I'll leave the old code for the old binding in > the driver and add the new code for the new bindings with blk-ctrl. > Once the device tree is migrated to the new bindings, the old one > becomes harmless, but still works with old device trees lacking the > blk-ctrl. That makes sense. In my head, I wasn't thinking about > mixing older device trees. Exactly. While most people don't use it this way, the kernel and DT are supposed to be independent, e.g. the DTB could be included in the device firmware, while the kernel could be updated via a distro. To not break this use-case without a good reason, new kernels should try to not regress functionality with a existing binary DT. We can mandate DT updates for new functionality (like being able to use the G2 core only with the new blk-ctrl + split VPU binding), but we shouldn't break existing features if there isn't a very good reason to do so. Keeping the bit of code in the VPU driver to keep the old G1 only decoding working with a new kernel isn't much of a burden IMHO, so we should try to keep it alive. Regards, Lucas 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 C3485C433F5 for ; Tue, 7 Dec 2021 14:50:40 +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:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cxbAfyuOsOxLal3AM+0qduayJ+cnTe3ehi/BKxxWtcI=; b=Ghj0k9j5BCT5zS wPRc2FLwf/PvbxkLdnhKZ/JAekFz2Ebv4VnLlxCdVq5H5M6VCW2ir2PBr4ddwYD7ZkQ4ZlrODEd+G cq4lP0Uc/J6kQXSV9079LCBMEIPKaezO8GRBs7fGASJiZmgT9bd1cW1P5yVkgZdfdmg7NtLn1IWoU jHUd+X/V8u57BL6gcdfjYNrcd7jJBOfM89WeDjNpdmkogLusalDQPBrfV8eVJCHOKmTCdL4JgHCjh 0iMdJhf75xPwcNFEpEw6TCVwaRWewYFx2/kjVfpATJncB/MF5/Ff3oQS9ueXvacEpIP3Y6snIs3wM iMtB5cwK2IjHYKatjsgg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mubnf-0091J8-0B; Tue, 07 Dec 2021 14:50:35 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mubGy-008tIm-CV for linux-rockchip@lists.infradead.org; Tue, 07 Dec 2021 14:16:51 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mubGp-0001MK-F4; Tue, 07 Dec 2021 15:16:39 +0100 Message-ID: <3723dba86bc8c4ac4147d766787c926af486103f.camel@pengutronix.de> Subject: Re: [RFC V2 5/6] media: hantro: split i.MX8MQ G1 and G2 code From: Lucas Stach To: Adam Ford Cc: Ezequiel Garcia , linux-media , Chris Healy , Benjamin Gaignard , Hans Verkuil , Philipp Zabel , Mauro Carvalho Chehab , Rob Herring , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Greg Kroah-Hartman , "open list:HANTRO VPU CODEC DRIVER" , devicetree , arm-soc , Linux Kernel Mailing List , "open list:STAGING SUBSYSTEM" Date: Tue, 07 Dec 2021 15:16:37 +0100 In-Reply-To: References: <20211207015446.1250854-1-aford173@gmail.com> <20211207015446.1250854-6-aford173@gmail.com> <6e41beec102951ea057ba1af02ef4aaad40bd0dc.camel@pengutronix.de> User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-rockchip@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211207_061648_481343_27368EE0 X-CRM114-Status: GOOD ( 50.30 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org Am Dienstag, dem 07.12.2021 um 08:07 -0600 schrieb Adam Ford: > > > > > > [...] > > > > > > I think it's important to clarify that you are breaking support > > > > > > for the previous device-tree binding. Not only because of the compatible > > > > > > string change, but because the binding is now quite different. > > > > > > > > > > > > Note that in the past Benjamin tried to avoid this. > > > > > > IIRC, his proposal was backwards compatible. > > > > > > > > > > I was looking at how to do this, but the stand-alone vpu bindings did > > > > > the reset and the fuses manually, it causes issues. When the block > > > > > control is enabled those memory locations for the resets and fuses are > > > > > assigned to the blk-ctrl driver, so attempting to access them from a > > > > > different driver was a violation. > > > > > > > > > > When I started looking at this, the stand-alone VPU was trying to be > > > > > both G1 and G2, but when I was testing it before I made changes, I > > > > > didn't see the G2 function at all. When I was done the G2 seemed to > > > > > work, so it seems like this is an improvement. If you want me to keep > > > > > the previous compatible flag, I could rename the nxp,imx8mq-vpu-g1 > > > > > back to nxp,imx8mq-vpu and remove the reset/fuse controls, but I'd > > > > > have to add the blk-ctrl reference, so it seemed to me like a better > > > > > alternative to deprecate the old binding/driver and replace it with > > > > > the new one because of the significant changes. Since I'd like to > > > > > rebase the i.MX8M Mini I did on this work, it seemed weird to have > > > > > nxp,imx8mq-vpu, nxp,imx8mq-vpu-g2, nxp,imx8mm-vpu-g1, and > > > > > nxp,imx8mm-vpu-g2 where the only one without a Gx name was the > > > > > original 8MQ binding but limited to G1 functionality and the G2 > > > > > stripped out. > > > > > > > > I would very much appreciate if we could keep the driver code for the > > > > old binding. It does not need to have any new additional functionality, > > > > but just keep the existing G1 h.264 decode when booted on a old DT with > > > > the old VPU description and no blk-ctrl, so we don't regress > > > > functionality when a new kernel is booted with a old DT. > > > > > > > > New functionality with the G2 can depend on the new VPU binding and the > > > > blk-ctrl driver. > > > > > > How does that work when both the original VPU and the blk-ctrl attempt > > > to manipulate the reset and clock lines? The original binding for the > > > vpu was assigned: > > > > > > reg = <0x38300000 0x10000>, > > > <0x38310000 0x10000>, > > > <0x38320000 0x10000>; > > > reg-names = "g1", "g2", "ctrl"; > > > > > > If G2 is going to run from 38310000 and vpu-blk-ctrl run from > > > 38320000, they'll collide. > > > > > It's not going to work, but it also doesn't have to. Either you have a > > old DT where the VPU driver will poke the blk-ctrl registers, but no > > blk-ctrl driver, or you have a new DT where the VPU driver leaves the > > blk-ctrl region alone and the blk-ctrl driver needs to handle it. > > > > Just don't support mixing the old VPU DT binding with the new blk-ctrl > > way of doing things. The only thing that needs to keep working is a > > unchannged old DT, where the VPU uses the old binding, but no blk-ctrl > > is present as a separate node. > > I think I understand. I'll leave the old code for the old binding in > the driver and add the new code for the new bindings with blk-ctrl. > Once the device tree is migrated to the new bindings, the old one > becomes harmless, but still works with old device trees lacking the > blk-ctrl. That makes sense. In my head, I wasn't thinking about > mixing older device trees. Exactly. While most people don't use it this way, the kernel and DT are supposed to be independent, e.g. the DTB could be included in the device firmware, while the kernel could be updated via a distro. To not break this use-case without a good reason, new kernels should try to not regress functionality with a existing binary DT. We can mandate DT updates for new functionality (like being able to use the G2 core only with the new blk-ctrl + split VPU binding), but we shouldn't break existing features if there isn't a very good reason to do so. Keeping the bit of code in the VPU driver to keep the old G1 only decoding working with a new kernel isn't much of a burden IMHO, so we should try to keep it alive. Regards, Lucas _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip 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 38620C433F5 for ; Tue, 7 Dec 2021 14:53:05 +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:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3zsfjhPUFFoX6DSn0YO8bF5RYb8gUka9KXOUQyxORPE=; b=Yn/MbgUsT/367s SpGcxqfJPntpkpfWHjXvxwyBFq2ntvIH8/3K/iWbvha2rU1RhVzBLk38+mDZAtukJK0FF7SNYmSgC K37MVK5iqHf63CnZOGUxp96TAR8hxLQqa+CeD1gFz0qSmQpBTRSY+q09yc+MtROnUButZ4L74nO1W CCopraT+Scveo5/eWZqjvMYl4sGfEvestV2WRLiMa8uZ5pcNg8aM6T4yEEQZIf417nWssKYCX9gFr 3RRYMay4L7RwO6wwX940BMPlJscXV0M1enZIErNMbGP0v2E8ewtZW+k13/A8qtnTK6N/ueaQTbp/6 PlfYVw0mxleAU1xgCDcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mubnq-0091Kp-VW; Tue, 07 Dec 2021 14:50:48 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mubH0-008tK5-7R for linux-arm-kernel@lists.infradead.org; Tue, 07 Dec 2021 14:16:52 +0000 Received: from gallifrey.ext.pengutronix.de ([2001:67c:670:201:5054:ff:fe8d:eefb] helo=[IPv6:::1]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mubGp-0001MK-F4; Tue, 07 Dec 2021 15:16:39 +0100 Message-ID: <3723dba86bc8c4ac4147d766787c926af486103f.camel@pengutronix.de> Subject: Re: [RFC V2 5/6] media: hantro: split i.MX8MQ G1 and G2 code From: Lucas Stach To: Adam Ford Cc: Ezequiel Garcia , linux-media , Chris Healy , Benjamin Gaignard , Hans Verkuil , Philipp Zabel , Mauro Carvalho Chehab , Rob Herring , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Greg Kroah-Hartman , "open list:HANTRO VPU CODEC DRIVER" , devicetree , arm-soc , Linux Kernel Mailing List , "open list:STAGING SUBSYSTEM" Date: Tue, 07 Dec 2021 15:16:37 +0100 In-Reply-To: References: <20211207015446.1250854-1-aford173@gmail.com> <20211207015446.1250854-6-aford173@gmail.com> <6e41beec102951ea057ba1af02ef4aaad40bd0dc.camel@pengutronix.de> User-Agent: Evolution 3.40.4 (3.40.4-1.fc34) MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:201:5054:ff:fe8d:eefb X-SA-Exim-Mail-From: l.stach@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-arm-kernel@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211207_061650_348882_B793F891 X-CRM114-Status: GOOD ( 50.78 ) 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="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 Am Dienstag, dem 07.12.2021 um 08:07 -0600 schrieb Adam Ford: > > > > > > [...] > > > > > > I think it's important to clarify that you are breaking support > > > > > > for the previous device-tree binding. Not only because of the compatible > > > > > > string change, but because the binding is now quite different. > > > > > > > > > > > > Note that in the past Benjamin tried to avoid this. > > > > > > IIRC, his proposal was backwards compatible. > > > > > > > > > > I was looking at how to do this, but the stand-alone vpu bindings did > > > > > the reset and the fuses manually, it causes issues. When the block > > > > > control is enabled those memory locations for the resets and fuses are > > > > > assigned to the blk-ctrl driver, so attempting to access them from a > > > > > different driver was a violation. > > > > > > > > > > When I started looking at this, the stand-alone VPU was trying to be > > > > > both G1 and G2, but when I was testing it before I made changes, I > > > > > didn't see the G2 function at all. When I was done the G2 seemed to > > > > > work, so it seems like this is an improvement. If you want me to keep > > > > > the previous compatible flag, I could rename the nxp,imx8mq-vpu-g1 > > > > > back to nxp,imx8mq-vpu and remove the reset/fuse controls, but I'd > > > > > have to add the blk-ctrl reference, so it seemed to me like a better > > > > > alternative to deprecate the old binding/driver and replace it with > > > > > the new one because of the significant changes. Since I'd like to > > > > > rebase the i.MX8M Mini I did on this work, it seemed weird to have > > > > > nxp,imx8mq-vpu, nxp,imx8mq-vpu-g2, nxp,imx8mm-vpu-g1, and > > > > > nxp,imx8mm-vpu-g2 where the only one without a Gx name was the > > > > > original 8MQ binding but limited to G1 functionality and the G2 > > > > > stripped out. > > > > > > > > I would very much appreciate if we could keep the driver code for the > > > > old binding. It does not need to have any new additional functionality, > > > > but just keep the existing G1 h.264 decode when booted on a old DT with > > > > the old VPU description and no blk-ctrl, so we don't regress > > > > functionality when a new kernel is booted with a old DT. > > > > > > > > New functionality with the G2 can depend on the new VPU binding and the > > > > blk-ctrl driver. > > > > > > How does that work when both the original VPU and the blk-ctrl attempt > > > to manipulate the reset and clock lines? The original binding for the > > > vpu was assigned: > > > > > > reg = <0x38300000 0x10000>, > > > <0x38310000 0x10000>, > > > <0x38320000 0x10000>; > > > reg-names = "g1", "g2", "ctrl"; > > > > > > If G2 is going to run from 38310000 and vpu-blk-ctrl run from > > > 38320000, they'll collide. > > > > > It's not going to work, but it also doesn't have to. Either you have a > > old DT where the VPU driver will poke the blk-ctrl registers, but no > > blk-ctrl driver, or you have a new DT where the VPU driver leaves the > > blk-ctrl region alone and the blk-ctrl driver needs to handle it. > > > > Just don't support mixing the old VPU DT binding with the new blk-ctrl > > way of doing things. The only thing that needs to keep working is a > > unchannged old DT, where the VPU uses the old binding, but no blk-ctrl > > is present as a separate node. > > I think I understand. I'll leave the old code for the old binding in > the driver and add the new code for the new bindings with blk-ctrl. > Once the device tree is migrated to the new bindings, the old one > becomes harmless, but still works with old device trees lacking the > blk-ctrl. That makes sense. In my head, I wasn't thinking about > mixing older device trees. Exactly. While most people don't use it this way, the kernel and DT are supposed to be independent, e.g. the DTB could be included in the device firmware, while the kernel could be updated via a distro. To not break this use-case without a good reason, new kernels should try to not regress functionality with a existing binary DT. We can mandate DT updates for new functionality (like being able to use the G2 core only with the new blk-ctrl + split VPU binding), but we shouldn't break existing features if there isn't a very good reason to do so. Keeping the bit of code in the VPU driver to keep the old G1 only decoding working with a new kernel isn't much of a burden IMHO, so we should try to keep it alive. Regards, Lucas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel