ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
machinehum has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
colinsane has quit []
colinsane has joined #linux-sunxi
machinehum has joined #linux-sunxi
colinsane has quit []
colinsane has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
hexdump0815 has joined #linux-sunxi
machinehum has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
pg12 has quit [Remote host closed the connection]
pg12 has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
advancel has joined #linux-sunxi
vertex004 has joined #linux-sunxi
montjoie has quit [Remote host closed the connection]
Hypfer is now known as Guest13836
Hypfer has joined #linux-sunxi
Guest13836 has quit [Ping timeout: 480 seconds]
Net147_ has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
macromorgan_ has joined #linux-sunxi
montjoie has joined #linux-sunxi
uLumia has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
uLumia has quit []
Hypfer is now known as Guest13845
Hypfer has joined #linux-sunxi
Guest13845 has quit [Remote host closed the connection]
dsimic is now known as Guest13849
dsimic has joined #linux-sunxi
Guest13849 has quit [Ping timeout: 480 seconds]
warpme has quit []
gsz has joined #linux-sunxi
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit []
apritzel has quit []
uLumia has joined #linux-sunxi
apritzel has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN__ has quit [Remote host closed the connection]
macromorgan_ has quit []
macromorgan has joined #linux-sunxi
uLumia has quit []
KREYREN__ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
<apritzel> rzr: you did everything correctly, just happened to send the patch while I was away ;-)
Hypfer is now known as Guest13871
Hypfer has joined #linux-sunxi
Guest13871 has quit [Ping timeout: 480 seconds]
vertex004 has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
gamiee has quit [Remote host closed the connection]
gamiee has joined #linux-sunxi
machinehum has joined #linux-sunxi
warpme has quit []
vertex004 has joined #linux-sunxi
<jernej> linkmauve: please try this: http://sprunge.us/hmEMsg
<jernej> I only build tested it and checked (offline) that tables are correctly written in SRAM
<jernej> everything else was updated to follow open source version that I linked few days ago
<jernej> hm... probably ffmpeg can use stateless v4l2 decoding for jpeg
<jernej> *can be used
<linkmauve> I’ve started (re)adding JPEG decoding support in Onix today, I’ll try it alongside.
<linkmauve> Experimental userspace against experimental kernel driver, yay~
<jernej> that's how first of a kind codecs are developed :)
<jernej> but at least with JPEG it's easier, no extra data needed, just put whole image in buffer, submit it and hope for the best
<jernej> note that make request api optional for JPEG
vagrantc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
machinehum has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<linkmauve> jernej, hmm, I receive -53 when I VIDIOC_QBUF the out buffer containing my JPEG data.
<jernej> the only code that I changed outside jpeg driver itself it was to allow non-request api
<jernej> maybe that is causing the issue?
<linkmauve> I made sure not to pass a requests fd.
<linkmauve> I’ll try with one then.
<jernej> you can try also with supports_requests = false
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
<jernej> although it's probably some corner case that I didn't see
<linkmauve> I get ENOFILE on queuing the request fd on the media device when I do set it on the out buffer.
<jernej> just revert change I made for JPEG in cedrus_video.c at the end of the file
<linkmauve> Ok.
<linkmauve> Hmm no, even when I set it back to true it still rejects my MEDIA_REQUEST_IOC_QUEUE of that fd.
<linkmauve> But it seems quite useless, and no userspace program will ever use the request fd for decoding a JPEG I guess.
apritzel has joined #linux-sunxi
<linkmauve> I’ll revert that.
machinehum has joined #linux-sunxi
<linkmauve> Hmm, still -53 on QBUF when I set it to false, so that it doesn’t support requests at all.
<jernej> linkmauve: can you try hardcoding requires_requests to false? I think this is set earlier than format
<linkmauve> That’s exactly what I did.
<linkmauve> src_vq->supports_requests = false;
<linkmauve> src_vq->requires_requests = false;
<linkmauve> This is what I currently have, yet QBUF fails.
<linkmauve> [ 121.477969] video0: VIDIOC_QBUF: error -53: 00:00:00.000000 index=0, type=vid-out, request_fd=0, flags=0x00004000, field=any, sequence=0, memory=mmap, bytesused=451385, offset/userptr=0x0, length=451385
<linkmauve> [ 121.478047] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000
<linkmauve> This is what my kernel logs with 0xffff in /sys/class/video4linux/video0/dev_debug
<jernej> linkmauve: is it possible that you set V4L2_BUF_FLAG_REQUEST_FD flag to buffer in userspace?
<linkmauve> No, flags isn’t 0x00804000, it is 0x00004000.
<linkmauve> It sounds like drivers/media/common/videobuf2/videobuf2-core.c line 1654, but I can’t figure out how to enable dprintk(). ^^'
<linkmauve> Ah, I got a kernel oops…
<linkmauve> But this time QBUF worked, after I just removed the level check in dprintk(). :o
<jernej> that place could be hit only if requires_requests is true
<linkmauve> Oh, there is something wrong here!
<linkmauve> The trigger happens before the second QBUF, so it can’t know where to write the output…
<jernej> decoding should be triggered according to your output
<jernej> oh, try with queueing capture buffer first and then output buffer
<linkmauve> Yeah, but one syscall too early.
<jernej> since it doesn't use request api, capture and output buffer are probably not connected
<linkmauve> Now all of my ssh connections froze all at once at this point.
<linkmauve> I expect it’s the same crash I previously experienced when the decoding triggers.
<jernej> call streamon on output after capture
<linkmauve> Ah, this time DQBUF set the V4L2_BUF_FLAG_ERROR flag on the out buffer, but not on the cap buffer.
<linkmauve> [ 49.005107] cedrus_irq: 6 (error=6 done=5)
<linkmauve> And the whole board is frozen again.
<jernej> hm... looks like it's easier to give Cedrus request api jobs, since whole driver was designed that wa
<linkmauve> I’ve also tried doing the STREAMONs after the QBUFs.
<linkmauve> paulk, did your refactorings change anything in that area?
<linkmauve> Why would the error flag be on the out buffer? Could that mean that the capture buffer received the expected decoded data?
<linkmauve> Ah no, the error flag is present on both buffers actually.
advancel has quit [Quit: Leaving]
<paulk> mhh doesn't ring a bell
<paulk> but I've seen code which checks other registers for jpeg decode status though
<linkmauve> Oh!
<linkmauve> I’m decoding a 4:4:4 JPEG, yet the driver only allocates enough space for 4:2:0 data!
<linkmauve> Hmm, but it can only ever decode to ST12, which is 4:2:0, so that’s not it…
<jernej> linkmauve: oh, for 444 and 411 format you have to set bit 18 to VE_CTL register, so core knows that it needs transform to 420
<jernej> I forgot to implement that
<jernej> s/411/422
<linkmauve> I don’t see any VE_CTL here.
<jernej> register 0x14
<linkmauve> Ok, VE_DEC_MPEG_CTRL.
<jernej> yeah, that one :)
vertex004 has quit [Remote host closed the connection]
<linkmauve> https://linkmauve.fr/files/oops2.txt when I set that bit.
<linkmauve> Actually, my guess is that the oops is just hidden once in a while, when the kernel crashes after it has managed to send it over the ssh connection.
<linkmauve> I’ll switch to a serial console.
<linkmauve> Ok, serial is much worse than ssh, because it is so much slower.
<jernej> I'll try to test it tomorrow on H6 with IOMMU enabled, so it won't crash the system
<linkmauve> Thanks!
apritzel has quit [Ping timeout: 480 seconds]
<linkmauve> I’ve also tested with a 4:2:0 JPEG, but it did an oops as well.
<jernej> is there any collection of sample JPEG files with different features used?
<linkmauve> I don’t have any test suite atm.
<linkmauve> I just picked one from the photos people sent me over time.
<linkmauve> Perhaps Fate or Gstreamer have one?
<linkmauve> jernej, if you want my userspace program to test it with, `git clone -b jpeg-decoder https://git.linkmauve.fr/onix.git` and then `cargo run --release --example=jpeg-decoder <image.jpeg> <width> <height> <output.st12>`.
<jernej> ok, tnx
machinehum has quit [Ping timeout: 480 seconds]
<jernej> interesting, there is mjpegplus lib, which supports more formats
apritzel has joined #linux-sunxi
linkmauve has quit [Quit: Gateway shutdown]
vagrantc has quit [Quit: leaving]