<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>
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