<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
<javier__> I see...
<ndufresne> the pipeline I use is following
<ndufresne> v4l2videoNdec capture-io-mode=dmabuf ! kmssink
<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)
<javier__> ndufresne: now I get this: http://hastebin.com/colozuyinu.vbs
<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
<ndufresne> v4l2src io-mode=dmabuf ! video/x-raw,format=NV12 ! kmssink
<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]
bgamari has quit [*.net *.split]
masta has joined #linux-exynos
paulk-collins has joined #linux-exynos
cosm_ has joined #linux-exynos
bgamari has joined #linux-exynos
krzk has quit [Quit: Ex-Chat]
wiewo has joined #linux-exynos
bgamari has quit [*.net *.split]
wiewo_ has quit [Ping timeout: 244 seconds]
bgamari has joined #linux-exynos
amitk has quit [Quit: leaving]
LiquidAcid has joined #linux-exynos
<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> I see
<ndufresne> and then to let you use un-padded width/height
<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
<LiquidAcid> this shouldn't be here
<ndufresne> ok, and why the person who changed the rule didn't fix it ?
<ndufresne> anyway, I'm not going to refactor code that I'm not even going to change
<LiquidAcid> ndufresne, which rule? you mean atomic?
<ndufresne> for the simple reason my time is not unlimited
<ndufresne> Anyone actively maintaining that driver btw ?
<ndufresne> LiquidAcid: and, do you have an example of somewhere it's done right ? in case I change my mind
<LiquidAcid> ndufresne, not really, probably something to ask on #dri-devel
<LiquidAcid> i think intel got it right with their modifiers
<LiquidAcid> msm only has this:
<LiquidAcid> static int mdp4_plane_atomic_check(struct drm_plane *plane,
<LiquidAcid> struct drm_plane_state *state)
<LiquidAcid> {
<LiquidAcid> }
<LiquidAcid> return 0;
<ndufresne> except they forgot it would be nice to know what modifier a plane supports ;-P
<LiquidAcid> and even better, in atomic update: /* atomic_check should have ensured that this doesn't fail */
<ndufresne> wow, it's the fast path of checks
<LiquidAcid> ndufresne, i know the frustration
Vasco is now known as Vasco_O
cosm_ has quit [Quit: Leaving]
paulk-collins has quit [Quit: Leaving]
wwilly has quit [Quit: Leaving]
LiquidAcid has quit [Quit: Leaving]