ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
vagrantc has quit [Quit: leaving]
cyrozap has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 264 seconds]
azend has joined #linux-rockchip
kaspter has joined #linux-rockchip
kaspter has quit [Excess Flood]
kaspter has joined #linux-rockchip
azend has quit [Read error: Connection reset by peer]
azend has joined #linux-rockchip
azend has quit [Client Quit]
azend has joined #linux-rockchip
azend has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
azend has joined #linux-rockchip
azend has quit [Client Quit]
azend has joined #linux-rockchip
<samueldr> hi, with a gru-dumo, which is a scarlet, which is the base platform for the RK3399 chromeos tablets, there seems to be an issue with the mainline kernel and its display suspend/resume
<samueldr> I went as far back as to 5.0, when the board was added to mainline, and it's not a regression since its introduction, AFAICT
<samueldr> now tracking back the actual patch set where it was introduced just in case
<samueldr> the issue is with panel-innolux-p079zca, and clocks (I'll need to get back to 5.8 since I forgot to take note of the messages there, they had more details than on 5.0)
<samueldr> though on 5.0 it's dw-mipi-dsi-rockchip ff960000.mipi: failed to write command FIFO // panel-innolux-p079zca ff960000.mipi.0: [drm:0xffff00001058ff48] *ERROR* failed to enter sleep mode: -110
<samueldr> oh, it's also on 5.0 "pclk_mipi_dsi1 already disabled", and "pclk_mipi_dsi0 already disabled"; and "Enabling unprepared pclk_mipi_dsi0", and "Enabling unprepared pclk_mipi_dsi1"
<samueldr> this is a bit out of my league, but maybe not that much; it's simply that in the specific drivers, where the trace points to, it uses the enable_prepare (or is it prepare_enable) variant, and the equivalent to unprepare_disable; always, so it looks like that even though it should be preparing before enabling, something isn't working as expected
<samueldr> the backlight enables just fine, it looks like it has to do with the display interface (mipi)
_whitelogger has joined #linux-rockchip
<samueldr> so going back to the ancestor merge that introduced the commit to master before v5.0, same behaviour, to the commit that introduced its DT rockchip-drm display-subsystem: master bind failed: -517 :/ (trying to see if it ever was working for the kernel as I have it configured)
kaspter has quit [Ping timeout: 260 seconds]
kaspter has joined #linux-rockchip
vstehle has joined #linux-rockchip
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 265 seconds]
camus1 is now known as kaspter
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
<samueldr> so going back further, tried to find a revision where it all works, and it looks like it never does (I don't think it would be, but a configuration issue is still possible)
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 260 seconds]
kevery1 is now known as kevery
<mps> samueldr: looks like gru boards are not well maintained in mainline, at least some of them. I have gru-kevin and reported two serious bugs some months ago but nothing is done yet
<mps> one bug is emmc crash after resume and other is analogix DP core freezes screen at random
<samueldr> what's causing me the most issue here is that since it never worked, I can't bisect and find out a probable cause :)
<mps> in my case all worked fine with chromeos kernel 4.4.x series
<samueldr> what's even weirder is how the vendor kernels (chromeos-4.4) doesn't work for the display, at all :/
<mps> screen freezing on gru-kevin started after mainline 5.4
<samueldr> with v5.8 there is a regression (quite major) with sbs-battery that is causing a storm of register requests to the virtual battery of the chrome EC
<samueldr> there is a patch already on the ML for the storm issue
<samueldr> though it seems there is *another* issue part of the same patch set that is causing grief that I'm a bit off-putted to look into right now
<samueldr> at the very least that's something I was able to revert
<samueldr> though yeah, odd that in my particular case the chromeos kernel doesn't work, while it's quite obviously working on chromeos
<samueldr> I should expand, with chromeos-4.4 the display isn't usable at all
<mps> I tried to revert screen freeze bug for gru-kevin but is big patch and far out of my knowledge about display drivers programming
<samueldr> though yeah, I was hoping to get some guidance about what to look for when clocks misbehave as they do here in my case; somehow isn't prepared/unprepared when they should, or enabled/disabled
matthias_bgg has joined #linux-rockchip
vicencb has joined #linux-rockchip
putti_ has joined #linux-rockchip
Putti has quit [Ping timeout: 246 seconds]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
_whitelogger has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
<mickenx> lo
<mickenx> I have a rk3399 vop question
<mickenx> I run 800x600 hdmi display
<mickenx> quite often the pixels is closer to each other
<mickenx> like half
<mickenx> if I run with xres doubled it is allways perfect
<mickenx> it is just like the xres sometimes is smaller than 800, monitor doesn't detect it
<mickenx> any clues?
<mickenx> the pixels is xored
<mickenx> something in the config defenitely halfs the xres somehow , but not the mode only the window
stikonas has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
robmur01 has quit [Read error: Connection reset by peer]
robmur01 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
grkblood13 has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
<grkblood13> having an issue doing h264 hw encoding on the rk3328 (rock64) with ffmpeg. getting the following: "Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'" full command with test file is linked here: https://github.com/rockchip-linux/ffmpeg/issues/2#issuecomment-672830369
mps has quit [Ping timeout: 265 seconds]
mps has joined #linux-rockchip
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
vagrantc has joined #linux-rockchip
putti_ is now known as Putti
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
matthias_bgg has quit [Ping timeout: 256 seconds]
robmur01 has quit [Ping timeout: 256 seconds]
vicencb has quit [Quit: Leaving.]
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
<samueldr> continuing looking at the mipi issue on gru-dumo(scarlet); here's the exact messages on 5.8 when it fails to enable the display and then fails to suspend the failed-to-enable display https://gist.github.com/samueldr/2897ae61a42e1050d3ac3c5d87d09093
<samueldr> (I added the return value to the first messages)
<samueldr> 110 is ETIMEDOUT
<samueldr> readl_poll_timeout seems to timeout, which I don't know what it means exactly, even though I increated the timeout to an order of magnitude
warpme_ has joined #linux-rockchip
<samueldr> the default is 0.02s; going to 20s doesn't help either (unsurprisingly, only one order of magnitude I think would have shown if it was timing issues)
<samueldr> so I figure that figuring out why it fails to send the command(s) is needed; and is my current problem: what am I even looking for? :)
<samueldr> alright, so from the previous two logs, it might be that there are two issues, maybe not; on intuition I tried removing `clk_disable_unprepare` instances where it failed, and the second trace doesn't happen anymore, but the panel commands still fail
robmur01 has joined #linux-rockchip
vicencb has joined #linux-rockchip
vicencb has quit [Quit: Leaving.]
tlwoerner has quit [Quit: Leaving]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-rockchip
kevery1 has joined #linux-rockchip
kevery has quit [Ping timeout: 246 seconds]
kevery1 is now known as kevery