2024-10-25

<apritzel> I wonder if these are separate issues: if the board is designed to use RSB, which is push-pull, it probably doesn't have pull-up resistors on those pins
<loki666> and these cpufreq issues, happened when PMIC was addressed over rsb bus alos

2024-09-30

<loki666> it works with pmic on rsb
<loki666> I'll try to switch to rsb

2024-07-31

<macromorgan> yeah, that one should be good to go. Again the only holdup was waiting for more testing on the switch from rsb to i2c
<macromorgan> yes, I think they just wanted more testing on the switch from rsb to i2c

2024-07-30

<junari> I already did this. This is one of the reasons why I want to move from rsb to i2c
<macromorgan> I think you have to unplug the battery completely when you jump between rsb and i2c
<junari> hmm, when I change rsb to i2c in device tree (both u-boot and kernel) kernle doesn't boot anymore

2024-07-29

<junari> Is it because of different interfaces? Something like rsb in mainline and i2c in stock?

2024-07-23

<loki666> CONFIG_MFD_AXP20X_RSB=y
<loki666> wasn't there a change to use i2c instead of rsb for the pmic, but I don't think it landed .07 yet

2024-07-06

<apritzel> I have no idea, really. I heard arguments that RSB would enable faster switching, but have no idea if that really matters
<tokyovigilante> is there value in using RSB after boot, then resetting to I2C on shutdown? Wouldn't be robust to a kernel panic or other unclean shutdown (but cutting power does reset)
<apritzel> regardless we probably should have code in Linux to reset the PMIC back to I2C, in sunxi_rsb_remove(), but that would assume we always go through that, with an orderly reset
<apritzel> IIRC RSB is faster (3 MHz instead of 100 or 400 KHz), which doesn't strike me as a big advantage, though you can do power transitions faster
<apritzel> and given that I don't think the advantages of RSB are really a win
<tokyovigilante> Ah right, so there is no way to reset the device out of RSB mode without using RSB?
<apritzel> you mean to the RSB controller? for that this must be set up (clocks, reset, pin mux)
<tokyovigilante> 0x68 is the I2C bus, 0x3a3 is RSB, but 0x3e is a separate register to select which is active
<apritzel> put you would need to do this reset in RSB mode ...
<tokyovigilante> true, if we are all happy to use I2C, I had an idea that RSB had some technical advantages, and if we can do detection at boot in SPL where we are unconditionally using I2C, then that would be a win-win
<apritzel> ... which would all be nicely solved by not using RSB at all
<tokyovigilante> it is, but IMO not actually required, if we just do the detection over I2C in SPL we are free to use RSB elsewhere, and reboot is currently broken anyway, because the SPL is unconditionally trying to use I2C to configure the chip when it is set to RSB signalling
<apritzel> isn't macromorgan's plan to ditch RSB for all devices completely?

2024-07-05

