zombah has quit [Remote host closed the connection]
ssvb has quit [*.net *.split]
obbrobbrio has quit [*.net *.split]
tyler-baker has quit [*.net *.split]
ssvb has joined #linux-exynos
obbrobbrio has joined #linux-exynos
tyler-baker has joined #linux-exynos
ssvb has quit [*.net *.split]
obbrobbrio has quit [*.net *.split]
tyler-baker has quit [*.net *.split]
prahal has quit [*.net *.split]
pekka10 has quit [*.net *.split]
daniels has quit [*.net *.split]
ssvb has joined #linux-exynos
obbrobbrio has joined #linux-exynos
tyler-baker has joined #linux-exynos
prahal has joined #linux-exynos
pekka10 has joined #linux-exynos
daniels has joined #linux-exynos
prahal has quit [*.net *.split]
pekka10 has quit [*.net *.split]
daniels has quit [*.net *.split]
prahal has joined #linux-exynos
pekka10 has joined #linux-exynos
daniels has joined #linux-exynos
amitk has joined #linux-exynos
gautam__ has joined #linux-exynos
gautam__ has quit [Ping timeout: 246 seconds]
gautam__ has joined #linux-exynos
gautam__ has quit [Ping timeout: 245 seconds]
ssvb has quit [Ping timeout: 256 seconds]
gautam__ has joined #linux-exynos
zombah has joined #linux-exynos
<gautam__>
can anyone points me to any working kernel >=3.14 for arndale 5420 octa board
<amitk>
gautam__: define working. You can get 4 cores booting with mainline. But getting all 8 cores booting is a hit or miss depending on which firmware you have on there
<amitk>
gautam__: there were several reports of imprecise external aborts on the list on exynos boards some of which were addressed. You should have better luck with mainline
<gautam__>
amitk: I am currently trying mainline 3.17, but If I remember correctly I have used it before also was able to run it with 4 cores but monitor wasn't working. Let me try it again
<Wizzup>
at least try 3.19 I'd say
<amitk>
gautam__: what Wizzup said
<javier__>
gautam__: what video interface does the exynos5420 octa board has? HDMI?
<gautam__>
javier__, yes
<javier__>
gautam__: I don't see an hdmi dev node in exynos5420-arndale-octa.dts
<javier__>
so you will need to add that to have display working
<gautam__>
javier__: which kernel version you are talking about
<gautam__>
?
<javier__>
gautam__: today's linux-next tag (next-20150225)
opuk has quit [Ping timeout: 250 seconds]
<gautam__>
javier__: it might be in exynos5420.dtsi
<javier__>
amitk: hi, I finally got wifi woking on peach pit/pi
<javier__>
amitk: there was a subtle difference in how the pinctrl were defined in mainline and downstream exynos5420-pinctrl.dtsi
<javier__>
Doug Anderson from ChromiumOS pointed me that, I'll post the patches to add wifi and audio support for peach today and cc you
<javier__>
gautam__: it depends on the board but I would expect that at least you need some pinmuxing and define a hpd-gpio for hot-plug detection
<Wizzup>
javier__: cool!
<javier__>
gautam__: possibly some power supplies, a dcc i2c dev, etc
<javier__>
gautam__: I'm not familiar with that board though, is just suspicious that nothing is defining w.r.t hdmi
<gautam__>
javier__: there is hdmi node in exynos5420.dtsi
<javier__>
gautam__: of course there is because is a IP of the SoC
<javier__>
but then you need to define in your board how things are wired, which GPIO is used for hpd, which regulators are hooked, etc is board specific
opuk has joined #linux-exynos
<amitk>
javier__: \o/
opuk has quit [Ping timeout: 256 seconds]
ssk has quit [Remote host closed the connection]
opuk has joined #linux-exynos
ssvb has joined #linux-exynos
opuk has quit [Changing host]
opuk has joined #linux-exynos
dlezcano_ has quit [Remote host closed the connection]
dlezcano_ has joined #linux-exynos
<Wizzup>
javier__: I guess that means I can soon run mainline on my peach-pi
<javier__>
Wizzup: yeah, wifi still will need some more downstream patches to have highspeed mode supported and the ASoC and codec drivers needs more love but at a basic level all peripherals should be working on Snow and Peach Pit/Pi
<Wizzup>
I guess that will land in linux-next at some point?
<javier__>
Wizzup: yeah, 4.1 most likely
opuk has quit [Ping timeout: 252 seconds]
opuk has joined #linux-exynos
opuk has quit [Ping timeout: 256 seconds]
opuk has joined #linux-exynos
opuk has quit [Ping timeout: 250 seconds]
gautam__ has quit [Ping timeout: 250 seconds]
opuk has joined #linux-exynos
dlezcano has joined #linux-exynos
dlezcano_ has quit [Quit: Leaving]
afaerber_ has joined #linux-exynos
afaerber has quit [Ping timeout: 264 seconds]
prahal has quit [Quit: prahal]
amitk has left #linux-exynos [#linux-exynos]
prahal has joined #linux-exynos
zombah has quit [Quit: Leaving]
prahal has quit [Quit: prahal]
prahal has joined #linux-exynos
liquidAcid has joined #linux-exynos
opuk has quit [Changing host]
opuk has joined #linux-exynos
mkatic has joined #linux-exynos
<liquidAcid>
prahal, ping
<prahal>
liquidAcid: pong ! btw I read the backlog and cooked a r5p0 version . It helps
<liquidAcid>
maybe a few times, check if something appear in the kernel log
<mkatic>
anyone running X11 with armsoc on Snow with linux-next?
<prahal>
ok . count around 20 minutes
<mkatic>
i just tried it and i get a garbled screen, it is completely unusable
<mkatic>
fbturbo works fine though
<prahal>
liquidAcid: once each run I get kernel "[drm:g2d_check_buf_desc_is_valid [exynosdrm]] *ERROR* height[0] is out of range!" and userspace side "failed to set cmdlist."
<obbrobbrio>
mkatic: how are performances with fbturbo compared to fbdev? how to build it? i built armsoc on stock 3.8, but when i use it, it gives really poor performances and no opengl environment
<prahal>
I should unbuffer the userspace side as it seems random the point at which it fails now.
<liquidAcid>
prahal, thanks
<mkatic>
in general, you should get much better 2d performance with fbturbo than with armsoc
<liquidAcid>
so no freezes, etc.
<mkatic>
but you can't have opengles with fbturbo
<mkatic>
and fbturbo can do vt switches, armsoc will crash if you attempt a vt switch
<mkatic>
fbturbo is just a drop in replacement
<mkatic>
clone the repo, build and install it
<prahal>
liquidAcid: I run it from console with x11 off (with my x11 session I get "no version", then issues (but no freeze)
<mkatic>
and make sure you change the driver to "fbturbo" in xorg.conf
<prahal>
run as user (not root)
<mkatic>
you can find the git repo up on github
<liquidAcid>
prahal, ok, can you also check the cur frequency of sclk_g2d?
<obbrobbrio>
mkatic: thanks for the infos... do you mean xf86-video-fturbo on github?
<mkatic>
that's the one, yes
<mkatic>
trivial to build and install
<obbrobbrio>
some special flags or settings needed?
<mkatic>
nothing
<obbrobbrio>
well i'll try... the sed part is that i can't get armsoc to work
<obbrobbrio>
did you ever manage to do that?
<obbrobbrio>
*sad
<mkatic>
it does work fine when i use 3.8 chromeos kernel
<prahal>
220mhz (I am at 880mhz mpll ...
<mkatic>
but it is noticeably slower than fbturbo
<obbrobbrio>
mkatic: oh, so do you think wasn't it working as intended?
<mkatic>
but i am also interested in getting opengles to work
<prahal>
I switched back as I tried all my u-boot bin and it was of no help to get rid of the mali mmu issue (though I believe this issue never occurred before .. the display is messed when it happens ...
<mkatic>
and you get android apps on your chromebook
<mkatic>
without actually running android, of course
<obbrobbrio>
oh nice, also if i'm more interested in a regular linux experience, but i'm even experiencing slow page rendering with some websites in iceweasel
<mkatic>
you should see a substantial improvement with fbturbo
<obbrobbrio>
yes thanks for the tip... i hope one day i'll get mali driver to work (and you too :))
<liquidAcid>
prahal, can you confirm that it's 400mhz?
<prahal>
sclk g2d ? was 220mhz
<liquidAcid>
prahal, so are you using new uboot?
<prahal>
the latest upstream with 880mhz test reapplied
<liquidAcid>
hmm
<obbrobbrio>
guys actually i'm using default chromeos 3.8 kernel because i don't know how good is hardware support for later releases... what's the status at the moment? the latest release usable? any non-supported hardware?
<liquidAcid>
well, i need someone with a 400mhz setup
<prahal>
the spec tells 200mhz
<liquidAcid>
i know, but it also seems to work with 400mhz+
<prahal>
weird I am mostly with your kernel (the divider should match thus you should have 200mhz . bring interest
<prahal>
no too old my last import of your tree is
<liquidAcid>
to give a bit more information, i'm currently debugging some issue i found on my standard kernel, which strangely disappears when i switch to my debug kernel
<liquidAcid>
on the standard kernel the test i send you hangs, or freezes the system completly after a while, on the debug kernel it runs through
zombah has joined #linux-exynos
<prahal>
no dynamic debug which you could turn on/off on the same kernel ?
<daniels>
mkatic: yeah, but have been dragged on to tegra for the past few days so not been able to get a new tree on top of -next
<liquidAcid>
prahal, i wouldn't know where to start
<liquidAcid>
with drm.debug = 0xff i can see a final call to g2d_set_cmdlist
<prahal>
pr_debug comes to mind, I would need to read anew the doc for dynamic debug in the kernel Documentation dir
<liquidAcid>
i would rather guess the lockup happens in g2d_exec
<prahal>
then already the exact same kernel (not with or without a build flag)
<liquidAcid>
exact kernel, just different config
<prahal>
indeed if the command is not sent it cannot be the hw that hang
<liquidAcid>
is it possible to the lockup to happen before the msg ends up on the uart?
<mkatic>
daniels: Which xf86-video-armsoc did you use? I see a number of forks on github plus the chromeos and linaro repos
<daniels>
mkatic: ah, this isn't using x11, but your best bet would be the cros one
<mkatic>
oh, you just had it running via fbdev?
<daniels>
mkatic: not quite ...
<mkatic>
hm, i'm not quite following you
<prahal>
liquidAcid: runs fine at 440mhz too
<liquidAcid>
prahal, now that you mentioned it, apart from debug i also have devfreq activated in debug
<liquidAcid>
hmmm
<prahal>
exynos_bus_devfreq ?
<prahal>
this one I have off as it failed to build and I did not bother back then
<liquidAcid>
yes, that one
<liquidAcid>
strangely i haven't encountered the issue in the retroarch backend yet
<liquidAcid>
i'm probably not doing enough fast solid color clears...
<liquidAcid>
prahal, well, that's interesting -- it doesn't happen if i also build the standard kernel with devfreq
<prahal>
I need you libdrm for retroarch ? seems the one I am using miss g2d at least the scale g2d routine
<liquidAcid>
prahal, yes, the scale and blend routine is still pending on the ml
<liquidAcid>
i hope it gets merged soon
<liquidAcid>
hmm, uboot not booting after update
<prahal>
? u-boot itself
<prahal>
sd-fuse.sh ?
<liquidAcid>
yeah u-boot itself
<liquidAcid>
probably missing some stuff, should pull again
zombah has quit [Quit: Leaving]
<prahal>
I am at "4641429" from git://git.denx.de/u-boot.git with bd99e6d9 reverted (there is a conflict in a comment )
<prahal>
as sclk_g2d_acp was switch from 400 to 200 mhz in b00f8edb5
<prahal>
did a rebuild and flash , boot
<liquidAcid>
i'm probably missing that sdhci patch
<liquidAcid>
seems to boot now
<liquidAcid>
sclk_mpll = 880000000
<liquidAcid>
MUHAHA! :D
<prahal>
is libMali really supposed to do openvg ? it does not defines them (but mali400-odroid deb kindly removed openvg and conflict
<liquidAcid>
openvg? i don't think so, at least not for mali-400
<prahal>
ouch I should revisit (my fps are so low those days ... I am far from the metrics a year ago wher I was tuning the kernel for mali
<prahal>
that need to be benchmarked properly (I did not for this one even then ..... then the big fs corruption and practical matters. )
<liquidAcid>
ah ok, good to know
<prahal>
I was comparing the fps from es2gears even then (not a benchmark , I hope it was still good enough to compare) and I have no numbers for this patch <- I did so to compare 3.0.63 hkdk to my 3.14 , then my branch with or without an RGB hack
<liquidAcid>
prahal, did you see my benchmark with the preloader?
<prahal>
no , preloader ?
<prahal>
could it be that rendering over a transparent background slow things down
<obbrobbrio>
i already searched the web for the error, but i someone say it doesn-'t work on some kernels, others confirm it works... any experience here?
<liquidAcid>
prahal, 440mhz seems to be too high for the engine, i see massive corruption when doing blits
liquidAcid has quit [Quit: Leaving]
liquidAcid has joined #linux-exynos
<liquidAcid>
prahal, more fallout: mmc_busclk (sdhci) is 100mhz after the update (vs. 500mhz before)
<prahal>
clk recalc_rate fun :)
<prahal>
I do not suffer this one on emmc only as of the removal of the parent/child recalc_rate relationship (though I am at 40mhz with "mpll 880mhz"+ "remove parent relationship" when I was at 50mhz with "no revert"+mpll 400mhz
<prahal>
880mhz was for mali ?
<liquidAcid>
ah, i was just giving it a try
<liquidAcid>
gotta revert, this breaks too much stuff
<liquidAcid>
mali is actually slower after this
<prahal>
"you shouldn't care for 800x880mhz diffent if you aren't using Mali+MFC at the same time (AKA Video Playback on a GLES sink)" <- from #odroid backlog , dixit mdrjr