08:26 <loki666> Can I help any of the pending patch series with a Tested-by?

08:28 <loki666> I saw tokyovigilante patch, but I think it still too soon for that

08:30 <loki666> I can test macromorgan patches, but I feel it will also need a V2

08:31 <loki666> apritzel iommu patch?

08:58 <apritzel_> loki666: any public feedback is useful, really. And be it to show that people are interested in those features, and it's not just some box-ticking exercise

09:51 <loki666> Ok, I'll just need a simple test case (something to actually run the code) to validate that it works

09:54 <apritzel_> loki666: if you could test tokyovigilante's DE33 patches, that would be very useful. Try to apply them on top of current mainline, then add as much LCD code on top as you need

09:54 <apritzel_> I haven't checked, but I'd assume that tokyovigilante's branch is still based on an earlier version of the DE33 patches?

09:55 <apritzel_> so it would be good to go as close to mainline with this as possible, just add enough of the rest to actually see a picture

09:56 <apritzel_> and maybe add in the iommu code here as well, I think the DE references that as well?

09:57 <apritzel_> another thing you could test are the crypto patches I sent: https://lore.kernel.org/linux-sunxi/20240616220719.26641-1-andre.przywara@arm.com/T/#t

10:31 <tokyovigilante> My branch is still against 6.10-rc2, and I generally try to go back to as close to mainline as possible when preparing a patch for submission, rather than have a pile of out of tree code underneath (I do have most of the pending AXP patches applied, and the IOMMUv2 patches).

10:32 <tokyovigilante> apritzel: I'll give the crypto patches a try tomorrow, I also want to go back to the audio codec driver while I wait for DE feedback, and I have some deferred userspace work to catch up on.

10:33 <tokyovigilante> I see Lee has merged the cpufreq bin for the H700, hopefully the DT patches will also get acked presently.

10:39 <tokyovigilante> I have got the LCD patches squashed on top for testing, so if you build 35e2be56 from my de33-mainline-v1 branch you should get a display

10:52 <loki666> Ok I'll hack this over the weekend

10:53 <apritzel_> tokyovigilante: ah, very good, thanks for the update

16:58 <apritzel_> wens: many thanks for the reviews, much appreciated!

17:34 <macromorgan> yeah, going to do a V2 but so far I don't expect any major changes. That of course may change if someone finds a bug or an issue with the way I am doing things currently. So far I just need to fix a few macros for creating MFD cells and update the DT YAML doc commit message.

20:35 <loki666> macromorgan: ok, what would be a valid test ?

20:36 <macromorgan> does the battery percentage show correct, does the online/present values reflect reality, do the input current/input voltage look correct

20:36 <macromorgan> honestly since I refactored so much a good test case would be "it doesn't break on this other board that previously worked"

20:37 <loki666> arf, that would be difficult, as I only own a rg35xx-h

20:53 <loki666> apritzel, tokyovigilante: https://pastebin.com/FSeUwNbm this is 6.10rc4 + axp717 missing irq + v2 iommu + de33 + gpadc + tokyovigilante LCD patch

20:54 <loki666> I don't see sun8i-mixer 1100000.mixer: Adding to iommu group 0

20:55 <loki666> and lcd screen is dead

20:58 <macromorgan> apritzel: I'm working on the U-Boot stuff now, and was curious... I loaded the 6 patch series for the axp driver changes for SPL, and I'm getting this error now when compiling the axp_spl.c file: error: unknown type name ‘u8’

20:58 <macromorgan> I feel like the compiler should know what a u8 is...

20:59 <macromorgan> I can bypass it, I just didn't know if you have seen that before

21:11 <apritzel> macromorgan: there was a hiccup in the U-Boot tree, with common.h first removed, then brought back

21:12 <apritzel> u8 is a Linux invention, not endorsed by the C standard, so you need some custom header for that

21:13 <apritzel> stdint.h gives you uint8_t and friends, but you need linux/types.h for the shorter versions

21:15 <apritzel> so you need to include the latter in axp_spl.c

21:15 <macromorgan> okay... I got around it by defining it myself in a header, but that'll just be an ugly patch for now

21:15 <macromorgan> I'm trying to build U-Boot with an upstream device tree currently

21:15 <apritzel> what's the difference?

21:16 <apritzel> do you mean using the dts/upstream directory?

21:32 <macromorgan> yes, I'm going to set the CONFIG_OF_UPSTREAM=y and work from there

21:32 <macromorgan> Have U-Boot "loading" so far, looks like I have some bugs to work out: https://paste.debian.net/1321105/

21:32 <macromorgan> this is using the mainline tree

21:33 <macromorgan> I'm hopeful I can include 5 of the necessary trees in CONFIG_OF_LIST and then set the correct one at runtime

21:33 <macromorgan> trying to get it set up properly for my board first, then I'll work on the runtime detection code

21:34 <apritzel> there should basically no different between OF_UPSTREAM and the classic way, since we sync the DT files manually for years now

21:34 <apritzel> in fact atm the "upstream" tree is lagging behind, because the sync policy is *very* conservative

21:34 <macromorgan> right

21:34 <macromorgan> I'm copying the upstream tree in there currently, in fact

21:34 <apritzel> that's the main reason I didn't switch over yet

21:35 <apritzel> so I don't see the point, really, it would actually hold us back, since for instance we don't get the RG35xx .dts files quickly enough

21:36 <apritzel> I think the next sync would be merging in v6.9 in a few weeks (around the U-Boot merge window)

21:47 <macromorgan> okay... I'll probably do it with a U-Boot specific tree first and move forward from there.

22:54 <tokyovigilante> loki666: probably missing the IOMMU kconfig? you don’t have the first two init lines either. no drm bring up either

23:43 <Jookia> has anyone use linuxboot instead of u-boot second stage? ie SPL -> Linux kernel?

23:45 <Jookia> i imagine on the t113 it wouldn't work as there's no psci then :(