16:28 <apritzel> smaeul: do you have anything clean for the D1/R258/NCAT2 pinctrl in U-Boot already?

16:29 <apritzel> smaeul: if not, I would fix this (for R528/T113 support), and move it out of arch/arm/nonsense by the way

16:31 <smaeul> apritzel: nah, I just hacked it in: https://github.com/smaeul/u-boot/commit/ae77de60483aa9be2f513aa3139a28f3e6c59022

16:32 <smaeul> moving GPIO out of arch/arm is on my list, but it's like 10 levels of yaks deep

16:34 <smaeul> I was going to try to remove the non-DM GPIO function calls from drivers, but it turns out that requires 1) adding AXP152 bindings, 2) adding a bunch of panel bindings, and 3) adding PMICs and display pipelines to a bunch of devicetrees

16:34 <apritzel> smaeul: yeah, I saw your hacks, hence the question ;-) I was thinking you have bigger fish to fry, so let me have a look

16:36 <smaeul> oh and of course the DM driver for AXP GPIO depends on DM_PMIC, which depends on DM clocks, which don't work on A31/A23/A33 because of the PRCM MFD mess

16:37 <smaeul> I was in the middle of responding to your comments on my series removing the A31/A23/A33 platform SMP code... so if you're wondering what the _real_ reason is, it's for D1 pinctrl support in U-Boot

16:38 <apritzel> my plan was: move pinmux.c to drivers/pinctrl/sunxi, move asm/arch/gpio.h to something generic, handle the differing offsets via CONFIG_SUNXI_NEW_PINCTRL in pinmux.c

16:43 <smaeul> sounds reasonable. half of asm/arch/gpio.h (like the part that depends on asm/arch/cpu.h) can just stay there

16:47 <smaeul> same thing for pinmux.c -- anything that depends on asm/arch won't be usable on RISC-V. though you should be able to hide the non-bank functions behind ARM && SPL

16:52 <apritzel> asm/arch/gpio.h sounds like a U-Boot anachronism to begin with, and not sure why we include asm/arch/cpu.h in the first place

18:38 <jernej> apritzel, smaeul: if it helps anything, I have a patch for partially converting DE2 and sun8i HDMI driver to DM resets and clocks

18:39 <jernej> partial because there is no infrastructure to calculate factors for whole clock chain

18:39 <jernej> in DM clock driver (right?)

18:40 <smaeul> yes, that certainly helps! right, there is no rate support in the DM clock driver yet

18:40 <jernej> smaeul: take a look at this branch then: https://github.com/jernejsk/u-boot/commits/de2-fixes

18:41 <jernej> some patches are already included upstream, but not last few

18:41 <jernej> mostly because there is missing infrastructure to support two screens in U-Boot

18:46 <jernej> IIRC commit https://github.com/jernejsk/u-boot/commit/2d5caec7d384024f2c3f33a4fed66c9d9b77c4fd breaks video support on A64

18:47 <apritzel> jernej: awesome!

18:47 <jernej> apritzel: I think you should remember these patches, since you did some research why A64 breaks :)

18:47 <apritzel> jernej: yeah, I remember we stopped merging the series at this point back then

18:48 <jernej> but some following patches should still improve situation, at least from DM perspective

18:48 <apritzel> I gracefully forgot the details, but I think it was some U-Boot "speciality", which maybe was fixed meanwhile?

18:50 <jernej> as I said, issue is that U-Boot proper doesn't support more than one screen

18:52 <jernej> anyway, only one patch causes issue (the one mentioned few lines above). Most, if not all, patches following it, is just refactoring to DM clocks/resets and using DT provided information

18:53 <jernej> it would also stop probing HDMI driver on boards where is no HDMI connector

19:11 <apritzel> smaeul: I see now that the GPIO stuff is all very painful in the details, but I will try anyway ...

22:12 <apritzel> smaeul: have you explored what it would take to move (most of?) arch/arm/mach-sunxi/Kconfig into board/sunxi/Kconfig? Are there any pitfalls?

