Re: [PATCH v6 3/3] arm64: dts: qcom: sm8250: Add JPEG encoder node

[Dmitry Baryshkov]

On Mon, Nov 02, 2026 at 11:28:28AM +0200, Atanas Filipov wrote:
> On Fri, Aug 21, 2026 at 12:36:26AM +0300, Dmitry Baryshkov wrote:
> > This will be true if:
> > - MMCX is a parent of the TITAN_TOP_GDSC (in Linux kernel)
> > - the driver casts the vote on the TITAN_TOP_GDSC using the opp tables.
> 
> Both hold for v7:
> 
>  - camcc-sm8250 attaches MMCX and registers TITAN_TOP_GDSC as its
>    subdomain, so a performance state set on TITAN_TOP_GDSC reaches
>    MMCX unchanged.
>  - v7 adds required-opps to every JPEG OPP entry (min_svs to turbo),
>    so dev_pm_opp_set_rate() votes the MMCX level through the single
>    TITAN_TOP_GDSC power domain.
> 
> > Checking the 4.19 kernel. cam_cc_jpeg_clk_src casts votes on the vdd_mm
> > (MMCX) power domain, while its parents (pll0, pll2) cast votes on
> > vdd_mx (MX) power domain. Note, that frequencies used by those clocks do
> > not match, so we need separate entries at each of the corners.
> 
> Agreed that the PLLs need MX. Upstream nothing votes MX for them
> today: the camcc-sm8250 binding and DT describe MMCX only, and the
> rpmhpd MMCX domain on SM8250 has no MX parent. On SM8450 and later
> the camcc node carries MXC next to MMCX.
> 
> Since MX feeds the camcc PLLs, which every camera consumer shares, I
> think that vote belongs to the camcc-sm8250 clock controller rather
> than to the jpeg-encoder node, so v7 keeps TITAN_TOP_GDSC as the only
> power domain of the JPEG node. Does that work for you?

Konrad started to work on that part, but currently all the votes belong
to the consumers, which means that end-devices should also vote on the
MX (e.g. see Iris devices).

-- 
With best wishes
Dmitry