From: Michael Tretter <m.tretter@pengutronix.de>
To: Shengyu Qu <wiagn233@outlook.com>
Cc: devicetree@vger.kernel.org, ezequiel@vanguardiasur.com.ar,
frattaroli.nicolas@gmail.com, heiko@sntech.de,
jacob-chen@iotwrt.com, krzysztof.kozlowski+dt@linaro.org,
krzysztof.kozlowski@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-rockchip@lists.infradead.org, mchehab@kernel.org,
robh+dt@kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH RESEND 2/2] arm64: dts: rockchip: Add RGA2 support to rk356x
Date: Fri, 17 Feb 2023 16:32:14 +0100 [thread overview]
Message-ID: <20230217153214.GB28242@pengutronix.de> (raw)
In-Reply-To: <TY3P286MB2611256E28AF951F2B38A5B098A19@TY3P286MB2611.JPNP286.PROD.OUTLOOK.COM>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-17 15:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 9:14 [PATCH RESEND 0/2] media: rockchip: rga: Add rk3568 support Michael Tretter
2023-01-20 9:14 ` [PATCH RESEND 1/2] media: dt-bindings: media: rockchip-rga: add rockchip,rk3568-rga Michael Tretter
2023-01-20 9:28 ` Heiko Stübner
2023-01-25 11:47 ` Ezequiel Garcia
2023-01-20 9:14 ` [PATCH RESEND 2/2] arm64: dts: rockchip: Add RGA2 support to rk356x Michael Tretter
2023-01-21 16:50 ` Shengyu Qu
2023-02-17 11:04 ` Michael Tretter
2023-02-17 14:14 ` Shengyu Qu
2023-02-17 15:32 ` Michael Tretter [this message]
2023-02-17 16:01 ` Shengyu Qu
2023-05-17 18:39 ` Sakari Ailus
2023-05-21 10:46 ` Heiko Stübner
2023-05-22 8:58 ` Sakari Ailus
2023-01-23 19:49 ` [PATCH RESEND 0/2] media: rockchip: rga: Add rk3568 support Nicolas Dufresne
2023-05-21 10:44 ` Heiko Stuebner
2023-05-21 19:32 ` Diederik de Haas
2023-05-22 10:29 ` Michael Tretter
2023-05-23 11:13 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230217153214.GB28242@pengutronix.de \
--to=m.tretter@pengutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=frattaroli.nicolas@gmail.com \
--cc=heiko@sntech.de \
--cc=jacob-chen@iotwrt.com \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=robh+dt@kernel.org \
--cc=wiagn233@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).