Re: [PATCH 3/4] media: qcom: camss: share VFE clock sources by the highest rate

[Atanas Filipov]

On 23/10/2026 22:41, Bryan O'Donoghue wrote:
> You're simultaneously adding a new clock to an existing list and
> introducing a behaviour change at the same time.
>
> Those two things should be split on principle.

Agreed, I will split it in v2. The grouping goes first, then a
separate patch lets the VFE set the AREG clock rate. In that order the
two VFEs never set the shared fast AHB source without the grouping in
place.

> It seems to me as a read this that the above text is the abstract
> description of at least one patch - which should have examples in the
> commit log, to make it less abstract.

Will do. For example, on SM8250 the two VFE Lite share one core clock
source, which the VFE sets to 400 or 480 MHz from the pixel rate:

  - VFE Lite 0 streams the CSID test pattern and sets the source to
    480 MHz.
  - VFE Lite 1 then starts an imx577 stream, needs only 400 MHz, and
    sets the shared source to 400 MHz under the running VFE Lite 0.

With the grouping the source stays at 480 MHz until VFE Lite 0 stops,
and then drops to the 400 MHz still requested by VFE Lite 1. Once the
VFE also sets the AREG clock rate, the same applies to the fast AHB
source shared by the AREG clocks of VFE0 and VFE1.

> What do you mean by user here, its not clear to me. Another engine ? I
> think so - you mean the JPEG has a dependency on the clocks listed in
> CAMSS ?

No, JPEG is not involved. A user is a VFE clock fed by the shared
source, so the users of the fast AHB source are the AREG clocks of
VFE0 and VFE1, both inside CAMSS. The grouping only covers the VFEs,
which is why the cover letter says that drivers outside CAMSS are not
covered.

I can rename it in v2 if a different name reads better.

> I thought we decided for full separation of JPEG and CAMSS/IFE ?

Yes, and this series keeps that: it only touches CAMSS.

Regards,
Atanas