01:39 <stikonas> vagrantc: yes, grub-efi

01:39 <stikonas> grub-set-default and grub-reboot are especially nice for updating

11:57 <eballetbo> mmind00: is the unbalanced regulator warning 100% reproducible for you?

11:57 <mmind00> eballetbo: yep on Kevin it happens every time

11:58 <mmind00> eballetbo: as I said funnily enough only in my netboot setup where backlight bringup happens reaaaaallly late

12:01 <eballetbo> mmind00: curious, looks like I am not able to reproduce the issue with my netboot setup

12:02 <mmind00> eballetbo: oh nice ... so it looks like I found some sort of corner case then :-)

12:02 <mmind00> eballetbo: I'll do a bit of digging on my own then :-)

12:03 <eballetbo> mmind00: ok, I'll trigger more runs on our lava instance

13:06 <mmind00> eballetbo: in your logs, do you see the "pp3300_disp: disabling" message, where the regulator core disables pp3300_disp as unused regulator?

13:17 <mmind00> eballetbo: in the probe function, while props.power is set to pwm_backlight_initial_power_state(), this is likely never called before the initial backlight_update_status() directly after ... and I guess before your patch that error simply never triggered because there was also the pb->enabled tracking in the driver, that now gets read from the pwm-state directly

13:19 <mmind00> eballetbo: ah no, that isn't a function pointer, but I guess the protection through the pb->enabled still kept the issue from appearing

13:19 <mmind00> with I guess pwm running, but backlight regulator being off

13:24 <mmind00> eballetbo: pwm_backlight_initial_power_state() does check the regulator-state before the pwm-state (and doesn't reach the pwm-check at all) and the backlight power relies currently on the pwm-state

14:37 <eballetbo> mmind00: https://lava.collabora.co.uk/scheduler/job/1341185#L1054

14:38 <eballetbo> Here is the "pp3300_disp: disabling" message

15:46 <field^Mop> mmind00: hi, last time we talked about rk3188 rrpro, did i mention that bb tried to set a clk rate twice to the same rate which crashed the soc. any ad-hoc idea why only some rk3188 rrpros crashed, others didn't?

15:47 <field^Mop> mmind00: and maybe, as a topper, why bb might try to set the same clk rate twice (and why only on some boards)?

15:58 <field^Mop> mmind00: and, is it ok to crash when set to the same clk rate twice?

18:05 <mmind00> field^Mop: you will need to explain your abbreviations :-) ... rrpro, bb

18:05 <mmind00> field^Mop: right I now I don't really know what you're talking about

21:32 <field^Mop> mmind00: sorry. rk3188 on a radxa rock pro, bb barebox

22:03 <mmind00> field^Mop: ah ... barebox ... any crash on clock rate setting should not be ok :-) ... but I guess you need to know which clock is the affected one

22:03 <mmind00> field^Mop: but then again, I don't really spend time on barebox :-)

22:04 <field^Mop> mmind00: that's ok. I do. :-)

22:07 <aalm> field^Mop, does it support efi?

22:08 <field^Mop> aalm: https://www.barebox.org/doc/latest/boards/efi.html

22:09 <aalm> apparently not, on arm/rk3188

22:10 <field^Mop> aalm: not on rk3188, no

22:10 <stikonas> can't you use u-boot for efi?

22:11 <aalm> yep, was just wondering if bb is an option for me even

22:13 <field^Mop> stikonas: u-boot w/ efi on rk3188?

22:14 <aalm> efi on u-boot has hardly anything so much arch specific, that it shouldn't work just the same as on other armv7/armv8 SoCs atleast

22:14 <stikonas> field^Mop: I don't have rk3188 but it works fine on rk3399

22:14 <stikonas> presumably rk3188 has better support

22:14 <stikonas> as it was out for longer

22:15 <field^Mop> mmind00: strangely enough, it's one rk3188 that fails to run bb w/o the ckl rate patch.

