ChanServ changed the topic of #linux-msm to:
_whitelogger has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
<Mis012[m]> uh hm, why is https://github.com/torvalds/linux/blob/master/drivers/phy/qualcomm/phy-qcom-qmp.c#L2253 not a clock driver instead of a magic sequence?
<Mis012[m]> SSC, PLL, VCO, DIV... clearly a clock
<aka_[m]> you know why
<aka_[m]> noone wants to deal and if its preset and always same....
<aka_[m]> why bother
<Mis012[m]> because mainline ought to have standards
<Mis012[m]> like "avoid magic"
<aka_[m]> then you should avoid shit like PSCI and cpufreq-hw you can deal with setting PLLs like it was done before right?
<aka_[m]> Instead of having it done in background write thousands line of code for one soc.
<Mis012[m]> and whether it's always the same is definitely debatable
<Mis012[m]> the stuff that PSCI replaced was mostly proprietary ways to do the same thing, that is offload it to TZ
<Mis012[m]> cpufreq-hw isn't too bad, if it's actually in hw
<Mis012[m]> but I wouldn't dare assume that based on it being called that
<Mis012[m]> it would sure be cleaner to at least talk PSCI to the rpm and not to TZ
lumag_ has joined #linux-msm
<konradybcio> >because mainline ought to have standards
<konradybcio> unless you're intel, amd or any other big player, eh
<Mis012[m]> pretty sure mainline has some power to leverage over them if anyone cared to do it
<konradybcio> yes they do and it should be used more frequently
<konradybcio> especially with arm soc vendors, now that they have to go mainline for various reasons
<Mis012[m]> look at fucking M$ making them run circles
<Mis012[m]> would be nice to instead force AMD and Intel to force M$ to support device trees
<Mis012[m]> and all in all stop catering their hw to M$'s dubious sw architecture decisions
<Mis012[m]> konradybcio: mainline managed to force qcom to support PSCI... funnily enough, that would actually be a downgrade if they didn't already do the same ugly thing just in their own way
<Mis012[m]> but I guess noone would do power management in Linux anyway if they use TZ at all
<konradybcio> tz is not mandatory, but it's very convenient for the vendor
<Mis012[m]> well... not sure if PSCI allows for doing power management in RPM sw for example...
<Mis012[m]> or is there some standardized way to bring up cores on aarch64 that Linux cannot use solely because it's not allowed to by XPUs/SMMUs?
<Mis012[m]> I mean, it would make sense if there was...
<Mis012[m]> but I don't think I saw it in the allowed options for CPU core power management on aarch64
jhovold has quit [Ping timeout: 480 seconds]
<konradybcio> there is none to my knowledge
<konradybcio> and psci was created to make linux think there is one
cxl000 has quit [Server closed connection]
cxl000 has joined #linux-msm
Danct12 has quit [Server closed connection]
Danct12 has joined #linux-msm
<Mis012[m]> sad...
<Mis012[m]> you'd think at least Cortex CPU cores would have a de facto standardized bringup
<konradybcio> it's not about the CPUs themselves, everything depends on the wider picture, as things like power rails are SoC-dependent