Schimsalabim has quit [Read error: Connection reset by peer]
apritzel has quit [Quit: Leaving]
Schimsalabim has joined #linux-sunxi
geosback has joined #linux-sunxi
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
gsz has joined #linux-sunxi
wens has quit [Remote host closed the connection]
wens has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
wens has quit [Remote host closed the connection]
wens has joined #linux-sunxi
<machinehum>
hullo
<machinehum>
I was reading about cpufreq, when it talks about changing voltages it this done inside the SOC? Or the external AXP* module?
<machinehum>
I've never tried this before but trying to lower power consumption on the thing I'm working on
<gnarface>
i don't actually know, but i think it's done in the AXP* module, based on the fact that i know they need drivers
<gnarface>
(sorry, only bothering you with a response because i think everyone else here is asleep right now)
<machinehum>
gnarface: All good :)
<machinehum>
I'm just wondering, because my board doesn't use those modules
<machinehum>
So I'm just wondering if things will still work
<machinehum>
But I mean the answer is, I should try.
<gnarface>
just be careful not to give it too much juice!
parthiban has joined #linux-sunxi
<machinehum>
hmm
<machinehum>
I'll try
<gnarface>
i couldn't even be sure there's any standardization of such task designation between different devices, i just think i remember that the axp-* drivers kept coming up related to battery charging and screen flickering issues in early development for various pine64 devices
Schimsalabim has quit [Ping timeout: 480 seconds]
<gnarface>
so at least in some cases i'm pretty sure there's voltage control going on in there, but i couldn't be sure it's a mutually exclusive type thing
Schimsalabim has joined #linux-sunxi
<parthiban>
MasterR3C0RD: Regarding the syscon node patch, will you be able to send v2 before Chritmas. I would like to send my display patches to get initial reviews based on it. Thanks.
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
mripard has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
machinehum: gnarface: voltage for the CPU cores is a power input pin on all known Allwinner SoCs, so the supply must come from outside
<apritzel>
in the simplest case you have a 1.1V (or so) fixed regulator on the board, and declare that in the DT
<apritzel>
DVFS is based on (voltage,frequency) pairs, though voltage could be a range. Since the voltage goes squared into the power equation, there are quite some savings by making this adjustable
<apritzel>
some (older) boards have a separate adjustable regulator for the CPUs (sun50i-h5-orangepi-pc2.dts), some have a simple switch between two fixed voltages (sun8i-h3-orangepi-one.dts)
<apritzel>
machinehum: so you can still have DVFS, but with less savings (since you can only adjust the frequency)
<apritzel>
not sure from the top of my head if the existing OPP tables would work with a fixed voltage, or if we would need to explicitly specify a range in there to make the framework accept that
<apritzel>
in the worst case you could just override the OPP tables in your DT
<apritzel>
dsimic: yes, replies from Krzysztof are a known problem ;-) He is quite busy with *all* those DT changes descending on him, and those terse answers are actually among the least problematic ones ;-)
<dsimic>
apritzel: oh, I fully understand he's busy, but taking extra ~30 seconds per response would make a world of difference
<dsimic>
to add a few more kind words :)
<dsimic>
regarding the DVFS voltages, the framework compares the OPP voltages (or the OPP voltage ranges) and the capabilities of the associated regulator, and allows only those OPPs for which the associated regulator is capable of providing appropriate voltage
<apritzel>
dsimic: I now wonder if that's the difference between the three cell microvolt property we use for the H6 and the single cell one used for the H616 ...
<dsimic>
apritzel: here's a quotation from opp-v2-base.yaml:
<dsimic>
65 A single regulator's voltage is specified with an array of size one or three.
<dsimic>
66 Single entry is for target voltage and three entries are for <target min max>
<dsimic>
67 voltages.
<dsimic>
size-one array is what I referred earlier to as "compares the OPP voltages"
<dsimic>
and the size-three array relates to "or the OPP voltage ranges" as I referred to it above
<dsimic>
where "target" is the best voltage, if it can be configured, while "min" and "max" define the permissible range
<apritzel>
so a lot of bits and bobs for just saying "... or any higher voltage" ;-)
<dsimic>
or lower :)
<dsimic>
though, configuring a lower voltage wouldn't make much sense
<apritzel>
well, typically the voltage given for an OPP is the lowest possible
<dsimic>
but it would still be possible, technically
<dsimic>
indeed
<apritzel>
I see that, but I thought that "a higher voltage works as well, but is just less efficient" is a generally true statement, and nothing that needs to explicitly spelled out in each DT
<apritzel>
I mean in this much detail
<dsimic>
higher voltages should always work, with more energy wasted, of course
<apritzel>
so it would be sufficient to specify a max allowed core voltage *once*, for all OPPs, and then the framework automatically creates the ranges from that
<dsimic>
perhaps sometimes having the ability to say "don't ever go above the exact OPP voltage" (or above some other value, i.e. "max") is the expected behavior
<dsimic>
I'll keep thinking about the possible scenarios in which that may be desirable
<dsimic>
for now, I see none :)
<dsimic>
though, it's too late now for any changes, the bindings are set in stone
<apritzel>
maybe it's just the usual "most generic solution", covering every possible scenario, without introducing special properties for everything that might come up in the future
<dsimic>
might be, it's really generic
<apritzel>
not necessarily, we can change them, as long as they stay compatible. And I think the one vs three cell microvolt properties are generic already, so we could switch them if needed
<apritzel>
but I have a feeling that machinehum is not actually looking at an H616 SoC?
dsimic is now known as Guest3462
dsimic has joined #linux-sunxi
<dsimic>
sorry, I've been disconnected for a few minutes
<dsimic>
in general, the OPP voltage ranges are useful only for the designs that share the same regulator between two different rails
<dsimic>
such as the GPU and NPU on some Rockchip boards
Guest3462 has quit [Ping timeout: 480 seconds]
<dsimic>
you're right, we could introduce opp-microvolt-max as a new property, for example, and avoid the ranges entirely
<dsimic>
I'll start working on a related project soon, hopefully, and I'll see to implement that along the way
<dsimic>
it would simplify the OPP lists a lot
<dsimic>
when opp-microvolt-max is specified, it would apply to all OPPs, which would then be size-one arrays
<dsimic>
on my TODO list is already to add debug messages emitted when the "target" voltages end up unused, i.e. when the more generous ["min", "max"] ranges end up used
<dsimic>
those should be highly useful during the bringup phases of the boards, because that might reveal some DT issues