ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at | Logs at | ML at
<ayaka> rperier: I have tried it before
<ayaka> you may look at the dts I released but it doesn't work at all
cnxsoft has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-rockchip
betheynyx has quit [Read error: Connection reset by peer]
_whitelogger has joined #linux-rockchip
lkcl has quit [Ping timeout: 276 seconds]
lkcl has joined #linux-rockchip
fungi has quit [Ping timeout: 255 seconds]
fungi has joined #linux-rockchip
<rperier> ayaka: what did you try before ?
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 255 seconds]
Omegamoon has joined #linux-rockchip
mrjay has joined #linux-rockchip
<mrjay> LongChair: it looks good ... i want one :) ... ps dts patches for tinker board are on rockchip patchwork now
<LongChair> yeah i'm glad asus made that board, hoping it will become popular
<LongChair> what's the dts patches ?
<LongChair> yeah those start selling, now available everywhere yet though
<LongChair> UK, fi, no, & dk is all i have found yet
<LongChair> but i expect that they should land elsewhere rather soon
<mrjay> LongChair: dts patches are board specific settings in linux kernel
<LongChair> oh right
<LongChair> so there is a dts for tinker in RK linux repo you mean ?
<mrjay> LongChair: not in rk linux ... in mainline kernel ... look:
<LongChair> oh sweet
<LongChair> so tinker will run on mainline ?
<mrjay> it should when patches will be merged
<LongChair> great news
<mrjay> i wonder what wifi chip tinker board uses
<mrjay> anybody knows?
<LongChair> no haven't seen anything official about it
<mrjay> lets hope it's linux friendly :)
<Omegamoon> Tinker board has the Realtek RTL8723BS
<Omegamoon> which is linux friendly indeed :)
lkcl has quit [Ping timeout: 245 seconds]
libv_ is now known as libv
wzyy2 has joined #linux-rockchip
<wzyy2> Tinker board is support in rk linux branch.
<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.
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> It worked though
<Myy> [13217.771228] rk-vcodec ff9c0000.hevc-service: closed
<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
<Myy> It appears, yeah
<Myy> Here a few more simple tests
<Myy> This still does not test encoding/decoding though
<Myy> After rechecking the code, I'm actually testing the vpu-service so... weird...
<Myy> Retesting with both services don't generate oopses