<tokyovigilante> then 4. hand off to u-boot to boot with the DT (and RSB configuration will then work
<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,
<apritzel> you mean the PMIC stayed in RSB mode all of the time?
<apritzel> b/c RSB is push/pull ...

2024-07-02

<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.
<tokyovigilante> sorry I2C or RSB? we configure DCDC1 and DCDC2 via I2C (by direct bitbanging in SPL) but that’s really
<macromorgan> basically do things like i2c dev 0 (or whatever the rsb bus is), then i2c probe?
<wens> I'd say give it a try? the RSB bus driver is kind of lacking
<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()?

2024-06-27

<apritzel> macromorgan: the AXP305 used on the OPi Zero2 can do both, I believe all RSB PMICs also speak I2C
<macromorgan> orange pi zero 2 is using RSB not i2c as best I can tell, at least per the device tree

2024-06-26

<apritzel> in the SPL. The OPi Zero2 uses RSB later on (in TF-A, U-Boot proper and Linux), but the OrangePi Zero3 uses R_I2C all around, because the AXP313 does not support RSB

2024-06-24

<apritzel> so one possible problem resulting in "Failed to set core voltage" is that the PMIC is still in RSB state, so talking to it via I2C doesn't work

2024-06-07

<apritzel> you need: "case 0x3a3: return 0x2d;" just before the existing case in get_rsb_rt_address()
<apritzel> (sorry,I forgot that the AXP717 uses a different RSB address than the AXP305)
<tokyovigilante> maybe, you need the AXP RSB driver, that’s the bus the PMIC communicates over, if that’s not working it can’t set correct voltages and will not boot
<loki666> ERROR: PMIC: no mapping for RSB address 0x3a3
<tokyovigilante> [ 2.328067] axp20x-rsb sunxi-rsb-3a3: Failed to ack 0x49: -5
<apritzel> macromorgan (and tokyovigilante): I reworked the H616 PMIC TF-A patches, so they pick the bus type (I2C or RSB) from the DT. That should fix the Anbernic devices with the RTC

2024-06-04

<macromorgan> sorry... been busy but want to respond to the RTC question. We have 5 total devices (the 35XX+, the 35XXH, the 35XX-2024, the 28XX, and the 35XXSP). The 35XXSP and 28XX appear to have the external RTC, the other 3 devices do not. I was proposing we switch all 5 to the I2C bus from the RSB bus so they're more or less homogenous. That way we can use the RTC on the 2 devices that do and keep all 5 of them more or less the same.

2024-06-02

<apritzel_> and RSB seems to be an Allwinner/X-Powers invention that's only used with their AXP PMICs
<apritzel_> but: "our code has issues when using RSB" is not an argument ;-)
<apritzel_> macromorgan: if the PMIC is the only thing on that bus, we use RSB, that's what Allwinner recommends anyway, and RSB is better in many regards
<macromorgan> unless there is some way to use the RTC via RSB that I'm not aware of
<macromorgan> so how much crap would we stir if we changed the Anbernic's PMIC from the RSB bus to the I2C bus (in both U-Boot and Linux, but especially U-Boot)?

2024-05-09

<macromorgan> `regulator list` in U-Boot doesn't show anything unless I enable the rsb driver, which requires setting SUNXI_RSB_BASE (in cpu_sun50i_h6.h) as well as bypassing prcm_apb0_enable() with an ifdef in sun8i_rsb.c

2024-05-08

<apritzel> macromorgan: not sure I follow: it should be triggered by its compatible name, you just need to enable the driver (CONFIG_SYS_I2C_SUN8I_RSB)
<macromorgan> right but the RSB driver needs to be set up
<apritzel> macromorgan: in U-Boot proper? That should be taken care of: the RSB driver enables the clock references in the DT
<macromorgan> so for the rsb bus we need the abp2 clock (looking at u-boot), or do we assume by the time we're working it's already set up?

2024-04-27

<apritzel> (ohci and pio before r_rsb)

2024-04-17

<apritzel> in general addressing DT children is the responsibility of the DT parent device, and some devices might use a very specific and different addressing (like I2C or RSB), compared to all those MMIO mapped devices
<apritzel> and the AXP regulator node itself needs to be inside the RSB node, since only that driver knows how to access the AXP registers (via the RSB bus)

2024-03-23

<tokyovigilante> TF-A code looks good apritzel: INFO: Probing for PMIC on RSB:

2024-03-12

<apritzel> that actually makes sense (PMIC is still in RSB mode, SPL tries I2C), though I thought we fixed that, in Linux

2024-03-11

<apritzel> You can try to skip the whole TF-A PMIC code, by hacking this: if you put "return 0;" just before the rsb_init() call in TF-A's plat/allwinner/sun50i_h616/sunxi_power.c
<apritzel> macromorgan: this frequency setting is a known issue, because of the AXP being driven via RSB in Linux and TF-A and I2C in the SPL

2024-03-08

<tokyovigilante> that's with skipping rsb_init in TF-A
<apritzel> or actually this might not help, because in case of a reboot I think it's the kernel leaving the PMIC in RSB?
<apritzel> tokyovigilante: also, as a hack, if you put "return 0;" just before the rsb_init() call in TF-A's plat/allwinner/sun50i_h616/sunxi_power.c, that might avoid the message and thus the slow frequency

2024-03-04

<tokyovigilante> I did see it trying RSB access
<jernej> Issue is that TF-A switches PMIC to RSB bus, but switches back to I2C only if everything goes right.

2024-02-14

<apritzel> it's needed anyway, because the AXP313 is I2C only, while we address the AXP805 via RSB

2024-01-31

<apritzel> btw this shows some other issue: you don't list CONFIG_MFD_AXP20X_RSB in your list, but pretty sure that's needed for the Teres-I?

