csd has quit [Ping timeout: 260 seconds]
csd has joined #linux-exynos
<memeka> how is the Exynos Scaler used for DRM in 4.18?
Ultrasauce has quit [Ping timeout: 240 seconds]
Ultrasauce has joined #linux-exynos
mszyprow has joined #linux-exynos
javier___ has joined #linux-exynos
javier___ has quit [Client Quit]
<memeka> mszyprow: ping
<mszyprow> memeka: pong
<memeka> mszyprow: I have issues with the drm
<mszyprow> memeka: what's broken?
<memeka> mszyprow: is mixer graphic0 and graphic1 supposed to work the same?
<mszyprow> memeka: what do you mean?
<mszyprow> memeka: they should behave the same way, the only difference might depend on the zpos
<mszyprow> memeka: the only difference should be the result of their z-order
<mszyprow> graph1 is on top of graph0 by default
<mszyprow> but this matter only for formats with alpha or non-full screen planes
<memeka> mszyprow: I changed graph1 type from CURSOR to OVERLAY
<memeka> Since you guys don’t have (probably never) implemented the video plane, I modified ffmpeg to send in decode to gsc
<memeka> Using dmabuf
<memeka> And then export the gsc output (drmprime)
<memeka> mszyprow: bug 1 I found - on yuv420, gsc capture sets wrong bytesperline
<memeka> It sums up nv12 planes bytesperline from output
<memeka> Bug 2 - gsc output bytesperline is wrong too
<memeka> Eg MFC capture NV12 has 2 planes with bytesperline 1920 each
<memeka> I do GFMT from MFC and SFMT the same on gsc output
<memeka> Gsc output then reports 1920 first plane and 960 second
<mszyprow> afair bytesperline in case of planar formats is a bit fishy, I don't remember if v4l2 specs are really precise on it
<memeka> Then I set gsc capture to yuv420, bytesperline is 2880 instead of 1920
<memeka> mszyprow: but most important
<memeka> When using kodi
<memeka> With video on PRIMARY plane (graphic0)
<memeka> And egl graphics GUI on overlay plane (graphic1)
<memeka> After displaying first video frame, I get kernel crash in iommu
<memeka> Just GUI is ok
<mszyprow> memeka: well, the bug means that mixer reads outside of the passed buffer
<memeka> Playing video with same code on drm (no GUI) also ok
<mszyprow> memeka: but it is hard to tell what is the reason for it
<mszyprow> memeka: is there any way to reproduce this?
<mszyprow> memeka: I mean could you share the image of sdcard that reproduces this issue?
<memeka> mszyprow: of course
<memeka> I can give u github
<mszyprow> memeka: it would take lots of time for me to setup everything
<memeka> From kodi and ffmpeg
<memeka> But image also
<memeka> Yeah faster
<memeka> Drm also behaves diff on 4.14 and 4.18
<mszyprow> having an image which quickly reproduces the issue allows me to take a look into this in a some spare few minutes
<memeka> Cool I’ll upload the image then
<mszyprow> just mail me the link and a few words of instruction how to trigger it
<mszyprow> xu4?
<memeka> In 12h or so tho, I’m at home now
<memeka> Yup
<memeka> Thx
<mszyprow> no problem, I will take a look into that tomorrow or so
<memeka> Ideally the video plane would be set in mixer :)
<mszyprow> next week I'm on holidays
<memeka> Maybe gsc sets wrong bytesusef
<mszyprow> probably
<memeka> But why is working with drm only
<memeka> Looks to me only when both planes are in use the crash happens
<mszyprow> but anyway drm should check provided buffers and forbid configuring mixer the way it triggers iommu page fault
<memeka> Maybe 4.18 has this fixed
<memeka> I need to integrate Mali to check :(
<mszyprow> Andrzej did some fixes in the mixer recently
<memeka> But on 4.14 it doesn’t work
<memeka> Oh something weird too
<mszyprow> but they were related to interlace and tile formats only
<memeka> If kodi is setup with both GUI and video on same plane
<mszyprow> but you may also check to apply mixer patches from mainline from v4.14..v4.18 releases
<memeka> Then it plays video for 10-20 seconds before crash
<memeka> It flickers like hell
<memeka> Since GUI and video mix there :)
<memeka> But doesn’t crash on 1st frame like when drawing on both planes at the same time
<mszyprow> okay, I will check, graph0 and graph1 are same from the hw registers point of view
<memeka> This is why for sure there must be something in mixer
<memeka> mszyprow: yeah I actually changed them too
<memeka> Made graphic1 primary
<memeka> It worked well
<memeka> Until again using both at the same time
<memeka> Is there any plan to do 542x video plane after 5433?
<mszyprow> yes, we plan to give it again a try but that depends on other tasks too
<memeka> Hope you make the time
<memeka> :)
<memeka> K I’m off for now
<memeka> I’ll email you tmr
<mszyprow> okay, have a nice evening
<memeka> mszyprow: one more thing :)
<memeka> 4.18 on odroid xu4 gives this on boot: https://www.irccloud.com/pastebin/GsX10NmR/
<memeka> for multiple devices
<memeka> dwc3_exynos_probe, s3c24xx_serial_probe, g2d_probe, exynos5_i2c_probe, exynos_ohci_probe, s5p_cec_probe, exynos_tmu_probe, ......
<memeka> and more
<mszyprow> are you sure you use proper dtb?
<mszyprow> from v4.18-rcX?
<mszyprow> I don't ovserve such issue here
<mszyprow> commit 6abdf8d135b77693e6f3f4ad8212bcbc6434eb2b fixed invalid gic irq flags long time ago...
<memeka> ah right let me see if i copied :D
<memeka> sorry :))
<memeka> i had the 4.14 one :))
<mszyprow> this still doesn't explain the issue, as v4.14 should also have it fixed
<mszyprow> that commit was merged to v4.10
<memeka> [ 5.119377] dwc3 12400000.dwc3: Failed to get clk 'ref': -2
<memeka> [ 4.979526] dwc3 12000000.dwc3: Failed to get clk 'ref': -2
<memeka> [ 4.701611] OF: graph: no port node found in /soc/hdmi@14530000
<memeka> [ 3.991894] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
<memeka> [ 4.049193] thermal thermal_zone0: failed to read out thermal zone (-22)
<memeka> zone1, zone2 same
<memeka> [ 3.409268] exynos-hdmi 14530000.hdmi: Failed to get supply 'vdd': -517
<memeka> these are kind of the only error
<memeka> ah wait!
<mszyprow> all are harmless and too verbose
<mszyprow> but right, one should clean the useless warnings too
<memeka> [ 0.180343] CPU4: Spectre v2: incorrect context switching function, system vulnerable
<memeka> hah :)
<mszyprow> yes, this one is new
<mszyprow> and there is also "CPU: WARNING: CPU(s) started in wrong/inconsistent modes (primary CPU mode 0x1a"
<mszyprow> this is probably the one that might be important to check
<memeka> mszyprow: i don't know where those are coming from
<memeka> EGL version: 1.4 Midgard-"r17p0-01rel0" == looks like mali works
<memeka> tmr i can test kodi with 4.18 :D
<memeka> mszyprow: here is a full log of the boot: https://pastebin.com/pw23sFBF
<memeka> you can see there are still some issues there :(
<mszyprow> memeka: 4.18.0-rc4+ means you have some more patches on top of v4.18-rc4
<memeka> mszyprow: yeah, mali drivers
<mszyprow> memeka: so probably your dts patches use incorrect irq specifiers
<mszyprow> check that
<mszyprow> all SoC built-in hw should use IRQ_TYPE_LEVEL_HIGH as the last argument to GIC interrupt specfier
<mszyprow> mali too
<mszyprow> (although it still work fine with 0 - IRQ_TYPE_LEVEL_NONE)
<mszyprow> the warning was added in v4.18-rc1 or v4.17-rc1
<mszyprow> just to force everyone to fix dts to use proper values
<mszyprow> use "interrupts = <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;" for mali
<memeka> so <0 219 0> should be <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
<memeka> yes :)
<memeka> you were faster :))
<memeka> mszyprow: also:
<memeka> [ 2.552373] s5p-mfc 11000000.codec: Direct firmware load for s5p-mfc-v8.fw failed with error -2
<memeka> [ 2.560912] s5p_mfc_load_firmware:73: Firmware is not present in the /lib/firmware directory nor compiled in kernel
<memeka> i remember when this patch was added :|
<memeka> firmware actually is there
<memeka> but rootfs is not mounted at that point i think
<memeka> so it's a stupid message
<mszyprow> that warning comes because rootfs is not yet mounted
<mszyprow> also on my todo list to convert that to use deferred probe
<mszyprow> i was surprised that kernel firmware loader doesn't support deferred probe and don't check if rootfs is mounted...
<memeka> :) thx the intrerrupt spec did eliminate the warnings
<memeka> mszyprow: last thing :)
<memeka> so when exporting buffers to DRM
<memeka> should i use sizeimage or bytesused? is there a problem if i use sizeimage?
<mszyprow> buffer can be larger than the size of the real video data
<memeka> (i don't get any error in ssh playing videos on DRM on any of the 2 planes now ... but i can't see if there is an actual image :D)
<memeka> yeah so sizeimage should be ok
<mszyprow> so it is better to use the same size as the one used for allocating the buffer
<memeka> yup
<mszyprow> it will be rounded up to page size anyway
<memeka> mszyprow: on primary plane, CPU usage is ~17% playing 1080p video; on overlay it's ~26% same file
<memeka> so either one of them is not showing anything on screen
<memeka> or the overlay is using more CPU because it flickers and shows the console too behind
Vasco_O is now known as Vasco
genii has joined #linux-exynos
nighty- has joined #linux-exynos
<willmore> mszyprow, it may be that the firmware loader doesn't wait because the firmware may be built into the kernel and may be needed to mount root--maybe net booting over a USB network connection that needs a firmware?
<willmore> Or I'm worng. That's likely, too.
Vasco is now known as Vasco_O
nighty- has quit [Quit: Disappears in a puff of smoke]
mszyprow_ has joined #linux-exynos
mszyprow has quit [Read error: Connection reset by peer]
<memeka> mszyprow_ page fault still occurs on 4.18
genii has quit [Read error: Connection reset by peer]