22:23 <smaeul> apritzel: sort of. I tried moving all of the DRAM options to drivers/ram, but that got stuck on DM dependencies

22:24 <smaeul> I think all of the video options belong in drivers/video (well, the ones that don't belong in the devicetree)

22:24 <smaeul> the remainder I put in board/sunxi/Kconfig for D1

22:25 <smaeul> apritzel: the main pitfall is that you can only include board/sunxi/Kconfig from one place

22:26 <smaeul> so I don't think you would want to move the MACH_* options

22:27 <apritzel> did you try drivers/ddr? IIRC, I read on #u-boot the other day that this is meant for legacy (non-DM) DRAM drivers?

22:27 <smaeul> I didn't realize that existed

22:29 <apritzel> and yeah, for video I think we will move completely to DM and DT some day, so it might be worth waiting for that

22:30 <smaeul> to expand a bit on the pitfall: U-Boot includes _all_ architecture Kconfigs, unlike Linux which just includes arch/$ARCH/Kconfig, so you can't include board/sunxi/Kconfig from both arch/arm and arch/riscv. You have to include it from some top-level location and guard it with the ARM/RISC-V symbols

22:30 <smaeul> s/symbols$/platform symbols/

22:33 <apritzel> did you find any precedence of a platform with multiple architectures? I guess U-Boot avoided most of them by merging arm64 and arm ...

22:38 <smaeul> yeah, there are the powerpc->arm transitions

22:44 <apritzel> is asm/arm/cpu.h bothering you? I got somewhere with removing that from sunxi_common.h, and thinking about splitting this up, to smaller headers, just containing the few addresses that the (ARM) SPL needs hardcoded

22:44 <apritzel> asm/arch/cpu.h, I meant

22:46 <apritzel> smaeul: if you haven't guessed yet, my immediate motivation is R528/T113 support, and hoping to pave the way for the D1 on the way

22:48 <apritzel> as supporting both R528 and D1 would force us for instance to embrace the identical memory map/pinctrl/CCU of both, across arch/xxx directories

23:08 <apritzel> smaeul: did you find a nice location for sharing sunxi-specific header files, across arch/xxx ?

23:08 <apritzel> I see include/clk/sunxi.h, I guess this to share structs between clk and reset?

23:09 <apritzel> shall we have a include/sunxi/ directory, and put shared headers in there?

23:10 <apritzel> Or are shared headers (outside of driver subsystems) a sign of bad design, and we should avoid them in the first place?

23:17 <smaeul> apritzel: I don't know of a good place. what kind of header are you sharing?

23:19 <smaeul> > embrace the identical memory map/pinctrl/CCU of both

23:19 <apritzel> well, I guess what we need from arch/arm/include/asm/arch-sunxi? Or are trying to avoid them in the first with DM_SPL?

23:20 <smaeul> that just means reusing compatible strings, right?

23:21 <smaeul> yes, I'm trying to avoid asm/arch entirely

23:21 <apritzel> smaeul: well, I guess I am thinking too much about hardcoded SPL information

23:22 <apritzel> how are you setting up the PLLs and bus clocks? the DT doesn't help here, I guess? Or do you fish just the CCU base address from it?

23:23 <smaeul> right now I don't. but if I did, it would go in the clock driver probe function

23:25 <apritzel> not setting up those clocks in U-Boot at all, you mean? Is that done in OpenSBI or do you just rely on the defaults?

23:27 <smaeul> yes, I mean not setting them up at all. The settings from the BROM last all the way to Linux. But I do plan to add at least CPU clock set up, as the BROM default is ~400 MHz

23:28 <smaeul> so "but when I do" would be a more accurate tone

23:30 <smaeul> The defaults happen to work for RISC-V because the NBROM and SBROM are merged. so the BROM raises the bus and CPU clocks for crypto speed. The defaults from ARM NBROMs are probably worse