06:53 <dlan> mdrjr: I'd try to run mainline kernel for odroid-u3, and seems I need up-to-dated u-boot?

06:53 <dlan> the default seems have problem with device tree

06:58 <dlan> javier__: I tried your suggestion, to run a mainline kernel, cat zImage dtb > zImage.dtb ,then create uImage -> fail to run, no kernel msg

06:58 <mdrjr> just boot with zImage + dtb

06:58 <dlan> mdrjr: what do you mean?

06:59 <dlan> for just zImage + dtb

06:59 <mdrjr> cat zImage dtb > newzImage

06:59 <mdrjr> and boot with newzimage

06:59 <dlan> http://dpaste.com/0R36ZFE

06:59 <mdrjr> works like a charm :)

06:59 <dlan> ok

07:01 <dlan> I'm using arch/arm/configs/exynos_defconfig now, is this correct?

07:01 <dlan> and arch/arm/boot/dts/exynos4412-odroidu3.dts

07:01 <mdrjr> either exynos_defconfig or multiv7_defconfig

07:04 <dlan> mdrjr: thanks, works now, boot into system ;-)

08:08 <sjoerd> amitk: Did you happen to try hdmi out with the upsteam kernel on the xu3?

08:25 <javier__> dlan: it depends if you use bootm or bootz u-boot command to boot

08:27 <dlan> javier__: use bootm here, even it's zImage

08:31 <javier__> dlan: strange, I thought you needed the bootz command (CONFIG_CMD_BOOTZ) to boot raw zImages and that bootm only supported uImages

08:37 <javier__> dlan: I see, hardkernel u-boot behaves differently than mainline, instead of having a different bootz command, it has a CONFIG_ZIMAGE_BOOT option that allows to boot zImages with the bootm command

08:39 <dlan> javier__: great, guess so ;-)

10:10 <amitk> javier__: do you know if buck4 on the max77802 is supplies the vdd_g3d on the peach pi? I've copied from the dts file on the exynos-reference tree but I see the following message "deviceless supply vdd_g3d not found, using dummy regulator"

10:11 <amitk> sjoerd: I haven't tried out hdmi yet

10:11 <amitk> i've been trying to get the mali driver to register in the few hours I had last week

10:12 <sjoerd> amitk: ok I'm having some problems but turns out javier__ is seeing the exact same issue on recent kernels which the peach pi

10:12 <sjoerd> with problems i mean: http://people.collabora.com/~sjoerd/14120001.jpg

10:13 <sjoerd> amitk: fwiw the git issues were resolved by switching away from the git-ro remote on the linaro server

10:13 <sjoerd> so i gues that has some issues :/

10:13 <zenmetsu> i've gotten sjoerd's branch to work fine, working on getting kwin gles up to test the userspace stuff :)

10:14 <ukki> sjoerd: that looks familiar and is probably related to this: https://bugs.launchpad.net/linaro-ubuntu/+bug/1275351

10:14 <amitk> sjoerd: hmm, I'll report that to the gitolite admins. I just started a clone of my tree to find out if I was seeing the same problems

10:15 <sjoerd> javier__: ^

10:15 <amitk> sjoerd: that looks nice. xscreensaver? ;-p

10:16 <sjoerd> that should have been weston :)

10:16 <zenmetsu> ouch :)

10:17 <zenmetsu> so there is a wayland driver for mali? i saw a video that leads me to suspect as much

10:18 <sjoerd> http://community.arm.com/groups/arm-mali-graphics/blog/2014/08/14/mali-x11-vs-wayland-at-siggraph-2014

10:18 <sjoerd> Guess what ran on top of the kernel tree you're now using (well strictly speaking a previous iteration of that one)

10:18 <zenmetsu> yeah, saw that. didn't see that the driver was released though :/

10:19 <sjoerd> It's not yet unfortunately

10:24 <zenmetsu> oh well, hopefully it is still being actively developed. i've been quite impressed with the SoC so far, would like to see it have some staying power once people start moving off of x11

10:25 <javier__> amitk: yes, max77802 buck4 is the power supply of vdd_g3d, sorry what did you copy from the exynos-reference tree and which driver is failing to get that regulator?

10:25 <javier__> ukki: thanks for the pointer, I'll take a look

10:27 <javier__> amitk: I guess you need something like g3d-supply = <&buck4_reg>; on your device node

10:29 <javier__> amitk: that regulator is marked as always-on though so it shouldn't be a problem that the driver is using a dummy regulator afaict since the regulator will be always enabled

10:30 <amitk> javier__: well, mali is failing to set the operating voltage. I think I'll go back and start from sjoerd's tree to see what might be missing

10:31 <zenmetsu> amitk: i get same in my dmesg with regards to the mali failing to set operating voltage, but the device node is still created and I believe that it will work once i test with userland binaries

10:32 <javier__> amitk: hrmm, do you have your complete boot log? the max77802 regulators have as input supplies regulators from the tps65090 PMU

10:33 <javier__> but the max77802 probe is probed before tps65090 so the probe is deferred

10:33 <javier__> amitk: that DTS on sjoerd's tree didn't model the power scheme with that level of detail so maybe is because mali doesn't implement deferred probe correctly

10:35 <sjoerd> iirc the g3d is also on its own PD, in my tree the CR2 enabled writes directly to that cotroller.. But it should probably be a power domain defined in the dts

10:35 <javier__> amitk: you can try this change to see if that's the problem http://paste.debian.net/plain/134406

10:36 <javier__> amitk: iirc there was a similar issue with the big.LITTLE CPUFreq driver because it needed to set an operating voltage on probe but at that time the vdd_arm power supply (buck2) was not present yet due max77802 probe being deferred

10:44 <amitk> ok, will try this out and report back

10:49 <javier__> amitk: great, if that's not the problem then I can take a look to your branch

10:50 <javier__> amitk: I'm very ignorant about gfx in general and the mali driver in particular but I can try to figure out :)

10:53 <amitk> javier__: same here, I'm just trying to get gfx working so I can get a full-fledged desktop for my team to use on our real work around the scheduler (we can run realistic usecases)

10:53 <amitk> *all this on a mainline kernel

10:54 <sjoerd> \o/

10:54 <javier__> amitk: awesome

10:54 <amitk> so all your help is appreciated

15:48 <amitk> sjoerd: javier__: Should CONFIG_MALI_PLATFORM_FAKE really be enabled in the Kconfig? Even though we have a "real platform" which we set through CONFIG_MALI_PLATFORM_THIRDPARTY_NAME?

15:48 <amitk> what spaghetti code...

15:48 <sjoerd> amitk: I have to re-check the code for that every time.. it makes me go ngggg nggggg ngggg

15:48 <sjoerd> so don't know offhand sorry

15:49 <amitk> sjoerd: it seems to be enabled in your changes to exynos_defconfig

15:49 <amitk> but the code paths are subtly different to make debugging a pain