00:52 <macromorgan> sweet... got USB working on mainline. So far I've identified what looks like a missing regulator, some sort of enable pin (or possibly a 2nd missing regulator), a detect pin, and I just found apritzel's boost patches so I'll try them out next (I'm only getting 4.5v on my USB, so I think I need the boost)

00:53 <Jookia> nice!

01:34 <macromorgan> dumb question (and I feel like I should know this) but is the boost regulator expected to run the host port or the OTG port when in host mode?

01:35 <macromorgan> enabled or not I'm only getting about 4.5v out of my host port, and so far nothing I've done has changed that.

02:28 <tokyovigilante> macromorgan: awesome!

02:29 <tokyovigilante> Some sucess on the v4 cpufreq patches, but still not reaching 1.5GHz

02:29 <tokyovigilante> [ 1.662659] core: _opp_supported_by_regulators: OPP minuV: 1160000 maxuV: 1160000, not supported by regulator

02:29 <tokyovigilante> [ 1.662669] cpu cpu0: _opp_add: OPP not supported by regulators (1512000000)

02:29 <tokyovigilante> [ 1.663024] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1008000 KHz, changing to: 1032000 KHz

02:29 <tokyovigilante> got to 1.412 ok

02:30 <tokyovigilante> Does this imply I can push DCDC1 to 1.16v? at 1.10 currently

02:31 <tokyovigilante> Looks like the BSP does, wish me luck..

02:40 <tokyovigilante> Seems to accept the 1.16v limit, but getting random KPs immediately after, so would seem not that stable. Do I need a margin of error? Say 1.2v? I see the BSP allows up to 1.5v

02:45 <tokyovigilante> Nope, that didn't help

14:14 <blathijs> Hey folks, I'm running into a video decoding (or rendering maybe) issue and I'm wondering if this looks familiar to anyone. The problem is that when starting a video, every now and then the first frame gets decoded only partially - the bottom part (sometimes even 90%) of the image is rendered green. The image recovers gradually over the next couple of seconds as more incremental

14:14 <blathijs> frames are decoded until (I presume) the next keyframe when it recovers completely. Here's an image of the issue: https://imgur.com/sJPUm9Q (this is a few frames after the first one - the bottom part starts out entirely green and in the video the JBL logo "grows" into view, so the fact that that is shown makes me think all but the first frames decode properly.

14:17 <blathijs> I'm using gstreamer with v4l2slh264dec and kmssink for this (from a Python script, but I've also seen it with gst-launch-1.0). It seems to be a kernel regression - with a 6.1.11 kernel from armbian 23.02.1 the problem never occurred, after upgrading to 6.7.4 from armbian 24.2.1 it happens every 5-10 playbacks.

14:20 <blathijs> I think it is related to decoding, not rendering because of how the incorrect rendering behaves, and because it also happens with fbdevsink instead of kmssink (even more - it seems to happen *every* playback then, maybe related to the fact that fbdevsink is really slow, probably because it needs to do software scaling...)

20:46 <macromorgan> manually tinkering with registers on the AXP717 it looks like my charging port is exclusively for charging... (reports as DCP no matter what kind of cable or charger I use)...

20:52 <macromorgan> after flipping the bits to turn on cc detection and bc detection I show 0x00 for register 0xE7 no matter what kind of port I charge on, and I show 0x70 for register 0x05 (BC detect, corresponding to the detection of a DCP)

21:41 <linkmauve> blathijs, would you be able to bisect the kernel here?

21:41 <linkmauve> Also, which SoC are you using?

22:04 <macromorgan> weird, I have gadget mode working, but still only can detect it as a DCP port... ohh well, now onto messing more with the PMIC