2023-11-26

<apritzel> only that the current H616 TF-A code is married to the AXP305 via RSB, so it doesn't work on devices using the AXP313 (which are also using I2C only)

2023-08-14

<paulk> are there known issues with rsb?
<paulk> hi just got an orange pi one plus (h6) and u-boot/atf/linux cannot manage to talk to the pmic (rsb errors)

2023-07-14

<megi> but I don't see any changes in RSB driver

2023-02-13

<apritzel> jernej: the TF-A RSB DT patch has finally reached the master branch

2023-02-04

<MoeIcenowy> As this port is officially an I2C instead of RSB, maybe we shouldn't run any frequency higher than 400kHz
<MoeIcenowy> jernej: my RP-H6C does have good routing for RSB too
<jernej> which means RSB speed should be read from DT in such case
<jernej> apritzel: I noticed another potential issue. It's very possible that OrangePi 3 LTS board will have lower RSB speed, since due to trace routing, it doesn't allow for 3 MHz.

2023-02-01

<apritzel> well, no, but we were driving the I2C bus with both RSB frequency and RSB signals
<apritzel> jernej: just realised that we were cheating all the time on the PineH64: the RSB node is disabled there (because of that extra I2C RTC), but we were still using it
<jernej> what about fdt_path_offset()? it could be used to check if path exists and only two are needed, i2c and rsb
<apritzel> I guess I2C would somehow fail if there is no device (SDA/SCL floating), but maybe this I2C wrapper command in the RSB hardware cannot deal with this gracefully?

2023-01-10

<apritzel> you can do this via FEL, but it requires a sequence of writel's to talk to the RSB controller
<evadot> but iirc some node are now handled by this firmware (like rsb or something like that) so that might causes problem on FreeBSD (but I'm unsure since I've never tested)

2023-01-06

<MoeIcenowy> apritzel: in addition AXP288 does not claim RSB at all, only AXP

2023-01-02

<smaeul> I don't see any problem with that. RSB at 100 kHz is still nicer than I2C in terms of CPU-side overhead
<smaeul> yeah, I think Icenowy reported another H6 board that couldn't do normal RSB speeds.
<jernej> even though RSB node has "clock-frequency = <3000000>;"
<jernej> smaeul: I'm looking into OrangePi 3 LTS support and I noticed that AXP driver doesn't work under Linux. I suspect this is due to overclocked RSB bus: "sunxi-rsb 7083000.rsb: RSB running at 4000000 Hz"

2022-12-23

<junari> Yes, it was because the AT-F switches pmic to rsb mode or something else ...

2022-12-02

<apritzel> mmh, weird, I can't seem to write to the RSB register, though reading works
<apritzel> RSB is an Allwinner invention, just to talk to their AXP chips
<apritzel> there is only one RSB controller, only on those PL pins
<dikiy> apritzel: and on the RSB bus, there are only this controller or other too?
<apritzel> dikiy: on the A64 RSB is at 0x01F03400
<apritzel> I actually wrote that to talk to the RSB from Linux, in the early A64 days ;-)
<dikiy> karlp: yes, but I didnt give an importnce, as I though "who the hell would use RSB if there is a cooomon I2c available" xD
<apritzel> karlp: also RSB is much more fire-and-forget, so it's simpler to just program a command into the controller, and then it does the rest automatically
<karlp> ahh, rsb is push pull.
<apritzel> also RSB is much faster (3MHz) than I2C (100KHz), so you can send commands more quickly
<apritzel> you can talk to the RSB controller via /dev/mem, the register sequence to send an RSB command is simpler than via (the Allwinner implementation of) I2C
<apritzel> but we initialise the AXP to speak RSB
<apritzel> but we initialise the RSB to speak RSB
<apritzel> dikiy: it's both, actually. The AXP speaks both protocols, and those pins are muxed to both the RSB and an I2C controller
<karlp> not sure what userspace handles RSB though.

2022-11-24

