nashpa has joined #linux-exynos
TheSeven has quit [Disconnected by services]
[7] has joined #linux-exynos
masta__ has joined #linux-exynos
ansiwon has quit [Quit: leaving]
ansiwon has joined #linux-exynos
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
<ndufresne> javier__: ^
bgamari has quit [Quit: ZNC - http://znc.in]
wwilly has joined #linux-exynos
<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
<javier__> *unconditionally in
<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
LiquidAcid has joined #linux-exynos
wwilly has joined #linux-exynos
<wwilly> hi
<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
<Wizzup> cool! I'm going home now. past 0:00 :)
<wwilly> LiquidAcid, in boot: [ 16.222124] MyDebug pwm-fan.c:240:pwm_fan_probe:pwm_config (ebd1bc00, -1, 0)
<wwilly> LiquidAcid, reload module: [ 495.706788] MyDebug pwm-fan.c:240:pwm_fan_probe:pwm_config (ebd1bc00, 20971, 20972)
<LiquidAcid> wwilly, so period is zero then, eh?
isaque has quit [Quit: isaque]
<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
prahal has joined #linux-exynos
wwilly has quit [Quit: Leaving]
prahal has quit [Ping timeout: 244 seconds]