<wzyy2>
They have a branch which is fork from 4.4 kernel. It has better support (mipi screen and camera).
<mrjay>
Omegamoon: RTL8723BS doesn't have driver in mainline linux
<mrjay>
Omegamoon: only vendor linux driver is avaliable
<wzyy2>
Maybe i should port those back into rk-linux...
<wzyy2>
Yep, it use vendor linux driver.
<wzyy2>
I quite like tinker .. I brought one to home to replace my firefly as develop board.......
<mrjay>
it should be good generic server board
<LongChair>
wzyy2: where did you get it from ?
<LongChair>
because i don't see anyone else seeling it than farnell UK, and they won't ship outside uk ...
<wzyy2>
the samples form asus.
<mrjay>
where can i get sample from asus? :)
<LongChair>
wzyy2: CES ?
betheynyx has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
paulk-collins has joined #linux-rockchip
mrjay has quit [Quit: Page closed]
mrjay has joined #linux-rockchip
mrjay has left #linux-rockchip [#linux-rockchip]
mrjay has joined #linux-rockchip
mrjay has left #linux-rockchip [#linux-rockchip]
mrjay has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-rockchip
Myy has joined #linux-rockchip
<Myy>
phh : Did you advance on the VPU code ? I tried to run simple tests on it, but all I got was a quick lock-up and a zombie processes generator. I might call it Rockchip VPU Z. https://github.com/Miouyouyou/rockchip-vcodec-tests
lkcl has quit [Ping timeout: 255 seconds]
<Myy>
The lockups were due to some NULL dereference during the shutdown phase of the VPU, when invoking "close" on the File Descriptor.
mrjay has left #linux-rockchip [#linux-rockchip]
mrjay has joined #linux-rockchip
mrjay has quit [Remote host closed the connection]
<phh>
Myy: uh you mean it doesn't work at all for you?
<phh>
Myy: you're writing tests to be able to compare working downstream 4.4 VS non-working mainline 4.10?
<Myy>
Yeah
<phh>
Myy: from what I can tell, it looks like HEVC is working properly for me
<phh>
I think I'll write an ffmpeg module for it
<Myy>
Ah nice !
<phh>
(using mpp)
<Myy>
(´・ω・`)
<phh>
(rendering failed here)
<Myy>
Anyway, I'm trying to test the IOCTL directly, in order to test for bugs and regressions
<Myy>
The first simple test already send me a OOPS when I'm closing /dev/vpu_service
<Myy>
The printf work though
<Myy>
If I try a second time, the process will be become zombified
<phh>
what oops? something about drm detach?
<Myy>
I think, let me retry...
<phh>
ok right, fair enough, I have it as well. though I don't have it on hevc, can you try on hevc-service?
<Myy>
I'll try. I wonder if it responds to the same IOCTL though.
<Myy>
The crash doesn't happen everytime so I'm pretty sure that some memory buffer gets corrupted other time
<Myy>
I'm trying to install nodejs 5+ in order to use Pencil and draw a map of this thing
<Myy>
If the backtrace is right, vcodec_drm_detach has some problems
ayaka has quit [Read error: Connection reset by peer]
<Myy>
Meanwhile, yeah, it's about drm_detach though, which call iommu_detach on something that might not have been attached correctly (or already detached)
<phh>
Well, this is a dedicated thread, perhaps it is some synchronisation issue
<Myy>
Well, time for printk debugging then !
<Myy>
?? the device gets attached with arm_iommu
<Myy>
And gets detached with iommu ?
athidhep has joined #linux-rockchip
<Myy>
Unlike the vpu_service, It looks like the hevc service does not crash
Omegamoon has left #linux-rockchip [#linux-rockchip]
hramrach has quit [Ping timeout: 240 seconds]
<phh>
good, you just need to diff them :P
<Myy>
? The only thing I changed to use the hevc_service was to do open("/dev/hevc_service") instead of open("/dev/vpu_service"). I think the module I was using was in sync with the kernel in use. I just recompiled it a few minutes ago and there's no crashes atm.
<phh>
I mean in the driver
<Myy>
*was not in sync
<phh>
mmm ok
<Myy>
I tried to set the session type and... things appears ok. Though, I think I'll add some IOCTL to get the current session type, in order to check if it is set correctly.
<Myy>
"appears ok == didn't crash the machine"
hramrach has joined #linux-rockchip
<phh>
weird
<phh>
the module shouldn't load if kernel mismatches
<Myy>
It was the same version. Just recompiled differently. I still have not retried to use vpu_service though.
<Myy>
I'll commit my new tests when I'm done writing the test of COMPAT_VPU_IOC_GET_REG
<phh>
... I'm pretty confident the crash is only in vpu-service not in hevc-service