ChanServ changed the topic of #linux-msm to:
<steev> Marijn[m]: is that like, almost immediately? i'm getting something on the thinkpad x13s as soon as we leave efi services it reboots
<steev> it could be similar but i have no idea as i can't get any sort of uart
<konradybcio> I could catch a pstore ending at 0.3 with no useful info, but as I mentioned, I'll retry tomorrow
<steev> Marijn[m]: also i meant reverting the patch i posted above (but my no in response was saying that i tried it and that didn't work) - but that's the only recent patch to pincontrol things... i also tried andrew's linked patch and no luck either. i might try reverting those two commits though
<steev> was arch_nr_gpio supposed to go away?
<steev> ah, yes it was
Daanct12 has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #linux-msm
Daanct12 has quit [Quit: Quitting]
<mani_s> arnd_, any idea on allocating dma pool that's not part of kernel's linear map?
<arnd_> mani_s: do you mean something behind a PCI bridge?
<arnd_> I think you can just ioremap that
<mani_s> we are seeing the access violation with the qcom remoteproc driver since the buffer shared with modem by kernel is accessed by cpu
<arnd_> ah, so this is regular cached RAM that is not in the CPU memory map because it is owned by another OS running on the same CPU?
<mani_s> arnd_, the remote side is a separate modem dsp that has access to system RAM
<arnd_> ok. Does the device have cache-coherent DMA?
<mani_s> arnd_, looks like some part of the buffer was in the CPU cache and that leads to speculative access after sharing the buffer w/ modem
<Marijn[m]> steev: Ah thanks, could have guessed. Reverted it to no avail. Will need to (let Konrad) dig further
<mani_s> arnd_, i'm not entirely sure about that
<mani_s> arnd_, this patch is what triggering the crash: https://lore.kernel.org/all/20220823122111.17439-1-will@kernel.org/
<arnd_> I see it gets mapped using pgprot_dmacoherent(), which is defined as
<arnd_> what I Don't yet see is how arch_dma_prep_coherent() gets called on this buffer
<mani_s> arnd_, dma_alloc_attrs?
pespin has joined #linux-msm
<arnd_> ok, I see. So it appears the dma_direct_alloc_no_mapping() allocates pages looks like it allocates regular pages from the linear map and then flushes the cachelines but (after the patch) does not invalidate them, or remove the pages from the linear mapping. I'm not entirely sure if that is the code path that you hit here, or if the device declares its own memory as the coherent buffer
<mani_s> arnd_, my understanding is the same
<arnd_> creating the new vmap() mapping as normal-uncached would then leave you with an inconsistent state where you have a clean cacheline for an uncached mapping, and this may be invalid according to the architecture. This is way beyond my understanding of the architecture details, but I see wildea01 in #mm on this server, let's both join there and ask him
<mani_s> arnd_, sounds good
<mani_s> let me join
<mani_s> arnd_, I'm in
<arnd_> mani_s: ok, let me try to summarize the problem there
<konradybcio> no way, looks like spmi7 is finally on the way!
<Marijn[m]> (konradybcio pointed me to it 😬)
<konradybcio> I just got two more lines out of 8450
<konradybcio> [ 0.286909] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
<konradybcio> [ 0.286945] Modules linked in:
<konradybcio> that's... fun...
<konradybcio> welp what can I say
<konradybcio> next-20221115 works fine
<konradybcio> just your everyday -next experience
<konradybcio> wait no.. the compile took so long I simply forgot I picked Brian's fix.. whoops..
<Marijn[m]> So konradybcio Brian's patch fixes it for you as well? And the one from Thierry Reding?
<konradybcio> the one from Brian (https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u) is enough for me to get a successful boot on top of next-20221115
<ajhalaney[m]> hmmm interesting me and Brian both poked that yesterday, he sent that, then we found the one from Thierry and tested it since it looked like it was gonna picked up. Thierry's worked for us... but we're testing on a super minimal system at the moment
<konradybcio> lumag: Do not add any more qcom,SOC-smmu-500 entries to this list, unless they need special handling and can not be covered by the qcom,smmu-500 entry.
<konradybcio> does this also include -smmu-v2 entries? 6350 has one for adreno and I'm wondering whether to add a specific one, though obviously with -v2 there's quite some variance between each soc..
<flamingradian[m]> I think that is handled in arm-smmu.c and handed over to the qcom driver
<konradybcio> lumag: another q, the dsi-controller-main.yaml binding seems wrong.. it assumes all SoCs have the same set of clocks, in particular with byte_intf which was introduced in msm8998+sdm660, but the compatible behind it has been used since 8064.. I don't know if it's possible to conditionally set clock desc based on number present though
pespin has quit [Remote host closed the connection]
jhovold has quit [Ping timeout: 480 seconds]
<steev> ajhalaney[m]: thierry's patch didn't work for me here, will be trying brian's soon
<steev> here being the thinkpad
<steev> okay, with brian's patch, i get further, though pci seems broken for me, likely i screwed up a patch on there, or i'm missing some of johan's new patchset to the mailing list