wwilly has quit [Quit: This computer has gone to sleep]
wwilly has joined #linux-exynos
wwilly has quit [Client Quit]
[7] has quit [Disconnected by services]
TheSeven has joined #linux-exynos
afaerber has joined #linux-exynos
afaerber has quit [Read error: Connection reset by peer]
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-exynos
isaque has joined #linux-exynos
amitk has quit [Quit: leaving]
krzk has quit [Quit: Ex-Chat]
wwilly has joined #linux-exynos
libv_ is now known as libv
amitk has joined #linux-exynos
LiquidAcid has joined #linux-exynos
paulk-nyan-big has joined #linux-exynos
LiquidAcid has quit [Quit: Leaving]
amitk has quit [Quit: leaving]
paulk-nyan-big has quit [Ping timeout: 250 seconds]
wwilly has quit [Quit: Leaving]
paulk-nyan-big has joined #linux-exynos
Vasco_O is now known as Vasco
wwilly has joined #linux-exynos
paulk-nyan-big has quit [Ping timeout: 244 seconds]
wwilly has quit [Quit: This computer has gone to sleep]
wwilly has joined #linux-exynos
wwilly has quit [Client Quit]
ndufresne has joined #linux-exynos
<ndufresne>
javier__: I was back on Exynos work today, I've hacked away the broken colorspace in the FIMC driver, and tried to import dmabuf from the s5p-mfc into the fimc driver, and I get the same crash as in the drm driver
<ndufresne>
and userptr for the same format works
<ndufresne>
so there is really something broken with the dmabuf from s5p-mfc (in cma mode)
<ndufresne>
One thing I wonder is why Marek never finished the driver that allow rebooting ...
<javier__>
ndufresne: I see, but the dma-buf comes from videobuf2 right?
<javier__>
I mean, there isn't something specific from the s5p-mfc driver
<ndufresne>
javier__: is it, or is it wrapped around memory from the reserved memory ?
<ndufresne>
that two driver importing it crash the same way does not sound like a coincidence to me
<javier__>
ndufresne: yes, I agree with you
<javier__>
ndufresne: is just that looking at the driver, I just see calls to vb2 (i.e: vb2_reqbufs)
isaque has left #linux-exynos ["Até logo"]
* ndufresne
need to look too
<ndufresne>
other options, something around the fact each plane are split allocation ...
<ndufresne>
e.g. it would be addressing the second plane throught he first one
* ndufresne
really wonder the best trick to bebug this
<javier__>
ndufresne: speaking about planes, I see that kmssink only works for me on my Chromebook that has a display
<javier__>
it fails on my Odroid XU4 that only has HDMI output, saying something like there isn't a plane associated with the CRTC
<ndufresne>
same here, if I unplug the hdmi cable, and try it, it fails
<javier__>
don't have access to my Odroid now to check the exact error message
<javier__>
Ok, it failed for me even with the HDMI cable plugged...
<ndufresne>
hmm
<ndufresne>
would need to poke Victor (ceyusa)
<ndufresne>
it's a very recent element, known to work on exynos4 and imx.6
<ndufresne>
the goal is to make it work everywhere
<ndufresne>
as a good test tool
<javier__>
ndufresne: another question, gst calls VIDIOC_REQBUFS(0) with different memory types to know what streaming I/O methods are supported by the driver right?
<ndufresne>
right, it's a bit hacky, but works
<javier__>
I'm asking because the "Only V4L2_MEMORY_MMAP is supported" error is annoying, and is wrong then to report as an error if user-space tools do that
<javier__>
in fact, even the v4l2 doc says that is the way to know if a I/O method is supported
<javier__>
I'll change to a dbg message then
<ndufresne>
make sense
<ndufresne>
it's not a very useful trace atm
<javier__>
agreed
<ndufresne>
the probing we do in GStreamer is realtively unique
<ndufresne>
it's just a new use case here, trace are probably tailored for hardcoded path, where you never call something that might fail
<javier__>
ndufresne: yeah but the v4l2 doc says "to determine if the memory mapping flavor is supported applications must call the VIDIOC_REQBUFS ioctl"
<javier__>
so it sounds to me that gst does the rigth thing and the driver is the one that wrongly printouts as an error
<ndufresne>
javier__: btw, I'm pushed bunch of changes in upstream GStreamer yesterday, and backported most of it for stable 1.8.2, this is to make the s5p-mfc work without having to hack gst
<javier__>
ndufresne: cool, most patches already landed in -next
<javier__>
and Marek's latest iommu patches so that should land soon too afaict
<ndufresne>
that's great, I have un-finished patches here too, will come later
<ndufresne>
iommu will be a big step forward
<ndufresne>
it will allow stuff like userptr from userspace allocated buffer
<javier__>
ndufresne: yeah, he also bumped the mfc left to 16MiB as you suggested
<javier__>
so at least with !IOMMU will be still usable
<ndufresne>
ok, it's a start, I wonder what I got right now
<ndufresne>
right size here is 0x2000000 and left size is 0x1000000
<ndufresne>
I gess you have 0x1000000 and 0x0800000 right ?
<javier__>
ndufresne: exactly
<ndufresne>
does it works for full-hd for you ?
<ndufresne>
also, on Exynos5, the decoder is 4K capable, I bet those value need to be even bigger
<ndufresne>
(if only we had a formula)
<javier__>
ndufresne: haven't tried with full HD yet, but the current sizes were not usable even for 480p
<ndufresne>
true
<ndufresne>
as of now, I manage to get smooth playback with v4l2videodec ! v4l2videoconvert output-io-mode=userptr capture-io-mode=dmabuf ! kmdsink
<ndufresne>
* kmssink
<javier__>
ndufresne: but yeah, hopefully everyone could just use IOMMU and forget about those custom reservations
<javier__>
ndufresne: oh, that's great. I want to achieve the same for Exynos5
<ndufresne>
it uses 10% CPU, didn'took what it is
<ndufresne>
on Exynos5, you should have same, but 30 fps 4K video normally
<javier__>
ndufresne: yeah, I just need to figure out what's needed in the exynos drm driver to allow importing buffers with the s5p-mfc capture format
<javier__>
you mentioned the GSC, is just that I'm really lost in gfx land...
<javier__>
ndufresne: anyway, at least there is some progress with the s5p-mfc being more stable now :)
<javier__>
ndufresne: and luisbg will take a look to the vidioc_s_fmt() returning -EBUSY if streaming issue
<ndufresne>
ah right
<ndufresne>
the GSC need to show up as a memory front-end for the video plane
<ndufresne>
(there is no other way to access that plane)
<ndufresne>
the code of the gsc drivers (both v4l2 and drm) isn't so good
<ndufresne>
those two driver should be refactored into a media-node driver, just like Renesas vpp imho
<ndufresne>
so they could be used in both world
<ndufresne>
the Renesas R-CAR drm design is really similar
<javier__>
ndufresne: haven't looked at the renesas driver yet (I have it on my TODO) but does the DRM driver register a media entity?
<ndufresne>
not yet, but the drm driver uses some of the media drivers
<ndufresne>
I know Laurent wants both, so you could stream to a drm plane purely using v4l2, the drm cookie is one of the blocker I think
<ndufresne>
but I'm a bit over my hat, I don't understand all this
<javier__>
yeah, me neither. I'm familiar with the media controller framework but no with DRM
<ndufresne>
javier__: for the current state of the drm gsc, you probably need to do some custom ioctl, not sure ...
<ndufresne>
there must be someone we can ask ?
wwilly has joined #linux-exynos
* ndufresne
would ask Daniel, but he's gone on vacation for a month)
<javier__>
ndufresne: I'll ask around to see if someone can help
<ndufresne>
right now I'm working on colorspace in FIMC btw, it's all hardcoded to JPEG, but the driver support BT601 and BT701 only ...
<ndufresne>
(it does not even support wide range yuv ..)
<javier__>
ndufresne: Ok
<luisbg>
javier__: :) cool
<ndufresne>
luisbg: btw, about the EBUSY, it's fixed on gst side already, I did that yesterday, we simply ignore the error int hat case now
shuah has joined #linux-exynos
<ndufresne>
luisbg: something's wrong in v4l2transform scaling support though
<javier__>
ndufresne: great, I'll rebase then my gst-unsintalled and drop the reverts
<ndufresne>
I should probably find a better warning, since this is driver bug
<javier__>
ndufresne: btw, I thought that changing a format was not permitted while and you had to start / stop the stream before doing that
<ndufresne>
javier__: that's right, but we are changing the CAPTURE format, only the OUTPUT is streaming
<ndufresne>
CAPTURE/OUTPUT should stay independant
<javier__>
ndufresne: oh, you are right
<luisbg>
I'm in and out. Sorry. Will read the backscroll in a while
<luisbg>
ndufresne: nice seeing you around :)
<ndufresne>
we suggested in a workshop that probing the capture formats while output is streaming should give a different result
<ndufresne>
so one can adversize just the right format if let's say output is set to jpeg, which often produce different format compared to h264 decoder
<javier__>
ndufresne: nod, doesn't make sense to enum all the supported formats for capture if output started
<ndufresne>
luisbg: nice to see you to, these days, everytime I get some spare time I work on testing the stuff added to gstv4l2, and improving it, though I added kmssink to my list now ;-P
<ndufresne>
javier__: and it helps usespace making the right decision
<ndufresne>
for an encoder it would be the exact oposite
<javier__>
ndufresne: agreed, makes sense to restrict the formats for one node if the other started streaming since that restricts the format list
<ndufresne>
but that one requires spec work first, Pawel was supposed to do that, but clearly he abandonned it
<javier__>
ndufresne: so now that you explained me the issue, I think the patch is really trivial: