From: Igor Paunovic <royalnet026@gmail.com>
To: support <support@armdesigner.com>
Cc: Igor Paunovic <royalnet026@gmail.com>,
Sandy Huang <hjc@rock-chips.com>,
Heiko Stuebner <heiko@sntech.de>,
Andy Yan <andy.yan@rock-chips.com>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Chaoyi Chen <chaoyi.chen@rock-chips.com>,
Alexey Charkov <alchark@flipper.net>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
dri-devel <dri-devel@lists.freedesktop.org>,
linux-rockchip <linux-rockchip@lists.infradead.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] drm/rockchip: vop2: Scale the AXI clock to the bandwidth the mode needs
Date: Wed, 19 Aug 2026 12:02:47 +0200 [thread overview]
Message-ID: <20260819100249.7945-1-royalnet026@gmail.com> (raw)
In-Reply-To: <2026081916331211222713@armdesigner.com>
Hi Owen,
Thank you - and thank you for bringing this to the list. A fanless
RK3588J chassis at 60C ambient running dual HDMI plus DP is a far
stronger argument for scaling this clock than my bench ever was, and
the +3-5C junction delta at 750 MHz is exactly the number the
power/thermal side of this discussion was missing.
On your question - both, sequenced, because they answer different
questions:
- The BSP 6.1 48h soak first. That is your production reality and it
needs no bring-up; what it buys is the real-world deployment
evidence, and with your permission I will cite it in the v3 cover
letter alongside the multi-CRTC tearing observation.
- The mainline clean-room run when your DTS bring-up is ready. v3 will
be against drm-misc-next, and that run is the one I would attach
your Tested-by to, so the tag attests the tree the patch actually
targets. No rush on this one - if it lands during the v3 review
cycle rather than before it, that is still perfect timing.
I will CC you on v3. It will state the FRL/ACLK relationship
explicitly (on my board the HDMI FRL path holds the clock at 750 MHz
independently, which is why the DP path was the one that exposed the
scaling gap), and it will pick one direction for commit_setup vs
commit_tail and defend it in the cover letter - the question to the
maintainers about a rockchip-wide hook pair is still open, and v3
cannot wait on it forever.
Regards,
Igor
WARNING: multiple messages have this Message-ID (diff)
From: Igor Paunovic <royalnet026@gmail.com>
To: support <support@armdesigner.com>
Cc: Igor Paunovic <royalnet026@gmail.com>,
Simona Vetter <simona@ffwll.ch>, Heiko Stuebner <heiko@sntech.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Maxime Ripard <mripard@kernel.org>,
Sandy Huang <hjc@rock-chips.com>,
Alexey Charkov <alchark@flipper.net>,
linux-rockchip <linux-rockchip@lists.infradead.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Andy Yan <andy.yan@rock-chips.com>,
Chaoyi Chen <chaoyi.chen@rock-chips.com>,
David Airlie <airlied@gmail.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] drm/rockchip: vop2: Scale the AXI clock to the bandwidth the mode needs
Date: Wed, 19 Aug 2026 12:02:47 +0200 [thread overview]
Message-ID: <20260819100249.7945-1-royalnet026@gmail.com> (raw)
In-Reply-To: <2026081916331211222713@armdesigner.com>
Hi Owen,
Thank you - and thank you for bringing this to the list. A fanless
RK3588J chassis at 60C ambient running dual HDMI plus DP is a far
stronger argument for scaling this clock than my bench ever was, and
the +3-5C junction delta at 750 MHz is exactly the number the
power/thermal side of this discussion was missing.
On your question - both, sequenced, because they answer different
questions:
- The BSP 6.1 48h soak first. That is your production reality and it
needs no bring-up; what it buys is the real-world deployment
evidence, and with your permission I will cite it in the v3 cover
letter alongside the multi-CRTC tearing observation.
- The mainline clean-room run when your DTS bring-up is ready. v3 will
be against drm-misc-next, and that run is the one I would attach
your Tested-by to, so the tag attests the tree the patch actually
targets. No rush on this one - if it lands during the v3 review
cycle rather than before it, that is still perfect timing.
I will CC you on v3. It will state the FRL/ACLK relationship
explicitly (on my board the HDMI FRL path holds the clock at 750 MHz
independently, which is why the DP path was the one that exposed the
scaling gap), and it will pick one direction for commit_setup vs
commit_tail and defend it in the cover letter - the question to the
maintainers about a rockchip-wide hook pair is still open, and v3
cannot wait on it forever.
Regards,
Igor
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-08-19 10:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 9:45 [PATCH v2] drm/rockchip: vop2: Scale the AXI clock to the bandwidth the mode needs Igor Paunovic
2026-08-13 9:45 ` Igor Paunovic
2026-08-13 10:00 ` sashiko-bot
2026-08-13 10:13 ` Igor Paunovic
2026-08-13 10:13 ` Igor Paunovic
2026-08-14 1:18 ` Chaoyi Chen
2026-08-14 1:18 ` Chaoyi Chen
2026-08-19 8:33 ` support
2026-08-19 8:33 ` support
2026-08-19 10:02 ` Igor Paunovic [this message]
2026-08-19 10:02 ` Igor Paunovic
-- strict thread matches above, loose matches on Subject: below --
2026-08-18 3:48 support
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=20260819100249.7945-1-royalnet026@gmail.com \
--to=royalnet026@gmail.com \
--cc=airlied@gmail.com \
--cc=alchark@flipper.net \
--cc=andy.yan@rock-chips.com \
--cc=chaoyi.chen@rock-chips.com \
--cc=cristian.ciocaltea@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=simona@ffwll.ch \
--cc=support@armdesigner.com \
--cc=tzimmermann@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.