22:16 <stikonas> well, unfortunately I still have to run non-upstream u-boot on rockpro64 (rk3399) :(

22:16 <stikonas> and need a blob for lpddr4 initialization

22:16 <field^Mop> stikonas: hm, rk3188 is - ehm - particular. so, it wouldn't surprise me if it wasn't well supported efi-wise..

22:16 <aalm> stikonas, "mainline u-boot" or w/e it's called had broken support for booting the sdmmc for a long time, as far i can tell

22:17 <field^Mop> stikonas: on bb its the same. blob req'd. should port u-boot init to bb, though

22:17 <stikonas> well, I boot from eMMC

22:17 <field^Mop> aalm: emmc-nand on rk3188 is still unsupported in mainline. *argh

22:18 <mmind00> field^Mop: please don't mix storage options :-D ... emmc is a regular dw_mmc, while nand needs a driver for the nand controller obviously

22:20 <field^Mop> mmind00: oh, ofcourse you're right. *doh emmc is not populated on the rrpro and nand is not supported. none the better in the end..

22:21 <mmind00> field^Mop: https://github.com/mrjayy/u-boot-rk3066/commit/308ed3803348d1a06bee9e6ff6baeeeaf72cfe9f

22:24 <field^Mop> mmind00: hm, heard rumors, didn't investigate. but it's not in mainline kernel :-/

22:24 <field^Mop> mmind00: thx for the link though!

22:25 <field^Mop> mmind00: hm, it's rk3066, so rk3188 should work the same?

22:25 <mmind00> field^Mop: yep ... that was uboot, I think it was based on https://github.com/rockchip-linux/kernel/tree/release-4.4/drivers/rk_nand ... but then again I think nand itself is on an "endangered species list" :-)

22:25 <field^Mop> hm

22:25 <mmind00> all newer boards I have seen has emmc chips it seems

22:27 <field^Mop> bad luck for rk3188

22:35 <mmind00> field^Mop: depends ... I had some nice hdmi output on my radxarock with mainline recently

22:36 <mmind00> field^Mop: and now my edison2 tablet (also rk3188) also displays a nice console on the internal lvds display ... maybe at somepoint someone will try their hand on that nand stuff [not me though]

22:37 <field^Mop> mmind00: yes. same goes for the internal NIC..

22:37 <field^Mop> mmind00: throughput it hilarious using git over ssh i.e.

22:38 <field^Mop> mmind00: connection losses on end

22:38 <field^Mop> mmind00: for "light" stuff it's mostly working. bulk is fail

22:44 <field^Mop> mainline at least

22:47 <field^Mop> OT: anyone using git-annex?

23:00 <tlwoerner> i'm guessing these patches are in mainlist now?

23:00 <field^Mop> tlwoerner: where to find those patches?

23:03 <tlwoerner> https://patchwork.ozlabs.org/cover/972968/

23:04 <tlwoerner> field^Mop: ^^

23:04 <tlwoerner> last time i checked, i couldn't boot my rk3188 with mainline u-boot, but it did boot with the vendor's u-boot fork

23:04 <field^Mop> tlwoerner: thx :)

23:05 <tlwoerner> but that was a while ago, this conversation reminded me to try it out

23:05 <field^Mop> tlwoerner: hm, iirc, mmind00 is using u-boot. though i ignore whether it's mainline u-boot..

23:06 <tlwoerner> yes, it appears mmind00's patches are in mainline u-boot

23:07 <field^Mop> ok

23:09 <tlwoerner> field^Mop: which board do you have?

23:10 <field^Mop> rk3188-radxarockpro

23:10 <tlwoerner> field^Mop: nice, same here

23:10 <field^Mop> ah, ok :)

23:10 <field^Mop> noted. did you ever boot barebox?

23:12 <tlwoerner> field^Mop: no, it hasn't been on my radar (but it is now :-) )

23:13 <aalm> i got two radxarock(pro?)s w/rk3188

23:15 <field^Mop> asking bc one of the rrpros here won't boot one and the same image while the other one does. one gets a clk rate set twice then crashes. no clue why

23:20 <field^Mop> n8 everyone

23:20 <tlwoerner> i'll give it a whirl next week sometime