09:09 <hanetzer> bjdooks: managed to get it workin :)

11:12 <punit> Out of curiosity just checked what DS20L looks like - seems like you'd need an isolated server room to keep the jet engine like exhaust / cooling noise.

11:13 <Xogium> punit: maybe, more scary possibility is, the datacenter runs maz

11:13 <Xogium> ;p

11:16 <punit> hehe

11:18 <Xogium> slightly OT, but what is your take on risc-v ? I wonder how worth it it is... I mean, I have so many boards already in here that I guess the only thing I'd do with a risc-v one would be bring up :D wouldn't have much idea of what to do with it other than this. Also there are probably not that many of them able to run linux, I think I only saw maybe 2 or 3

11:18 <Xogium> I meant this as a general question btw not just punit

11:25 <psydroid> everything that works on arm should work on risc-v too

11:25 <psydroid> at least eventually

11:25 <hanetzer> hrm. so the sd/mmc controller on this soc. it appears to be the same controller as drivers/mmc/host/dw_mmc*, but datasheets and vendor source only show a single clock, where the designware stuff says it requires two clocks, ciu and biu

11:39 <jn> hanetzer: it seems plausible that the module's ciu and biu clocks might be connected to the same clock line from the SoC's clock generator

11:39 <jn> what do these names mean, and what are the requirements for these clocks (like minimum/maximum rates or relations to buses)?

11:40 <hanetzer> bus interface unit and card interface unit; the req for both is mentioned in the yaml for it.

11:42 <hanetzer> and the driver is 'hard wired' to req both :P

11:44 <Xogium> psydroid: neat

11:44 <jn> hmm, there are vendor integration specific bindings (e.g. for rockchip, rockchip-dw-mshc.yaml), so there is some wiggle room to do things differently

11:45 <jn> hanetzer: anyway, assuming for the moment, that both module clocks are supplied by the same SoC clock, it should suffice to specify this SoC clock as both biu and ciu

11:45 <jn> i haven't read the HiSi documentation to confirm if that's an accurate representation, though

11:47 <jn> Xogium: the SBI story in RISC-V is a bit annoying, but other than that, it's just another RISC ISA. it does its job, what matters is implementation quality

11:48 <Xogium> jn: yeah I figured that was about it

11:49 <Xogium> but I'm not sure if its really that great to have it apparently more open

11:50 <hanetzer> jn: well, the doc for this only has one clock per mmc interface in its crg regs.

11:50 <hanetzer> guess I'll give that a go :)

11:50 <jn> hanetzer: what does it say about ciu and biu on the MMC side?

11:50 <hanetzer> nothing major in the docs.

11:55 <jn> Xogium: the benefits of RISC-V's openness are quite obscure to most users. software developers can't benefit from it, because having a published specification isn't RISC-V's innovation. OS/driver developers can't benefit from it, because having any kind of openness on the SoC is not in the scope of RISC-V. SoC integrators get questionable benefit because they still have to get a bunch of peripherals (but a RISC-V core might be a tiny bit cheaper than an

11:55 <jn> ARM core). the real benefit comes when you want to develop a new CPU core, which very few people attempt.

11:57 <hanetzer> jn: there's references to it that match references in other hisi socs that do implement both, but it strikes me as copypasta from the synopsis databook (which I really wish was publicly available lmao)

11:57 <Xogium> right

11:58 <Xogium> even st doesn't do that

11:58 <Xogium> developing cpu cores, I mean. They make SoC, but that's it

12:01 <jn> hanetzer: hmm. seems reasonable to describe it in the DT as ciu and biu being supplied by the same CRG clock, perhaps with a comment about the uncertainty of the situation

12:02 <hanetzer> yeh

12:37 <hanetzer> heh. enabling the dma controller driver borks bootup. probably need some soc specific glue code or figuring out the dma-channel-mask bits

12:41 <hanetzer> like, it ends up getting to udevd[71]: startting eudev-3.2.11 and then hangs apparently :)

12:42 <hanetzer> the regs and vendor code very much resemble the k3-dma driver

12:59 <hanetzer> as a test, I enabled K3_DMA but removed the dma data from uart0; output continues, however input fails.

13:55 <hanetzer> ah no. something about the boot prior put the serial in a weird state.

16:17 <hanetzer> so, I'm under the assumption there's no particular special handling for having multiple uarts in one device? Reason I ask is as a test I flipped uart1/uart2 to status = "okay"; and they don't seem to have probed

19:54 <hanetzer> oh yay, got a use-after-free in the hisi-femac driver

21:03 <hanetzer> ahh there we go. my dumb ass forgot to add the second clock to the uart nodes. thank you dtbs_check :)