16:03 <prahal__> liquidAcid: finally got to the atomic item : I have an issue !-) - if dpms in gnome-shell = vblank_off then pageflip , the pageflip *succeed* . Well it is acked by atomic code but no reference is taken -> on vblank_on the vblank events are left off and gnome-shell is waiting for its reply forever

16:04 <prahal__> btw I was indeed interested by the dma + sound thread . Thanks

16:05 <liquidAcid> prahal__, i can't get 4.2-rc to work atm, all regulator lookups fail for some reason

16:06 <prahal__> I switched to linux-next 20150723

16:06 <liquidAcid> and 4.1.y has broken vsync for me, lots of tearing (probably because of the unfinished atomic conversion)

16:06 <prahal__> with an added kdbus fix

16:06 <liquidAcid> uh, kdbus *yuck*

16:08 <liquidAcid> [ 1.122334] dwc2 12480000.hsotg: Failed to get supply 'vusb_d': -517

16:10 <liquidAcid> no idea what 517 is supposed to be at all

16:11 <liquidAcid> [ 0.769211] exynos-hdmi 12d00000.hdmi: Failed to get supply 'vdd': -517

16:11 <liquidAcid> well, at least its consistent

16:27 <prahal__> july 14 has "regulator: core: Handle full constraints systems when resolving supplies" 9f7e25edb1575a6d2363dc003f9cc09d840657e2 <- it tells this is not necessary for DT .... but this is so close to http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/308626.html ...

16:28 <prahal__> this is in rc4

16:29 <liquidAcid> hmm, 517 seems to be EPROBE_DEFER

16:30 <liquidAcid> prahal__, yeah, that looks very similar

16:35 <liquidAcid> although i don't see why it should defer probing at this point

16:58 <liquidAcid> prahal__, it shouldn't defer probe at this point

16:58 <liquidAcid> either something is broken with the dt parsing or its something else

17:39 <liquidAcid> [ 0.548362] hw perfevents: Failed to parse /pmu/interrupt-affinity[0]

17:40 <liquidAcid> i don't get it

19:57 <liquidAcid> hmm, looks like it fails in regulator_dev_lookup()

20:30 <liquidAcid> strange, i should find that regulator, it's clearly in the fdt

21:27 <javier__> liquidAcid: with what board are you having that issue?

21:27 <liquidAcid> javier__, odroid-x2

21:27 <liquidAcid> i tracked it down to: http://lxr.free-electrons.com/source/drivers/regulator/core.c#L1289

21:28 <liquidAcid> regulator_list is non-empty and in fact all regulators are there, but node == r->dev.of_node is never true

21:31 <javier__> but is the regulator returned by of_get_regulator(dev, supply) in the regulator_list?

21:32 <liquidAcid> javier__, yes, vdd-supply for hdmi is ldo8

21:33 <liquidAcid> i also run fdtdump in the dtb, all the nodes are there and the phandles are all correct

21:34 <liquidAcid> guess i should switch of selftest on

21:35 <javier__> liquidAcid: yeah, the DTS seems correct, how weird

21:35 <javier__> this is just a plain 4.2-rc3 with no patches on top?

21:36 <liquidAcid> torvalds/master with ~180 patches on top

21:36 <liquidAcid> nothing touching drivers/regulator and drivers/of though

21:37 <javier__> liquidAcid: can you share your complete boot log ooi?

21:37 <javier__> I'm curious what could be causing it...

21:37 <javier__> it's OK for a regulator_get() to return -EPROBE_DEFER now since the logic to lookup the parent supply was moved from regulator_register() to regulator_get()

21:37 <javier__> but in this case I don't see that a parent input supply is defined for the ldo8 regulator

21:38 <javier__> so it should succeed if the regulator has been registered already

21:38 <liquidAcid> javier__, correct, but parent doesn't seem to be issue

21:38 <liquidAcid> javier__, gimme a moment, i need to rebuild and reboot to grab the log

21:39 <javier__> liquidAcid: correct, I was just thinking aloud

21:39 <javier__> liquidAcid: no rush, I'm just courious :)

21:41 <liquidAcid> javier__, that's a partial dmesg: http://pastebin.com/iEnLig9L

21:41 <liquidAcid> it really just only affects regulators

21:46 <javier__> liquidAcid: I see, so you are having lookup fails for *all* regulators, it is not only about the HDMI vdd supply

21:47 <javier__> very weird indeed, I don't have a good idea of what could be causing this on your tree...

21:51 <liquidAcid> javier__, yes, it's if i'm using a wrong/corrupt db

21:51 <liquidAcid> *dtb

21:52 <liquidAcid> but i double-checked this, and if the dtb was corrupt then i probably wouldn't get that far in the boot process anyway

21:55 <liquidAcid> javier__, http://pastebin.com/NUJWj4nb

21:55 <liquidAcid> more complete log

21:55 <liquidAcid> looks like r->dev.of_node is null for every regulator

22:01 <liquidAcid> or at least for all ldos and bucks

22:06 <javier__> liquidAcid: mmm, the only thing I can think is adding printouts to regulator_register() to see why those of_node are not filled

22:06 <liquidAcid> ahhhhhh, i see *lightbulb*

22:07 <javier__> ?

22:09 <liquidAcid> i changed regulator names in my tree (ldo@X and buck@X), but this time i also removed the regulator-compatible properties -- now the max77686 driver can't associate the regulators

22:09 <javier__> ah, that makes sense

22:13 <javier__> that's why I always just use the node name to match whatever is used in the driver instead or regulator-compatible

22:13 <liquidAcid> javier__, and i think regulator-compatible is deprecated, isn't it?

22:13 <javier__> liquidAcid: yes it is

22:18 <javier__> liquidAcid: glad that you found the issue, I'm going to sleep since is very late here, bye!

22:18 <liquidAcid> javier__, thx for the help

22:18 <javier__> liquidAcid: I didn't help anything tbh :)

22:19 <liquidAcid> javier__, well, explaining the issue to another person already helps a lot i guess :)

22:19 <javier__> liquidAcid: indeed :)