On Thu, Jun 30, 2022 at 08:49:03PM +0100, Bryan O'Donoghue wrote:
> On 30/06/2022 20:01, Krzysztof Kozlowski wrote:
> > On 30/06/2022 14:08, Bryan O'Donoghue wrote:
> > > The existing msm8916.dtsi does not depend on nor require power-domains.
> > > Drop from the list of required.
> >
> > That's not good reason. The bindings are about hardware so the question
> > is whether being a part of power domain or toggling power domain on/off
> > is considered required for the DSI.
>
> AFAIK no but, I will check this again and if it is definitely not required,
> I'll churn the commit log to describe it better.
>
The power domain in the DSI node is used together with the OPP table to
vote for performance states depending on the clock frequency of the byte
clock. In the downstream kernel this is part of the clock driver.
In mainline this needs to be done in the consumer driver.
The MSM8916 port was never really optimized for power usage. With
incomplete interconnect support etc the power domains tend to be at
maximum state most of the time, so it does not cause any issues if you
forget to vote for performance states in some places.
In general, the situation on MSM8916/MSM8939 is not really any different
from newer SoCs. The downstream MSM8916 gcc driver contains:
static struct rcg_clk byte0_clk_src = {
/* ... */
.c = {
/* ... */
VDD_DIG_FMAX_MAP2(LOW, 94400000, NOMINAL, 188500000),
},
};
which should be ideally translated into an OPP table with
power-domains = <&rpmpd MSM8916_VDDCX>; similar to newer SoCs.
(I'm not saying that "power-domains" should be required, just that it
could be added for MSM8916/MSM8939 if someone wants to properly
power-optimize them...)
Thanks,
Stephan
