ansiwon has quit [Read error: Connection reset by peer]
ansiwon has joined #linux-exynos
amitk has joined #linux-exynos
krzk has joined #linux-exynos
krzk has quit [Quit: Ex-Chat]
krzk has joined #linux-exynos
Vasco_O is now known as Vasco
<ndufresne>
Weird, so dmabuf import in kms drivers (even in tiled formats) works when the dmabuf is from FIMC, but crash when it's from MFC, sounds like a regression in the decoder
<javier__>
ndufresne: mm, that's weird indeed. And as you said it seems to be a bug in the s5p-mfc driver and not Exynos DRM
<javier__>
ndufresne: can I reproduce it in a Exynos5 board?
<ndufresne>
I don't know, but you can try
<ndufresne>
you need GStreamer from master
<ndufresne>
(with kmssink)
<javier__>
ndufresne: Ok
<javier__>
ndufresne: what's your gst pipeline?
<ndufresne>
and then a pipeline like, filesrc location=my.mp4 ! qtdemux ! h264parse ! v4l2videoNdec capture-io-mode=dmabuf ! kmssink
<ndufresne>
for now I focus on static pipeline like this
<wwilly>
hi all
<ndufresne>
specailly on Exynos 4, since it produce a weird format
<wwilly>
javier__, are you sure about the interrupt numbers you given to me last time for the A7 pmu?
bgamari has joined #linux-exynos
<javier__>
wwilly: that's what I read in the Exynos user manual
<wwilly>
ok
bgamari has quit [Remote host closed the connection]
<javier__>
wwilly: but I never tried since as we discussed PMU support for b.L never landed
<javier__>
so I may be wrong...
bgamari has joined #linux-exynos
<wwilly>
apparently we have the possibility to mix pmu, with CONFIG_ARM_PMU enabled; Say y if you want to use CPU performance monitors on ARM-based │
<wwilly>
│ systems.
<wwilly>
ok, it said ARM-based
<wwilly>
not ARM-b.L system based
<wwilly>
and for the A15, it is correct the DTS?
<wwilly>
I just want to be sure about my test before asking on #armlinux
<javier__>
wwilly: I don't have neither the DTS nor the correct IRQs at hand, so whatever I wrote the other day :)
<javier__>
but yes, the IRQs for one cluster where correct AFAICT and the other was the one I shared
<javier__>
*were
<wwilly>
ok
<javier__>
wwilly: so you can remove the CPU nodes for the cores of one cluster and test PMU for ARM
<wwilly>
uhm??
<javier__>
I can't remember right now from which core Exynos5422 booted and if disabling that may be an issue
bgamari has quit [Read error: Connection reset by peer]
bgamari has joined #linux-exynos
<wwilly>
it boots on cpu0, which is on A7 cluster
<javier__>
wwilly: I thought you were asking if the A15 were correct to try ARM_PMU using a single cluster
<wwilly>
no I asking if A7 and A15 dts we discuss together are correct, and just say that we have actually an option named ARM PMU framework
krzk has quit [Quit: Ex-Chat]
<wwilly>
but we are not sure that this option can use multiple PMUs at the same time in a context with heterogeneous cpu
<wwilly>
with that option, perf list me effectively PMC for A7 and for A15
<wwilly>
but when I test it, it looks really strange, for instance, A7:cpu-cycles and A15:cpu-cycles are really close together, even if I set A7 to 200MHz and A15 to 2Ghz
<wwilly>
so I guess is not working
<wwilly>
I prepare a pastebin to show that
<javier__>
wwilly: Ok, I checked the IRC logs
<javier__>
<javier__> wwilly: the A15 IRQs seems to be correct, the A7 no AFAICT should be:
<javier__>
so yeah, A15 were correct and so the IRQs on the hardkernel DTS + the ones I shared should be correct
<wwilly>
ok
<javier__>
wwilly: the CONFIG_ARM_PMU Kconfig symbol just enables drivers/perf/arm_pmu.c which is ARM PMU support
<javier__>
I see there is a PERF_PMU_CAP_HETEROGENEOUS_CPUS but that is set unconditionallyin cpu_pmu_init() which is weird
<wwilly>
the two numbers after A7 and A15 are the cpu frequency, from /sys/devices/system/cpu/cpufreq/policy{0,4}/scaling_cur_freq
isaque has joined #linux-exynos
<isaque>
Hi guys, I've installed 4.6 in my Snow and audio is still broken
<isaque>
it seems an old issue, but it was working back on 3.4, right?
<isaque>
Do we have anybody working on this?
<javier__>
isaque: it was not working back, 3.4 is a completely different kernel since is the ChromiumOS one
<javier__>
isaque: I don't think anybody is working on this
<isaque>
javier__: hey man, how are you?
<isaque>
javier__: oh boy, really?
<isaque>
javier__: so, the version running on ChromeOS is still 3.4?
<javier__>
isaque: yes, I tried a little bit for a couple of days but couldn't get to work
<javier__>
isaque: no, latest ChromeOS tree for Exynos based Chromebooks is 3.8
<javier__>
but their first version was 3.4
<isaque>
javier__: I tried to compile 3.8 but it failed me to provide sound
<javier__>
strange, that's what shipped on the device
<javier__>
although I never build the ChromiumOS tree, just used as a reference for upstreaming work
<isaque>
javier__: hmmm, I though you did, my bad
<isaque>
javier__: I tried to use Arch's kernel, which is 3.8.11 and that didn't work too.
<isaque>
javier__: I don't know if the model I'm using is too old :)
<javier__>
isaque: yeah, that's likely the ChromiumOS tree since 3.8.11 is what's shipped there
<javier__>
isaque: I was hopping that someone could work on the audio issue, bmbeach mentioned that he managed to get audio working but using a user-space program
<isaque>
javier__: well, if I knew where to start, I would be glad to help
<isaque>
javier__: but I don't have experience with kernel development, so I'm kind of a paper weight
paulk-collins has joined #linux-exynos
prahal has quit [Remote host closed the connection]
wwilly has quit [Ping timeout: 260 seconds]
<ndufresne>
javier__: when I asked about my crash on armlinux channel, they started a discussion about lowmem/highmem, I'm increasing the cmasize in those test, do I need to make sure my memory block does not go over a certain address ?
<javier__>
ndufresne: not sure what the restrictions are, I think you should ask Marek about it
<wwilly>
[ 3.656022] pwm-fan pwm-fan: Failed to configure PWM
<wwilly>
[ 3.659600] pwm-fan: probe of pwm-fan failed with error -22
<wwilly>
with the odroidxu3 board
<LiquidAcid>
Wizzup, new code in the armsoc g2d branch ;)
<LiquidAcid>
wwilly, EINVAL, maybe you can find out where it comes from
<wwilly>
uhm, interesting or not, if I compile it as a module pwm-fan and pwm-samsung, still have an error at boot, but when I reload it it is working, no error
<LiquidAcid>
wwilly, EINVAL has to come directly from pwm_config
<LiquidAcid>
wwilly, check the arguments of the call
<wwilly>
ok, I'm new at kernel debuging, typically, I write a printf on my code, what is the good way to do kernel debugging instead of printk?
<LiquidAcid>
wwilly, since there is no debug facilities in that part of code, i'd just put some printks there
<LiquidAcid>
e.g. in pwm_fan_probe() and pwm_config()
<wwilly>
yep
<Wizzup>
LiquidAcid: ack, I'm going to find this bug in grsec and then try out your patches
<Wizzup>
slash sources
_whitelogger has joined #linux-exynos
<Wizzup>
LiquidAcid: your code looked simple enough
<Wizzup>
by that I mean clear
<LiquidAcid>
Wizzup, i'm still getting some asserts when using dri2 with userptr
<Wizzup>
Did you have a lot of kernel changes? I saw you linked your odroid tree, but I'd prefer to test on my chromebook
<LiquidAcid>
probably some refcounting problem, but i'm too tired to solve it today *yawn*
<Wizzup>
ack
<LiquidAcid>
Wizzup, you could cherry-pick all changes that affect drm/g2d
<Wizzup>
ack
<Wizzup>
I can also try it with my odroid some time later - but that one is at home atm
<LiquidAcid>
Wizzup, ok, i think i've found the error
<wwilly>
for debugging easily, do we provide a dump for each data structure?
<LiquidAcid>
wwilly, looks like a problem with dt parsing to me
<LiquidAcid>
20972 seems to be the value that is given in the dt, you might need to check a bit more where the zero comes from
<LiquidAcid>
could also be some probing order issue
LiquidAcid has quit [Quit: Leaving]
<wwilly>
uhm, I think something are wrong or broken about pwm globally, I have also [ 15.984121] leds_pwm pwmleds: unable to request PWM for green:mmc0: -517