04:35 <wens> not getting the per-port muxes discussion

04:54 <Jookia> wens: do you mean the T113 discussion?

05:56 <wens> Jookia: the one Robot_ started

05:56 <Jookia> Ah ok, nevermind :)

07:15 <tokyovigilante> macromorgan: apritzel: can I ask if either of you have seen or better yet had a solution for the AXP717 not being entirely reset after a power cycle? Have had some testing of a mainline-based firmware and this was a chief complaint, that they had to disassemble their devices to pull the battery before the vendor BSP would boot after running a current u-boot build

09:08 <apritzel> wens: the per-port mux discussion is about U-Boot, where we have a much simpler, though limited approach for holding the mux values for each function

09:09 <apritzel> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pinctrl/sunxi/pinctrl-sunxi.c?ref_type=heads#L16-29

09:10 <apritzel> tokyovigilante: at the moment I don't think anyone *resets* the AXP at all

09:10 <apritzel> tokyovigilante: are you saying the the BSP code seems to rely on certain conditions, which are not met after mainline firmware ran?

09:12 <tokyovigilante> thanks, probably just a vendor driver bug then. Yeah that seems to be the case. I have noticed on reboot however (not a hard power cut) that I do get the "failed to set CPU voltage" message, but the kernel is able to boot subsequently. Even more orthogonally I am occasionally seeing a DRAM size misdetection on reboot, but have not seen it on cold boot since pulling in jernej's latest DRAM fixes

09:19 <apritzel> tokyovigilante: "failed to set CPU voltage" probably also means failing to set the DRAM voltage. After a warm boot that should be correct already, though

09:20 <apritzel> we could think about introducing a PMIC reset in the SPL code, just before we set up any voltages

09:21 <apritzel> that's about the only place we can do this, though, as otherwise we would lose some essential rails, like the DRAM

09:41 <tokyovigilante> thanks, will have a look. Other fish to fry but would be a good QoL improvement

09:44 <apritzel> tokyovigilante: "failed to set CPU voltage" should be less of a problem now, with DVFS support in the kernel. Without that the CPU frequency was fixed to 408 MHz

09:56 <apritzel> wens: has it been discussed before to put the RSB bus devices back into I2C mode in sunxi_rsb_remove()? So to undo the action of sunxi_rsb_init_device_mode()?

09:56 <apritzel> I think that should solve that problem, at least on an orderly reboot

10:00 <tokyovigilante> apritzel: yup it doesn't seem to trouble linux at all

12:55 <wens> apritzel: Oh, U-boot, that explains a lot :)

12:55 <wens> apritzel: it was unknown if devices could be put back into I2C mode at all, especially if multiple devices were on the bus

12:57 <apritzel> wens: it seems to work at least for the recent PMICs that we support in TF-A - we do this "reset-to-I2C" there already

12:59 <apritzel> wens: U-Boot pinctrl> yeah, U-Boot is always fun, though it's actually quite a feat to condense those ridiculously elaborate tables of all Linux pinctrl drivers into one 26KB source file

13:36 <wens> I'd say give it a try? the RSB bus driver is kind of lacking

14:29 <wens> https://www.cnx-software.com/2024/07/02/allwinner-t527-digital-signage-and-smart-display-board-offers-hdmi-edp-mipi-dsi-and-lvds-display-interfaces/

20:21 <tokyovigilante> thanks apritzel and wens, although I see macromorgan has just sent a patch changing the RG35XX devices over to I2C, which probably resolves the issue from a different angle, as the PMIC will be in I2C mode regardless. if that is the preferred approach I will test and feed back hopefully today.

20:35 <macromorgan> tokyovigilante: are you able to get i2c working in U-Boot on the r_i2c bus?

20:36 <macromorgan> basically do things like i2c dev 0 (or whatever the rsb bus is), then i2c probe?

20:42 <tokyovigilante> sorry I2C or RSB? we configure DCDC1 and DCDC2 via I2C (by direct bitbanging in SPL) but that’s really

20:43 <tokyovigilante> just to get DRAM to 1.1v for boot, then Linux uses RSB currently. I could get responses from the chip when I was directly writing to the 0x34 register though.

20:43 <tokyovigilante> are you thinking of device detection in u-boot?

20:54 <macromorgan> yes, I'm working on U-Boot now. I'm trying to get 1 device first, then I can start the detection code

20:55 <macromorgan> problem is I can't get i2c working in either SPL or proper U-Boot

20:55 <macromorgan> I'm not getting acks according to the status from the i2c bus register

21:49 <apritzel> macromorgan: I still find this very odd, can you share some (ideally minimal) branch somewhere?

21:50 <macromorgan> let me double check all my patches... I think I left off last week rebasing on as close to mainline as possible, so let me restart there again

21:51 <macromorgan> I'll put together a patch series