04:30 <Tooniis[m]> bamse: isnt that what Suggested-by is for?

04:47 <bamse> Tooniis[m]: to me, "Suggested-by" means that said person suggested that i should implement this patch

04:47 <bamse> Tooniis[m]: just as Reported-by means said person reported an issue ad i wrote this patch to resolve it

04:48 <bamse> Tooniis[m]: we don't have a way to say someone made suggestions during the evolution of this patch

17:32 <Mis012[m]> what is wrong with me...

17:32 <Mis012[m]> turns out I didn't allow Linux to access the SCC registers

17:33 <Mis012[m]> and here I sit wondering why it crashes on me

17:33 <Mis012[m]> 🤦‍♂️

17:36 <Mis012[m]> so much for trying to cater to the "security" argument by only enabling what was necessary...

17:43 <calebccff> vkoul: do you know is msm8998 uses the same addresses for the dsc blocks?

17:43 <calebccff> downstream doesn't seem to have dpu at all for 8998, i noticed the pingpong block uses the 845 addresses

17:44 <calebccff> s/is msm8998/if msm8998/

17:57 <Mis012[m]> calebccff: which addresses concretely?

18:01 <calebccff> Mis012[m]: https://github.com/calebccff/linux-wahoo/commit/5288ac1599a4786ae36766a286c86091a1b95f75

18:06 <Mis012[m]> looks like 0 and 1 are offset by `0x1000`

18:06 <calebccff> aha, thanks

18:06 <Mis012[m]> 2 and 3 don't seem to exist

18:07 <Mis012[m]> yw

18:07 <calebccff> Mis012[m]: do you have interconnects working on 8998? seems there's been some noise upstream since Konrad wrote the driver for it and it doesn't seem to work properly

18:08 <calebccff> also the drivers were commonized, I ported the 8998 driver to use the new common code along with 660 but haven't been able to test properly as my damn device keeps crashing and I don't have UART /_/

18:09 <Mis012[m]> calebccff: I don't know how to put it, but somainline promised to put out their proprietary tree publicly, I wasn't able to find it, so I gave up and now I just work on stuff atop mainline and try to minimize the amount of time that I let the display try to burn itself out

18:09 <calebccff> hmm, so you don't have interconnects up?

18:09 <calebccff> fyi - https://github.com/calebccff/linux-wahoo/commit/b6d284ab933219a214b878e5085656f1016fe0ca

18:10 <Mis012[m]> I tried to apply the patches manually, it didn't work out well, so I figured I'll wait until it lands if I can't have a tree with it pre-applied

18:10 <calebccff> deathmist has a pretty solid kernel for 8998 with everything up to date https://gitlab.com/msm8998-mainline/linux

18:11 <Mis012[m]> interesting, should give that a look :)

18:13 <calebccff> and it's /only/ ~150 patches on top of mainline

18:13 <Mis012[m]> heh

18:13 <Mis012[m]> calebccff: btw it looks like the init sequence for the SSC bus is quite a bit simpler on 845, only some clock enabling

18:13 <Mis012[m]> unless the rest was hidden somewhere else

18:14 <Mis012[m]> and also all the clocks that need to be enabled are in the pretty-much-side-effect-free 0x1000 block of SSC-related clocks in GCC

18:15 <Mis012[m]> though I guess you would have to disallow starting the SSC hexagon at all, since it's clocks are also in that area

18:16 <Mis012[m]> or you could decide that you don't care about the "security" scenario of Linux trying to hack the SSC fw

18:19 <aka_[m]> calebccff: any idea if rpm-icc will get support for qcom,agg-ports| qcom,vrail-comp and something like this: qcom,qport = <3 4>;

18:19 <aka_[m]> ?

18:20 <Mis012[m]> does the i in icc stand for imaginary?

18:20 <aka_[m]> they are on 8996/8998 dts but i cannot find it anywhere

18:21 <aka_[m]> tho the one for rpmh have ports-num or something like that

18:21 <Mis012[m]> pretty sure that clock controller only exists because some clocks don't have hw voting

18:23 <aka_[m]> oh lol

18:23 <aka_[m]> i was wondering if other socs have issues with power domains on SDHCI and it turns out none of them provide it in dts as power-domain

18:24 <Mis012[m]> can't have issue with X if X doesn't exist :taps_head:

18:24 <aka_[m]> nor i see OPP tables there

18:25 <aka_[m]> atleast 8916/8996/8998

18:25 <Mis012[m]> or at least if you don't acknowledge that X exists

18:25 <aka_[m]> SDM660 seems to have these.

18:26 <calebccff> aka_[m]: honestly i don't even know what interconnects do lol

18:26 <calebccff> seems like 8998 has very similar hw to 660

18:28 <Mis012[m]> well, interconnect drivers touch NoC routing configuration registers like QoS

18:28 <aka_[m]> i kinda enjoy fact that USB/Chipidea stack got some updates

18:28 <aka_[m]> not i don;t have to reconnect usb between reboots to have pc see it

18:28 <calebccff> Mis012[m]: ELI5 or don't bother :P I should do some of my own research tbh

18:29 <aka_[m]> *now

18:29 <Mis012[m]> well, NoC is Network On Chip

18:29 <calebccff> ah

18:30 <Mis012[m]> and since it's modeled like a network, they also use networking terms like Quality of Service

18:30 <Mis012[m]> ideally the NoC mostly gets out of the way and lets you pretend that you just have discrete AHB APB AXI etc buses going around

18:32 <Mis012[m]> but since it's not perfect, stuff like QoS registers let you configure what you want to compromise

18:33 <calebccff> i see

18:33 <Mis012[m]> I haven't looked into everything, but I remember the QoS registers :P

18:34 <Mis012[m]> in general the idea of QoS is basically "I want this AHB bus to be really fast, so give the packets for that priority over packets for other buses"

18:35 <calebccff> so what's with cnoc, snoc, a1noc, mnoc etc

18:36 <Mis012[m]> there are nice block diagrams for that, but even in NDA docs they would appear by accident :P

18:36 <Mis012[m]> iirc I have a blurry 8996 one

18:37 <Mis012[m]> just have to remember which random NDA doc I randomly found on the internet it was in

18:49 <Mis012[m]> oh, it was 8994

18:51 <Mis012[m]> it's not as blurry as I remember

18:54 <Mis012[m]> well, I guess it doesn't explain what these are