01:06 <smaeul> Jacmet: add "thead,c900-plic" as a fallback compatible to the PLIC node in the device tree. the issue is that OpenSBI is using this new compatible (https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd), but the Linux tree is out of date

01:06 <smaeul> I hope to get Linux rebased and pushed again by the end of this week

07:06 <Jacmet> smaeul: ahh, thanks - Will try that!

07:14 <Jacmet> smaeul: hmm, but that opensbi commit is in upstream opensbi, I am using your opensbi branch (d1-wip) as well, which hasn't been updated since August

12:23 <smaeul> Jacmet: the upstream commit is in that branch (https://github.com/smaeul/opensbi/commits/d1-wip). It's been rebased several times, so you probably want to check the commit date (2021-10-20), not the author date (2021-08-08)

12:27 <Jacmet> smaeul: correct, current top is b9125c6f8909d

12:29 <Jacmet> smaeul: I am not sure I get the relation to Linux here, what dtb is opensbi using? The u-boot one in the toc1 file?

12:44 <smaeul> Jacmet: yes, opensbi uses the dtb in the toc1

12:46 <smaeul> ah, I see what you mean. the instructions have the dtb in the toc1 coming from the u-boot build, so yes, you could fix it up there, regardless of Linux

12:59 <Jacmet> ok, thanks

13:53 <Jacmet> smaeul: thanks, it works - The trick is to REPLACE the existing sifive,plic-1.0.0 entry and not just append thead,c900-plic to it as opensbi looks for sifive first (and u-boot doesn't care)

14:03 <apritzel> Jacmet: that sounds like an OpenSBI bug then? It should adhere to the proper semantics of compatible fallback strings?

14:17 <Jacmet> apritzel: arguable yes, but this is largely libfdt code so U-Boot /Linux probably behaves the same?

14:19 <apritzel> well, maybe the *order* of the calls is wrong, then? So if the THead PLIC needs a quirk, it should be searched for first, and only then it should look for the SiFive PLIC?

14:19 <Jacmet> apritzel: registering the plic driver causes opensbi to call fdt_find_match which calls fdt_node_offset_by_compatible for each compatible of the driver in turn, so the sifive compatible "wins" over the thead one even though the thead compatible is listed before the sifive one in the dts (E.G. it scans in driver compatible order, not in dts compatible order)

14:19 <Jacmet> apritzel: true

14:36 <apritzel> Jacmet: so that part of the PLIC is not architected, hence the need for an implementor specific compatible string?

14:38 <apritzel> What would be the result if the generic sifive code would be used instead? If there is a problem preventing this to work on THead hardware, then using a fallback is not the right solution

14:46 <Jacmet> apritzel: see https://github.com/riscv-software-src/opensbi/commit/78c2b19218bd - The d1 needs to flip a bit to make the plic accessible from S-mode so Linux can use it

14:47 <Jacmet> apritzel: other than that it is afaik compatible with the sifive one

14:48 <apritzel> Jacmet: ah, I see, so that distinction is irrelevant for Linux itself?

14:49 <apritzel> in this case I wouldn't even bother with coding this in the DT, just have that hardcoded in OpenSBI, for the D1

14:49 <Jacmet> apritzel: yes (afaik at least, I'm pretty much a riscv noob)

14:49 <apritzel> or maybe have a DT property noting that, instead of a compatible string

14:50 <Jacmet> apritzel: the conclusion seems to be to simply drop the sifive compatible for Linux: https://lists.infradead.org/pipermail/opensbi/2021-November/002040.html

14:55 <apritzel> so the bit can only be set from M-mode?

15:02 <Jacmet> apritzel: I believe so, I haven't actually seen any of this documented in the D1 user manual

15:03 <apritzel> "documented in the D1 user manual": LOL, welcome to Allwinner

15:05 <Jacmet> yeah ;)

15:14 <apritzel> I guess for those parts they would just refer to the THEAD manuals anyway (and rightfully so), like they do for the ARM GIC

15:59 <jernej> apritzel: did you have time to look into H616 clock issue?

16:01 <apritzel> jernej: no, sorry, "make" wanted to do a full rebuild, for which I didn't have enough patience ;-)

16:06 <jernej> ok

16:19 <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);

16:20 <jernej> which is weird, because pm_runtime_resume(rsb->dev) is supposed to do just that

16:20 <jernej> however, this doesn't resolve reboot issue

16:20 <jernej> so I there must be another issue

16:21 <jernej> not sure if I'll have time to investigate this further today

16:22 <apritzel> jernej: thanks! I will try to remember typing "make" *before* having dinner ;-)

