<ndufresne>
javier__: sorry you have hit that, in fact Philipp Zabel started looking at that before me, we'll bring a patch for 1.8 for sure when ready
<ndufresne>
javier__: is that with iommu or without ? (you need to test without of course, otherwise page fault are no longer an issue)
<ndufresne>
javier__: note that MFC driver is wrong in returing EBUSY, it should fix the FMT structure to whatever it supports
<javier__>
ndufresne: no worries, thanks to you for warn me about it the other day. Otherwise I would expend a lot of time trying to figure out the problem
<javier__>
ndufresne: yes, that's without IOMMU
<ndufresne>
hmm, interesting, and with 1080p ?
<ndufresne>
did you change the reservation ?
<ndufresne>
javier__: ah, wait, videoconvert
<javier__>
ndufresne: I used the values you suggested (8 and 16 MiB) but no, it wasn't a 1080p but a small video (480p)
<ndufresne>
javier__: videoconvert will convert to RGB for Exynos5, unless you hook the GScaler somehow
<javier__>
ndufresne: ah, but I thought I used the pipeline you gave me
<ndufresne>
and the resulting memory is no longer dmabuf
<ndufresne>
I had to patch kmssink and the kernel to get the NV12 tile format to be negotiated
<ndufresne>
that part will take a while to upstream, because there is issues in the DRM interface, we cannot detect support for modifiers atm (it's generally hardcoded in userspace, but kmssink is generic)
<ndufresne>
javier__: for Exynos5, you need to use the video plane, and for that you need to connect the GScaler to that plane, because the video plane has no memory interface
<javier__>
ndufresne: I see, I tried your pipeline and indeed I get a: WARNING: erroneous pipeline: could not link h264parse0 to v4l2video1dec0
<ndufresne>
I have not yet found how that actually works, but as there is a GScale driver, I suspect there is a way
<ndufresne>
javier__: hmm, that sounds like a different issue, have you rebooted ?
<ndufresne>
/dev/video devices swaps around all the time
TheSeven has quit [Ping timeout: 272 seconds]
<javier__>
ndufresne: err, sorry I did indeed used an old command from the shell history that used a different video node
<ndufresne>
javier__: the error sais mainly that v4l2video1dec does not support h264, which usually mean this is not the decoder you expect (e.g. the jpeg decoder)
<ndufresne>
the jpeg decoder (at least on Eynos 4) is a different story, the driver serisouly need work
<javier__>
ndufresne: yes, sorry. It's late here so I'm more stupid than usual ;)
<javier__>
anyways, it seems testing DRM dma-buf import won't be trivial then if I need to figure out how to hook the GSC
<ndufresne>
hehe, no problem, I'll be at work tomorrow if you'd like some help at a saner time ;-P
<ndufresne>
javier__: have you installed vivid driver ?
<ndufresne>
I usually test that first
<javier__>
ndufresne: great, I'm chasing an issue now with the s5p-mfc driver causing a unhandled fault / imprecise abort when the module is removed and loaded
<ndufresne>
For testing something representative, use the following
<javier__>
ndufresne: great, I'll install vivid to test then
<javier__>
ndufresne: are your kmssink patches available?
<ndufresne>
for NV12 tiled though, it's not implemented in vivid unfortunatly, I tested dmabuf import in NV12 here, from the FIMC driver, and that worked
<ndufresne>
javier__: I'll try to make all my patches (even if tempory) available soon
<javier__>
ndufresne: Ok, thanks
<ndufresne>
I only got that running for real last Friday
<javier__>
ndufresne: have to leave for now, thanks again for your help
<ndufresne>
some patches are to fix regressions (like the ebusy thing you've hit), others are to fix remaining FIMC bugs ;-P
<ndufresne>
good night !
<javier__>
ndufresne: thanks, you too!
<ndufresne>
thanks to you in looking into this, I'd like just like you to keep this driver stable as long as possible
TheSeven has joined #linux-exynos
mturquette has joined #linux-exynos
Wizzup has quit [Ping timeout: 240 seconds]
Wizzup has joined #linux-exynos
ansiwon has quit [Quit: leaving]
masta has quit [Read error: Connection reset by peer]
masta has joined #linux-exynos
amitk has joined #linux-exynos
ansiwon has joined #linux-exynos
krzk has joined #linux-exynos
dlan has joined #linux-exynos
ansiwon has quit [Quit: leaving]
indy_ is now known as indy
steev has quit [Ping timeout: 260 seconds]
steev has joined #linux-exynos
krzk has quit [Quit: Ex-Chat]
wwilly has joined #linux-exynos
krzk has joined #linux-exynos
nashpa has quit [Quit: Going away]
nashpa has joined #linux-exynos
ansiwon has joined #linux-exynos
ansiwon has quit [Read error: Connection reset by peer]
ansiwon has joined #linux-exynos
isaque has quit [Quit: isaque]
isaque has joined #linux-exynos
<ndufresne>
javier__: I just saw a patchset from Marek, which seems to address DMABuf (from cma) issues
<javier__>
ndufresne: AFAIU that's only for when IOMMU is enabled
<javier__>
you mean "[PATCH v5 0/2] vb2-dma-contig: configure DMA max segment size properly" right?
<javier__>
that was part of his previous series to add IOMMU support to sp5-mfc but now was split on its own series
<ndufresne>
javier__: ah, ok, I read it up-side-down I guess
bzyx has quit [Ping timeout: 244 seconds]
bzyx has joined #linux-exynos
masta has quit [Read error: Connection reset by peer]
<LiquidAcid>
maybe this gets the g2d up and running for oyu
<LiquidAcid>
Wizzup, also you mentioned a kernel oops yesterday (when plugging in hdmi), care to pastebin this so i can take a look?
<Wizzup>
Hiya. I will look at the changeset in a bit. As for the hdmi log, I can make a picture. Probably not get the log in txt since I have no serial
<Wizzup>
May be until tomorrow before I can take a good look and test.
<LiquidAcid>
Wizzup, the commit just implements what i discussed with javier__ yesterday
<Wizzup>
Acknowledged
<javier__>
LiquidAcid: great
<javier__>
it's a pity that my XU4 board completely died and doesn't boot anymore, since IOMMU is working there
<javier__>
I asked for a replacement board but it will take ~2 weeks to arrive
<LiquidAcid>
javier__, i have no idea if it's going to work though, so let's just be cautiously optimistic :)
<javier__>
LiquidAcid: yes I know but at least I would be able to test on that board since with IOMMU enabled my Peach doesn't boot
<javier__>
I should give a try to your branch that has the latest version of Marek's patches that fix that issue but IIRC didn't work for me when he posted them
<javier__>
it was a long time ago though so I may be misremembering
bgamari has quit [Ping timeout: 258 seconds]
bgamari has joined #linux-exynos
<LiquidAcid>
javier__, yeah, would definitely be good if someone else could test the code
<Wizzup>
I'm assuming the chances of me bfreaking my peach-pi are low, so kI'll try to do it tomorrow
<LiquidAcid>
Wizzup, i keep an eye/ear out for the explosion when you do ;)
<ndufresne>
javier__: Marek state that he tested his latest patches on U3, like I'm using, does it means he got IOMMU working on Exynos 4 ?
<LiquidAcid>
ndufresne, btw i checked 4.6 vanilla on my odroid and it's working fine (iommu enabled)
<ndufresne>
exynos 5 ?
<LiquidAcid>
ndufresne, exynos4412
<ndufresne>
I should probably retry
<LiquidAcid>
but for me this was never broken, so i'm unsure what issue you're seeing
<ndufresne>
I only rebased on final 4.6 last Friday
* ndufresne
hope to have some more time soon
<ndufresne>
if that works, it means we can enable it in the defconf and remove the reserved region from the DT
<ndufresne>
would save a lot of ram while not decoding
<LiquidAcid>
ndufresne, btw, anywhere where i can see your nv12mt/drm patches?
<ndufresne>
(ok, let me push that somewhere, it's WIP though)
<ndufresne>
LiquidAcid: I'm setting up a repo, sorry for the delay, should speed up things later
<LiquidAcid>
ndufresne, no need to hurry, was just asking
<javier__>
ndufresne: oh, I missed he mentioned that but yes, it should be work on your XU2 as well
<javier__>
ndufresne: we can't enabled in the defconf because some machines don't boot with IOMMU enabled (i.e: Snow, Pit and Pi Chromebooks)
<javier__>
*enable
<javier__>
so until that's sorted, it should remain disabled by default
<ndufresne>
the VideoProcessor support any step of cropping, and you don't need to tell it about the padding (it's implicit for tile formats)
<LiquidAcid>
ndufresne, i think these checks should go into atomic_check
<ndufresne>
could not tell ;-P
<ndufresne>
what are the atomic check ?
<ndufresne>
are these check per framebuffer ?
<ndufresne>
LiquidAcid: also, this patch might be opening a door to crash the msm driver, I didn't took time to ask them yet
<ndufresne>
they support this format on older revision, as they were using the Samsung MFC apparently as their CODEC, until they replace with their own
<LiquidAcid>
ndufresne, point is that vp_video_buffer() is called during the atomic commit phase, which is to late to error out
<LiquidAcid>
ndufresne, best to ask gustavo or marek about it though
<ndufresne>
possible, though in gst it failed cleanly
<ndufresne>
maybe I was being lucky
<ndufresne>
I just modified it in place, the code was there before ;-P
<LiquidAcid>
yes, but that's how atomic is supposed to work
<LiquidAcid>
there is also still code left in the non-vp path which could potentially error, but it's from pre-atomic time
<LiquidAcid>
if you introduce new code i doubt you get it in if it clearly violates atomic semantics
<ndufresne>
lol, I like the use of "violates" here, anyway, sure, I expect reviewers to give pointer if existing code is wrong