09:42 <mriesch> i wonder whether there should be some relation between the (rockchip) i2c controllers and the corresponding supplies

09:44 <mriesch> it seems currently we rely on supplies to be powered on initially. after probe, devices on the respective i2c bus may take over and get the corresponding supply.

09:45 <mriesch> should i just use regulator-boot-on; and get on with it? or does it make sense to add a -supply property to the rk3x driver?

11:36 <robmur01> mriesch: if there's an external power rail to the i2c block in the SoC besides its general I/O domain supply, then yes, but supplies for external chips on the other end of the bus should logically belong to those chips themselves

11:37 <robmur01> just imagine if there were like 7 different chips on one bus all powered independently

11:52 <mriesch> robmur01: as far as i can tell, there is no extra supply in that sense, but naturally the io domain has a supply

11:53 <mriesch> but then i can't see a relation in the device tree between the i2c controller and the io domain -> is there supposed to be one?

12:12 <robmur01> hmm, good point, I guess it's typically just been the case that most I/O domain supplies are always-on anyway (either physically, or logically due to GPIOs and whatever else in the same block being important)

12:18 <robmur01> I suppose there could be a possible argument for something like an "i2c-supply" representing the signalling voltage for the bus itself

12:22 <mriesch> robmur01: indeed usually the supply is on anyway. but one can construct corner cases in which this does not hold. guess there could be a level shifter or optocoupler in between, then the supplies of master and slave are likely to be different

12:23 <robmur01> but looking at some rk356x schematics it seems like i2c pins are still mixed up with various other stuff in shared I/O domains, so the chances of being able to do meaningful power management from the i2c driver without breaking other things in general seem slim, therefore simply going with the always-on status quo seems the most pragmatic option

12:25 <mriesch> as to the "i2c-supply": i wonder whether this is something rockchip specific... should it enter the i2c controller core, if anything?

12:33 <robmur01> I'm not sure it would generalise that well in practice - no idea how common it is for the I/O pads to be powered independently of the controller itself

12:42 <mriesch> ok, i'll go with the pragmatic approach for now :-)

12:44 <robmur01> even for Rockchip it seems like a very niche case - looking at Quartz64 for instance I don't see any i2c pins where there aren't also GPIOs/UARTs/etc. also being used in the same domain

16:06 <mort> my px30 gets 5 FPS when showing a very simple 2D animation using OpenGL. I suspect the GL drivers aren't working properly. Any idea how I could debug this when using the rockchip bsp?

16:08 <mort> literally just putting a small texture on the screen gets 19 FPS, so something's definitely amiss with the GL drivers

17:04 <mmind00> mort: depends on what stack you're running ... i.e. mesa with panfrost, arm binary driver madness, gl-in-software ... I guess glxinfo and friends will help to find out

19:32 <CounterPillow> macromorgan: Hi, Nicolas here. Maybe the 100mV less than the min design capacity thing is good just as a battery health thing, my safety concerns are satisfied now that I've learned it does have a default cutout voltage.

19:32 <macromorgan> okay, I can do that

19:34 <CounterPillow> Thanks for your work on this, it is much appreciated