<bamse>
so you're sayig that the first 22 entries looks the same...but then we stop reading in the upstream driver?
<calebccff>
that's what I saw, I just added some more logging and it is being read properly, the upstream driver just handles boost frequencies properly
<calebccff>
the top 3 frequencies on the oneplus 6 are "boost" frequencies
<bamse>
am i reading the driver correctly in that we just skip those?
<calebccff>
so they hit the match on drivers/cpufreq/qcom-cpufreq-hw.c:208
<calebccff>
There's a comment on like 220 "only treat the last frequency that might be a boost as the boost frequency"
<bamse>
okay, so we can only have a single turbo frequency
<calebccff>
is that a limitation in cpufreq?
<calebccff>
also, oddly, the opp tables in sdm845.dtsi don't quite match what's read from device
<calebccff>
they match up to 2649600000, then my device goes 2707200000, 2764800000, 2784000000, 2803200000 but the dts just has 2745600000 and then the max freq
<bamse>
same on db845c
<calebccff>
does that matter? I don't see any errors about it
<calebccff>
ah i guess not because those intermediate frequencies are just ignored
<bamse>
we disable all opps, then we add the matches we find
<bamse>
so you should have 2.6496 as your highest frequency and then 2.8032 as a turbo frequency
<calebccff>
yeah that matches what i've got
<calebccff>
damn :)
<bamse>
policy4/cpuinfo_max_freq:2803200
<bamse>
policy4/scaling_max_freq:2649600
<bamse>
but if you poke a 1 into /sys/devices/system/cpu/cpufreq/boost the latter matches the prior
<bamse>
do you tell it to go fast?
<calebccff>
I did not
<calebccff>
I'll give it a poke
<calebccff>
what does policy4 refer to?
<bamse>
the cpu cluster starting with cpu4
<bamse>
i.e the big cluster
<calebccff>
ah i see, got it
<bamse>
but on the laptop we had to mark 2.95GHz as "turbo-mode"...i wonder what that does then...
<bamse>
steev: why did we mark 2.95GHz on the c630 as "turbo-mode"
<bamse>
steev: seems the code does that already for us?
<calebccff>
marks a frequency as "over [the devices] operating frequency"
<bamse>
is that good or bad? ;)
<steev>
bamse: iirc, if you don't enable that, it'll never actually boost to it
<calebccff>
ah
<bamse>
steev: so it won't use that frequency?
<calebccff>
well that answers my question
<steev>
right
<calebccff>
which was "how come I never see the boost freq unless i poke sysfs"
<bamse>
steev: so when we conclude from the hardware tables that a particular frequency is a CPUFREQ_BOOST_FREQ we must also have marked that turbo-mode for it to picked?
<steev>
that is my understanding, yes
<calebccff>
o.o
<bamse>
even with poking a 1 into boost in sysfs?
<steev>
bamse: that i'm not sure; if you want i can drop it here and see; turbo-mode documentation is kinda... meh, because it makes it seem like it can only run for a short while, not a long time, whereas with boost enabled, it runs at 2.96GHz here just fine for long(ish?) periods of time, e.g. compiling
<calebccff>
just did a whole geekbench run with boost on and it stayed at the boost freq for the whole time
<calebccff>
still got a lower score though :/
<steev>
if it's hammering the cpu, that'll do it, as long as it doesn't hit thermal limits?
<steev>
i also abuse turbo-mode on amlogic s905y(2?) to give it a 2GHz but don't enable by default so that if there isn't cooling it doesn't hang out at 70C constantly
<calebccff>
it's a little warm, but not that bad, probably shouldn't be using Android for benchmarking this
<steev>
i need to bump to 5.16.12 anyway
<bamse>
calebccff: so it reported the higher frequency in geekbench as well?
<calebccff>
it still reported whatever was in cpuinfo_max_freq
<bamse>
steev: the "problem" we see is that the last 4 frequencies in the opp table are marked as boost frequencies in the hardware, but not turbo-mode in dt...
<bamse>
calebccff: which isn't 2.8?
<bamse>
calebccff: on the db845c cpuinfo_max_freq is 2.8 always...but scaling_max drops to 2.6 without boost
<calebccff>
bamse: huh interesting, no it's 2.649 on my op6
<steev>
bamse: without turbo-mode, yes, echoing 1 into boost, it does appear to work here
<calebccff>
Should check what's in the LUT table on db845c
<bamse>
calebccff: i added some prints and got the same table as your downstream device
<calebccff>
bamse: same boost frrequencies too?
<bamse>
yes
<bamse>
well in particular 2803200000 is there
<steev>
bamse: you want me to throw a patch to remove the turbo-mode ?
<bamse>
hence the cpuinfo_max_freq i reported above
<bamse>
steev: so we've concluded that it doesn't do anything?
<steev>
well
<calebccff>
bamse: the boost frequency isn't reported as 2.8ghz on my device though
<calebccff>
sorry, the max freq*
<bamse>
steev: looks like it's only used to set CPUFREQ_BOOST_FREQ in the cpufreq table...
<bamse>
calebccff: but the lut reader finds it as LUT_TURBO_IND?
<steev>
bamse: well, with 0 in boost, it never actually bumps up to 2956800
<calebccff>
are there any good userspace tools that actually do that?
<bamse>
steev: but i think that's the correct behavior
<steev>
how is a user to know if it's not made explicit?
<calebccff>
i'd suspect that downstream makes use of it :P
<bamse>
calebccff: but then you enter that last conditional block when i is 27, right? and mark freq 26 as boost?
<calebccff>
bamse: yeah, 2.8GHz is correctly set as the boost frequency
<steev>
That’s kinda why I did it, I expected the 2.95 and was never seeing it, I didn’t realize you could just echo 1 into that file at the time
<bamse>
calebccff: no idea why it doesn't hsow up as your cpuinfo_max_freq then...
<steev>
Well
<calebccff>
bamse: i figured the boost freq and max freq being different made sense. odd that it does show up on db845c
<steev>
I’m still applying a few cpufreq patches here…
<bamse>
steev: well, iirc it wasn't entirely clear what was needed
<bamse>
steev: of course you do ;)
<calebccff>
steev: so turbo-mode is exactly the same as setting the CPUFREQ_BOOST_FREQ flag?
<steev>
calebccff: I assume yes
<steev>
Which I guess the driver does automatically for the highest frequency?
<calebccff>
steev: yeah
<steev>
That seems weird to me
<calebccff>
steev: well i stopped the driver from marking the max freq as CPUFREQ_BOOST_FREQ and set turbo-mode on it instead and now cpuinfo_max_freq is 2803200
<steev>
Right
<steev>
There’s another patch to add boost Drew’s to that list
<steev>
freqs
<steev>
Let me finish this smoke and then I’ll try to find it
<bamse>
steev: not automatically for the highest frequency, only if that happens to be marked as a LUT_TURBO_IND in the LUT by the driver
<calebccff>
drivers/opp/cpu.c sets the CPUFREQ_BOOST_FREQ flag if the max freq has the turbo-mode flag, so that much is the same
<calebccff>
except doing it that way seems to allow the boost frequency to actually be hit :D
<bamse>
and the fact that it's named "core_count" probably implies that the frequency will only be reached when a single core is active
<calebccff>
bamse: with boost=1 i had that as max freq through a whole geek bench run which i presume included multicore
<bamse>
calebccff: 2.6 or 2.8?
<calebccff>
2.8
<bamse>
calebccff: and linux will go 2.8, then the osm (cpufreq-hw) will scale that back as needed
<calebccff>
aha i see, so what linux is reporting is probably wrong?
<calebccff>
when under load like that
<bamse>
yes, and then the interrupts specified in lmh will fire and let us know that we're being throttled
<bamse>
which is reported as "thermal pressure" to the scheduler
<steev>
fwiw, at least on the c630, i've never seen it get thermal throttled
<calebccff>
bamse: ahh i see
<steev>
looks like the first commit is the one you want caleb
<bamse>
so core_count isn't a core count...it's just because it's 4 on 3 and 1 cpu clusters as well
<calebccff>
steev: yeah that looks good
<steev>
oh, actually you do want both
<calebccff>
so it seems like setting CPUFREQ_BOOST_FREQ in the cpufreq driver might be the wrong approach, and it would be better to set turbo-mode in dts - that way the boost freq is actually hit by default
<bamse>
calebccff: are you sure? i think it looks like we mark the opp entry as BOOST either way...and the boost sysfs just toggles if we should consider using them or not
<bamse>
steev: does those changes reflect the actual max frequency, or just what's presented in sysfs?
<calebccff>
bamse: disabling the LUT_TURBO_IND check and setting turbo-mode let the boost frequency be hit, beforehand it required poking sysfs to enable it
<steev>
bamse: iirc, without those patches, it always reported 2.8GHz as the max
<calebccff>
it reported 2.64 for me
<bamse>
calebccff: yeah, but i think it's by design that boost is 0...and needs to be poked
<bamse>
steev: reported or ran at...?
<steev>
well, 2.8 is what is non-boost on the c630
<bamse>
right, calebccff has 2.6 as last non-boost and 2.8 as boost
<steev>
bamse: well, i dunno that, i have no idea how to tell what frequency it's actually running at if cpufreq-info never reports it
<bamse>
and as i said above, my sysfs values changes when i change boost
<steev>
mine didn't/don't
<steev>
2.96 never shows up
<bamse>
cpuinfo_max_freq is at 2.8 (the boost) and scaling_max_freq bounces between 2.6 and 2.8 as i flip the switch
<calebccff>
bamse: dev_pm_opp_init_cpufreq_table() sets the CPUFREQ_BOOST_FREQ flag if turbo-mode is set in dts, the qcom cpufreq driver sets it based on the LUT, for some reason one of these requires poking boost to make it actually boost
<calebccff>
or android is doing it for me -_-
<calebccff>
i don't seem to have the "boost" property in sysfs anymore
<bamse>
i think that depends on you having a turbo frequency
<bamse>
cpuinfo_max_freq is at 2.8 (the boost) and scaling_max_freq() on sdm845
<bamse>
meh
<bamse>
was trying to say that we shouldn't end up in dev_pm_opp_init_cpufreq_table() on sdm845
<calebccff>
ah righttt
<calebccff>
so turbo-mode does actually do nothing then
<bamse>
that's my conclusion...
<calebccff>
well, sorry for the confusion
<calebccff>
still, does it make sense to hide the max freq behind a boost flag?
<bamse>
the way db845c shows it, that cpuinfo max is with boost, but scaling_max depends on boost makes sense to me
<bamse>
but i have no idea why it differs from what you're seeing
<calebccff>
it seems like ignoring LUT_TURBO_IND and not setting CPUFREQ_BOOST_FREQ lets the max freq be hit most of the time, LMH IRQs fire and the current frequency reflects that ~10 seconds later as the thermal pressure adjusts
<steev>
I don’t *think* that patch has made it into next yet
<calebccff>
oops, nevermind, that's an IRQ storm if ever I've seen one
<steev>
You should see the one I get with that one guy’s patches… which was something I wanted to ask bamse about
<calebccff>
steev: might be worth checking the lmh IRQs with boost enabled while under load on c630
<bamse>
calebccff: you got an storm when you're hitting the thermal throttling?
<calebccff>
bamse: seems so, probably adding print statements to the IRQ handler wasn't the best idea
<bamse>
haha, no :)
* calebccff
has a frozen device now
<steev>
bamse: ^^ without those, with the patches for usb, we hit an interrupt storm, but I’m not sure that those settings are correct?
<bamse>
steev: hmm, so linux-next should be broken on c630 now?
<steev>
Mmm, maybe? Did his patches go in?
<steev>
Last I knew he was likely spinning up a new revision
<bamse>
steev: thought the conclusion was that the changes in usb was broken
<bamse>
that said, i don't think it make sense to me that those are HIGH...
<steev>
Not sure, I mean, it does *work* with the patch above
<bamse>
you should test more without additional patches ;)
<steev>
Well without that, absolutely broken
<steev>
The c630 doesn’t even boot
<bamse>
okay, we should definitely flush that out then
<bamse>
i don't think i have merged those...
<steev>
I don’t think he’s sent a new revision but I haven’t looked at my email recently, been occupied with.. war things
<bamse>
does that help?
<bamse>
thought one was supposed to do the opposite ;)
<calebccff>
bamse: the osm actually tells you what frequency it thinks you should throttle to?
<calebccff>
changing the LMH interrupts to IRQ_TYPE_EDGE_RISING seemed to uh "fix" the storming...
<steev>
bamse: friends and family over there, so... i worry :)
<bamse>
calebccff: the lmh interrupt is supposed to be high, and we should disable it and poll the value from ther eon
<bamse>
steev: ahh, very sorry to hear that, hope they are doing okay
<bamse>
calebccff: no the osm will throttle, but it's nice to let us know that it did it
<calebccff>
bamse: ah i see, will do some more testing hopefully soon
<calebccff>
it would be nice if we could have the 2.8ghz frequency available all the time
<bamse>
calebccff: right, but for that you should just write 1 to boost in your init.rc i think
<bamse>
calebccff: and then once you start caring about battery level perhaps 0 is a better choice? although i don't know how much it costs...
<calebccff>
hm I hadn't really considered battery
<bamse>
well, it's 845...we haven't done much on that front yet...
<calebccff>
the thing with adding a write to the init.rc is then we also need to go do that on postmarketOS, mobian and whatever other distros fancy supporting our devices, fixing it in kernel would be nicer
<calebccff>
there's already a lot of userspace stuff for limiting frequencies to preserve power fwiw
<bamse>
calebccff: yeah, i don't know why it's default 0...
<bamse>
and with android it might be better to rush to completion and then power collapse the whole thing
<bamse>
but we have quite a bit of work to get there...
<calebccff>
yeah, I'm quite interested in stealing some Android ideas and applying them in postmarketOS, there's some cool cgroup stuff for prioritising in-focus apps
<bamse>
right
<bamse>
and i am quite interested, given the state of the 845/850 laptop, to make it idle harder
<bamse>
Lenovo says we can do 24 hour local video playback...i haven't measured in a while, but we are or have been at about half of that
<bamse>
so idling cpus, scaling busses, pm_runtime things not in used...there's plenty of work
<calebccff>
ah yeah, pm_suspend support for more peripherals would be really cool, haven't looked into details but for example with input devices that have wakeup support we should be suspending them when not in use
<bamse>
and then suspend/resume would be really nice, so i don't need to charge the damn thing all the time
<steev>
so, pretty much nothing but the battery driver
<bamse>
steev: that is indeed a nice list
<bamse>
right
<calebccff>
damn, modem doesn't wake up system
<bamse>
calebccff: which part of modem?
<calebccff>
how do you mean?
<bamse>
what event happened that you expected to see wake up the system
<calebccff>
i made a phone call
<calebccff>
it rung - so the modem was still on
<calebccff>
but phone stayed in suspend
<calebccff>
when i woke it up it immediately cancelled the call
<bamse>
hmm, the glink irq doesn't seem to be irq_set_wake()...thought we had that in place
<calebccff>
missing wakeup-source; in dt?
<bamse>
hmm, but it's IRQF_NO_SUSPEND...
<bamse>
we've been discussing this back and forth...not sure what the end result was though
<bamse>
i need to take a deeper look at that again :/
<steev>
srinik: that reminds me, any luck with the comp popping?
<calebccff>
bamse: that would be very helpful :D, some others hopefully will too as we're trying to get this device closer to daily-drivable
<steev>
just do it and take all the glory
<bamse>
right, just fix it!
<bamse>
:)
<bamse>
calebccff: where are you on charger and fuel gauge?
<calebccff>
bamse: hopefully rradc will get in with v9, we have a charger driver which does the basics (charger type, setting max current limit) and a fuel gauge which reads most of the battery stats
<calebccff>
the oneplus 6 is a tricky one, for some reason it just refuses to charge at more than 500mA, seems like oneplus do some funky stuff in the bootloader (dash charger related?) and I haven't figured out how to undo it
<bamse>
calebccff: upstream or work in progress?
<calebccff>
the dash charging hardware is completely separate, some stm8 MCU and a driver to mux the usb data pins to it so it can talk to the charger
<bamse>
fun...
<bamse>
why do something standard...
<calebccff>
work in progress, once rradc is in it should be fairly straightforward
<calebccff>
and i have a more... normal.. device to test things on
<bamse>
nice
<calebccff>
I really wonder if it's worth probing the SPMI lines to figure out what exactly the bootloader is doing on the op6
mort_ has quit [Server closed connection]
mort_ has joined #linux-msm
deathmist has quit [Server closed connection]
deathmist has joined #linux-msm
hexdump01 has joined #linux-msm
hexdump0815 has quit [Ping timeout: 480 seconds]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
jojo_autoboy[m] has quit [Server closed connection]
jojo_autoboy[m] has joined #linux-msm
go4godvin has quit [Server closed connection]
go4godvin has joined #linux-msm
pevik has joined #linux-msm
danct12_ has joined #linux-msm
danct12_ has quit []
Daanct12 has joined #linux-msm
Daanct12 has quit [Quit: Leaving]
ichernev[m] has quit [Server closed connection]
ichernev[m] has joined #linux-msm
Daanct12 has joined #linux-msm
Daanct12 has quit []
jhovold has joined #linux-msm
Daanct12 has joined #linux-msm
cxl000 has quit [Quit: Leaving]
Daanct12 has quit [Remote host closed the connection]
alexeymin has quit [Server closed connection]
Daanct12 has joined #linux-msm
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
enok has quit [Remote host closed the connection]
enok has joined #linux-msm
cxl000 has joined #linux-msm
pespin has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]