16:54 <azer_> hi all, is there a repo or something around, where one can find already built kernel images for exynos platforms, like the arm chromebook (snow)?

17:08 <si1v3r> Kinda, the arch guys have them available.

17:08 <si1v3r> I do not know if they are mainline or cros based at this point in time.

17:30 <azer_> si1v3r: thanks, you mean like this: https://aur.archlinux.org/packages/linux-chromebook/ ?

17:33 <si1v3r> Looks right. I'm not an arch user.

17:34 <si1v3r> One funny bit I noticed when I was playing with using an arch kernel in debian was that arch gzips their modules. gunzipping them allowed them to work with debian. No idea why that is.

17:34 <azer_> in general, is there a place where i can download the latest one available from the chromium project? sorry but i have hard time figuring out how this arm world works :)

17:35 <azer_> oh si1v3r thanks, maybe i'll give them a try

17:35 <si1v3r> As far as I know they only provide sources, however it's easy to build a kernel if you already know all the options.

17:45 <WarheadsSE> azer_: he meant Arch Linux ARm

17:48 <azer_> i'm wondering why a repo doesn't exist... i'm not saying other people "must" do it... i'm not pretending it, and i appreciate others' work, that's sure. but wouldn't it be feasible to maintain a repo with already built images? so that people not so used to kernel building can take advantage from it as well?

17:48 <si1v3r> bandwidth costs money

17:48 <azer_> maybe you already got this question lots of time, sorry for that

17:49 <si1v3r> the problem with doing that is that there is not a lot of agreement on how kernels should be packaged yet.

17:51 <azer_> oh i understand

17:51 <si1v3r> anyhoooo..... feel free to do it yourself. :)

17:52 <si1v3r> Others might use it.

17:54 <azer_> yep, i'd bet it would be useful... if i learn one day i can consider it ;) sadly i'm not sure when i will be able to spend enough time on that

17:57 <azer_> WarheadsSE: yes thanks, i'm looking at arch linux arm

18:15 <Wizzup_> azer_: we mostly focus on mainline

18:15 <Wizzup_> Having some binaries if definitely something we should do soon...

18:15 <Wizzup_> is*

18:22 <liquidAcid> imo not providing binaries is imo a good idea, since it keeps the people away that are just "endusers"

18:24 <si1v3r> yeah......... but it also prevents some of the ambitious end users from getting in deeper.

18:25 <Wizzup_> It's nice to "just" have a u-boot that works.

18:25 <Wizzup_> Same for a kernel - so you have a starting point

18:25 <si1v3r> recovery mode

18:25 <Wizzup_> I didn't mean to offer complete rootfs-es necessarily

18:26 <Wizzup_> I've been wanting to do this for peach-pi and snow, but currently fighting a btrfs issue before I can fully test snow

18:26 <liquidAcid> imo it just increases the number of people that are like: hey, i tried you foo image and bar isn't working -- fix this!

18:28 <liquidAcid> if you let people build their stuff itself you can at least assume that they have some basic competence in bug reporting

18:28 <liquidAcid> that's just my experience though :)

18:29 <Wizzup_> u-boot building can be a pain

18:29 <Wizzup_> especially since the documentation is completely lacking on their side too

18:29 <Wizzup_> not even loadaddrs are mentioned

18:33 <liquidAcid> well, kernel building can be a pain as well on arm boards -- so many config options / how do you i know if i've selected everything vital

18:34 <liquidAcid> when i was build my first kernel myself more than a decade ago i also struggled really hard

18:35 <liquidAcid> it's all a learning process (no instant gratification *g*)

18:40 <Wizzup_> defconfig mostly works

18:41 <Wizzup_> The idea is to make the platform easier to use for everyone as well, so I don't feel that much for "let's make it extra hard" :-)

18:45 <liquidAcid> guess i'm in the opposite party then, i don't feel that much for "let's dumb down everything so it's accesible to everyone"

18:51 <liquidAcid> prahal, oh, i see some nice iommu changes!? :D

19:11 <azer_> liquidAcid: why keep "endusers" away? what is the point of developing anything if you don't address "common" people?

19:13 <liquidAcid> azer_, because what the project currently needs are developers, people writing code, people being able to file proper bugreport, people that know how to triage issues -- the typical "enduser" doesn't do anything of this

19:15 <Wizzup_> I think both stimulate each other

19:22 <si1v3r> it's a dirty game

19:46 <prahal> liquidAcid: yes ! did it dirty (about the dma bit mask hardcoded in quite many places ....

19:49 <prahal> running right now upon this code . Back to fighting the audio . audio is well then if I use gstreamer mfc+audio or at times only audio suddenly I got an xrun every second . till I reboot

19:49 <prahal> if it feels like a deja vu to someone please tell the fix :)

19:50 <liquidAcid> prahal, this audio bug, does this also affect vanilla alsa?

19:50 <prahal> yes

19:50 <liquidAcid> k, i roughly remember that you were fixing some audio bug that mostly happened when pulseaudio was added

19:51 <prahal> mind when it starts pulseaudio was always on

19:52 <prahal> but even killing pulseaudio and removing the binary and pulse-alsa conf files , after it initiate even plain aplay -D hw:0,0 , no go .... weird

19:53 <prahal> yup I had a hack in pulseaudio , it was a clean way to replace the PULSE_LATENCY_MSEC=60 workaround ...

19:54 <prahal> I do test the mix of kernel changes and pulse fixes right now

20:02 <prahal> liquidAcid: the mfc probe crash is tricky . It is kind of the opposite of the drm issue . mfc subdrv have no iommu set when their dma is called on the dt defined memory region . So we have to tell them the parent device assigned iommu setting (dma_ops + mapping) . When in drm the parent device lacks the iommu settings and have to be told to use one from its children (which is fragile as depending on the set of enabled child

20:03 <prahal> the first one iterated upon might not have an iommu either

20:04 <liquidAcid> ah, makes sense that it pagefaults when loading fw then

20:18 <liquidAcid> prahal, already seen this? https://patchwork.kernel.org/patch/6338751/

20:21 <prahal> quite a lot of removals , well cleaned up

20:23 <liquidAcid> the userptr code is in serious need of cleanup :)

20:43 <liquidAcid> prahal, i was wondering, since you're using r5p0, is this version of the blob using this GET_FB_DMA_BUF ioctl?

20:43 <liquidAcid> (or maybe you're just using the x11 blob?)

21:32 <liquidAcid> chidori ~ # uname -a

21:32 <liquidAcid> Linux chidori 4.1.0-rc2-debug+ #1 SMP PREEMPT Tue May 5 23:29:40 CEST 2015 armv7l SAMSUNG EXYNOS (Flattened Device Tree) GNU/Linux

21:32 <liquidAcid> prahal, yeah :)

21:33 <liquidAcid> prahal, you should rename your branch ;)

23:28 <prahal> I use the x11 blob

23:29 <prahal> rename ? <- 4.1

23:31 <liquidAcid> prahal, yeah, odroid-4.0 is based on 4.1 afais

23:35 <prahal> well spotted

23:37 <prahal> written on the todo

23:38 <prahal> too late for this day , time to read

23:38 <liquidAcid> hehe