00:00 <loki666> it works, with some hiccups... Not critical. But perfs of libMali are much better

00:04 <loki666> For the use case of the Anbernic devices, 3D is not such a big deal, honestly. So we'll deal without fine for 16bit consoles emulation. But it would have been great to have libmali

00:09 <apritzel> I don't think libmali has a real future with mainline anyway

00:10 <loki666> Thanks anyway

06:15 <wens> it seems resources have been reallocated to panthor, and so panfrost got sort of put on the back burner with regards to getting more improvements

08:03 <szemzoa_> is the sun50-iommu driver working? I can't register more than one device behind iommu. The first one is registering (I can't test currently if it's works or not), and all the other devices fail to register: https://pastebin.com/CmZxbkr1

08:33 <warpme> guys: i'm hacking with h728 tvbox and 6.12.3 kernel. box boots but ends with cpu0 softlookup: https://gist.github.com/warpme/c2d7d2e5a6fc8f388454e94070f0f18a What will be your advise to move forward with this?

09:02 <linkmauve> wens, panthor is just the kernel driver, panfrost being either the kernel driver for older Mali GPUs, or the Mesa driver for both.

09:02 <linkmauve> panvk being the other Mesa driver, the one doing Vulkan.

10:34 <apritzel_> warpme: where did you get the regulator voltages from? I see some corrections done by the kernel, and I wonder if they are correct

10:41 <warpme> apritzel: my minimal dt ( https://gist.github.com/warpme/551cce0ef42e778ef31f2a0744cf316c ) is based on avaota a1 dt iirc. I was trying to deduce from vendor android dt ( https://gist.github.com/warpme/54a713a53919e9ffa04c114fbb398a06 ) but I failed with determine as i see there only ranges but no concrete values .....

10:43 <apritzel_> yes, that's a big problem with the vendor DT: no voltages

10:44 <apritzel_> my box arrived yesterday, and I dumped /sys/kernel/debug/regulator/regulator_summary, but didn't find time yet to convert that

10:45 <warpme> I was trying to set L143/L270 to i.e 990mV to be sure cpul/cpub supplys are not too low - but this not helps...

10:45 <apritzel_> warpme: btw: did you figure out what the second set of UART pins is for?

10:47 <warpme> oh no. now i'm trying to get minimal boot with usb-eth to incrementally play with dt (using network to upload dtb to device (instead of constant remove/inserd sd card with changed dtb)

10:47 <apritzel_> warpme: you would need to change some parts, for instance there is no USB-OTG, so dr_mode should be host

10:48 <apritzel_> and I saw 5V on the USB port even in FEL, so I guess there are always powered

10:51 <warpme> oh - for sure dt is really crappy now! I stuck with boot softlookups so no any corrections yet in dt...

10:57 <apritzel_> do you get further if you remove USB, and maybe even the regulators? You wouldn't need them for SD card/eMMC, and probably not even for USB, if the ports are really always-on

10:58 <apritzel_> warpme: also: do you know of any mainlining efforts for the AIC8800 WiFi chip? Quick googling just turned up the usual crappy vendor driver repos

11:00 <warpme> re h728 dt - ah ok - let me try this... re: aic8800 - well - i back-ported it to 6.12.3 (sdio and usb variants). sdio works well. usb is a bit unstable.....

11:04 <apritzel_> with "back-ported" you mean ported some vendor code to work on mainline?

11:05 <warpme> re h728 very minimal dt: may you hint me what parts i can remove (for testing)?

11:06 <warpme> re aic8800 - yes: making it compiling+working and also making a bit less spamming kernel logs...

11:08 <apritzel_> remove reg_vcc12v and reg_usb_vbus, set dr_mode to "host", drop everything from usbphy except status

11:09 <apritzel_> (and fill the gaps created by those removals)

11:13 <apritzel_> in a second step you could remove the whole r_i2c node, drop the pio node

11:16 <apritzel_> also the SD card vqmmc looks wrong, why does it point to a 1.8V regulator?

11:21 <apritzel_> macromorgan: what's your estimate on fixing up the PLATFORM_DEVID_AUTO issue? Can you do this in a bullet-proof way this week?

11:21 <apritzel_> I am asking because otherwise we should revert the patch, to buy us more time for a proper solution

11:22 <warpme> for vqmmc: i deduce this from vendor dt: L5283/5284 are pointing to L4738. So on cldo1 on axp717 in my dt.

11:22 <apritzel_> macromorgan: it's not strictly needed atm, since only the A523/T527 boards come with two regulators, and they are not supported yet

11:24 <apritzel_> warpme: that's all smoke and mirrors. The SD card is supplied by an internal switch controlled by some PIO registers. We don't support it in mainline yet (I have some patches, but they don't work)

11:24 <apritzel_> warpme: so you can just drop the vqmmc property, the kernel will then look at vmmc

11:44 <warpme> apritzel: well - after removing reg_vcc12v, reg_usb_vbus, setting dr_mode to "host", dropping everything from usbphy except status - for 5 boots i got 100% successful boots + stable telnet on booted board :-) Many thx! So now time to get onboard Eth. For gmac i found: https://github.com/AvaotaSBC/linux/tree/main/bsp/drivers/gmac I see vendor dt L7014 points to sunxi-gmac and this bps driver https://github.com/AvaotaSBC/linux/blob/bbdd2

11:44 <warpme> ee80232fa9ed031a85b50b71fb9e7e1445a/bsp/drivers/gmac/sunxi-gmac.c#L3468 acting like sunxi-gmac....

12:57 <apritzel_> please don't waste any time on those vendor drivers

12:58 <apritzel_> I compared the docs and they seemed very similar, if not identical to the previous one

12:58 <apritzel_> but there must be some tiny detail, as it doesn't work easily when pretending to be an A64 compatible GMAC

12:58 <apritzel_> hint hint: nice topic for anyone to dive into ...

13:13 <warpme> ah a523 gmac is thing i not yet investigated... So should try with existing in-kernel gmac driver (in other words: is a523 gmac similiar enough to existing in-kernel gmac to go with)?

13:57 <macromorgan> I don't know... thus far I've half-assed a few solutions but they don't work. I'm thinking maybe I just document that if you're using the ADC device then you map individual channels? I have to try that this week.

15:26 <apritzel_> warpme: yes, I think I already compared the registers, and they looked the same. But there must be something missing, as it didn't work for me, on the Avaota at least

15:27 <apritzel_> an added complication is that the box has a Maxio MAE0621 PHY. I didn't find an upstream driver for it, but some nasty out-of-tree bits again. Not sure how much we need, but that's something to look out for

15:28 <apritzel_> macromorgan: I was afraid you were saying that, which sounds like more we should revert that patch in mainline, then bring it back once we have a solution that people agree on

15:33 <macromorgan> it feels to me like the way it was done in the past was wrong honestly, and this change you guys did just broke that wrong behavior

15:33 <macromorgan> it was looking at the parent device for the ADC channel, but the parent device is the MFD which isn't an ADC device

15:33 <macromorgan> just happenstance it worked I guess

15:36 <macromorgan> so far the solution I was working on was to add an additional routine to the USB and battery drivers that looked for the ADC device. Then, instead of calling devm_iio_channel_get() we'd call devm_fwnode_iio_channel_get_by_name() (because that function doesn't assume the device for devm purposes is the ADC device)

