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

[Atanas Filipov <atanas.filipov@oss.qualcomm.com>]

On 11/2/2026 12:31 PM, Dmitry Baryshkov wrote:
> 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).
> 
Thank you for the clarification! I will add the domain in the next patch 
series.

Regards,
Atanas