13:27 <javier__> afaerber: hi, I remember you said that got audio working on spring in mainline at some point, do you mind to share your ucm profile?

13:28 <afaerber> javier__, hi. I wanted to contact you, too, as I am unable to boot my Spring with any recent kernel, even with your v2 clk fixes applied :/

13:29 <javier__> afaerber: hrmm, I can boot Snow with today's linux-next so I wonder what's the difference...

13:30 <javier__> afaerber: no worries, it would be great if you can send me once you have access to it so I can compare with the one I've for Snow

13:30 <afaerber> at some point without exynos drm's iommu config option enabled, I was able to boot it to a black screen and ssh in; since enabling it there is no power on usb, only backlight

13:31 <afaerber> I have one small patch to fix a mismerge of my patch with those mmc property name changes, then a series for asoc support, and I noticed you added for mwifiex power-on sequence to Snow

13:32 <javier__> afaerber: yes I did, sorry I forgot to cc you

13:40 <javier__> afaerber: sorry, I didn't get the relation between exynos drm iommu support and power on usb

13:41 <afaerber> javier__, I don't see the relation either and I have no UART to see what's going wrong, but seems to go terribly wrong (clocks, iommu, ... something pretty low-level probably)

13:42 <afaerber> do you have any other local patches? are power domains okay? I saw some patch for audio there

13:44 <javier__> afaerber: I can boot Snow using today's -next with no extra patches and exynos_defconfig

13:44 <javier__> afaerber: the audio patch was only to source the codec with the correct master clock which is enough to have playback working on peach pit with a correct ucm profile

13:45 <javier__> but is not enough in snow, that's why I wanted to look at your ucm profile even when spring uses a different codec

13:45 <javier__> afaerber: I wonder what is causing spring to fail booting...

13:45 <afaerber> well, like I told you, I only had it sporadically working myself

13:46 <afaerber> (audio, that is)

13:47 <javier__> afaerber: since you don't have a serial console then your only change is to do a git bisect to see what broke spring :-/

13:47 <javier__> *chance

14:27 <obbrobbrio> hi all, i'm setting up an arm chromebook snow converted to debian. how do i set which devices/buttons are allowed to wakeup the system suspended to ram when no acpi subsystem is available (hence no /proc/acpi/wakeup file)?

15:08 <javier__> obbrobbrio: afaict there isn't with DT a convenient interface to enable/disable wakeup sources like in ACPI

15:09 <javier__> obbrobbrio: you need to add/remove the wakeup source property in each device node in the DT

15:09 <javier__> obbrobbrio: you can look which devices are wakeup sources for your chromebook in /sys/kernel/debug/wakeup_sources

15:29 <obbrobbrio> javier__: thanks. i'll test as soon as possible, but does this imply recompiling the kernel?

15:31 <obbrobbrio> javier__: because to keep things easy i'm using the stock chromeos kernel...

15:32 <javier__> obbrobbrio: well not the kernel but the DT and re-creating the FIT image if you are not using nv-uboot

15:36 <obbrobbrio> javier__: mhhh, i'm really new to this... any resources to study about?

15:42 <javier__> obbrobbrio: http://linux-exynos.org/wiki/Samsung_Chromebook_XE303C12/Installing_Linux explains how to replace your kernel

15:54 <obbrobbrio> javier__: the reason i was not using a custom kernel was to not lose compatibility with the hardware... will every piece of hardware work after compiling the kernel by myself using that guide?

15:58 <javier__> obbrobbrio: the section "Linux_kernel" shows you the process to rebuild a FIT image, you won't loose any hw compatibility since you are not going to modify the kernel

15:58 <javier__> only the DT but since the DT is bundled in the FIT image, you have to create a new FIT

16:07 <obbrobbrio> javier__: yes i see, sorry... as i said i'm not very familiar with these steps. thanks

16:12 <javier__> obbrobbrio: you are welcome

16:15 <obbrobbrio> javier__: can i also ask if there is a proper way to get mali T604 drivers to work and have nice performances? for now fbdev is used by X, i tried some days ago for a couple of hours to follow http://community.arm.com/docs/DOC-9494 and extract from the script just what i needed, i compiled armsoc driver by myself but it crashed X many times

16:15 <obbrobbrio> do you know if it's even possible to get acceptable results?

16:16 <javier__> obbrobbrio: first I need to understand what your goal is

16:16 <obbrobbrio> i'm going to find the time to dig into it in the next days...

16:18 <obbrobbrio> javier__: with fbdev some web pages are slow to render and scroll, mplayer/mpv can't play in full screen, when playing some videos the cpu is heavily loaded

16:19 <obbrobbrio> javier__: i'd like some sort of hardware acceleration and opengl environment

16:21 <obbrobbrio> and i think that i'd need the proper video drivers for that, don't i? that's why i'm asking...

16:23 <Tenkawa> hi all

16:23 <Tenkawa> whats new?

16:31 <Tenkawa> anyone know usb_modewsitch very well?

21:47 <obbrobbrio> javier__: are you here?

21:53 <obbrobbrio> javier__: i just tested that /sys/kernel/debug/wakeup_sources entries are actually those devices which have a wakeup file in /sys/devices tree (find /sys/devices -name wakeup)

21:55 <obbrobbrio> each of these wakeup files can contain either 'enabled' or 'disabled', and if you set one of them to 'disable' it disappears from wakeup_sources

21:57 <obbrobbrio> and indeed it is disabled from waking up the system... i tried disabling the touchpad and it works, so one could do this even without going through DT recompilation