<smaeul> but that may cause problems with boards having non-PMIC peripherals on that bus -- would the RTC still handled the "noise" from 100 kHz RSB?
<smaeul> we already switch the PMIC back to I2C mode, so the easiest solution would be to reduce the frequency but keep using RSB
<MoeIcenowy> I2C sounds a good fallback, but it could not cooperate with PMICs already set to RSB
<smaeul> there may not be space to put both I2C and RSB drivers in TF-A
<MoeIcenowy> I just think using RSB not so appropriate, I don't know whether it works or not in real life
<MoeIcenowy> well the RP-H6 issue is just a bus not capable of 3MHz RSB
<MoeIcenowy> e.g. using RSB is not a good idea on the shared bus of Pine H64
<apritzel> I think we need to do something there anyways, IIRC there was some reboot problem with some SoC, because of RSB vs. I2C?
<MoeIcenowy> because H6 does not officially has RSB
<MoeIcenowy> BTW should we lower the H6 ATF RSB frequency to 100k?
<MoeIcenowy> so it may just left the PMIC in RSB mode
<MoeIcenowy> ATF says `ERROR:   RSB: read command: 0x103`
<apritzel> MoeIcenowy: Does I2C work, to talk to the AXP? Or can you tune down the RSB frequency to something stable?
<MoeIcenowy> apritzel: got a weird H6 board that its RSB cannot run at 3MHz

2022-06-06

<jernej> supposedly AXP806 works only on I2C bus, but not RSB

2022-03-17

<smaeul> what ABI breaks are you concerned about? r_intc, H6 RSB, anything else?

2022-03-16

<jernej> apritzel: most RSB interactions seem to break boot
<jernej> apritzel: if I comment out rsb_* functions, it continues
<apritzel> the next ERROR message would be the timeout from drivers/allwinner/sunxi_rsb.c:rsb_wait_bit()
<apritzel> jernej: are the RSB pins connected to something else?

2021-12-29

<apritzel> there is a lot of refactoring, significant changes in how we do core power management, using RSB for talking to the PMIC, enabling the SCP, and enabling a Cortex-A53 erratum workaround (1530924)

2021-11-04

<smaeul> jernej: I guess I was trying to be too clever with the RSB code. maybe changing it to `if (!pm_runtime_status_suspended(rsb->dev)) clk_disable_unprepare(rsb->clk);` would be ideal
<jernej> however, if sunxi_rsb_hw_exit() is called first and pm_runtime_disable() after that, all is well
<jernej> apritzel: smaeul: it looks like power management in RSB bus driver is wrong. From what I figured, you can't resume already disabled "PM runtime", even if it is suspended.
<jernej> which is weird, because pm_runtime_resume(rsb->dev) is supposed to do just that
<jernej> apritzel: r-apb2-rsb warning issue can be bypassed by changing this line https://elixir.bootlin.com/linux/latest/source/drivers/bus/sunxi-rsb.c#L692 to clk_prepare_enable(rsb->clk);

2021-11-03

<jernej> r-apb2-rsb already disabled

2021-10-11

<smaeul> a faster way to get RSB working would be to patch the non-DM clock/pin setup for A64
<smaeul> well, after this series, the r_ccu driver, and the pinctrl series, it would be one extra patch to hook up DM clocks/resets for RSB
<smaeul> ("Select SUN8I_RSB more carefully")... might as well do the same thing everywhere
<smaeul> ironically, 2 of 3 A80 defconfigs *don't* use RSB
<smaeul> well tbh I consider `select SYS_I2C_SUN8I_RSB` itself to be a hack, which I only did to avoid needing defconfig updates
<smaeul> one solution would be to downgrade the `select SYS_I2C_SUN8I_RSB` to an imply

2021-10-09

<smaeul> so anything with a PMIC and not P2WI or RSB

2021-07-02

<jernej> it's like sunxi_rsb_hw_exit() is called 2 times
<jernej> apritzel, smaeul: I get warning on X96 (H616) at reboot: "r-apb2-rsb already disabled" and "r-apb2-rsb already unprepared"

2021-06-22

<apritzel> tbh I wrote peekpoke to be able to talk via RSB to the AXP(803), hence all those wait commands ...
<warpme_> ah ok - forgot pmic is communicated via rsb
<jernej> nothing, unless you want to drive RSB manually :)

2021-06-18

<jernej> not sure why RSB wouldn't work on GS1
<jernej> apritzel, smaeul: RSB also uses open-drain driver, right?

2021-05-30

<smaeul> yeah you need at least 5.12 to not break Linux's RSB controller driver after a suspend/resume cycle