15:46 <minecrell> robclark: Any chance we can try e.g. +S (TLS only) instead of +M for this channel? (hoping this will also prevent most spammers). People keep writing from Matrix but don't notice that the messages don't show up here because somehow the Matrix bridge always logs people out of NicksServ. So often entire conversations don't show up here which is kind

15:46 <minecrell> of strange

16:05 <minecrell> robclark: With -M I mean

16:05 <robclark> oh, right

16:06 <minecrell[m]> Hello

16:06 <kholk[m]> I have no idea why this thing is not working

16:06 <minecrell> robclark: Great, thanks :)

16:06 <robclark> np

16:06 <minecrell> kholk[m]: Now it's not necessary anymore

16:06 <kholk[m]> at least on the ..

16:06 <kholk[m]> oh

16:06 <kholk[m]> thank you Rob :)))

16:06 <kholk[m]> so that's why nobody ever replied me, I feel lame... :)))

16:07 <kholk[m]> so I guess I should repeat everything...

16:10 <kholk[m]> in short: I've found another way to get SDM630/660 SMMU to work upstream, but this implies manually writing a list of context banks in the dts; the qcom-arm-smmu driver will get this stuff, arm-smmu will check for an implementation detail "reset_cb_nodisable(smmu, cbndx)" - if true, in arm_smmu_device_reset, we won't write FAULT in FSR and won't set ACTLR to 0 (so we avoid disabling it)

16:10 <kholk[m]> I couldn't find any SMMU register that has any relation with the contexts that we cannot disable

16:10 <kholk[m]> but I'm not sure about this approach being right

16:11 <kholk[m]> nobody else in SoMainline was actually able to find any other better way... so before spamming emails upstream I wanted to check with the people here

16:12 <kholk[m]> if you got any other idea, or you think I overlooked something... I can redo it somehow

16:12 <kholk[m]> otherwise if you're interested to see the code for the approach, I can give you a github link

16:21 <minecrell> kholk[m]: This is supposed to be a replacement for qcom,skip-init downstream I guess?

16:21 <kholk[m]> no

16:21 <kholk[m]> qcom,skip-init is skipping the entire initialization

16:21 <kholk[m]> what I'm doing is just skipping the disablement of some contexts, but actually goes on through the entire reset

16:21 <minecrell> ah, I see

16:22 <kholk[m]> I don't even know why I haven't just thrown a link

16:22 <kholk[m]> https://github.com/SoMainline/linux/commit/62107449164933f3f3fa9e9e90a7f94e85a78321

16:22 <kholk[m]> that's it, basically

16:23 <minecrell> Well, that's fairly simple :D

16:23 <kholk[m]> well yes, at least in arm-smmu.c it is

16:23 <kholk[m]> the logic here is that there at arm_smmu_device_reset time

16:23 <kholk[m]> when we call arm_smmu_write_context_bank, cb->cfg is null

16:23 <kholk[m]> so that function does just one write and returns

16:24 <kholk[m]> that's what I'm avoiding at all

16:24 <kholk[m]> the qcom-arm-smmu counterpart is here. https://github.com/SoMainline/linux/commit/f1759bcf6ab62c34a1018a7a020442486f99bbcd

16:24 <kholk[m]> it's nothing complicated

16:24 <minecrell> Perhaps bamse has some opinion at this. Although judging from previous discussions on the mailing list I guess you will mainly need to convince Robin and Will there

16:24 <kholk[m]> but still, my doubts about the approach by itself are standing out a bit

16:25 <kholk[m]> well... yeah... exactly why I'm here asking

16:25 <kholk[m]> I always felt like I was wasting their time in poor ways

16:26 <minecrell> ah, I see

16:26 <kholk[m]> heh

16:27 <kholk[m]> in any case, the guys in here do know qcom stuff specifically, so perhaps it may emerge that I'm underestimating something

16:27 <kholk[m]> in which case we may simply get to a golden solution, who knows