12:08 <warpme> well - it looks like my aic8800 based wifi port from rk world works ok on x96pro+ :-) So now with 6.12.8 on h728 we have working: sd card, usb, eth, wifi, led. For making this box usable headless appliance doing some practical things i miss smp. So what is status/prospects for smp on a523/h728?

14:41 <apritzel> warpme: please be careful on what you say: ... "So now with 6.12.8 *AND A BUNCH OF DODGY (BSP BASED) AND UNREVIEWED PATCHES ON TOP* we have working: ..."

14:42 <apritzel> I hate to say it, but that's basically the same what Allwinner does: take some base kernel and slap their code on top, hacking on it with a jagged axe until it works (TM)

14:44 <apritzel> yes, SD card and USB 2.0(!) work with the patches on the list, but eMMC does not (why?), Wifi is very far from mainline, Ethernet using a different driver is BS (but sound fixable relatively easy)

14:44 <warpme> apritzel : where is issue? in word "we" or in bsp roots of code? To be clear: by saying "we" i was intending to say we as community (as i'm sharing my work so community has my work). Is this problematic in nay way?

14:45 <apritzel> well, it's proliferating dodgy BSP code (Wifi, Ethernet), and that's not helping for mainlining. And it gives the false impression that the work is done, because it's working

14:46 <warpme> well: "not helping for mainlining" - nobody say that i need to go your way of mainlining right? Maybe i have alternative approach to help with mainlining?

14:47 <warpme> and i'll will be careful from now! thx for pointer!

14:48 <apritzel> and I hate this situation where there are dozen of repos out there with people piling up rejected, unreviewed, or even outright wrong patches, all in various states of disrepair

14:48 <apritzel> what's the alternative way?

14:50 <apritzel> to answer your question: I don't know if anyone is looking at TF-A code, I am certainly not at the moment. I am very happy to review and merge patches, though

14:54 <apritzel> to be clear: it's cool to have people that fiddle around with the code, and figure out how to get things to run on a kernel that's closer to mainline than Allwinner's, but sadly it often stops there, and so does not help :-(

15:36 <BroderTuck> apritzel: Sad that there doesn't seem to be many reviews on your A523 patchset(s)

15:41 <apritzel> hint: one does not need to be an expert to do a review (though you might become one in the process)

15:44 <apritzel> I think a lot of the clock driver is pretty schematic, once you wrapped your head around how the macros work. The rest is comparing the values to the CCU section in the manual

15:45 <apritzel> and for motivation: I know of at least two small bugs in that patch already. See if you can find more ...

15:49 <BroderTuck> Speaking of review, I see that Lee Jones had a comment on your revert patch...

16:00 <apritzel> ah, right, thanks for the heads up, need to send this out today, before it's too late

16:02 <dok> hi all, i've sent a patch series to barebox bootloader mailinglist, it adds an initial support for allwinner A64 (Pine64 board)

16:03 <dok> it only works as a second stage, ie still need u-boot for dram and tf-a

16:05 <wens> finally got time to send off the pull requests

16:05 <apritzel> dok: why, exactly? We already have enough to do with U-Boot, and I don't really like diverting developers to other bootloaders

16:05 <dok> well, for fun...

16:22 <BroderTuck> I do see one thing. In ccu-sun50i-h6-r.c in the same directory, the gating macro for the rtc clock doesn't end with 0 but with CLK_IGNORE_UNUSED

16:24 <BroderTuck> (looking at your a523-v1 branch)

16:29 <apritzel> we should not need that on the A523, since we reference this clock in the RTC node in the .dtsi

16:29 <apritzel> this was a later addition to the H6 clock driver, hence this hack: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=38d321b61bda326

16:32 <BroderTuck> Ah, makes sense

16:34 <apritzel> BroderTuck: but good find, keep digging ;-)

20:17 <loki666> apritzel: speaking of dodgy unreviewed patch... https://gist.github.com/loki666/3999223848bf3146a59dd4786a31d2c3 do you think this can be posted ?

20:18 <loki666> I could try with the flag IRQCHIP_MASK_ON_SUSPEND... not sure if it's needed, and even less clue to justify any of the flags

20:19 <loki666> ^without

20:21 <loki666> except that's what the BSP code does :p

20:56 <jernej> anyone here with H616 or alike soc, where DRAM size is occasionally misdetected? If so, please test this patch: https://gist.github.com/jernejsk/648220b08c73ced183eee4d1197d8756

21:13 <loki666> jernej: I will, I have an ungly retry loop until ok

21:15 <loki666> how should I test that, boot 10times hoping there is a diff in detected rows ?

21:21 <jernej> I just put "sunxi-fel spl spl/sunxi-spl.bin" command in a infinite loop, with 1 second delay and looked at console output

21:22 <jernej> I wrote this for T527, since there was misdetection in about 1/20 cases

21:22 <jernej> rare, but still common enough to be annoying

21:34 <apritzel> loki666: ah, yeah, almost forgot about this suspend thing: yes, please post this!

21:34 <apritzel> Don't bother with making the code too perfect, the list will complain (and hopefully explain!) anyway

21:35 <apritzel> so if you are in doubt, just mention it somewhere

21:46 <loki666> jernej: ok I'll try

21:47 <loki666> apritzel: I'll prepare a patch, for the rational... I'll probably check with you before posting

23:17 <loki666> apritzel: should I have the wakeup-source; property in another patch ?

23:37 <apritzel> yes, definitely: DT patches must always be separate from code patches

23:59 <loki666> ok