Re: [PATCH v4 0/5] Add Qualcomm JPEG V4L2 encoder for SM8250

[Vladimir Zapolskiy]

On 7/6/26 17:12, Bryan O'Donoghue wrote:
> On 06/07/2026 14:57, Vladimir Zapolskiy wrote:
> > > This debate is going nowhere. Check the downstream you don't need the
> > > docs titan_top_gdsc is provided by CAMCC.
> >
> > There is no debate, since my arguments are not debated so far... Why?
>
> An odd claim, since this is the fourth ? level of email reply.
>
> > And at the same time you didn't provide any support to have N identical
> > spread hardware property descriptions instead of the single one.
> >
> > What is a good enough reason to prefer complexity over simplicity?
>
> I'm not sure I parse your here. The core fact is there is no "thing" in
> the CAMSS block that can be modelled as a provider to JPEG in lieu of
> TITAN_TOP_GDSC.

That's fine, I have never said the opposite.

> That GDSC is provided by CAMCC not by any other silicon block. So

That's fine.

> omitting power-domains for individual nodes is incorrect. Best practice
> and in fact the _only_ practice that can work is to list power-domains,

Let's step back and discuss hardware description of CAMSS IPs, so far
there is no point to jump to the practice.

> interconnects in the individual nodes themselves as - I've pointed out
> multiple times now - those blocks have to ramp clocks and scale voltages
> dependent on their particular use cases.

Right, you've pointed it a few times, no surprise a straw man fallacy
argument resembles as is, because it does not address or debate the
initial point of concern [1], when the absolutely excessive complexity
is proposed to be implemented for "CAMSS power island" and its IPs.

[1] https://lore.kernel.org/linux-media/e04cb9dc-76dd-4fa8-92f4-be002bf7ee8b@xxxxxxxxxx

--
Best wishes,
Vladimir