Message ID | 20230119-rk3568-rga-v1-2-43d4d14365e6@pengutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp95503wrn; Fri, 20 Jan 2023 01:16:03 -0800 (PST) X-Google-Smtp-Source: AMrXdXvOhzRIPzRnYos/qcuCXn3QeQnQ2uXuQGm+PftTlOjlF1JMPboL9xC9mhovWrEhToGr+9Lb X-Received: by 2002:a17:907:1107:b0:870:e329:5f2f with SMTP id qu7-20020a170907110700b00870e3295f2fmr14587894ejb.51.1674206163704; Fri, 20 Jan 2023 01:16:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674206163; cv=none; d=google.com; s=arc-20160816; b=yM0XqK/8olAASwZuaGwod/jfpRvkN0WlcZkXTI8sVshgi7byiD/rZt9FjCFZMtrNwW tP9ixvGea74vUWkeZ5qfGLw+ssdQc4vXuKNrm1S0AsX9dTBkGFSeFBtXhCdZwMQL05cY etTun958PCCfTm51QkMHSK7YkaQDizJKgEu5XbkeJ1Gi2VCC/jZMFQFcJEqKeKjX9QFd iE8JOwuBnq6QdE8FvDjj31Zyb6zyDziLay4QwQioMPt2JFFKXBC5vKtNesdUdeq0ccJf VqVwnbbBo2bqXdoTutW9i8uQbQLMV2nWPQl2SbutfWdFyDuArKAhibwHrVOMMUiPJ9bT mK7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from; bh=iluUZMu4oDqFyHXnV6SpcJUQbsFRrpGMEAnMLOPsUkI=; b=tb6iY9DU26M5ZynQe4GdawJHTOSGHa77isQc6FUHBNo0A1Coi0ex83drSJP6fbVHdY Dhk6mYigean4j8BGQE2bv8AWFtweZ/jzhUW3gV+TGer30ejc1fQve2VdRngTM4d+/JZz s3ejz/GjFm9gbmh3Lh3AOLM4tXc52UlJMnZaOaTvxbFh2zL3GB+jU9D7wlizdrDGiCwZ H6WS9eKlH9HoYXZgkv5ZTRj8ztcc2sRP//RfRiIXbDzG0MXfgzNcTZqX0xG7UnhUrAg4 rUrq89n7MsSgcxu4KBLoKf8k11AwYcMyUp0ZKIH6nzytB+WTBVFzoDuK4o1YilGyazSZ KmRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f19-20020a056402195300b0049defeaec6dsi21461281edz.530.2023.01.20.01.15.40; Fri, 20 Jan 2023 01:16:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230023AbjATJPP (ORCPT <rfc822;changwoo.m@gmail.com> + 99 others); Fri, 20 Jan 2023 04:15:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229967AbjATJPH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Jan 2023 04:15:07 -0500 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 678528BA92 for <linux-kernel@vger.kernel.org>; Fri, 20 Jan 2023 01:14:47 -0800 (PST) Received: from dude05.red.stw.pengutronix.de ([2a0a:edc0:0:1101:1d::54]) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from <m.tretter@pengutronix.de>) id 1pInTg-0001QK-Bq; Fri, 20 Jan 2023 10:14:28 +0100 From: Michael Tretter <m.tretter@pengutronix.de> Date: Fri, 20 Jan 2023 10:14:22 +0100 Subject: [PATCH RESEND 2/2] arm64: dts: rockchip: Add RGA2 support to rk356x MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230119-rk3568-rga-v1-2-43d4d14365e6@pengutronix.de> References: <20230119-rk3568-rga-v1-0-43d4d14365e6@pengutronix.de> In-Reply-To: <20230119-rk3568-rga-v1-0-43d4d14365e6@pengutronix.de> To: Jacob Chen <jacob-chen@iotwrt.com>, Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>, Mauro Carvalho Chehab <mchehab@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Heiko Stuebner <heiko@sntech.de> Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Nicolas Frattaroli <frattaroli.nicolas@gmail.com>, Michael Tretter <m.tretter@pengutronix.de> X-Mailer: b4 0.11.2 X-SA-Exim-Connect-IP: 2a0a:edc0:0:1101:1d::54 X-SA-Exim-Mail-From: m.tretter@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755532402280756213?= X-GMAIL-MSGID: =?utf-8?q?1755532402280756213?= |
Series |
media: rockchip: rga: Add rk3568 support
|
|
Commit Message
Michael Tretter
Jan. 20, 2023, 9:14 a.m. UTC
The rk3568 also features a RGA2 block. Add the necessary device tree node. Acked-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> --- arch/arm64/boot/dts/rockchip/rk356x.dtsi | 11 +++++++++++ 1 file changed, 11 insertions(+)
Comments
Hello Michael, Since we have the over-4GB problem now, should we mark this problem as a TODO or something? Shengyu
Hi, On Sun, 22 Jan 2023 00:50:37 +0800, Shengyu Qu wrote: > Since we have the over-4GB problem now, should we mark this problem as a > TODO or something? I am not really sure where to put such a TODO to make it visible for people that are running into the issue and to make sure that it is removed once it is fixed. Maybe it would be better to add error handling to the rga_buf_map function to fail if the address of the buffer that should be mapped has the upper 32 bit set and print a warning. Furthermore, the driver would be able to skip the buffer and prevent potential memory corruption caused by the erroneous mapping. Unfortunately, I don't have hardware that allows me to test this. Michael
Hi Michael, Seems we could use GFP_DMA32 flag to limit memory required by driver into upper size range(actually using ZONE_DMA32 configured by device tree). Just some driver modification needed. Maybe Nicolas could help testing? I would like to fix this, but I don't have much free time these days. Best regards, Shengyu > Hi, > > On Sun, 22 Jan 2023 00:50:37 +0800, Shengyu Qu wrote: >> Since we have the over-4GB problem now, should we mark this problem as a >> TODO or something? > I am not really sure where to put such a TODO to make it visible for people > that are running into the issue and to make sure that it is removed once it is > fixed. > > Maybe it would be better to add error handling to the rga_buf_map function to > fail if the address of the buffer that should be mapped has the upper 32 bit > set and print a warning. Furthermore, the driver would be able to skip the > buffer and prevent potential memory corruption caused by the erroneous > mapping. > > Unfortunately, I don't have hardware that allows me to test this. > > Michael
Hi Shengyu, On Fri, 17 Feb 2023 22:14:13 +0800, Shengyu Qu wrote: > Seems we could use GFP_DMA32 flag to limit memory required by driver into > upper size range(actually using ZONE_DMA32 configured by device tree). Just > some driver modification needed. I don't think the GFP_DMA32 flag works with DmaBuf import. The buffer may be allocated by some other driver that is able to address more than 4G and imported into the RGA driver. In this case, limiting the allocations is not enough, but we would still need error handling in the map function for buffers that cannot be addressed by the RGA. I guess we need both, a limit for the allocation and error checking for the map. Michael > Maybe Nicolas could help testing? I would > > like to fix this, but I don't have much free time these days. > > Best regards, > > Shengyu > > > Hi, > > > > On Sun, 22 Jan 2023 00:50:37 +0800, Shengyu Qu wrote: > > > Since we have the over-4GB problem now, should we mark this problem as a > > > TODO or something? > > I am not really sure where to put such a TODO to make it visible for people > > that are running into the issue and to make sure that it is removed once it is > > fixed. > > > > Maybe it would be better to add error handling to the rga_buf_map function to > > fail if the address of the buffer that should be mapped has the upper 32 bit > > set and print a warning. Furthermore, the driver would be able to skip the > > buffer and prevent potential memory corruption caused by the erroneous > > mapping. > > > > Unfortunately, I don't have hardware that allows me to test this. > > > > Michael
Hi, Michael, > I don't think the GFP_DMA32 flag works with DmaBuf import. The buffer may be > allocated by some other driver that is able to address more than 4G and > imported into the RGA driver. In this case, limiting the allocations is not > enough, but we would still need error handling in the map function for buffers > that cannot be addressed by the RGA. > > I guess we need both, a limit for the allocation and error checking for the > map. Maybe you are right.. I haven't digged into v4l2-m2m API, so I'm not sure about it. Seems we need others' help. Shengyu
Hi folks, On Fri, Jan 20, 2023 at 10:14:22AM +0100, Michael Tretter wrote: > The rk3568 also features a RGA2 block. Add the necessary device tree > node. > > Acked-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Can this patch be merged via the media tree? I don't expect merging the other one via a different tree being an issue either, so alternatively to the 1st patch: Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Hi, Am Mittwoch, 17. Mai 2023, 20:39:08 CEST schrieb Sakari Ailus: > Hi folks, > > On Fri, Jan 20, 2023 at 10:14:22AM +0100, Michael Tretter wrote: > > The rk3568 also features a RGA2 block. Add the necessary device tree > > node. > > > > Acked-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> > > Can this patch be merged via the media tree? I don't expect merging the > other one via a different tree being an issue either, so alternatively to > the 1st patch: > > Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> thanks for the Ack. To prevent conflicts with other additions to the rk356x.dtsi file, I've picked now both patches for the rockchip tree. Thanks Heiko
On Sun, May 21, 2023 at 12:46:11PM +0200, Heiko Stübner wrote: > Hi, > > Am Mittwoch, 17. Mai 2023, 20:39:08 CEST schrieb Sakari Ailus: > > Hi folks, > > > > On Fri, Jan 20, 2023 at 10:14:22AM +0100, Michael Tretter wrote: > > > The rk3568 also features a RGA2 block. Add the necessary device tree > > > node. > > > > > > Acked-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> > > > Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> > > > > Can this patch be merged via the media tree? I don't expect merging the > > other one via a different tree being an issue either, so alternatively to > > the 1st patch: > > > > Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > thanks for the Ack. To prevent conflicts with other additions to the > rk356x.dtsi file, I've picked now both patches for the rockchip tree. Thank you!
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi index 5706c3e24f0a..704b13f7f717 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi @@ -612,6 +612,17 @@ vdpu_mmu: iommu@fdea0800 { #iommu-cells = <0>; }; + rga: rga@fdeb0000 { + compatible = "rockchip,rk3568-rga", "rockchip,rk3288-rga"; + reg = <0x0 0xfdeb0000 0x0 0x180>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru CLK_RGA_CORE>; + clock-names = "aclk", "hclk", "sclk"; + resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru SRST_H_RGA>; + reset-names = "core", "axi", "ahb"; + power-domains = <&power RK3568_PD_RGA>; + }; + vepu: video-codec@fdee0000 { compatible = "rockchip,rk3568-vepu"; reg = <0x0 0xfdee0000 0x0 0x800>;