03:27 <wens> juanesf91: well they seem to work correctly

07:17 <jernej> wens: this is completely vibecoded H616 VP9 support: https://github.com/jernejsk/linux-1/commits/vp9-v1/

07:18 <jernej> almost all reference bitstreams are correctly decoded. Some issues remain with dynamic scaling, v4l2 limitation

07:18 <jernej> wens: you have bug in iommu channels, 2 & 3 are needed

07:39 <gamiee> damn, another nice example of how llms can help with those stuff

07:39 <gamiee> impressive

07:44 <jernej> gamiee: they considerably speed up my projects that were put on hold :)

07:45 <gamiee> jernej : same :) the only shame is that sometimes, it takes the joy of writing code and working with it. Or sometimes due to the lack of the whole exploring process will cause not discovering some nice stuff.

07:45 <gamiee> But well, it is a tool

07:46 <jernej> gamiee: in my case, it discovered HW bugs in VC-1 decoder and even figured out what is the issue :)

07:46 <gamiee> pretty impressive! Do you have some test harness that LLM can even automatically test the stuff?

07:50 <jernej> yeah, I have target board booting via tftp, then I run Claude Code or Codex inside kernel source folder, which is exposed via tftp, also ghidra exposed via MCP. Boards are reachable via ssh for mainline, or can be manually booted to Android (TV boxes), so they can be instrumented via frida framework and information is thus captured dynamically.

07:50 <jernej> then I have just to steer LLM correctly and sometimes reboot board manually.

07:51 <jernej> final thing would be USB relay board for power cycling

07:51 <jernej> so I could leave it unattended for long time

07:52 <gamiee> damn ! This is indeed proper LLM harness, love it!

07:52 <gamiee> future is scary :D

07:52 <gamiee> to one side, yeah, finally no need to waste 8 hour figuring out silicon bug, or some dumb issue in my driver, but still... it had it's charm

07:53 <jernej> once I spent a few years (on and off) figuring HW bug. I don't want to repeat that again.

07:53 <gamiee> haha I can imagine

07:58 <electricworry> jernej: when you said analogue audio is working for H616, is that in the mainline kernel (e.g. v7.1) without any patches?

07:59 <jernej> I think apritzel said that, but I can check

07:59 <electricworry> Oh sorry.

08:00 <jernej> I see "allwinner,sun50i-h616-codec" in DT, so yes, it should work if it's properly instantiated in board DT.

08:09 <wens> jernej: might have been a copy-paste error :(

08:11 <wens> jernej: I guess I'll respin my patch series?

08:13 <jernej> wens: please do. Also, does sram_claim behave correctly?

08:18 <wens> yes

08:19 <wens> well the sram drivers are already merged

08:19 <wens> https://lore.kernel.org/linux-sunxi/20260505134812.408316-8-wens@kernel.org/

08:19 <wens> as you can see, the VE claims two SRAM regions.

08:20 <wens> one is SRAM C, and the other is VE SRAM

08:30 <jernej> ah, sorry, missed that

09:03 <wens> wow my wip tree was still on 6.19-rc

14:00 <wens> v2 sent

14:06 <jernej> wens: I guess we need R-b or A-b on last one from someone else?

14:48 <wens> yeah

14:49 <apritzel> wens, jernej: just for patch 7/7?

14:50 <jernej> apritzel: yes

14:50 <apritzel> on it ...

14:50 <jernej> thanks!

15:13 <jernej> apritzel: since I'm testing on 4G DRAM board, iommu had to be fixed to support full range. Maybe you're interested in this commit: https://github.com/jernejsk/linux-1/commit/f79517942f48ff70e8d346d41d25afe4f2ba1dc1

15:18 <apritzel> jernej: ah makes sense. Well, in an Allwinner kind of way, in another world this would be a horrible hack ;-)

15:18 <apritzel> and it's quite shortsighted, since on the newer SoCs they need more than 32 bits anyway ...

15:20 <jernej> apritzel: hack in HW sense? I don't think it can be done nicer in software

15:21 <jernej> yeah, newer iommus support 34 bits, so they changed approach

15:21 <apritzel> yeah, sorry, in HW. Allwinner is always so stingy with their bits ...

15:22 <wens> I have a similar change in my tree, but using separate macro. using PHYS_OFFSET didn't work for me when I was working on it

15:23 <wens> my PHYS_OFFSET comes out as 0xfff1000040000000, not 0x40000000

15:25 <jernej> that's strange

15:29 <wens> I know

16:07 <valdikss> jernej: final thing would be USB relay board for power cycling <<< you can reboot on many USB hubs, no additional hardware needed. https://github.com/mvp/uhubctl

16:08 <valdikss> I have a LED strip glued to the back of my display, ambilight-style. I connect it to the display's USB port and can enable/disable it programmatically with uhubctl.

16:08 <jernej> interesting! let me check if I have compatible one

16:11 <jernej> hm... it may even work

16:28 <jernej> valdikss: it works! thanks!

16:28 <gamiee> valdikss: that really works? I bought this one... sec.

16:30 <gamiee> https://www.coolgear.com/product/10-port-managed-usb-3-hub-w-15kv-esd-surge-protection-on-off-per-port-control-software I have this one

16:30 <gamiee> I have CLI tool which can turn on/off the USBs I need, so it's easy to automatize it (both for human test scripts or LLM)

16:31 <gamiee> https://gami.ee/files/Screenshot_20260711_183046.png For manual control I made this plasmoid, so it integrates nicely + it can detect what is connected to that USB port and have memory on turn off.

16:34 <gamiee> there is external controller which can fully cut off the power to the hub port