Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jianfeng Liu <liujianfeng1994@gmail.com>
To: sigmaris@gmail.com
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org,
	didi.debian@cknow.org, ezequiel@vanguardiasur.com.ar,
	heiko@sntech.de, krzk+dt@kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-rockchip@lists.infradead.org, liujianfeng1994@gmail.com,
	mchehab@kernel.org, p.zabel@pengutronix.de, robh@kernel.org,
	sebastian.reichel@collabora.com, sfr@canb.auug.org.au,
	nicolas@ndufresne.ca, linkmauve@linkmauve.fr
Subject: Re: Re: [PATCH v6 2/2] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588
Date: Sat, 20 Apr 2024 13:09:13 +0800	[thread overview]
Message-ID: <20240420050913.182225-1-liujianfeng1994@gmail.com> (raw)
In-Reply-To: <B9F108CF-4BC5-41A0-A28A-1CA1F4D2CD3C@gmail.com>

Hi Hugh,

Fri, 19 Apr 2024 18:28:01 +0100, Hugh Cole-Baker wrote:
>The register range at 0xfdb50000 length 0x800 includes "VEPU121 core0" encoder
>regs at offset 0 and "VDPU121" decoder regs at offset 0x400 (referring to the
>TRM v1.0 Part 1, section 5.5.1). So I think the "rockchip,rk3588-vdpu121"
>compatible isn't exactly correct to use for this entire device.

There are five vepu121 cores for jpeg encoding. And Emmanuel is doing work on
them[1]. And at the moment the driver doesn’t yet support exposing these cores
all as a single video node to userspace, so Emmanuel only exposes one single
core.

>IMO "rockchip,rk3588-vpu121" would be more appropriate if including both the
>decoder and encoder. It also raises the question of whether the decoder and
>encoder should be modeled in DT as one device like on RK3399, or separate
>devices. In the vendor DT [0] they are modeled as two devices but they share
>clocks, resets, IOMMU, and a "rockchip,taskqueue-node" value.

Now we have 5 jpeg enc cores, one from 0xfdb50000 and other four from
0xfdba00000. I tried to add a decoding only core 0xfb50400, but that does not
work. So the vpu should be defined as one node in devicetree for both encoder
and decoder like rk3399.

This vpu121 should be exactly the same as the one in rk3399 which supports both
encoding and decoding. But the current hantro driver has disabled h264 decoding
since there is anthoer decoder rkvdec on rk3399. This vpu121 is the only
decoder which supports h254 decoding on rk3588, so we can't just use the
vpu_variant from rk3399. Maybe we can use rk3399_vpu_variant back when rkvdec2
on rk3588 is supported by mainline kernel.

At the moment we can keep the compatible string same as the one from rk356x.
Since there are already jpeg enc cores at 0xfdba0000, we can ignore the one at
0xfdb50000. When rkvdec2 is supported, I will change "rockchip,rk3588-vpu121"
same as "rockchip,rk3399-vpu".

And I think changing "rockchip,rk3588-vdpu121" to "rockchip,rk3588-vpu121"
should match the hardware correctly.

[1] https://lore.kernel.org/all/20240418141509.2485053-1-linkmauve@linkmauve.fr/

Best regards,
Jianfeng

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2024-04-20  5:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18 11:10 [PATCH v6 0/2] Add hantro g1 video decoder support for RK3588 Jianfeng Liu
2024-04-18 11:10 ` [PATCH v6 1/2] dt-bindings: media: rockchip-vpu: Add rk3588 vdpu121 compatible string Jianfeng Liu
2024-04-18 11:10 ` [PATCH v6 2/2] arm64: dts: rockchip: Add Hantro G1 VPU support for RK3588 Jianfeng Liu
2024-04-19 17:28   ` Hugh Cole-Baker
2024-04-20  5:09     ` Jianfeng Liu [this message]
2024-04-26 12:49       ` Nicolas Dufresne

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=20240420050913.182225-1-liujianfeng1994@gmail.com \
    --to=liujianfeng1994@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=heiko@sntech.de \
    --cc=krzk+dt@kernel.org \
    --cc=linkmauve@linkmauve.fr \
    --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=nicolas@ndufresne.ca \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sigmaris@gmail.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