16:23 <jernej> how long does it take on your PC? it's just few minutes for me

16:23 <jernej> or is this too long for you? :)

16:34 <apritzel> jernej: my main machine is a good ol' Thinkpad X230, that takes about 30 minutes for a full build, while screaming loudly. And watching Youtube meanwhile makes it even take longer ;-)

16:35 <jernej> ah :)

16:35 <apritzel> I have other, faster machines around, but syncing trees and the compiled images gets tedious and error prone over time

20:41 <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.

20:42 <jernej> I get -EACCES here: https://elixir.bootlin.com/linux/latest/source/drivers/bus/sunxi-rsb.c#L692

20:45 <jernej> however, if sunxi_rsb_hw_exit() is called first and pm_runtime_disable() after that, all is well

20:46 <jernej> but I don't know if this is acceptable

20:51 <jernej> apritzel: sun8i_dwmac_exit() actually hangs at regulator_disable()

20:55 <jernej> actually, this might be a bit weirder

20:56 <jernej> If I just remove regulator from emac node, it still hangs at reset, even if regulator code is commented out

22:52 <smaeul> apritzel: for the 8211e issue, all that should be needed is a DT sync. I was planning to do that, but the driver change got merged first...

22:55 <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

23:01 <smaeul> Jacmet: it is definitely a bug that opensbi's compatible matching does not follow the order in the DT -- the difference vs Linux/U-Boot is that opensbi is starting with a dirver and trying to find a node; the usual way is to start with a node and try to find a driver

23:15 <apritzel> smaeul: do you know if this PLIC compatible string discussion has settled? If this is a pure firmware quirk to allow access from S-mode, it doesn't sound like compatible string material at all.

23:15 <apritzel> instead it should be quirk property, or even not mentioned in the DT at la

23:15 <apritzel> ... at all, but instead hardcoded in firmware

23:16 <smaeul> apritzel: yes, there are differences visible in S-mode: claiming an IRQ masks it until EOI, which sifive PLIC does not do

23:17 <smaeul> but even if the S-mode behavior was the same, the DT describes the hardware to the M-mode code too, so I would still say it belongs in the DT

23:17 <apritzel> yeah, but I think there is precedence for this being handled in properties

23:18 <apritzel> but actually if it has those incompatible differences, it shouldn't use the fallback at all?

23:18 <smaeul> right, it shouldn't use the fallback

23:20 <smaeul> > add "thead,c900-plic" as a fallback compatible to the PLIC node // here I meant that "thead,c900-plic" should be a fallback for "allwinner,sun20i-d1-plic", not that the sifive,*/riscv,* compatible should be there

23:20 <apritzel> ah, I see

23:27 <smaeul> Jacmet: btw delegation register this is documented in the D1 manual: PLIC_CTRL_REG on page 210

23:28 <smaeul> s/delegation register this/this delegation register/

23:37 <apritzel> jernej: real 32m46.624s ;-)

23:40 <apritzel> smaeul: DT sync for the phy-mode property, you mean? We already have "rgmii-txid" for the Pine64+ in U-Boot

23:41 <smaeul> yes

23:42 <smaeul> hmm, not sure what the issue is with that specific board then. of course we will need phy-mode for a bunch of other boards

23:42 <smaeul> I will try my Pine64+ here

23:57 <apritzel> smaeul: I see the same as Tom here: Pine64+ Ethernet stops working with that 8211e patch