00:03 <wigyori> loosely related - i was looking at how much of the d1 support has been mainlined into u-boot (tried to upgrade from 2023.01), and it seems like it stopped or wasn't even attempted

00:06 <apritzel> wigyori: yes, I haven't seen any RISC-V patches on the list, if that's what you mean

00:07 <apritzel> I started some preparation for disentangling sunxi and arch/arm, but there is still some work left

00:08 <apritzel> smaeul wanted to introduce DM_SPL for the D1, so DT driven code in the SPL, but I am not a big fan of that, and it's another big chunk of code and changes

00:10 <apritzel> in general the D1 mainline interest died a bit down, it seems? Or maybe it's good enough as it is?

00:11 <wigyori> yes, seems like interest died down on it - it was a good soc, but better ones have been released

00:12 <wigyori> actually, i'm fine with running on 2023.01 anyway

00:17 <apritzel> what does "good SoC" mean here? I found it mostly "meh": apart from the novelty of having a RISC-V core in a cheap chip, was there really anything interesting in it?

00:18 <apritzel> on the plus side there was quite some momentum for upstreaming back then, which helps other SoCs now

02:50 <tokyovigilante> Have moved the colorspace code into the mixer object for the DE33 and working well. Planning to submit a v1 of the LCD TCON enablement along with v6 of the DE33 patch, should I split out the DTSI changes for the H616 into separate patches, or are they better together? Or is a SOC/TCON split sufficient?

02:51 <tokyovigilante> And I see a new revision of the PWM patch for the H616 et al has been submitted, should I just stick with a simple GPIO control for the backlight or put in a PWM node now?

07:04 <wens> bigger problem is finding someone to review the drm code :|

07:30 <jernej> wens: I'll do it in following days

08:30 <loki666> tokyovigilante: pwm patch is not for h616 yet, marcromorgan is waiting for D1 to be merged first

08:43 <wens> apritzel: I think I might just land the A523 CCU patches directly without too much review of the SoC bits

09:11 <BroderTuck> So...

09:11 <BroderTuck> Considering something that may end up being just plain unworkable.

09:12 <BroderTuck> Warpme once posted a link here to https://gist.github.com/warpme/2705f38fc713f130247fc257e4b3b55a (a Maxio driver)

09:12 <BroderTuck> Searching for info on the mae0621A I find claims that the chip is pin-to-pin compatible with the realtek rtl8211f

09:12 <BroderTuck> and comparing that driver ( drivers/net/phy/realtek/realtek_main.c ) to this one shows several functionally identical #defines

09:12 <BroderTuck> So, my insane idea was to incorporate the maxio stuff into the realtek driver.

09:12 <BroderTuck> Not an easy task since there are still mejor differences, and with my skills I'm not sure if I would get anything that works.

09:12 <BroderTuck> (dt bits in particular, I don't speak dte)

09:13 <BroderTuck> *dts

09:21 <BroderTuck> warpme: Morning

09:23 <warpme> Morning!

09:23 <warpme> BroderTuck: re maxio: my experience with cubie a5e: my board has 2 maxio chips soledred - but in my case (with gmac/gmac200 drivers ported from bsp) - both are using generic phy kernel code to serve maxio chips....

09:31 <warpme> my port of gmac/gmac200: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.14/files/1139-net-ethernet-allwinner-add-gmac200-support.patch https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.14/files/1140-net-ethernet-allwinner-add-gmac-support.patch

09:32 <warpme> and dtsi adds: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.14/files/1151-arm64-dtsi-allwinner-add-gmac1-in-A523-dtsi.patch https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.14/files/1152-arm64-dtsi-allwinner-add-gmac0-in-A523-dtsi.patch

09:37 <warpme> above code gives me eth0/eth1 working well on cubie a5e and h728 based x96pro+. On oip4a however i can't get rx path working (i see dhcp bcst, my server replays but kernel not receiving those replays). As now we have .sch - i'll try to verify: is my past guessing of hw correct.....

10:10 <jernej> if anyone is annoyed with phoenix images, here is a script to convert it to ordinary raw images, which can be flashed with dd or whatever: https://gist.github.com/jernejsk/7290b340ecc636bafd52f80fa3ed9fff

10:10 <jernej> tested with radxa phoenix image

10:11 <jernej> it was born out of frustration because I was doing this manually and accidentally rewrite beginning of my laptop drive due to corrupted gpt table in that phoenix image :)

10:41 <chewitt> BroderTuck it's possible that the original source for that driver is https://github.com/chewitt/linux/commit/dbcc56c1a71911850208663846c93f80307eb455

10:41 <chewitt> which I copied from some files that some Amlogic user shared with me

10:41 <chewitt> and I cleaned up a little to pass checkpatch

10:43 <chewitt> in my original commit I have clearly noted that the GPL license needs to be confirmed; because the original sources don't have any mention of licensing

10:43 <chewitt> but .. to compile/test it in the kernel you need some of that boilerplate

10:44 <apritzel> chewitt: that's a good start, but what worries me are the parts that reach into the stmmac and generic phy_device code

10:44 <chewitt> as provenance is questionable (and nobody at Maxio that I can find emails for responded to my Q's) adding support to the realtek driver would be a great move

10:45 <chewitt> for context .. I have limited coding skills so beyond fixing a couple of simple checkpatch issues I've made zero attempt to clean anything up

10:47 <apritzel> because they look like they would break abstraction, and the #ifdef in phy_device.c looks definitely wrong. That would mean that the design of the driver is not quite right

10:48 <chewitt> I'm fairly sure the driver code I was given came from a vendor BSP code drop, so there's probably multiple kernel crimes committed

10:49 <chewitt> it probably went from the "look mom it works!" stage straight to "shipped to customer" :)

10:50 <chewitt> it might be interesting to have a Mandarin speaker email the original author

10:51 <chewitt> no guarantees he's still there, but might get more success

10:56 <chewitt> I'll have a polite word with @smp79 about not removing license comments and patch attribution in the future

11:17 <BroderTuck> So yeah, getting this into proper mainlining shape isn't gonna be easy, I'm most likely not gonna attempt it myself anyway.

22:24 <tokyovigilante> loki666: thanks, do you think it can be adapted or should we reconsider one of the existing ones?

22:25 <tokyovigilante> jernej: thanks I appreciate it

22:26 <Jookia> i realized i can just use another git worktree and buildroot dir for mainlining efforts... that's going to be so much easier than having to context switch