<geekerlw>
stdint, with --gst-debug-level=vpudec:5 ?
<stdint>
yes
<geekerlw>
stdint, I found the more cpu occupancy rate, the more probability the vpu decoder process dead
<wzyy2>
I have found that too
<geekerlw>
stdint, sometimes it looped more than two hours, sometimes it looped less than 10 minutes
<stdint>
geekerlw, which player do you use?
<wzyy2>
If I go to the drag window, it's easy to stop working.
<wzyy2>
If I drag window...
<geekerlw>
stdint, I tested with my simple test program and the xfce parole
<stdint>
if you still writing a player yourselves, don't ask me
<geekerlw>
booth have this problem
<wzyy2>
which sink do you use?
<stdint>
use gst-launch
<geekerlw>
stdint, no, I'll use the parole instead, the program is only to test the plugin
<wzyy2>
eglglessink?
<stdint>
I wonder how do you choose my plugin at parole
<geekerlw>
stdint, I just found parole yesterday, when I start playing, it seems found your plugin automatic
<geekerlw>
wzyy2, the eglglessink have the problem also
<stdint>
without log, without truth
<wzyy2>
The problem may not caused by gstreamer or mpp, because I haven't got it recently
<wzyy2>
we will update a complete environment and then you can test in it..
<stdint>
just send me a correct log first or I can't say anything
<geekerlw>
wzyy2, another problem , the desktop may stop working with the xserver-xorg 1.18.4 and libmali-1.5-2 , and the old 1.18.21-4 worked more well
<geekerlw>
stdint, I'll test more times, and I'll send you the correct log
<geekerlw>
happy New Year you all !
<stdint>
no need to care about X anymore, branch is nearly over in debian
<stdint>
try wayland or waiting the porting for X 1.19
<stdint>
but I still welcome the report about branch 1.18, it is not too difficult, I would have a look
<geekerlw>
wayland is a good choose
<wzyy2>
Debian stretch is updated too frequently.....We can not ensure the stability....
<wzyy2>
How long will it become the stable distribution?.
<stdint>
the testing become stable costs one and half year
<stdint>
but stretch have not become testing I think
geekerlw has quit [Read error: Connection reset by peer]
geekerlw has joined #linux-rockchip
geekerlw has quit [Read error: Connection reset by peer]
geekerlw has joined #linux-rockchip
hyperion has quit [Ping timeout: 264 seconds]
_whitelogger has joined #linux-rockchip
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-rockchip
geekerlw has left #linux-rockchip ["Leaving"]
geekerlw has joined #linux-rockchip
geekerlw has quit [Client Quit]
geekerlw has joined #linux-rockchip
geekerlw has quit [Quit: Leaving]
geekerlw has joined #linux-rockchip
<LongChair>
morning, did anyone played with the mali fbdev drivers already ?
<stdint>
no error from vpudec, no more buffer from upstream
<stdint>
blame the upstream
<stdint>
the upstream element
<geekerlw>
ok, I'll check my environment and test again
cnxsoft has quit [Ping timeout: 256 seconds]
<stdint>
geekerlw, you may enable the debug of vpubufferpool
<stdint>
if you didn't find any problem there, report that to #gstreamer
<geekerlw>
ok, I'll have a try
cnxsoft has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
muvlon has quit [Ping timeout: 240 seconds]
zzarr has quit [Remote host closed the connection]
XingZheng has quit [Ping timeout: 256 seconds]
muvlon has joined #linux-rockchip
lkcl has joined #linux-rockchip
mac-l1 has joined #linux-rockchip
Omegamoon has joined #linux-rockchip
Aussie_matt has joined #linux-rockchip
zzarr has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
Aussie_matt has quit [Remote host closed the connection]
Aussie_matt has joined #linux-rockchip
<mmind00>
diego71: not sure if you made any progress on your cpufreq issue, but I just ran my firefly with some 4.10-rc1-based kernel build from multi_v7_defconfig and get working cpufreq ... dmesg shows cpufreq moving away from the unlisted 500MHz to 600MHz as well
<mmind00>
diego71: maybe you can mount debugfs again and look at /debug/regulator/regulator_summary and look for vdd_cpu if it is present?
<mmind00>
which should have a child named cpu0
jkstrick has joined #linux-rockchip
Aussie_matt has quit [Remote host closed the connection]
cnxsoft has quit [Quit: cnxsoft]
muvlon has quit [Ping timeout: 240 seconds]
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 246 seconds]
libv has joined #linux-rockchip
libv_ has quit [Ping timeout: 264 seconds]
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 246 seconds]
<diego71>
mmind00: yes, i've tested the linux-next one, with multi_v7_defconfig, and they looks fine (except, i had to patch mmc driver)
<diego71>
mmind00: thanks anyway
<mmind00>
diego71: ok, glad to hear its working for you again
<diego71>
and there is till the problem with the usb
<diego71>
*still
<diego71>
(I was told there is a fix around, that should arrive in mainline...)
libv has joined #linux-rockchip
libv_ has quit [Ping timeout: 268 seconds]
vagrantc has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 248 seconds]
libv has joined #linux-rockchip
libv_ has quit [Ping timeout: 258 seconds]
libv has quit [Ping timeout: 264 seconds]
libv has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
vagrantc has joined #linux-rockchip
<phh>
LongChair: mali fbdev driver...? you mean fbdev-x11 driver with mali support? it's obsolete compared to either rockchip's X or even wayland
<LongChair>
I meant a video driver that doesn't require a window manager
<LongChair>
not fbdev-x11, just fbdev
<phh>
oh right of course, sorry
<LongChair>
np :)
Omegamoon has quit [Ping timeout: 264 seconds]
Omegamoon has joined #linux-rockchip
libv has quit [Ping timeout: 248 seconds]
dlezcano has quit [Ping timeout: 258 seconds]
libv has joined #linux-rockchip
dlezcano has joined #linux-rockchip
mac-l1 has quit [Ping timeout: 260 seconds]
vagrantc_ has joined #linux-rockchip
vagrantc has quit [Ping timeout: 256 seconds]
vagrantc_ is now known as vagrantc
<diego71>
vagrantc: fyi, the firefly, with kernel 4.10-rc1 is much faster than the 4.8 from debian
<diego71>
now it uses 1.6Ghz, instead of 500Mhz of the old kernel
<vagrantc>
good news
<vagrantc>
wonder what changed
<vagrantc>
i've got one board running 4.9-rc8, too
<vagrantc>
debian's likely going to be shipping 4.9 for the upcoming release
<diego71>
vagrantc: how it works with 4.9?
<vagrantc>
oh, wait, i'm running 4.7 and 4.8 ...
<vagrantc>
i should try 4.9
<diego71>
looks like the debian kernel (4.8) doesn't support cpufreq for the rockchip
<diego71>
(I don't understand if it is a bug, or just missing some feature needed for cpufreq)
<vagrantc>
well, if it means it runs at 500MHz, i'd call it a bug worth backporting a fix for :)
<diego71>
I suspect that 500Mhz is the standard clock at boot. With 4.10-rc1, I got this message:
<diego71>
[ 0.662741] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 600000 KHz
<vagrantc>
cpufreq-info still not showing anything on 4.9-rc8
<vagrantc>
i don't get any cpufreq info out of dmesg
<diego71>
I can try to bisect from 4.9 to 4.10-rc1 to see where cpufreq start to work
<vagrantc>
that'd be awsome
<vagrantc>
it might also just be modules we need to enable in debian
<diego71>
for 4.10, i've just used multi_v7_defconfig
<vagrantc>
i've always thought my firefly boards were a bit slow
<vagrantc>
so it's not surprising to hear cpufreq not working might make them run at a slow clock speed
<vagrantc>
multi_v7_defconfig is like looking for a needle in a haystack in which someone's already sifted through maybe 10% of the haystack
<vagrantc>
ok, maybe not that bad :)
<diego71>
The idea is to test 4.9, with multi_v7_defconfig. If it works, is something with the debian kernel (maybe something different in the config).
<diego71>
if not, it is something fixed between 4.9 and 4.10-rc1
<vagrantc>
well, between 4.9-rc8 and...
<vagrantc>
but yes, bisecting would be good
<diego71>
right ...
<vagrantc>
i'm also looking at the device-tree to see if there's an obvious driver we've missed in the config or something
<mmind00>
vagrantc: also maybe look into debugfs regulator/regulator_summary ... I could fathom that the vdd_cpu is not present
<vagrantc>
i swear i got cpufreq on the veyron-speedy, though ...
<vagrantc>
i'm going to boot that and see
<mmind00>
vagrantc: pmic setup is vastly different between veyron (rk808) and firefly (act8846 + syr-something)
<vagrantc>
ah, so it's basically meaningless with the veyron
<vagrantc>
for the firefly
<vagrantc>
needed to boot it anyways :)
<mmind00>
vagrantc: firefly's regulator-drivers are in multi_v7_defconfig since september 2015, but I'm not sure if that's also the case for your debian kernel-config
<vagrantc>
paulk-collins: was it you that mentioned something about a usb bug causing problems with usb-wifi adapters?
<vagrantc>
mmind00: which are they?
<mmind00>
vagrantc: CONFIG_REGULATOR_ACT8865=y and CONFIG_REGULATOR_ACT8865=y