00:40 <hanetzer> hehe.. we'd never get a movie like that in the current atmosphere

00:44 <alyssa----> chewitt: Shoot, sorry, there's a corresponding nondrm commit that I think I forgot to push, thank you for the reminder

01:02 <alyssa----> chewitt: Pushed, build should be fine now, sorry about that.

01:02 <alyssa----> Well, sorry not sorry, this is like the fourth time this has happened, ahem

02:57 <chewitt> @alyssa---- no problem, i'm just glad the fix is known/speedy :)

04:58 <tomeu> I'm always at how much serial output slows boot down on most SoCs

04:58 <tomeu> *surprised

08:08 <tomeu> nice, got reset working :)

08:09 <HdkR> high five

08:09 <tomeu> now, where was that TODO list

08:11 <tomeu> ah, here: https://www.irccloud.com/pastebin/fxGC36Eb/

08:39 <narmstrong> tomeu: can you add it in the panfrost drm driver repo like robher suggested ? I can do a merge request with for this if you want

08:39 <tomeu> narmstrong: yep, was already planning to

08:39 <tomeu> will push in a bit

08:39 <narmstrong> Bifrost DT bindings are submitted to dri-devel, I only need robher review

08:43 <tomeu> awesome

08:43 <tomeu> next for me is runtime PM

08:44 <narmstrong> tomeu: you pushed your reset changes on your gitlab fd-o linux repo ?

08:57 <tomeu> not yet, I'm still cleaning up

09:34 <tomeu> narmstrong: https://gitlab.freedesktop.org/panfrost/linux/merge_requests/2

10:52 <urjaman> mmind00: "drivers/core/ofnode.c:183: ofnode_first_subnode: Assertion `ofnode_valid(node)' failed." from a dev_for_each_subnode in pinconfig_post_bind ... (that was called by pinctrl_post_bind when binding rockchip_rk3288_pinctrl)

11:59 <mmind00> urjaman: which veyron are you building?

11:59 <mmind00> urjaman: u-boot does some voodoo regarding slimming down the devicetree used in spl ... so there are those u-boot,dm-pre-reloc properties added

12:00 <mmind00> see rk3288-veyron-speedy-u-boot.dtsi ... for reasons I really cannot understand, that dtsi only got added to the speedy dts, not the other veyrons it seems

12:01 <urjaman> speedy. anyways i got past that (i dunno how properly, but got...) by adding a validity check (+ret 0 if not valid) before that dev_for_each_subnode

12:02 <urjaman> with that it gets past dram init and atleast reading something from SPI... when i added #define DEBUG to the common spl.c i got it attempting to print the entirety of u-boot to me :P

12:03 <urjaman> apparently the mini printf doesnt support the length limit style of "%32s" ...

12:03 <mmind00> urjaman: ah, I guess the pinctrl driver somehow at least expected one &gpioX to also have the pre-reloc flag ... and David missed that there may not be any of them

12:03 <mmind00> you probably submit that fix upstream ;-)

12:04 <mmind00> +could

12:05 <urjaman> but yeah before the #define DEBUG it stopped with some sort of an initcall failure (that print isnt very ... readable off the bat) so i'm now trying to see what actually failed

12:14 <urjaman> oh looks like it managed to jump to u-boot and the initcall failure is from u-boot (but before it would write its banner?...)

14:28 <urjaman> https://urja.dev/nextcloud/index.php/s/yiMM6m9mEkorACi/preview maaan these screens are reflective, anyways yay

14:31 <tomeu> cool!

14:45 <mmind00> urjaman: congrats ... what was the culprit for the hang you saw?

14:47 <urjaman> the u-boot side initcall failure was teh "Enable debug UART" pinctrl request in rk3288-board.c failing - i just #if 0'd that for now (it was only for chainloading u-boot originally ...) i think i noticed some similar code being removed from rk3288-board-spl.c recently so i think that might also not be necessary ever?

14:49 <urjaman> "If we use the new pinctrl driver, the pinctrl setup will be done by device probe." is what the -spl.c commit said...

14:52 <urjaman> i'll clean this up into commits in the evening ... i'm rather exhausted by the amount of debugging i had to do :P

17:43 <urjaman> https://github.com/urjaman/u-boot/commits/c201-stuff i cleaned up most of my inane debug prints and put the rest of stuff into commits of varying quality :P

17:51 <urjaman> there's bunch of other stuff to figure out now tho... like why doesnt the microSD slot work ("mmc dev 1" results in "Card did not respond to voltage select!" but nothing else) ... or why the otg-capable (near screen) usb port doesnt find devices ... (i could guess that has something to do with umm .. OTG)

17:52 <urjaman> eMMC works tho, yay :P (the only thing that i dont have an OS on at the moment, sigh)

17:52 <urjaman> or well .. an OS that i would want to boot that is

18:03 <urjaman> oh neat, the "sysboot" (boot a syslinux config file ...) depends on CONFIG_CMD_PXE

18:03 <urjaman> super logical.

21:56 <urjaman> the microSD thing is quite simple yet confusing ... nobody thought to write code for the DW MMC controller driver (or the mmc core or rockchip dw mmc... i'm not sure at what level of abstraction that code should live) the code to turn on the IO voltage regulator (vqmmc_supply)

21:57 <urjaman> i can use the regulator debug commands to set the voltage and turn it on and then the microSD works just fine

23:42 <alyssa----> ITE: Alyssa argues with herself about writing a DE that doesn't suck.

23:42 <HdkR> i3!

23:42 <HdkR> Or sway if you hate multimonitor

23:43 <alyssa----> HdkR: Specifically written for eye candy

23:44 <HdkR> Oh, Compiz-fusion then

23:44 <alyssa----> Compiz is, like, so 2008

23:44 <Lyude> hottest question of 2019: when does panfrost get support for the all mighty Desktop Cube

23:57 <HdkR> All hail the cube

23:58 <urjaman> man i had a cuube ... in like 2008 :P

23:59 <urjaman> actually i had a dual-monitor cube (it was odd)