ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion
clarity has joined #linux-rockchip
kevery has joined #linux-rockchip
archetyp has quit [Quit: Leaving]
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
hanetzer has quit [Ping timeout: 256 seconds]
hanetzer has joined #linux-rockchip
hanetzer has joined #linux-rockchip
hanetzer has quit [Changing host]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 252 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 244 seconds]
kevery1 is now known as kevery
clarity has quit [Ping timeout: 244 seconds]
clarity has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 245 seconds]
archetyp has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 245 seconds]
kevery1 is now known as kevery
csrpi[m] has quit [Ping timeout: 245 seconds]
samueldr has quit [Ping timeout: 256 seconds]
psydroid has quit [Ping timeout: 252 seconds]
csrpi[m] has joined #linux-rockchip
samueldr has joined #linux-rockchip
psydroid has joined #linux-rockchip
dianders has quit []
dianders has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
ServerStatsDisco has quit [Ping timeout: 245 seconds]
ServerStatsDisco has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
kevery has quit [Client Quit]
chewitt has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #linux-rockchip
Guest84 has joined #linux-rockchip
Guest84 has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-rockchip
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
mriesch has quit [Remote host closed the connection]
mriesch has joined #linux-rockchip
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #linux-rockchip
<macromorgan>
dsi broken for anyone else on mainline master?
<pgwipeout[m]>
macromorgan board? Uboot or kernel?
<macromorgan>
rk3326 (Odroid Go Advance) on kernel master branch, synced as of 2 hours ago
<macromorgan>
trying to see if I can pinpoint the commit now
stikonas has joined #linux-rockchip
<pgwipeout[m]>
As of 5.14.0 rk3399 works. I know some vop changes just dropped though
<pgwipeout[m]>
There were also driver core changes landed for 5.15
<mmind00>
just checked px30-minievb with dsi display ... and yes somthing seems to have broken ... 5.14 was working ... even when merging an earlier drm-misc tree
<mmind00>
so for same kernel: 5.14 + merge-window until earlier this afternoon I get, rk3399 edp display works; px30 dsi-display ends up with a spew of "vblank wait timed out"
<macromorgan>
yeah, ditto for me
<macromorgan>
I'm in the middle of a bisect so give me a bit and I can find the commit that broke it
<macromorgan>
I've narrowed it down to something within the last 2 days
<macromorgan>
something between commit a9c9a6f741cdaa2fa9ba24a790db8d07295761e3 (newest that fails) and 4ac6d90867a4de2e12117e755dbd76e08d88697f (oldest that works)
<pgwipeout[m]>
So fractional divider isn't coming up with the same result.
<pgwipeout[m]>
Can you make a patch to run both side by side and output the results?
<pgwipeout[m]>
Or if you can't, if I make one could you run it?
<macromorgan>
yeah, hang on
<macromorgan>
I'm reporting it first as a bug
<macromorgan>
then I'll figure out the fix
<macromorgan>
actually let me just test the different values first and include that in my bug report
<pgwipeout[m]>
Yup, that's why I recommended it ;)
<macromorgan>
well now this is interesting... on the kernel that works: Rate 7649082492112076800 , Parent Rate 17000000, Best Numerator 65535, Best Denominator 1
<macromorgan>
that rate seems just a little high...
<macromorgan>
looks like someone snuck an error into an unsigned int field?
<CounterPillow>
perhaps a call in the driver is storing a signed int in an unsigned int and doesn't do any error checking
<macromorgan>
probably... now just to figure out where...
<macromorgan>
let's see what values master returns
<macromorgan>
Rate 17000999, Parent Rate 17000000, Best Numerator 17018, Best Denominator 17017
<macromorgan>
no sign of that giant f'ing number though, weird
<CounterPillow>
that the less broken rate causes things to break is incredibly funny to me
<macromorgan>
par for the course...
<pgwipeout[m]>
It's actually getting clamped
hanetzer has quit [Quit: WeeChat 3.2]
<pgwipeout[m]>
Something really weird happened there
<pgwipeout[m]>
Rate is fed to it by another function.
<macromorgan>
yeah, I guess I have a weekend project... figure out what the hell is going on here...
<macromorgan>
fls_long(*parent_rate / rate - 1);
<macromorgan>
so if the parent rate and rate are the same (or very close) then the -1 will basically make it a negative
<CounterPillow>
well that was a quick weekend project :D
<macromorgan>
yeah, now I just have to write a patch that works, submit it upstream, and whatnot
<macromorgan>
meanwhile, the beer is going undrank
<CounterPillow>
Writing the patch can wait until tomorrow, that's what sessions and bookmarks in code editors are for ;)
<pgwipeout[m]>
Yeah but that's already happening exactly the same as written in clk_fd_general_approximation
alpernebbi has quit [Quit: alpernebbi]
<pgwipeout[m]>
This shouldn't have broken things.
<pgwipeout[m]>
The real question is how did we get a rate passed in the first place that was insane.
<pgwipeout[m]>
Unless you grabbed that variable in a strange location.
<pgwipeout[m]>
Ohhhh
<pgwipeout[m]>
If you grabbed rate in the working function it will have been modified.