<daniels>
libv: it's unfair to slate the kernel status based on an ancient 3.4 fork you've used, without ever having tried actual current mainline
<libv>
daniels: i believe that i have clearly explained the situation
<libv>
this is an issue of integration.
<libv>
the old kernel has working mali, but horrible display driver
<libv>
while mainline might have a working display driver, it probably does not have a working mali
<daniels>
libv: as i told you, it does have working mali
<libv>
daniels: perhaps, perhaps not
<libv>
daniels: i would have to waste time to go find out.
<daniels>
libv: download r5p0 source from malideveloper.arm.com -> compile for kernel -> it works
<Wizzup>
and the instructions were somewhat lacking, and I think only very recently linux-next has working hdmi
<libv>
daniels: 3.4 display driver was shit, samsung idiot display people & arm idiotic binary only policy waste my time, i believe i have every right to complain
<Wizzup>
the first part of course falls partially to blame to us, not writing enough wiki pages yet... :)
<libv>
plus, i clearly explained the situation
<libv>
Wizzup: blame is not the right word
<libv>
Wizzup: samsung is to blame
<Wizzup>
I guess that's true
<daniels>
libv: personally i think spending time with a three-year old kernel that has a known broken display driver is more of a waste than compiling a current mainline kernel, changing one line in defconfig and then compiling the same external module you'd be compiling anyway, but i guess we have different priorities
* daniels
goes back to looking at mali's rendering working just fine on hdmi on current mainline
<libv>
daniels: again. i would have had to spend extra time to make sure of that
<libv>
with the added benefit of the possibility of having had nothing to demo at all.
<libv>
i believe that i am perfectly clear and logical here
<libv>
as i was in the blog post
<libv>
and i believe that i also explained this reasoning extensively in the last two weeks of january when i was hitting these issues and when this was mentioned here
<libv>
yes, it supposedly works on mainline. great. thank you for that information.
<daniels>
to me, your blog post reads 'i'm stuck on 3.4 and can't move off and everything is shit and there are some people but also everything is shit'
<libv>
but 3.4 was horribly broken, and i did not want to waste time on fixing it and risk not having a demo
<libv>
i had working mali, i had working ptrace, i had a broken display driver
<libv>
daniels: did you also read the bit where i talk about linux-exynos and the pain of having to deal with many SoC families?
<libv>
perhaps you should focus on that
<libv>
This sentence in particular: "The information for doing a proper linux installation on an android or chrome device is usually dispersed, not up to date, and not too good, and i get to do a lot of the legwork for myself every time, knowing full well that a lot of others have done so already but couldn't be bothered to document thing"
<libv>
so please stop trying to berate me, and evaluate your own actions
<daniels>
libv: good luck with 3.4
<libv>
daniels: who says that i will stick with it forever?
<libv>
could it be that i have updating the installation for my chromebook and finally putting my odroid xu3 to good use, are high up my todo list?
<libv>
but not as high as "produce a demo for fosdem" was 2-3 weeks ago?
<libv>
daniels: do you need me to explain my logic again?
<daniels>
libv: i'd rather you didn't
<libv>
i'm not sure whether you will now finally relent and admit that my logic in this specific situation actually makes sense, instead of just trying to drag this out endlessly.
<Wizzup>
The compromise would be to note in the blog post that the situation has since gotten better in recent kernels, I guess
<javier__>
Wizzup: or at least test a newer kernel before taking conclusions...
<libv>
what conclusion?
<Wizzup>
javier__: he didn't draw a conclusion in the blog post; he just mentions 3.4.0 didn't work well
<libv>
3.4 has a horribly broken display driver. period.
<libv>
do i state there that it is now oh so much better?
<daniels>
'The ARM chromebook and its broken kms driver is much of the same.'
<libv>
daniels: are you deliberately taking this out of context just so you can drag this out?
<daniels>
i mean, that bit is entirely missing a qualifier about how you picked a random three-year old fork rather than using the chromebook vendor tree which actually shipped on the device (really shockingly stable), or mainline
<libv>
daniels: do you really have nothing better to do with your time?
<Wizzup>
3.4.0 was the chromebook vendor tree
<daniels>
libv: you're right - this is actually detracting from working on kms in a current mainline kernel. so i'll go back to that, and you can go back to ... whatever it is.
<javier__>
libv: for me your conclusion seems to be "Samsung Chromebooks is badly support with any other kernel than the vendor one but now things could get better now since there is a linux-exynos.org wiki"
<Wizzup>
and shipped on snow at the time
<daniels>
Wizzup: oh right, for snow, sorry - i was thinking pi(t)
<libv>
are you now going to finish off stating that your life is too short for all of this?
<javier__>
libv: but I don't really care tbh, I prefer spending my time trying to fix the situation than complaining about it
<libv>
javier__: are you thereby implying that i whine instead of code?
* Wizzup
often codes and whines about his own code
<libv>
for some context which might explain why daniels feels he needs to pursue this as he does, and why i respond like i do (and this is some really limited context when the last 11 years are taken into account): https://bugs.freedesktop.org/show_bug.cgi?id=45232
<javier__>
libv: no, I was talking about the Exynos SoC in general and Samsung Chromebooks in particular
<afaerber>
ftr, the HP Chromebook vendor tree is 3.8 based, so "Samsung" is worth pointing out
<afaerber>
javier__, I've tried adding the pwrseq node for Spring and my dmesg gets spammed with "mmc1: error -110 whilst initialising SDIO card"
<afaerber>
any idea why?
<Wizzup>
libv: yeah, the changes that are listed there (the wishlist one) are ones that I plan to pick up soon, but right now I have to rush getting work done before departing for a week to bulgaria and then spain
<Wizzup>
at this point I think mainline (or linux-next) is actually getting in pretty good shape
<Wizzup>
I'd definitely like some advice a few weeks from now on how to make all of this easily accessible (providing a kernel for people, or just u-boot binaries)
<Wizzup>
we already have some bits that are quite OK, but as a whole it just doesn't come together yet
<libv>
Wizzup: that RecentChanges link was not aimed at you
<Wizzup>
I realised
<Wizzup>
but it just reminded me
<javier__>
afaerber: yes, I get the same error on Peach Pit/Pi (Exynos5420/5422/5800) but didn't get it for Snow (Exynos5250)
<libv>
just pointing out that people should not spend their time taking a few small statements in that blog post out of context, to artificially get a discussion going or to artificially sustain it, while they could instead spend time documenting the fact that mainline has working hdmi and mali on exynos
<libv>
which actually also is a part of that blog post.
<javier__>
afaerber: please keep in mind that is a wip, for example addy's modified patch always retries in mci_send_cmd() instead of giving up after a couple of times and also had to revert a patch that broke fw loading instead of finding the cause
<afaerber>
javier__, btw does it matter which of the 3 s5m8767 32khz clocks I pass to the pwrseq? I just took the first one (0)
<javier__>
afaerber: yes it does, it has to be the one that is routed to the wifi chip
<javier__>
which may explain the timeout if the clock is not the correct one
<afaerber>
javier__, can you look that up for me then? :)
<javier__>
afaerber: I don't have a schematic for spring sorry
<javier__>
afaerber: you have to ask to one of the ChromiumOS folks
<afaerber>
javier__, hm, is there some way to tell from downstream DT?
<afaerber>
given there's only 3 I could just try them all ;)
<javier__>
afaerber: indeed, you can do that :)
<afaerber>
javier__, as far as WIP, your sd1_* nodes are still extended the old way
<afaerber>
for Spring I was asked to do it via &sd1_clk {...}; etc.
dlezcano has joined #linux-exynos
<javier__>
afaerber: thanks for the feedback, I'll change before posting once I've it working
<afaerber>
[ +0,003772] mmc1: new high speed SDIO card at address 0001
<afaerber>
[ +0,000442] mwifiex: rx work enabled, cpus 2
<afaerber>
[ +0,000168] mwifiex_sdio mmc1:0001:1: Direct firmware load for mrvl/sd8797_uapsta.bin failed with error -2
<afaerber>
[ +0,000019] mwifiex_sdio mmc1:0001:1: Failed to get firmware mrvl/sd8797_uapsta.bin
<Wizzup>
yes
<Wizzup>
I also get that on snow when the patch that javier reverted in above link is not reverted
<Wizzup>
so fw loading for wifi is/was broken on linux-next, at least a few days ago
<javier__>
afaerber: awesome and yeah I had to revert that commit
<javier__>
it would be good to root cause but I didn't have time and I'm busy with other stuff now
<afaerber>
reverting did not help
<Wizzup>
did you enable the config to enable userspace to load the fw?
<afaerber>
which config?
<afaerber>
CONFIG_FW_LOADER=y
<afaerber>
# CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
<afaerber>
Wizzup, you mean the latter?
<javier__>
afaerber: with CONFIG_FW_LOADER_USER_HELPER_FALLBACK
<Wizzup>
the latter, yes
<javier__>
in fact, I found the in-kernel fw loading not working and needed the user-space helper
<javier__>
afaerber: so is CONFIG_FW_LOADER_USER_HELPER_FALLBACK + reverting the mentioned commit
<afaerber>
at times it's really depressing how little works in linux-next...
<Wizzup>
I was actually surprised that a lot of stuff did work
<Wizzup>
snow is almost usable now
<Wizzup>
basically audio and then I will consider it for daily use again
<Wizzup>
now I'm still on peach-pi with chromeos 3.8 kernel
<javier__>
afaerber: yeah, the problem is that the regression testing in mainline is basically to boot and get a serial console
<javier__>
it will be nice to have a more automated unit test to catch these kind of regressions earlier
<afaerber>
[ +0,000348] mwifiex_sdio mmc1:0001:1: Direct firmware load for mrvl/sd8797_uap
<afaerber>
sta.bin failed with error -2
<afaerber>
[ +0,000017] mwifiex_sdio mmc1:0001:1: Falling back to user helper
<afaerber>
followed by late
<afaerber>
[ +0,157714] mwifiex_sdio mmc1:0001:1: Failed to get firmware mrvl/sd8797_uapsta.bin
sjoerd has joined #linux-exynos
ssvb has joined #linux-exynos
_whitelogger has joined #linux-exynos
prahal has joined #linux-exynos
liquidAcid has joined #linux-exynos
afaerber_ has joined #linux-exynos
<obbrobbrio>
guys, how do i install mali T604 drivers on snow? is it fine taking just graphics-related steps from this guide? http://community.arm.com/docs/DOC-9494
afaerber has quit [Ping timeout: 250 seconds]
afaerber_ is now known as afaerber
bmbeach has joined #linux-exynos
<bmbeach>
hello anybody home?
ssvb has quit [Ping timeout: 240 seconds]
ssvb has joined #linux-exynos
<bmbeach>
Wizzup are you there?
<bmbeach>
I tried booting using the cat ... procedure and it worked fine
<bmbeach>
and also noticed the following kernel option with the following text:
<bmbeach>
With this option, the boot code will look for a device tree
<bmbeach>
binary (DTB) appended to zImage (e.g. cat zImage
<bmbeach>
<filename>.dtb > zImage_w_dtb).
<bmbeach>
This is meant as a backward compatibility convenience for
<bmbeach>
those systems with a bootloader that can't be upgraded to
<bmbeach>
accommodate the documented boot protocol using a device
<bmbeach>
tree.
<bmbeach>
Beware that there is very little in terms of protection
<bmbeach>
against this option being confused by leftover garbage in
<bmbeach>
memory that migh look like a DTB header after a reboot if no
<bmbeach>
actual DTB is appended to zImage. Do not leave this option
<bmbeach>
active in a production kernel if you don't intend to always
<bmbeach>
append a DTB. Proper passing of the location into r2 of a
<bmbeach>
bootloader provided DTB is always preferable to this option.
<bmbeach>
thought this might solve the problem but when I disabled it , rebuilt the kernel and rebooted the kernel still crashed
<bmbeach>
but anyway I'm am now booting 3.19.0-next-20150216
<bmbeach>
notice that I still booted off nv_uboot-snow-simplefb and
<bmbeach>
things like clk_ignore_unused and it still worked. theses I will
<bmbeach>
eventually fix
<bmbeach>
On x-windows everything works fine but it is using fbdev
dme has quit [Quit: Coyote finally caught me]
<bmbeach>
shutdown -r works fine and shutdown -h shuts down but the power led stays on.
<bmbeach>
also I noticed in /sys/class/power.. I am finding the following values
<bmbeach>
voltage_max_design 7500000
<bmbeach>
voltage_min_design 7500000
<bmbeach>
voltage_now 8559000
<bmbeach>
I think voltage_max_design should be around 8559000
<bmbeach>
also I get on "dmesg" the following value
<bmbeach>
Total of 2 processors activated (96.00 BogoMIPS)
<bmbeach>
that value should be around 3000
bmbeach has left #linux-exynos [#linux-exynos]
aballier has quit [Read error: Connection reset by peer]
aballier has joined #linux-exynos
dlezcano has quit [Remote host closed the connection]
liquidAcid has quit [Quit: Leaving]
<afaerber>
javier__, disabling exynos thermal resolved my boot issues on next-20150218