03:45 <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

03:46 <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

03:46 <samueldr> now tracking back the actual patch set where it was introduced just in case

03:47 <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)

03:47 <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

03:49 <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"

03:51 <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

03:53 <samueldr> the backlight enables just fine, it looks like it has to do with the display interface (mipi)

04:32 <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)

06:27 <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)

06:37 <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

06:39 <mps> one bug is emmc crash after resume and other is analogix DP core freezes screen at random

06:39 <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 :)

06:39 <mps> in my case all worked fine with chromeos kernel 4.4.x series

06:40 <samueldr> what's even weirder is how the vendor kernels (chromeos-4.4) doesn't work for the display, at all :/

06:40 <mps> screen freezing on gru-kevin started after mainline 5.4

06:40 <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

06:40 <samueldr> there is a patch already on the ML for the storm issue

06:41 <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

06:41 <samueldr> at the very least that's something I was able to revert

06:42 <samueldr> though yeah, odd that in my particular case the chromeos kernel doesn't work, while it's quite obviously working on chromeos

06:43 <samueldr> I should expand, with chromeos-4.4 the display isn't usable at all

06:43 <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

06:44 <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

07:50 <mmind00> Esmil: https://lore.kernel.org/linux-rockchip/ :-)

10:10 <mickenx> lo

10:10 <mickenx> I have a rk3399 vop question

10:10 <mickenx> I run 800x600 hdmi display

10:11 <mickenx> quite often the pixels is closer to each other

10:11 <mickenx> like half

10:11 <mickenx> if I run with xres doubled it is allways perfect

10:12 <mickenx> it is just like the xres sometimes is smaller than 800, monitor doesn't detect it

10:12 <mickenx> any clues?

10:13 <mickenx> the pixels is xored

10:19 <mickenx> something in the config defenitely halfs the xres somehow , but not the mode only the window

14:25 <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

20:00 <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

20:00 <samueldr> (I added the return value to the first messages)

20:01 <samueldr> 110 is ETIMEDOUT

20:02 <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

20:27 <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)

20:27 <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? :)

20:46 <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