<mixfix41> aww yes I finally booted a compiled kernel after x number tries. but this only has the wifi module enabled so
dlezcano_ has quit [Remote host closed the connection]
amitk has joined #linux-exynos
dlezcano has joined #linux-exynos
paulk-veyron-min has joined #linux-exynos
paulk-veyron-min has quit [Ping timeout: 240 seconds]
dlezcano has quit [Remote host closed the connection]
dlezcano has joined #linux-exynos
LiquidAcid has joined #linux-exynos
<ndufresne> on 4.8 rc5, I get some spam on Odroid U2/3, "mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)", any idea ?
LiquidAcid has quit [Quit: Leaving]
TheSeven has quit [Ping timeout: 255 seconds]
[7] has joined #linux-exynos
paulk-collins has joined #linux-exynos
<mixfix41> no audio or webccam with 4.7.2 http://pastebin.com/fJ3n1uxK
<mixfix41> at least I got slackware back on totally worth it!
<mixfix41> and here it is working on peach http://pastebin.com/9KqchMVd
<mixfix41> with the older kernel..
<javier__> mixfix41: audio is known issue, the webcam should work afaict
<javier__> did you try with exynos_defconfig?
<javier__> if you are comparing with the vendor 3.8 kernel, then isn't a good comparision since that has nothing to do with mainline
<mixfix41> actually this is my current lsmod though with 4.7.2 http://pastebin.com/A4TqnPiP
<mixfix41> yea I use that one
<mixfix41> then I went through menu config and it kicks with this source I got so definitely not getting a blank
<javier__> so mainline v4.7.2 + mainline exynos_defconfig should give you a working webcam, unless there is a regression
<mixfix41> well not exactly mainline, I'm using the kernel found from slackware arm
<javier__> mixfix41: ah, not sure what that is tbh
<mixfix41> but I think thats pretty mainline and it works compared to the linux.git I was using
<mixfix41> or atleast boots :)
<javier__> I can give a try to the webcam using mainline on my peach pi, not today though
<mixfix41> do it awesome distro
<mixfix41> they came out with hardfloat very recently
<mixfix41> I'll have to look at this dmesg http://pastebin.com/SeFmcg10
<mixfix41> oh your doing mainline... cool
<mixfix41> and here it the 3.8.11 dmesg thats working with sound http://pastebin.com/Xf1eB96w
<mixfix41> ah ic
LiquidAcid has joined #linux-exynos
<Gottox> ls
ayaka has quit [Read error: Connection timed out]
ayaka has joined #linux-exynos
<ndufresne> javier__: fyi, I enabmed IOMMU on my kernel (Odroid U2), as soon as I import a dmabuf i
<ndufresne> it crash
<ndufresne> at least it boots now in master ;-P
<LiquidAcid> ndufresne, which iommu is that btw?
<ndufresne> you mean which driver ? exynos-iommu, the Odroid U2 is an Exynos 4412
<LiquidAcid> ndufresne, no, i mean which device the iommu belongs to
<ndufresne> and the dmabuf in that case was passed between s5p-fimc and exynos-drm (drm driver is the importer)
<ndufresne> so it must belong to the allocating driver, which is s5p-fimc,
* ndufresne checking with another producer
<LiquidAcid> neverwind, it's sysmmu_tv
amitk has quit [Quit: leaving]
<LiquidAcid> *mind
<ndufresne> ok
<ndufresne> so all v4l2 driver share some code ?
<LiquidAcid> i would do another check with drm.debug=0xff to have a bit more "context"
<ndufresne> ok
<LiquidAcid> seems strange to get a pagefault if you're just importing and not actually scanning out from the buffer
<ndufresne> it should also be scanning out, I don't have any indication when the fault occure, I agree we need more context
<LiquidAcid> i thought you said you just imported it?
<ndufresne> no, I only mean that there is a dmabuf being imported for scannount, unlike copying to a drm allocated buffer (which works)
<LiquidAcid> i guess you need to provide more info then
<ndufresne> LiquidAcid: more info, not sure yet if it's going to be useful, https://paste.fedoraproject.org/427336/47370922/
<LiquidAcid> ndufresne, i don't see any addfb call?
<ndufresne> we do drmPrimeFDToHandle, kms_bo_get_prop, and then drmModeAddFB2
<ndufresne> maybe it crashed before, is the drm.core.debug suppose to trace all this ?
<LiquidAcid> ndufresne, well, point is that i don't see that addfb2 call in the log, making it pretty much worthless
<ndufresne> I'm trying to see if it's called
<LiquidAcid> i cannot figure out which bo 0x9e2e0000 is supposed to belong to without
<ndufresne> (question is what do I need to do to get that trace)
<LiquidAcid> <LiquidAcid> i would do another check with drm.debug=0xff to have a bit more "context"
<ndufresne> which I just did
<ndufresne> or maybe I got it wrong, isn't echo 0xff > /sys/module/drm/parameters/debug the same ?
<LiquidAcid> yes, that's correct
<LiquidAcid> but you log is pretty much incomplete
<ndufresne> so I was wondering if there is extra build time trace I forgot, but yeah, trace tend to be incomplete on kernel panic I guess
<LiquidAcid> works fine on my x2, not sure what you're doing to capture the uart
<ndufresne> it's the ttl thingy, save as on X2
<ndufresne> * same
<ndufresne> hence me wondering what could be missing
<ndufresne> (build time
<LiquidAcid> CONFIG_LOG_BUF_SHIFT?
<ndufresne> it's set to 17
<LiquidAcid> same here
<LiquidAcid> CONFIG_LOG_BUF_SHIFT=17
<LiquidAcid> CONFIG_NMI_LOG_BUF_SHIFT=13
<LiquidAcid> CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
<ndufresne> same, those are most likely from the exynos default
<javier__> ndufresne: I see, I'm no enabling iommu here (exynos5800 peach pi chromebook) due page faults caused by the bootloader leaving the fimd doing dma accesses
<javier__> so I can't even boot the device if iommu is enabled
<ndufresne> I thought it just worked on exynos5 ?
<javier__> ndufresne: I think it works on non-chromebooks exynos5 machines
<LiquidAcid> no idea when or if this ever gets accepted upstream
<javier__> LiquidAcid: right, that's Marek's fix for the issue but IIRC that was nacked
<LiquidAcid> javier__, yeah, that' why i said "ever" ;)
<javier__> LiquidAcid: OK :)
<ndufresne> that seems more like for javier__'s issue
<LiquidAcid> ndufresne, yes
<ndufresne> so that fact it boots is pretty much luck for me
<LiquidAcid> no idea about your logging problem, but i guess it's an issue with the tool capturing the serial output
<ndufresne> no, the issue is me, working on it
<ndufresne> I was not tracing directly, but though systemd
<LiquidAcid> hehe
<javier__> ndufresne: do you have the page fault only when doing dma-buf importing? does it work if you don't use dma-buf sharing?
<javier__> also, did you test with a different driver than s5p-fimc (i.e: vivid)
<javier__> ?
<ndufresne> It works without dmabuf if I decoder, convert, display here
<ndufresne> I haven't done more tests yet
<ndufresne> (like vivid
<javier__> ndufresne: Ok
<javier__> trying to figure out if the issue is on s5p-fimc, exynos-drm or exynos-iommu
<LiquidAcid> javier__, 99% of the times exynos-iommu is just the messenger
<javier__> LiquidAcid: I see, so you would rather bet on s5p-fimc or exynos-drm doing the wrong thing?
<LiquidAcid> yes, especially since this "codepath" is pretty much untested
<javier__> indeed
<LiquidAcid> at least i don't know about any real world applications out there that use buffer import/export between different devices on the exynos soc
<javier__> LiquidAcid: yeah, exynos-drm buffer import works for me if I do dma-buf sharing with a vivid virtual capture device but I didn't test with iommu enabled
<javier__> I tried using the s5p-mfc instead of vivid, but exynos-drm doesn't seem to support the NV12/21 formats that is output by the m2m device
<javier__> AFAIU the Gscaler could be used to do CSC but it didn't work for me when I enabled support for it in the exynos-drm driver
<ndufresne> same here, dmabuf sharing works for me, with vivid, mfc, fimc and exynos-drm, except it crash with tiled image produce by the decoder
<LiquidAcid> javier__, i'd say that you simply don't see the issue then, invalid access to memory that is
<ndufresne> without iommu
<javier__> LiquidAcid: yeah
<ndufresne> javier__: you just if "if I enable it in the drm driver", is that enabled manually ?
* ndufresne don't recall enable that
<LiquidAcid> javier__, but it still happens (like with the fimd bug that i reported some while back)
<LiquidAcid> which is afaik still not fixed
<javier__> ndufresne: CONFIG_DRM_EXYNOS_GSC
<javier__> but that's an exynos5 only IP block
<javier__> similar to exynos4 fimc IIRC
<ndufresne> ok, I see here, CONFIG_DRM_EXYNOS_IOMMU=y
<ndufresne> and for fimc it seems to simply be conditional to CONFIG_EXYNOS_IOMMU=y
* ndufresne should enable CONFIG_EXYNOS_IOMMU_DEBUG probably ...
<javier__> have to leave for a while, ttyl
<ndufresne> javier__: at least it proves that iommu solves the memory allocation issue we have with cma
<ndufresne> javier__: same crash with vivid
<ndufresne> to be continued
LiquidAcid has quit [Quit: Leaving]
paulk-collins has quit [Quit: Leaving]