| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | iive has quit IRC (Quit: They came for me...) | [00:30] |
| ........ (idle for 36mn) | ||
| crazy_imp has quit IRC (Ping timeout: 276 seconds) | [01:06] | |
| shuah has quit IRC (Quit: Ex-Chat) | [01:20] | |
| ...................... (idle for 1h49mn) | ||
| 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 | [03:09] |
| ............... (idle for 1h12mn) | ||
| *** | jmleo has quit IRC (Ping timeout: 276 seconds) | [04:21] |
| ....................................... (idle for 3h10mn) | ||
| kbingham has quit IRC (Ping timeout: 240 seconds) | [07:31] | |
| ...... (idle for 27mn) | ||
| hverkuil | mchehab: linuxtv.org seems to have problems, can you take a look? All I get is 'Index of /'. | [07:58] |
| it seems to be http related, accessing the git repo works fine. | [08:09] | |
| .............. (idle for 1h5mn) | ||
| *** | groleo has quit IRC (Ping timeout: 240 seconds) | [09:14] |
| ............................................ (idle for 3h35mn) | ||
| mchehab | hverkuil: what was missing were the redirects from http->https
it should be fixed now | [12:49] |
| hverkuil | mchehab: that looks much better! Thanks. | [12:49] |
| mchehab | I had to fix the configs yesterday, in order to renew the letsencrypt certs
(they should be renewed on every ~90 days) | [12:50] |
| ........................ (idle for 1h56mn) | ||
| javier__ | ndufresne: hi, it seems that GStreamer doesn't parse correctly what are the video nodes for the registered decoders
ndufresne: http://hastebin.com/kiduqenaja.hs I'm using the GStramer in my distro though, which is 1.4.5 so maybe this is fixed in mainline already? | [14:46] |
| ndufresne | javier__: you mean it does not support the extended CAPS ? | [15:00] |
| *** | bparrot has quit IRC (Remote host closed the connection) | [15:07] |
| javier__ | ndufresne: no, I meant that it only works if the MFC decoder is registered as /dev/video0
ndufresne: 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 look like the kernel log says: [ 13.010701] s5p-mfc 11000000.codec: decoder registered as /dev/video4 but there isn't a v4l2video4dec element according to gst-inspect-1.0 s/look like/look how | [15:08] |
| ndufresne: 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 | [15:16] | |
| ndufresne | javier__: sorry, I'm back
javier__: it should work regardless what node it is as of 1.8 at least, we track the /dev/videoN changes and update the elements accordingly before that, you'd have to keep them streight (before that we where only using it with fixed videoN assignment javier__: to fix it, just rm the gst cache depending on your setup, should be $HOME/.cache/gstreamer-1.0/registry.arm.bin or armvXX depending what your kernel report javier__: note that the jpeg decoder does not work, as it only allow 1 buffer allocation, at the moment gst requires at least 2 We also need to add a parser, to split data into full frame and then, need to fix the driver which fail for random reason ;-P | [15:19] |
| javier__ | ndufresne: Ok, I see the .cache/gstreamer-1.0/registry.armv7hl.bin file, I'll remove it and test
ndufresne: yes, one driver at at time :P | [15:25] |
| ndufresne | (y)
javier__: 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 | [15:27] |
| javier__ | ndufresne: Ok and yes, lets wait until the encoder gst element is ready and then the his enc kernel patches can be discussed
that's why I only posted his dec patch from that series | [15:29] |
| ndufresne | nod | [15:30] |
| javier__ | ndufresne: expected but after removing the cache file then gst-inspect reported the correct video dec elements and gst-launch worked
sorry, I didn't know about this cache file ndufresne: 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 ndufresne: I'll bother you about that another day though since is not a blocker :) | [15:32] |
| ndufresne | did any calls to the driver failed during probing ? | [15:36] |
| javier__ | ndufresne: I don't think so and also gst-inspect didn't show those elements
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 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 so I don't really need to play with gst master right now | [15:37] |
| ndufresne | nod | [15:39] |
| javier__: before I forget, all the samsung,mfc-r/l reservation are wrong (all over the board)
javier__: 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 the MFC driver pretends to support 4 instances, the theorical maximum number of buffer is 16 So at 1080p, the small 8mb we reserve will never do 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) javier__: 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 it's nice though if you can override it in your board file, I don't know how that work with dtsi | [15:50] | |
| javier__ | ndufresne: yes, you can override any node that's defined one level up in the hierarchy
ndufresne: I see, so what's your suggested sizes for mfc-{r,l} ? | [15:54] |
| ndufresne | so imho, those reservation should be in the root nodes, and the Nack was just wrong
javier__: we should find something that match the maximum specification, which is different for Exynos 4 and 5 | [15:54] |
| javier__ | ndufresne: agreed, do you have a pointer to the discussion? | [15:55] |
| ndufresne | I saw that yesterday, but didn't keep the link, let me find it back | [15:55] |
| javier__ | ndufresne: a definition for SoC .dtsi makes sense to me
and as you said, board dts can override if needed | [15:55] |
| ndufresne | I like you change to use a generic memory reservation though | [15:56] |
| javier__ | ndufresne: well, is Marek's changes | [15:56] |
| ndufresne | ah right, well, I like this idea | [15:57] |
| javier__ | but I think those patches have problems since don't maintain DT backward compatibility | [15:57] |
| ndufresne | it's cleaner, less code
hmm, right, that was something I feared so the DT ABI is to be considered stable ? | [15:57] |
| javier__ | OTOH, one can claim that this never worked in mainline properly...
ndufresne: yes, that's the idea ndufresne: although not everyone agrees on that https://www.youtube.com/watch?v=rPRqIS9q6CY | [15:57] |
| ndufresne | which have never worked indeed, even the DT backward thingy, use an older DT, and it generally won't boot ;-P
lol, a Fairy Tail .... | [15:58] |
| javier__ | ndufresne: I was talking about the MFC driver, not the DT ABI in general :) | [15:58] |
| ndufresne | * tal
yep | [15:58] |
| javier__ | ndufresne: but I might agree with you on the DT backward compatibility :P
ndufresne: but being serious again, I agree with a mfc-{r,l} definition per MFC version so all SoCs with v8 should have the same and so on | [15:59] |
| 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
(or got broken during rework) | [16:00] |
| javier__ | ndufresne: 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 | [16:01] |
| *** | benjiG has left | [16:01] |
| javier__ | ndufresne: right now I see that is 8MiB in most boards which as you said is too small | [16:02] |
| 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
That worked, both over Chromium and using GStreamer we later lower down to 2, as we needed more memory javier__: one of my reflection is that this setting let you shoot yourself in the foot 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) 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 so when it fails, it fails with weird run-time error, which is super hard ot handle in the userspace 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 ? | [16:04] |
| *** | neg has quit IRC (Remote host closed the connection) | [16:11] |
| javier__ | ndufresne: it works reliable on exynos5 but as you said, not many people care about exynos4 nowadays
and still it should work properly with iommu disabled | [16:19] |
| 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
javier__: the test we do is playback a short video, stop everything, and start again, over and over | [16:20] |
| javier__ | ndufresne: 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
ndufresne: it would be great if you can reproduce that with mainline | [16:21] |
| ndufresne | yes, cma and reservation can be controlled (cma= is a kernel parameter) | [16:21] |
| javier__ | although I guess you have proper mali support there so playback doesn't suck | [16:21] |
| ndufresne | javier__: well, for mainline I'm working on kmssink now, so we I don't need Mali
but for that I need to figure-out what config I got wrong, as the FIMC won't work | [16:22] |
| javier__ | ndufresne: btw, there is a #linux-exynos channel. I think we should move this discussion there to stop spamming the media people | [16:22] |
| ndufresne | ok | [16:22] |
| ............................ (idle for 2h16mn) | ||
| javier__: 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
from what I read, the bank1 is in the order of few hundred Kb so I'm digging more, it make little sense to me right now ... | [18:38] | |
| javier__ | ndufresne: I see, I'll take a closer look to the banks logic tomorrow | [18:48] |
| ndufresne | javier__: here bank2 fails, trying to allocate 1638400, but the bank is not exhausted yet
basically it fails on the first allocation bigger then a megabyte, that's a strange coincidence | [18:52] |
| ............. (idle for 1h3mn) | ||
| *** | awalls has left | [19:57] |
| ...................... (idle for 1h48mn) | ||
| javier__ | ndufresne: sorry, I wasn't online
ndufresne: 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 ndufresne: 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 | [21:45] |
| ......................... (idle for 2h2mn) | ||
| *** | APic has quit IRC (Ping timeout: 260 seconds) | [23:48] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |