ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
vagrantc has quit [Quit: leaving]
Tenkawa has quit [Quit: Was I really ever here?]
kevery has joined #linux-rockchip
kevery has quit [Client Quit]
kevery has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
stikonas has quit [Ping timeout: 268 seconds]
camus has joined #linux-rockchip
lurchi_ is now known as lurchi__
camus has quit [Quit: camus]
camus has joined #linux-rockchip
wens_ is now known as wens
kevery has quit [Quit: kevery]
kevery has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 256 seconds]
SallyAhaj has quit [Remote host closed the connection]
SallyAhaj has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
ldevulder has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 268 seconds]
camus has joined #linux-rockchip
camus1 has quit [Ping timeout: 256 seconds]
matthias_bgg has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Read error: Connection reset by peer]
camus has joined #linux-rockchip
camus1 has quit [Ping timeout: 240 seconds]
camus1 has joined #linux-rockchip
camus has quit [Read error: Connection reset by peer]
camus has joined #linux-rockchip
camus1 has quit [Ping timeout: 240 seconds]
stikonas has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 245 seconds]
matthias_bgg has joined #linux-rockchip
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
camus1 has joined #linux-rockchip
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
camus has quit [Remote host closed the connection]
camus has joined #linux-rockchip
montjoie has quit [Quit: leaving]
camus has quit [Quit: camus]
Tenkawa has joined #linux-rockchip
Tenkawa has quit [Quit: ... ... ... ... ...]
SallyAhaj has quit [Remote host closed the connection]
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
Tenkawa has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
matthias_bgg has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
matthias_bgg has joined #linux-rockchip
SallyAhaj has joined #linux-rockchip
lurchi__ is now known as lurchi_
vagrantc has joined #linux-rockchip
zoiahorn has quit [Remote host closed the connection]
zoiahorn has joined #linux-rockchip
SallyAhaj has quit [Remote host closed the connection]
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
lopsided98_ has quit [Remote host closed the connection]
lopsided98 has joined #linux-rockchip
unkraut_ has quit [Remote host closed the connection]
unkraut has joined #linux-rockchip
f476 has quit [Ping timeout: 240 seconds]
f476 has joined #linux-rockchip
mrjay has joined #linux-rockchip
<mrjay> hi
psydroid has joined #linux-rockchip
<mrjay> does changing CPU frequency works on rockchip boards?
<mrjay> I'm getting EBUSY error
<Tenkawa> which distrib?
<Tenkawa> It is working here in 64 bit debian
<Tenkawa> on a rk3399 rockpro64
<mrjay> ubuntu with my kernel, cpu armv7
<mps> mrjay: it works long time for rk3399 in my box
<mps> oh, armv7, no idea
<mrjay> maybe could someone check on rk3188 or rk3036 or rk3288
mrjay has quit [Quit: Client closed]
SallyAhaj has joined #linux-rockchip
<urja> "changing"? like yeah the schedutil governor is happily doing it on my rk3288 laptop but i'm not sure what one would do to get the EBUSY ...
<urja> I mean cpupower frequency-set works... (set governor to performance, and set a frequency worked)
<robmur01> I'm guilty of not even changing the governor and just setting scaling_{min,max}_freq to whatever :)
ente` has quit [Ping timeout: 252 seconds]
ente has joined #linux-rockchip
<robmur01> just fired up the RK3288 box, and sure enough switching to userspace governor and setting a specific speed the "proper" way works just fine too
<Tenkawa> robmur01: yeah the only reference I can even find to EBUSY is from a kernel change years and years ago
mrjay has joined #linux-rockchip
<mrjay> Tenkawa: kernel is brand new
<mrjay> thank you guys for reporting
<Tenkawa> mrjay: no.. my point is the "message
<Tenkawa> er message isn't in the code
<Tenkawa> it was patched years ago
<mrjay> ahh ok
<Tenkawa> 2014
<Tenkawa> So instead of returning EBUSY we return 0 to stop the
<Tenkawa> governor from changing the frequency without alerting a failure to
<Tenkawa> do the same on reboot, as this is not an errorneaos condition.
<Tenkawa> they changed that behaviour
<Tenkawa> I have never seen an EBUSY exit from a cpufreq call myself personally
<robmur01> looking at the cpufreq sysfs code, it looks like it can still return -EBUSY if something is hogging the CPU hotplug lock
stikonas has quit [Read error: Connection reset by peer]
<Tenkawa> robmur01: interesting.. spinlock condition?
<Tenkawa> I wonder if he tries soft disabling the non-primary cpu's through /sys and see if that frees it up
stikonas has joined #linux-rockchip
* Tenkawa is debugging a few 5.17 kernel bugs at the moment
<Tenkawa> so I have definitely already seen some fun to come
<mrjay> it's weird, maybe my board is broken
<robmur01> ah, OK, so that's probably indicative of something actively refusing the frequency change
<mrjay> i think so
<robmur01> anything else in dmesg?
<mrjay> core_peri
<mrjay> it tries to change freq of core_peri and fails
matthias_bgg has quit [Quit: Leaving]
<robmur01> at a guess it seems likely to be either the clock driver itself rejecting an invalid rate, or possibly the global timer not being able to scale appropriately (assuming this is RK3188 or one of the other older SoCs)
<robmur01> although the i2c driver seems to have a notifier as well so depending on the clock tree it's possible that i2c being active might end up preventing a parent clock from changing too
<mrjay> thanks ... that are awesome clues ... i'm looking at the cpu frequency now and governor tries to set it to 300mhz
<mrjay> and op-table lists 312mhz
<robmur01> yeah, in that case the governor's wrong, it needs to pick something valid from scaling_available_frequencies
macc24 has quit [Ping timeout: 256 seconds]
macc24 has joined #linux-rockchip
<robmur01> RK3288 seems happy to round any rate I throw at it to the nearest valid one, which suggests the the CPU clock driver itself doesn't mind, so I'd guess it's probably one of those notifiers for the Cortex-A9 global/local timers getting in the way
<mrjay> hmm ... how to debug this?
stikonas has quit [Read error: Connection reset by peer]
<robmur01> actually, I don't see how that would work; clearly the userspace governor is rounding to a valid OPP *before* anything gets that far
stikonas has joined #linux-rockchip
<robmur01> so it must be the governor itself that's broken if it ends up requesting a bad rate
<mrjay> maybe u-boot sets cpu clk to weird value
<robmur01> if that's the case, it should get fixed up when cpufreq starts (it'll log a message if so)
<robmur01> (look for "Running at unlisted initial frequency" - my RK3288 certainly does that)
<mrjay> 300000khz tries to change to 300000khz
cp- has quit [Ping timeout: 256 seconds]
cp- has joined #linux-rockchip
<robmur01> hmm, do you have bogus OPPs in your DT perhaps?
kevery has joined #linux-rockchip
kevery has quit [Client Quit]
<mrjay> everything looks good in dts