09:33 <apritzel> tokyovigilante: just a heads up: please hold back with a v3 of the DE33 series for now, I am still in the middle of looking at the patches in anger

09:34 <apritzel> there is no rush anyway, I'd wait till after -rc1 is out

09:37 <apritzel> if anyone wants to help: we could use some regression testing on V3s, H3, R40, A64, H5, H6, D1

09:49 <gamiee> apritzel: what needs to be tested? Can do on H3.

09:50 <apritzel> gamiee: any graphics related stuff, it's tokyovigilante's and jernej's DE33 support series, which has quite some refactoring patches

09:51 <apritzel> so normal graphics output, plus something exercising the video "overlay" path

09:52 <apritzel> https://lore.kernel.org/linux-sunxi/20240703105454.41254-1-ryan@testtoast.com/T/#t

10:05 <tokyovigilante> apritzel: no worries, thanks, have just tidied the feedback I've gotten so far.

10:05 <tokyovigilante> sure yeah. Ideally the TCON work will be easier on top, that is much less new code and mostly DT

14:35 <macromorgan> I've been able to rule out anything in A-TF causing problems with i2c on the r_i2c bus as well as pinctrl stuff. That really only leaves the possibility for a clock problem or a power domain, right?

14:39 <macromorgan> are there any docs on the PRCM registers perhaps? I'm curious if there's anything in there clock wise that could be off.

14:40 <apritzel> macromorgan: I am still puzzled, the i2c command worked for me like a charm on mainline and the OPi Zero3 (which also uses I2C for PMIC communication)

14:40 <apritzel> I still have to try your branch, though

14:40 <macromorgan> on the r_i2c bus?

14:40 <macromorgan> so far all I've done is change some RAM init stuff

14:41 <macromorgan> I wonder if there's slight differences for the H700... but if there was it seems like we'd have seen it in the Linux driver

14:41 <macromorgan> I can use i2c just fine on the non r_i2c bus

14:41 <apritzel> yes, R_I2C. And yeah, I browsed over the changes quickly, but nothing caught my eye

14:41 <macromorgan> then I wonder what the hell am I doing wrong

14:53 <macromorgan> just reset the device (hard) and now it's working... what, the, f

14:56 <macromorgan> note that holding down the power button wasn't good enough, I had to actually yank the battery... and now r_i2c is working?

15:02 <apritzel> do you need the internal pull ups configured for the I2C pins?

15:04 <apritzel> b/c RSB is push/pull ...

15:06 <macromorgan> I set them and it made no difference, but then I removed all power and disconnected the battery and all of a sudden i2c mode started working...

15:08 <macromorgan> and since the device is supposed to reset into i2c mode by default, it makes me think that something was never fully resetting/powering it down?

15:10 <apritzel> you mean the PMIC stayed in RSB mode all of the time?

15:13 <apritzel> but I remember U-Boot's i2c command being touchy at times

15:14 <apritzel> for instance I also saw: "Error reading the chip: 37812248" (or 40957960) when trying it right now, but now it works

15:16 <apritzel> but adding "bias-pull-up;" to the r_i2c_pins DT node seems to improve things

15:18 <apritzel> => i2c md 36 3 1 -> 0003: 4b K

15:23 <macromorgan> I temporarily added a few routines of sunxi_gpio_set_pull(SUNXI_GPL(0), SUNXI_GPIO_PULL_DISABLE) and sunxi_gpio_set_drv(SUNXI_GPL(0), 1) to both pins (matching the BSP DT) to no avail

15:23 <macromorgan> but when I did the hard reset it started to work, go figure

15:26 <apritzel> macromorgan: U-Boot proper looks at the DT for setting up the pins, so bias-pull-up should do the trick, it seems to make the difference to me (tried twice now)

15:26 <macromorgan> okay, I can add it

15:27 <macromorgan> should we add it to the main linux tree too?

15:30 <apritzel> yes, but only to board .dts

