Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Zhentao Guo via B4 Relay" <devnull+zhentao.guo.amlogic.com@kernel.org>
Cc: linux-amlogic@lists.infradead.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org, robh@kernel.org,
	neil.armstrong@linaro.org
Subject: Re: [PATCH RFC RESEND v5 5/6] arm64: dts: amlogic: Add video decoder driver support for S4 SOCs
Date: Tue, 26 May 2026 10:38:19 +0000	[thread overview]
Message-ID: <20260526103819.AFEA71F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260526-b4-s4-vdec-upstream-v5-5-33bc817f93f4@amlogic.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The patch silently introduces an `optee` node which is not mentioned in the commit message, and places it incorrectly at the root of the device tree.
- [Low] The newly added `canvas` and `video-codec` nodes break the expected unit-address sorting within the `soc` simple-bus node.
--

commit 9f1bc8bd76d58f7598508700fcc37888ae1dbf0f
Author: Zhentao Guo <zhentao.guo@amlogic.com>

arm64: dts: amlogic: Add video decoder driver support for S4 SOCs

This commit adds the vdec node to enable Amlogic V4L2 stateless video
decoder support for S4 SOCs. It also introduces an optee node and a canvas
node required for the decoder.

> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> @@ -96,6 +96,11 @@ saradc: adc@fe026000 {
>  		status = "disabled";
>  	};
>  
> +	optee {
> +		compatible = "linaro,optee-tz";
> +		method = "smc";
> +	};

[Severity: Medium]
Should this optee node addition be explicitly mentioned in the commit
message? The commit description currently only mentions adding the vdec
node.

Also, should this node be placed under a firmware node instead of at the root
level of the device tree?

>  	soc {
>  		compatible = "simple-bus";
>  		#address-cells = <2>;

[ ... ]

> @@ -907,5 +912,34 @@ emmc: mmc@fe08c000 {
>  			assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C>;
>  			assigned-clock-rates = <24000000>;
>  		};
> +
> +		canvas: video-lut@fe036048 {
> +			compatible = "amlogic,canvas";
> +			reg = <0x0 0xfe036048 0x0 0x14>;
> +		};
> +
> +		video-codec@fe320000 {

[Severity: Low]
Does appending these nodes break the expected unit-address sorting within the
soc simple-bus node? The canvas node at fe036048 and the video-codec node at
fe320000 appear to be placed at the end of the block, after mmc@fe08c000,
rather than being ordered sequentially.

> +			compatible = "amlogic,s4-vdec";
> +			reg = <0x0 0xfe320000 0x0 0x10000>,
> +			      <0x0 0xfe036000 0x0 0x20>;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-b4-s4-vdec-upstream-v5-0-33bc817f93f4@amlogic.com?part=5

  reply	other threads:[~2026-05-26 10:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  8:40 [PATCH RFC RESEND v5 0/6] Add Amlogic stateless H.264 video decoder for S4 Zhentao Guo via B4 Relay
2026-05-26  8:40 ` [PATCH RFC RESEND v5 1/6] firmware: meson: sm: Add video firmware loading SMC call Zhentao Guo via B4 Relay
2026-05-26  9:01   ` sashiko-bot
2026-05-26  8:40 ` [PATCH RFC RESEND v5 2/6] firmware: meson: sm: video firmware loading via secure monitor Zhentao Guo via B4 Relay
2026-05-26  9:18   ` sashiko-bot
2026-05-26  8:40 ` [PATCH RFC RESEND v5 3/6] media: dt-bindings: Add Amlogic V4L2 video decoder Zhentao Guo via B4 Relay
2026-05-26  9:29   ` sashiko-bot
2026-05-26  8:40 ` [PATCH RFC RESEND v5 4/6] decoder: Add V4L2 stateless H.264 decoder driver Zhentao Guo via B4 Relay
2026-05-26 10:04   ` sashiko-bot
2026-05-26  8:40 ` [PATCH RFC RESEND v5 5/6] arm64: dts: amlogic: Add video decoder driver support for S4 SOCs Zhentao Guo via B4 Relay
2026-05-26 10:38   ` sashiko-bot [this message]
2026-05-26  8:40 ` [PATCH RFC RESEND v5 6/6] arm64: defconfig: Enable CONFIG_VIDEO_AMLOGIC_VDEC Zhentao Guo via B4 Relay
2026-05-26 10:52   ` sashiko-bot

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=20260526103819.AFEA71F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=devnull+zhentao.guo.amlogic.com@kernel.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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