<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
***: crazy_imp has quit IRC (Ping timeout: 276 seconds)
<br> shuah has quit IRC (Quit: Ex-Chat)
koike: ezequielg, it seems that it is because of the changes in patch [media] vb2: drop v4l2_format argument from queue_setup, I just sent a patch [media] stk1160: Check *nplanes in queue_setup, do you mind testing it please? Thank you
***: jmleo has quit IRC (Ping timeout: 276 seconds)
<br> kbingham has quit IRC (Ping timeout: 240 seconds)
hverkuil: <u>mchehab</u>: linuxtv.org seems to have problems, can you take a look? All I get is 'Index of /'.
<br> it seems to be http related, accessing the git repo works fine.
***: groleo has quit IRC (Ping timeout: 240 seconds)
mchehab: <u>hverkuil</u>: what was missing were the redirects from http->https
<br> it should be fixed now
hverkuil: <u>mchehab</u>: that looks much better! Thanks.
mchehab: I had to fix the configs yesterday, in order to renew the letsencrypt certs
<br> (they should be renewed on every ~90 days)
javier__: <u>ndufresne</u>: hi, it seems that GStreamer doesn't parse correctly what are the video nodes for the registered decoders
<br> <u>ndufresne</u>: http://hastebin.com/kiduqenaja.hs
<br> I'm using the GStramer in my distro though, which is 1.4.5 so maybe this is fixed in mainline already?
ndufresne: <u>javier__</u>: you mean it does not support the extended CAPS ?
***: bparrot has quit IRC (Remote host closed the connection)
javier__: <u>ndufresne</u>: no, I meant that it only works if the MFC decoder is registered as /dev/video0
<br> <u>ndufresne</u>: but if for some reasons s5p-jpeg is registered before as /dev/video0 (i.e: enabled built-in while s5p-mfc is built as a module) and the s5p-mfc decoder ends as /dev/video4, then Gst doesn't work
<br> look like the kernel log says: [ 13.010701] s5p-mfc 11000000.codec: decoder registered as /dev/video4
<br> but there isn't a v4l2video4dec element according to gst-inspect-1.0
<br> s/look like/look how
<br> <u>ndufresne</u>: for now my workaaround has been just to disable CONFIG_VIDEO_SAMSUNG_S5P_JPEG so the mfc decoder always ends as video0, but wanted to mention in case you didn't notice or wasn't a known issue
ndufresne: <u>javier__</u>: sorry, I'm back
<br> <u>javier__</u>: it should work regardless what node it is
<br> as of 1.8 at least, we track the /dev/videoN changes and update the elements accordingly
<br> before that, you'd have to keep them streight
<br> (before that we where only using it with fixed videoN assignment
<br> <u>javier__</u>: to fix it, just rm the gst cache
<br> depending on your setup, should be $HOME/.cache/gstreamer-1.0/registry.arm.bin
<br> or armvXX
<br> depending what your kernel report
<br> <u>javier__</u>: note that the jpeg decoder does not work, as it only allow 1 buffer allocation, at the moment gst requires at least 2
<br> We also need to add a parser, to split data into full frame
<br> and then, need to fix the driver which fail for random reason ;-P
javier__: <u>ndufresne</u>: Ok, I see the .cache/gstreamer-1.0/registry.armv7hl.bin file, I'll remove it and test
<br> <u>ndufresne</u>: yes, one driver at at time :P
ndufresne: (y)
<br> <u>javier__</u>: btw, ayaka's encoder changes makes sense to me, though I can't test it right now, as I'm in the middle of a rewrite of the gst element he wrote
javier__: <u>ndufresne</u>: Ok and yes, lets wait until the encoder gst element is ready and then the his enc kernel patches can be discussed
<br> that's why I only posted his dec patch from that series
ndufresne: nod
javier__: <u>ndufresne</u>: expected but after removing the cache file then gst-inspect reported the correct video dec elements and gst-launch worked
<br> sorry, I didn't know about this cache file
<br> <u>ndufresne</u>: I've also setup gst-uninstalled on this machine so I can test the latest gst from master. Everything built correctly but the v4l2video?dec are not found
<br> <u>ndufresne</u>: I'll bother you about that another day though since is not a blocker :)
ndufresne: did any calls to the driver failed during probing ?
javier__: <u>ndufresne</u>: I don't think so and also gst-inspect didn't show those elements
<br> but don't sorry, probably was just me doing something stupid so I'll look at that and let you know if I need any help
<br> in any case, I'm using the gst from my distro and now thanks to your help I know how to get it to work if the video nodes changes
<br> so I don't really need to play with gst master right now
ndufresne: nod
<br> <u>javier__</u>: before I forget, all the samsung,mfc-r/l reservation are wrong (all over the board)
<br> <u>javier__</u>: the left reservation is used for Y planes, while the right resrvation for the YU plane, it make no sense to reserve both the same size
<br> the MFC driver pretends to support 4 instances, the theorical maximum number of buffer is 16
<br> So at 1080p, the small 8mb we reserve will never do
<br> you need approx 200MB / 100MB reservation for that to work, for which you need to make the CMA reservation much much bigger (it's 64Mb right now)
<br> <u>javier__</u>: also, one of the developper pretend this reservation is board specific, that is completly wrong, we use the same Firware regardless the board, this is also why this setting is a copy paste everywhere
<br> it's nice though if you can override it in your board file, I don't know how that work with dtsi
javier__: <u>ndufresne</u>: yes, you can override any node that's defined one level up in the hierarchy
<br> <u>ndufresne</u>: I see, so what's your suggested sizes for mfc-{r,l} ?
ndufresne: so imho, those reservation should be in the root nodes, and the Nack was just wrong
<br> <u>javier__</u>: we should find something that match the maximum specification, which is different for Exynos 4 and 5
javier__: <u>ndufresne</u>: agreed, do you have a pointer to the discussion?
ndufresne: I saw that yesterday, but didn't keep the link, let me find it back
javier__: <u>ndufresne</u>: a definition for SoC .dtsi makes sense to me
<br> and as you said, board dts can override if needed
ndufresne: I like you change to use a generic memory reservation though
javier__: <u>ndufresne</u>: well, is Marek's changes
ndufresne: ah right, well, I like this idea
javier__: but I think those patches have problems since don't maintain DT backward compatibility
ndufresne: it's cleaner, less code
<br> hmm, right, that was something I feared
<br> so the DT ABI is to be considered stable ?
javier__: OTOH, one can claim that this never worked in mainline properly...
<br> <u>ndufresne</u>: yes, that's the idea
<br> <u>ndufresne</u>: although not everyone agrees on that https://www.youtube.com/watch?v=rPRqIS9q6CY
ndufresne: which have never worked indeed, even the DT backward thingy, use an older DT, and it generally won't boot ;-P
<br> lol, a Fairy Tail ....
javier__: <u>ndufresne</u>: I was talking about the MFC driver, not the DT ABI in general :)
ndufresne: * tal
<br> yep
javier__: <u>ndufresne</u>: but I might agree with you on the DT backward compatibility :P
<br> <u>ndufresne</u>: but being serious again, I agree with a mfc-{r,l} definition per MFC version
<br> so all SoCs with v8 should have the same and so on
ndufresne: it's hard thing to generalize across the entire kernel, having stable DT is a valid idea, but on th ARM side so much stuff got merged that ain't working
<br> (or got broken during rework)
javier__: <u>ndufresne</u>: so maybe Marek's patches not keeping DT backward compatibility is the best option in this case, but while those land we should fix the mfc memory reservation so the sizes makes sense
***: benjiG has left
javier__: <u>ndufresne</u>: right now I see that is 8MiB in most boards which as you said is too small
ndufresne: last time I had to look at that it was for Endless, we endup reserving 256/128 (which is a bit too much), so we could do 4 1080p streams
<br> That worked, both over Chromium and using GStreamer
<br> we later lower down to 2, as we needed more memory
<br> <u>javier__</u>: one of my reflection is that this setting let you shoot yourself in the foot
<br> You can't just change that, you need to control cma= those, and the number of instances the MFC will accept (which is hardcoded to something right now)
<br> And right now, while you can change the reservation in the DT, you can't control the number of instances, neither the driver will tailor the number of instances base on these value
<br> so when it fails, it fails with weird run-time error, which is super hard ot handle in the userspace
<br> Obviously, working iommu could fix it, but it's been 5+ years and this is still not reliable, unless you are confident now that your latest branch properly fix that ?
***: neg has quit IRC (Remote host closed the connection)
javier__: <u>ndufresne</u>: it works reliable on exynos5 but as you said, not many people care about exynos4 nowadays
<br> and still it should work properly with iommu disabled
ndufresne: I wonder what version of that branch we have here on our demo box, but it works for 2-3hs, and then starts failing randomly, maybe it's not iommu related, but n allocation fails, which should not happen, there is plenty of virtual memory available
<br> <u>javier__</u>: the test we do is playback a short video, stop everything, and start again, over and over
javier__: <u>ndufresne</u>: so it seems the cma, memory reservation and number of instances are related but currently the driver relies on the DTS and cma being set properly
<br> <u>ndufresne</u>: it would be great if you can reproduce that with mainline
ndufresne: yes, cma and reservation can be controlled (cma= is a kernel parameter)
javier__: although I guess you have proper mali support there so playback doesn't suck
ndufresne: <u>javier__</u>: well, for mainline I'm working on kmssink now, so we I don't need Mali
<br> but for that I need to figure-out what config I got wrong, as the FIMC won't work
javier__: <u>ndufresne</u>: btw, there is a #linux-exynos channel. I think we should move this discussion there to stop spamming the media people
ndufresne: ok
<br> <u>javier__</u>: ok, apparently the bank are no longer the same as before, bank1 (mfc-l) is used for small allocation, and bank2 (mfc-r) for bigger allocation
<br> from what I read, the bank1 is in the order of few hundred Kb
<br> so I'm digging more, it make little sense to me right now ...
javier__: <u>ndufresne</u>: I see, I'll take a closer look to the banks logic tomorrow
ndufresne: <u>javier__</u>: here bank2 fails, trying to allocate 1638400, but the bank is not exhausted yet
<br> basically it fails on the first allocation bigger then a megabyte, that's a strange coincidence
***: awalls has left
javier__: <u>ndufresne</u>: sorry, I wasn't online
<br> <u>ndufresne</u>: I don't have access to my test board now, but I had to double the size of the regions to be able to decode a 480p H.264 video
<br> <u>ndufresne</u>: I've to admit that I still don't really understand what the regions are used for, I just followed your advice since you know much more about all this
***: APic has quit IRC (Ping timeout: 260 seconds)