15:30 <macromorgan> okay

15:31 <macromorgan> so when I write a 1 to register 0x27 the device shuts down (as expected) but when I press power to turn it back on it ignores the mmc and goes straight to FEL mode

16:07 <macromorgan> what's the proper way to add board specific code in U-Boot. It looks like for sunxi we don't specify a board per-se, just a device tree file. Is that correct?

16:08 <macromorgan> now that I have i2c working I want to start on board detection code

16:15 <apritzel> macromorgan: yes, sunxi does not support that somewhat dated concept of specific per-board code. For board detection, get inspiration from board_fit_config_name_match() in board/sunxi/board.c

16:17 <apritzel> this is SPL code, which is the best place to choose between DTs. In U-Boot proper it's somewhat too late, actually

16:18 <apritzel> I see that it sounds a bit over the top to pack five full DTBs in the FIT image, but that would work nicely already, without too many hacks

16:18 <macromorgan> I see that... I think I can figure it out

16:19 <macromorgan> would it be bad to still have a file in board/anbernic_rg35xx_h700 that does the actual detection? I'm thinking of changing that function in sunxi/board.c to a weak one and defining my own.

16:19 <macromorgan> basically I need to query MULTIPLE things to do proper board detection rather than just a simple GPIO pin or something

16:20 <macromorgan> I need to at a minimum probe for stuff on the i2c bus and check at least 1 GPIO... depending upon whether or not I can check a GPIO for the mmc1 slot or I have to resort to probing that might complicate things further

16:20 <macromorgan> so seperate file is to keep from blowing up the board.c anymore than it already is

16:28 <apritzel> having a separate directory in board/ will simply not work, but you can have a separate file in board/sunxi, see chip.c

17:23 <macromorgan> okay, I can do that then

17:24 <macromorgan> also, on that note do you know if any non-chip boards use the DIP scan? I'm wondering if it should just be an allwinner specific option (I see it all the time when I'm working on rockchip stuff)?

17:41 <macromorgan> can I add a new function to sunxi_image.h or some other header file? Or do I have to create a new one just for board detection?

17:45 <macromorgan> basically just now trying to figure out what function to make and where to stick it so it can be called by board_fit_config_name_match()

19:49 <apritzel> macromorgan: use an extra header file in board/sunxi/, and use #include "yourn"

19:50 <apritzel> ... #include <yourname.h>

19:51 <apritzel> and while you are at it, move the PinePhone and Pine64 DT parts also in that new file, so it doesn't feel too special

19:55 <apritzel> macromorgan: regarding CHIP_DIP_SCAN> this looks like accidentally outside of the "if ARCH_SUNXI" guard?

22:36 <macromorgan> okay will do, I'll also fix the CHIP DIP stuff and yes it'

22:36 <macromorgan> it's outside of that guard

22:39 <macromorgan> https://pasteboard.co/wHKJavVK3HPj.png

22:41 <macromorgan> (always thought it was funny because I did do work on the CHIP and at first wondered if something I did in my tree caused it to appear everywhere)

22:41 <macromorgan> unlreated topic, but I really need to rebase and resend my patches for slc-mode again to mainline U-boot

23:49 <tokyovigilante> macromorgan: just as an additional note, I think all the boot/reboot issues are because we don't reset the PMIC to I2C signalling after using RSB for the kernel. If we are adding custom detection code to the SPL, then the full logic could/should be: 1. reset/set AXP to I2C signalling in SPL (set register 0x3e to 00h), 2. Configure DCDC1 and DCDC2 in SPL as currently with I2C, 3. Do device detection with I2C and GPIO as needed,

23:49 <tokyovigilante> then 4. hand off to u-boot to boot with the DT (and RSB configuration will then work

23:50 <tokyovigilante> I might just try positively configuring for I2C in the AXP driver in my u-boot branch (maybe we shoud do that anyway as we are unconditionally using I2C in SPL)?