15:36 <macromorgan> I didn't get it working yet, but I think I was close last week

15:38 <apritzel_> yes, that it was broken before and just happened to work is also my hunch

15:43 <warpme> apritzel: for MAE0612 - initially i was looking for this: https://gist.github.com/warpme/2705f38fc713f130247fc257e4b3b55a

15:47 <apritzel_> warpme: well, question is: has this been reviewed, tested, sent to the list? It's not much better what Allwinner typically proposes otherwise, tbh ....

15:48 <apritzel_> Was it used in some Rockchip devices (I guess TV boxes) as well?

15:51 <warpme> idk :-( But at least it is kind of starting point maybe....

19:34 <enthdegree> Hello all. I'm interested in building a kernel for a pocketbook era, which has a sun8iw10

19:36 <enthdegree> pocketbook has published the kernel source for very-similar devices based on that same SoC here: https://github.com/pocketbook/kernel-b288/

19:37 <enthdegree> presumably (I will find out soon) the only significant change between the era's source and the published ones is its kernel config, which can be extracted from a working device

19:38 <enthdegree> There's a discussion on github about the eink driver I can't quite understand... will describe below

19:39 <enthdegree> The discussion spans before/after the publishing of that kernel source I linked above. Before publication they were trying to reverse-engineer this driver they called proprietary, "epdc.ko" (I'm guessing "epaper display controller")

19:40 <enthdegree> after publication of kernel-b288 they identify that epdc.ko significantly matches that source

19:40 <enthdegree> here's the discussion: https://github.com/koreader/koreader-base/issues/1202/

19:42 <enthdegree> Heres what I can't figure out: I can't discern whether compiling kernel-b288 produces a working epdc.ko

20:10 <enthdegree> well I guess I'm just doing it the blockhead way

20:10 <enthdegree> compiling & seeing ...