ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
wzyy2 has joined #linux-rockchip
descend-irc has joined #linux-rockchip
zzarr has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
bbelos has quit [Ping timeout: 255 seconds]
ssvb has quit [Read error: Connection reset by peer]
nighty has joined #linux-rockchip
IgorPec10 has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-rockchip
lkcl has joined #linux-rockchip
beeno has joined #linux-rockchip
stdint has joined #linux-rockchip
lkcl has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-rockchip
IgorPec10 has quit [Ping timeout: 260 seconds]
<LongChair1> ayaka: morning :) Changing the freq in vcodec didn't seem to change anything even at 600M
<LongChair1> stdint: it didn't even seem to alter the freq in /sys/kernel/debug/clk/aclk_hevc/clk_rate
<LongChair1> so i suppose it's not enough or something else needs to be done
<LongChair1> any idea ?
<LongChair1> also i'm getting that in kernel log : /sys/kernel/debug/clk/aclk_hevc
<LongChair1> oops that http://pastebin.com/Z26pZWWk
<stdint> LongChair1, it looks fine
<stdint> when you are playing a video, you would notice the frequency has been rise
<LongChair1> i can't see any diff
<LongChair1> and even if i set the freq to 500M or 600M on vcodec then /sys/kernel/debug/clk/aclk_hevc/clk_rate still shows 400M
<LongChair1> the /sys/kernel/debug/clk/aclk_hevc/clk_rate should show the right frequency right ?
<stdint> LongChair1, have you modify the source code as I told you yesterday?
<LongChair1> yes
<LongChair1> to 500M or 600M
<LongChair1> but can't really see any diff
IgorPec has quit [Ping timeout: 260 seconds]
<LongChair1> stdint: any other suggestion ? :)
<stdint> oh, sorry, it would apply to rk29 serial
<stdint> you have to modify the dtsi
<LongChair1> the only thing that seemed to alter the aclk_hevc/clk_rate would seem to be here https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm/boot/dts/rk3288.dtsi#L1368
<LongChair1> changing clocks in here https://github.com/rockchip-linux/kernel/blob/release-4.4/arch/arm/boot/dts/rk3288.dtsi#L1420-L1421 like the hclk_hevc doesn't show up in the kernel debug section
<LongChair1> so i dunno what's the right thing to patch in the dtsi
IgorPec has joined #linux-rockchip
wadim_ has joined #linux-rockchip
<stdint> LongChair1, you need to change the ACLK to 500MHZ with HCLK to 125MHZ
<LongChair1> yeah i tried that as it's mentionned in the comments
<LongChair1> but that didn't show up in the kernel debug stuff and didn't seem to make any difference
<stdint> clk_summary doesn't give you a correct clock?
<LongChair1> aclk_hevc 0 5 400000000 0 0
<LongChair1> hclk_hevc 0 3 100000000 0 0
<stdint> it is impossible
<LongChair1> when you patch dts file, is there anything to cleanup other than rebuild ?
<LongChair1> i saw the dts files being rebuild
<LongChair1> i will check once more, but did that a couple times and that didn't seem to do anything
<stdint> ok, let me have a try later
<LongChair1> cool thanks, i'll also doublecheck later on my side
BenG83__PB has joined #linux-rockchip
<stdint> LongChair1, sorry about my careless, you need to modify the vcodec driver not the dts
paulk-blaze has joined #linux-rockchip
<phh> stdint what you just said isn't totally clear... Could you paste a git diff?
lkcl has joined #linux-rockchip
<phh> Ah, hclk went to 125MHz because it is aclk/4? Ok thanks
<stdint> it supports 1/4, 1/2 and 1/1
<LongChair> stdint: oh so the if stuff was gimping it, ok. I will try that today. No problem with you being busy. I appreciate the support :)
<LongChair> so hclck could be also 250Mhz potentially with ak to 500 Mhz ?
<LongChair> aclk*
<stdint> yes I think so
<LongChair> ok i will try to change those and do some stress test
<LongChair> i suppose bad behavior would result in some freezes or so
<LongChair> due to potential overheat or volatage drop ?
<LongChair> i'm not too much worried about overheat given the heatsink that tinker has and the current temp
<LongChair> usually using hw decoding would result in low cpu usage and there is already a huge difference in terms of temp between cpu at low usage and 4 cores at 100% (i can see that when building on tinker)
<LongChair> i doubt vpu at high usage and cpu at low usage exceeds the cpu high usage temp
<LongChair> even though the heatsink gets to 50°C in such usage and that is way below the max rated temp
<LongChair> but then voltage drop could be an issue eventually
<LongChair> but still i would expect it to be fine :)
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft1 has joined #linux-rockchip
cnxsoft1 is now known as cnxsoft
IgorPec has quit [Ping timeout: 240 seconds]
nighty has quit [Quit: Disappears in a puff of smoke]
nighty has joined #linux-rockchip
IgorPec has joined #linux-rockchip
BenG83__PB has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Ping timeout: 260 seconds]
paulk-blaze has quit [Quit: Leaving]
<LongChair1> stdint: tried the 500M patch it indeed now shows in the clk_summary
<LongChair1> 500M is not enough though to play LG chess
<LongChair1> trying 600M
<LongChair1> ayaka, stdint: is there any way in kernel to alter the hclk as well ? or is that in dts file ?
wzyy2 has joined #linux-rockchip
<LongChair1> something is odd
<LongChair1> root@linaro-alip:~# cat /sys/kernel/debug/clk/clk_summary | grep hevc
<LongChair1> sclk_hevc_core 0 3 297000000 0 0
<LongChair1> sclk_hevc_cabac 0 3 297000000 0 0
<LongChair1> hclk_hevc 0 3 148500000 0 0
<LongChair1> aclk_hevc 0 5 594000000 0 0
<LongChair1> so now the freqs are set ... but it still cannot handle that freakin video
<LongChair1> and it seems to start playing ok, but after a few secs framedrops come at a high pace
mac-l1 has joined #linux-rockchip
<mac-l1> wzyy2: hi wzzy2. now slowly progressing to get approval with my first pullrequest for rockchip support in kodi mainline repo. now a kodi community members asks:
<mac-l1> Why can't Rockchip (or the Rockchip community) add a support library for VAAPI or VDPAU APIs instead?
<mac-l1> i know you already implemented VAAPI/VDPAU support before, so why is that support dropped?
<LongChair1> mac-l1, stdint: said that vaapi wrapper had issues, and that there were to many API to maintain and not so much time to spend on that
<LongChair1> mac-l1: i'm also discussing rockchip support with kodi guys
<LongChair1> the plan would be more to get rockchip mpp support into ffmpeg which is what i'm working on
<LongChair1> and then that they rework their drm rendered so that it can support drm/dmabuf
<LongChair1> currently only drm like support is vaapi
<LongChair1> and they want to rework that
<mac-l1> LongChair1: i checked your ffmpeg work and that looks great. it should actually get into the mainline ffmpeg repo.
<LongChair1> yeah once i get it working right
<LongChair1> i mean kodi will probably try it / find bugs .. once we have everyone happy with it. then we can upstream
<LongChair1> ffmpeg upstream process is heavy, so we don't want to do that several times :)
<LongChair1> i'm currently trying to figure out why i can't reach 4k@60 fps
<LongChair1> and that still requires some love
<mac-l1> i understand. also kodi upstream isnt too easy but that should be expected.
<mac-l1> i now have kodi running by implementing 1) basic rockchip support to get basic kodi running on the device 2) adding a rockchip decoder class that uses mpp/vpu and 3) adding a rockchip gles renderer class that renders using zero-copy and gles
cnxsoft has quit [Quit: cnxsoft]
<mac-l1> i am now pulling step 1)
<LongChair1> step 2 shouldn't be need with ffmpeg / mpp
<LongChair1> step 3 : its not ideal, gles won't allow 4K, better to wait for drm implementation
<mac-l1> i now dont use ffmpeg / mpp but direct mpp/vpu calls but i guess in the end it would be best if mpp is included as low level as possible so in ffmpeg
Luke_Pine64 has joined #linux-rockchip
<mac-l1> and step3) indeed, gles has real 4K limitations so you dont get the max out of the device, not ideal...
<mac-l1> but i guess that after step 3) there could be step 4) to implement a drm based renderer with overlay or so?
cnxsoft has joined #linux-rockchip
<mac-l1> i also experimented using rga to downscale 4K frames to 1080p. it partly works but not yet for all formats/dimensions so needs some work.
<mac-l1> so then at least 4K video could be played on 1080p displays (using rga and gles)
<mac-l1> but now my first step is to go through the process of getting at least some rockchip support in kodi baseline making a sound baseline for our further work.
<LongChair> mac-l1: imho we should focus on step 1, that is get proper performance with ffmpeg / 4K
<LongChair> if you feel like helping me there, you're welcome :)
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
cnxsoft has quit [Quit: cnxsoft]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
wzyy2 has joined #linux-rockchip
Luke_Pine64 has quit [Quit: Page closed]
wzyy2 has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
wzyy2 has joined #linux-rockchip
wadim_ has quit [Remote host closed the connection]
mac-l1 has quit [Quit: Page closed]
paulk-blaze has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 240 seconds]
<eballetbo> mmind00: seems display stays black on veyron when you resume the system, but it resumed, by chance do you have a clue?
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 258 seconds]
wzyy2 has joined #linux-rockchip
stdint has quit [Read error: Connection reset by peer]
wzyy2 has quit [Ping timeout: 240 seconds]
paulk-blaze has quit [Quit: Leaving]
stdint has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 246 seconds]
BenG83_PB has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
premoboss has joined #linux-rockchip
beeno has quit [Ping timeout: 260 seconds]
BenG83_PB has quit [Quit: Leaving]
ssvb has joined #linux-rockchip
<mmind00> eballetbo: nope, probably some bug in the edp driver? Did you try with hdmi connected as well? Just to determine if the problem is in the vops or encoder drivers.
<mmind00> eballetbo: it's nice to see that it resumed though :-)
premoboss has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
premoboss has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
premoboss has quit [Quit: Sto andando via]
IgorPec has quit [Quit: Nettalk6 - www.ntalk.de]
bbelos has joined #linux-rockchip
afaerber has quit [Quit: Leaving]
zzarr has quit [Quit: This computer has gone to sleep]
zzarr has joined #linux-rockchip
zzarr has quit [Remote host closed the connection]
zhecka__ has quit [Ping timeout: 256 seconds]
muvlon has joined #linux-rockchip
muvlon has quit [Ping timeout: 260 seconds]
Bad_UID has joined #linux-rockchip
afaerber has joined #linux-rockchip
nighty has quit [Quit: Disappears in a puff of smoke]
muvlon has joined #linux-rockchip
muvlon has quit [Ping timeout: 256 seconds]
muvlon has joined #linux-rockchip