dlezcano has quit [Remote host closed the connection]
dlezcano has joined #linux-exynos
LiquidAcid has quit [Quit: Leaving]
dlezcano has quit [Ping timeout: 244 seconds]
isaque has quit [Quit: isaque]
nashpa has quit [Ping timeout: 276 seconds]
nashpa has joined #linux-exynos
nashpa has quit [Ping timeout: 240 seconds]
nashpa has joined #linux-exynos
TheSeven has quit [Disconnected by services]
[7] has joined #linux-exynos
alexst has quit [Ping timeout: 272 seconds]
dlezcano has joined #linux-exynos
dlezcano has quit [Ping timeout: 244 seconds]
alexst has joined #linux-exynos
alexst has quit [Ping timeout: 272 seconds]
krzk_ has joined #linux-exynos
alexst has joined #linux-exynos
alexst has quit [Ping timeout: 240 seconds]
krzk_ has quit [Quit: Ex-Chat]
krzk_ has joined #linux-exynos
prahal__ has joined #linux-exynos
dlezcano has joined #linux-exynos
paulk-collins has joined #linux-exynos
krzk_ has quit [Quit: Ex-Chat]
isaque has joined #linux-exynos
ayaka has joined #linux-exynos
<ayaka> I have some problem with the DDC in HDMI for exynos 4412
<ayaka> I know it is a I2C bus attached to HDMI
<ayaka> but samsung,exynos4210-hdmiddc looks like a peripheral i2c devices
<ayaka> what does the samsung,exynos4210-hdmiddc really is
indy has quit [Ping timeout: 264 seconds]
paulk-collins has quit [Quit: Leaving]
Vasco_O is now known as Vasco
isaque has quit [Quit: isaque]
dlezcano has quit [Ping timeout: 240 seconds]
indy has joined #linux-exynos
indy has quit [Quit: ZNC - http://znc.sourceforge.net]
indy has joined #linux-exynos
dlezcano has joined #linux-exynos
dlezcano has quit [Ping timeout: 264 seconds]
dlezcano has joined #linux-exynos
alexst has joined #linux-exynos
snawrocki has quit [Remote host closed the connection]
dlezcano has quit [Ping timeout: 240 seconds]
dlezcano has joined #linux-exynos
isaque has joined #linux-exynos
dlezcano has quit [Ping timeout: 264 seconds]
alexst has quit [Ping timeout: 244 seconds]
dlezcano has joined #linux-exynos
paulk-collins has joined #linux-exynos
<javier__> ndufresne: kmssink only supports dma-buf import but no dma-buf export right?
<ndufresne> right
<ndufresne> currently it would be hard to figure-out what's best to offer between GBM and DMabuf
<javier__> ndufresne: Ok, now I understand why $ v4l2video4convert capture-io-mode=dmabuf worked but capture-io-mode=dmabuf-import
<ndufresne> maybe we need a way to remember the GBM for dmabuf backed by gbm, this way we would have best of both world
<javier__> ndufresne: there's a bug in gst though when trying to do dmabuf-import in a v4l2 driver though, QBUF fails but still STREAMON is attempted and gst hangs
<javier__> ndufresne: I would had expected to get an error and finish the pipeline when doing v4l2video4convert capture-io-mode=dmabuf-import ! kmssink
<ndufresne> but it can't right now, because the buffer pool have no idea in which context it tried to import the dmabuf
<javier__> ndufresne: ah, got it
<ndufresne> it needs to be rewritten
<ndufresne> more precisely, we need to remove capture from the buffer pool, it's just odd
<ndufresne> if I ever find the time, I'll just split out qbuf/dqbuf from the buffer pool control and move that up into the allocator, the allocator will be the authority on the queue, and then we'll be able to pick a specific buffer index to make kernel caching work in importation
<ndufresne> javier__: though, somehow I believe acquire should have failed, not sure what is goign on there, I would need to try
<ndufresne> javier__: so, did you at least manage to display something the other way around ?
<ndufresne> it's not the most efficient way to display stuff though, since the gsc can supposedly be directly connected to the HW video mixer
<javier__> ndufresne: oh, yes. v4l2 export / drm import worked pretty well
<ndufresne> that's cool
<javier__> ndufresne: yeah but the gsc drm support doesn't seem to be that good in mainline
<javier__> and also you need custom exynos IPP ioctls IIUC
<javier__> so can't be used with kmssink in its current form
<ndufresne> then it's probably better to factor out the gsc v4l2, and use that API in DRM ;-P
<ndufresne> gsc is multi-instance, so I'd just reserve 1 instance for the video plane
<ndufresne> we could also take the opportunity to expose gsc v4l2 as an interface to the drm video plane, that would be funny
<ndufresne> javier__: is that with IOMMU enabled ?
prahal__ has quit [Ping timeout: 264 seconds]
<javier__> ndufresne: yes, gsc is multi-instance but I mentioned being able to use both instances with different drivers is not supported in mainline yet
<javier__> IIRC the downstream kernel has a DT property to say if the instance should be used for the local path or to a external device
<ndufresne> javier__: no of course, you should have a single driver, and two interface drm and v4l2 on top, just like renesas
<ndufresne> you don't want random thread messing with your hardware registers
<javier__> ndufresne: yes, that would should be the path forward of course
<javier__> ndufresne: it's without IOMMU because I'm testing with a Chromebook right now and these machines don't boot with IOMMU enabled due the bootloader leaving the FIMD scaning out
<javier__> but I'll setup my XU4 and give a try with IOMMU enabled to see if I can reproduce your issue
<ndufresne> javier__: can't you just hard code an FIMD reset at boot ?
<ndufresne> ah ok
<javier__> ndufresne: I can't in the bootloader because is read-only (unless you risk to brick the machine) and IIUC iommu is enabled to early to do it in the kernel
<javier__> anyways, it's easier to test it with the XU4 :)
<ndufresne> ah, it basically page-fault ...
<ndufresne> it's annoying that we can't recover from a sysiommu page fault
<javier__> ndufresne: correct, it's a page fault. Marek posted this as a workaround but was nacked http://www.spinics.net/lists/arm-kernel/msg419747.html
<ndufresne> javier__: that solution seems really complicated
<ndufresne> still, I may not understand all details of it
<ndufresne> we basically have a contiguous set of pages that will need to be shadowed through sysiommu during boot
<javier__> ndufresne: yes, because the device is performing DMA operations and when IOMMU is enabled, it does an initial setup for all devices that causes page faults
<javier__> once the exynos drm driver is probed, then it requests the IO regions and the translation is done but the FIMD is doing dma operations before that
<ndufresne> ah, scanount is not the only buffer ...
LiquidAcid has joined #linux-exynos
<javier__> ndufresne: so Marek's approach is to add a iommu-reserved-mapping DT property that is used to create mappings when iommu is enabled, even before the device requests that IO region
<ndufresne> I guess that's where it get invasive
<ndufresne> I don't see any other solution though, maybe something that bind the reservation to the driver so it can be discarded later
<javier__> ndufresne: yeah, I didn't look at the patch in detail tbh so I don't know what happens with the mapping once the driver is probed
<javier__> probably is just a static mapping and is never discarded...
<javier__> ndufresne: anyway, this only happens with the Chromebooks since they have a display and that's why it doesn't affect the XU4
<ndufresne> nod
prahal__ has joined #linux-exynos
<LiquidAcid> prahal__, hey, concerning the devfreq thing we discussed some days ago, it's actually only bus_dmc that needs to be clocked at 400mht
<LiquidAcid> *mhz
alexst has joined #linux-exynos
<ayaka> ndufresne, could tell me how do you deal with the HDMI ddc when you enabled the HDMI at exynos 4
<ndufresne> I'm not sure I understand the question, not that I didn't anything special to get that working ont he Odroid U2
<prahal__> indeed , trans_stat of bus_dmc devfreq shows the value was always 400mhz since I switch its governor to performance (and that fixed the issue < flickers of the display)
<prahal__> gtg
<ayaka> well, maybe the driver change
<ayaka> I have to configure a DDC node at i2c or the HDMI seems not work
<ndufresne> ayaka: which board are you running on ?
<ayaka> ndufresne, not well known, a board called topeet itop 4412, which I just commit the dts file
<ayaka> s/commit/submit/
<LiquidAcid> prahal__, i still need to do some more tests, like trying low dmc clocks with default g2d clock -- but there definitely is some hard constrain with the respect to clocks here
<ndufresne> ayaka: ah, I see, I never learned how that part worked since the U2/U3 had a working dts already
<ndufresne> ayaka: the hdmi bits are in the odroid-common.dts, but is probably specific to all odroids
<ayaka> ok I may sent a letter to mail list to make sure what it is
<ndufresne> ayaka: might help, or not, https://paste.fedoraproject.org/437496/88728147/
<ayaka> yes I nearly copy the same thing from odroid-common
<ayaka> but anyway I finally understand what the colorimetry is in gstreamer
<ayaka> I could start the check with fimc
<ndufresne> ok
<prahal__> LiquidAcid: ... mind my first u2 board fails audio dma , I put the blame on the g2d oc but I also noticed dmc clocks diff between my new u2 board where audio is fine (the latter started to fail at times until I set g2d back to 200 . still it might be a boarder effect and the blame be on dmc
<LiquidAcid> prahal__, you have the same uboot running on both devices?
<prahal__> this is the same emmc :)
<LiquidAcid> mysterious :)
<prahal__> I switch the boards and keep the same externals items
<prahal__> bbl
<LiquidAcid> different hw revision?
masta has quit [Quit: Leaving]
<LiquidAcid> iirc then the bus frequencies are adjusted with the help of performance counters. if you see such differences there, then maybe the perf counters are returning different values (not sure why this should be the case though, IF the hardware is the same)
prahal__ has quit [Quit: prahal__]
prahal__ has joined #linux-exynos
<ayaka> ok I finally pass the ddc part
<ayaka> but I met exynos-drm exynos-drm: failed to bind 12d00000.hdmi (ops hdmi_component_ops [exynosdrm]): -1
<ayaka> I nee more time to debug the hdmi
prahal__ has quit [Quit: prahal__]
<ayaka> oh, it sounds like I forget to enable the mixer
prahal__ has joined #linux-exynos
<LiquidAcid> ayaka, will it blend? ;D
<ayaka> it is a component at exynos
<LiquidAcid> i know
<LiquidAcid> sry, guess my joke didn't work :(
<ayaka> I never go into deeply of the relationship of components in exynos
<ayaka> LiquidAcid, well, the English joke won't work with the those guys not native at it
<ayaka> it is ever a little problem to understand the English
<LiquidAcid> ayaka, and even worse when a german guy tries to do a joke in english :)
<ayaka> German is a joke themselves
<ayaka> like the organization of Italian and the hard working of France
<ayaka> I know this joke
<LiquidAcid> and english cuisine
<LiquidAcid> (to continue the joke)
<Gottox> We have a very distinct humor!
<LiquidAcid> Gottox, where are you from?
<Gottox> Germany ;)
<LiquidAcid> ah, i see
<ayaka> bounty of Holland
<ayaka> not offense
<Gottox> :D
<LiquidAcid> you're german when you know at least loriot and heinz erhardt
<ayaka> I learn this joke from Yes, Minister. It is a complete English art, so blame the Britain
<Gottox> Even Monty Python did two episodes of their flying circus in german. :D
dlezcano has quit [Ping timeout: 264 seconds]
<ayaka> Monty Python is the other problem for me, I can only understand the Python but beyond the Monty
<ayaka> I saw the SPAM last time, but maybe it is a difficult for me to understand
<LiquidAcid> my favorite is life of brian, closely followed by monty python and the holy grail
<ayaka> I hope I could buy those full quality version of those episodes, in the next time I could use them to testing the video system
<ayaka> now I could only use the Japanese anime(cartoon), it nearly erase my English ability
<LiquidAcid> watch it with subtitles like i do ;)
<ayaka> if you do a job about the video, and watching the same language videos at you free time
<ayaka> you would easily understand a language, and drop the subtitles
<LiquidAcid> so you speak japanese?
<ayaka> yes and not, it is not my native English, but I learn it from daily watching
<LiquidAcid> sadly this doesn't work for me, even though i'm able to understand quite some words and read a few kanji, doing any kind of proper conversation was impossible when i was in japan the last time
prahal__ has quit [Ping timeout: 272 seconds]
Vasco is now known as Vasco_O
alexst has quit [Ping timeout: 272 seconds]
alexst has joined #linux-exynos
dlezcano has joined #linux-exynos
paulk-collins has quit [Quit: Leaving]
alexst has quit [Ping timeout: 244 seconds]
alexst has joined #linux-exynos
LiquidAcid has quit [Quit: Leaving]