14:54 <yann> I'm working on getting VOP HDMI output work with higher clock rates, like it does on 4.4-rk. As far as I understand the problem when comparing 4.4-rk with 4.14 (the oldest upstream with video output on rk3399), mode_valid() rejects eg. 2560x1400@60, which requires 241500kHz, because clk_vpll is at 148500kHz and both cpll and gpll are at 200000kHz.

14:55 <macc24> Kwiboo: hey, do you know the status of hardware acelerated h264 on rk3326, rk3288 or rk3399?

14:58 <yann> clk_core_get_rate_nolock() is the one returning the current rate on those PLL clocks to clk_composite_determine_rate(), which just takes into account the _current_rate_ of those PLL clocks, and not what they could achieve. I find this troubling, anyone could clarify this ?

15:07 <yann> One striking difference when tracing who's calling set_rate() on clk_vpll with both kernels, is that 4.4 never calls it before I change the mode with xrandr, while 4.14 does change it on boot, though notably rockchip_drm_fbdev_init / register_framebuffer / restore_fbdev_mode_atomic / dw_hdmi_rockchip_encoder_enable. It is changing its rate from 1188000000 to 148500000, which happen to be the "current rate" that's causing mode_valid() to filter out QHD

15:34 <chewitt> @yann You probably want to chat with @knaerzche but he hangs around in the LibreELEC forum not IRC

15:35 <chewitt> @Kwiboo isn't around much at the moment, but Alex (knaerzche) has been progressing things

15:35 <chewitt> @macc24 ^ same comment

15:41 <macc24> ok

15:50 <yann> ok thx

16:04 <chewitt> @macc24 might be worth having a peek around https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches

16:04 <chewitt> that's the latest/greatest current patchset(s) for ffmpeg and kernel that we're using

16:17 <macc24> chewitt: please tell me that there is something like this for mt8183

16:33 <chewitt> err, nope

16:33 <chewitt> sorry :)

16:34 <chewitt> are there any mediatek Android boxes?

16:42 <macc24> no

16:42 <macc24> chewitt: but there are mediatek laptops

16:42 <macc24> shameless plug -> cadmium linux runs on one of them

16:43 <chewitt> LE generally targets consumer SBC devices and small form-factor box things, e.g. NUC, AndroidTV devices

16:44 <chewitt> laptops have never been target hardware for us

16:45 <macc24> ok

17:20 <robmur01> one of the Amazon FireTVs was technically a Mediatek Android TV box :P

17:21 <macc24> robmur01: which one

17:24 <robmur01> one from ~5-6 years ago had the same SoC as the first-gen MTK Chromebook IIRC... I remember getting boot logs off it - unmarked test pads on the board, switching from 115200 to 921600 partway through, great fun.

17:25 <macc24> if it's cheap then hmmmmmmmmmmmmmmmmmmmmm

17:28 <robmur01> we lost interest once it was clear how locked-down it was, dunno if anyone ever broke that. Also, PowerVR...

17:28 <macc24> ugh

17:34 <macc24> yeah that works too lol

17:35 <robmur01> the H96 Max is a little tempting, but inevitable crap slow RAM, crap slow eMMC, crap thermal design, etc...

17:35 <macc24> holy shit it's $40

17:35 <macc24> >rk3328

17:35 <macc24> ,___,

17:52 <macc24> o/ macromorgan

18:11 <mps> anyone running mainline kernel on helios64 board? what is needed to be enabled in kernel for serial console to work

18:12 <mps> I don't have a board but user of alpine linux asks me is it possible for alpine kernel to boot on this board

18:19 <robmur01> mps: SERIAL_8250_DW, on the small chance that it's not already enabled

18:21 <mps> robmur01: thanks, it is not enabled

18:22 <robmur01> AFAIK Helios64 is more or less the RK3399 reference design like most other boards, so any kernel that works on Rock Pro 64/Rock Pi 4/etc. should get *somewhere* at least

18:24 <mps> robmur01: btw, for serial console u-boot parameter should be "console=ttyS2,115200" ?

18:24 <mps> (I lost link for this somewhere)

18:24 <robmur01> I'd expect so - UART2 is the standard debug UART

18:24 <mps> ok, thanks again

18:26 <robmur01> baud rate depends on the bootloader - often it's the BSP default of 1500000, but some U-Boot configs do dial it down to 115200

18:28 <mps> yes, I read somewhere that is 1500000 but user posted u-boot config with 115200

18:28 <mps> anyway, user could try both and see which one will work