02:28 <leezu> abhinav_: there's a regression in linux 6.1 for sc7180 / lazor breaking display. Would you mind taking a look at https://gitlab.freedesktop.org/drm/msm/-/issues/22?

08:27 <z3ntu> Does anyone know whether fw_devlink=permissive is changing anything except probe order and because of that probably hits some EPROBE_DEFER cases in drivers? With this in cmdline I'm getting weird irq things in dmesg like "[ 2.178003] irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!"

08:27 <z3ntu> If it's just that, I'm thinking some driver that uses this irq doesn't clean up properly on probe fail maybe?

08:55 <z3ntu> hm seems this thread basically handles the same thing.. https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@linaro.org/

08:58 <z3ntu> Looks like fixing in USB node "&pdc 15 IRQ_TYPE_EDGE_BOTH" to "&pdc 15 IRQ_TYPE_LEVEL_HIGH" (and same for pdc 14) and the remoteprocs make these errors disappear and the drivers probe successfully

08:59 <z3ntu> but based on this message it seems like bugs on those two drivers that they don't clean up after themselves https://lore.kernel.org/lkml/8735gi5g7s.wl-maz@kernel.org/

13:27 <kholk> lumag: no, I don't remember of any, sorry

14:04 <kholk> aka_: I've just pushed another 18 commits around - notifying you since you're interested in 8976 :-)

14:04 <kholk> check the lists :-)

14:05 <kholk> ah, nvm, I've just realized that you do know already, as I've Cc'ed you on all of them

14:05 <aka_[m]> i have weird hobby of visiting lists 3 to 4 times per day

14:08 <kholk> heh, I've practically got an autorefresh on linux-mediatek... lol

14:13 <mal> kholk: in qcom_iommu_reset_ctx of the iommu patches, shouldn't ARM_SMMU_CB_FSR be ARM_SMMU_CB_FSRRESTORE or is there difference between different versions of iommu?

14:14 <kholk> mal: no, that's supposed to be FSR, downstream agrees with me :-)

14:14 <mal> hmm, really, can you show the sources

14:15 <kholk> msm-3.10, check 8976 tags

14:15 <aka_[m]> kholk: regarding other patches which are not shipped do you have anything about cpu pll?

14:15 <aka_[m]> Because i have some idea but im not sure how will that align with your plans

14:15 <aka_[m]> actually, i tested like half of this idea

14:15 <kholk> aka_: yes, I do... but scaling the HFPLL (big cluster) is not stable

14:15 <mal> kholk: for 3.4 msm8974 kernel https://github.com/LineageOS/android_kernel_fairphone_msm8974/blob/lineage-19.1/drivers/iommu/msm_iommu-v1.c#L463

14:16 <aka_[m]> kholk: well i got it to set rate and unixbench appears to be stable

14:16 <aka_[m]> but i didn't notice it to change freq

14:16 <aka_[m]> i mean i init it on max L

14:16 <aka_[m]> and it drops to 1.3Ghz

14:16 <aka_[m]> so it manage to change rate

14:17 <aka_[m]> maybe im lacking devfreq options in kernel

14:17 <aka_[m]> and this is not exactly stuff you made back on 4.9 kernel

14:17 <aka_[m]> i just use hfpll.c

14:18 <aka_[m]> for all clusters

14:18 <aka_[m]> 8953 fork have some downstream style cpu-mux-div driver but it could be wired to apcs-msm8916 which im yet to test

14:19 <kholk> mal: curious. can you check if you get any issues with my reset?

14:19 <kholk> aka_: that's a bit odd, as MSM8976 has a HF2 PLL, not the plain old HF - and it also needs a hacky call in SPM to actually power up

14:20 <mal> I just wonder which exact source you checked

14:20 <mal> I can't seem to find FSR in any

14:20 <aka_[m]> kholk: well perf numbers says i get cci and all clusters up

14:20 <kholk> mal: honestly? I checked that ~3 years ago and I've just rebased, cleaned and re-tested the patches before sending again

14:20 <aka_[m]> and hf2pll probably is lie

14:21 <aka_[m]> because you know its 28nm hpm pll

14:21 <kholk> aka_: no it's not a lie :)))

14:21 <aka_[m]> layout is almost exactly same like 8974

14:21 <kholk> "almost" is what makes it be a hf .. 2

14:21 <aka_[m]> qcom just stripped descriptions of fields

14:22 <aka_[m]> and all ops of v1 manage to start it.

14:22 <aka_[m]> Well, where did you got some such internal data on pll type?

14:22 <kholk> I'm also surprised that you could actually do this without programming the ramp controller, or having SAW up

14:22 <aka_[m]> i had like 36xx points in unixbench

14:22 <aka_[m]> with 1.1 on a53 and 1.3 on a72

14:23 <aka_[m]> and cci on max

14:23 <aka_[m]> was like 616Mhz/

14:23 <aka_[m]> ?

14:23 <kholk> check if you can do scaling then

14:23 <kholk> because last time I tried, without SPM calls to force ... I don't remember what ... on, I couldn't even *start* the HF2PLL

14:24 <kholk> perhaps you've got a different firmware?

14:24 <kholk> (different bootloader/tz/something)

14:25 <aka_[m]> its LA.BR something

14:25 <aka_[m]> 6.0 stock

14:25 <mal> kholk: which iommu is that v2 in reality, is it still using the v1 driver

14:25 <mal> in downstream

14:25 <aka_[m]> mal: its 8916 era one i assume

14:25 <kholk> aka_: the "something" is important xD ... but don't bother with that

14:26 <kholk> mal: yes still hw_v1.c

14:26 <mal> kholk: I was actually thinking what to do with those patches because my msm8974 iommu patches have some overlap with that patchset

14:27 <mal> I have checked several 3.4 and 3.10 kernels, even msm8976 ones, and none set FSR in reset_context, all set FSRRESTORE, I need to see if I can find something else

14:28 <aka_[m]> kholk: /firmware/verinfo says:

14:28 <aka_[m]> MSM8976.LA.1.0.1.c5-50024-STD.PROD-1.75233.1.76286.1

14:28 <kholk> mal: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/iommu/msm_iommu-v1.c#L446

14:28 <kholk> Marijn: can you please give a verinfo from suzu to aka_?

14:29 <kholk> mal: I think that you're right about never seeing FSR but always FSRRESTORE

14:31 <kholk> mal: I'm getting Marijn to test with FSRRESTORE instead of FSR, let's see what happens

14:34 <mal> kholk: I have been using FSRRESTORE on msm8974 always

14:35 <mal> kholk: btw, that link is to reset_iommu, reset_context is here https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/iommu/msm_iommu-v1.c#L541 also using FSRRESTORE

14:35 <aka_[m]> kholk: out of wonder, how where you unable to start pll, was it throwing errors?

14:35 <mal> but a bit different

14:35 <aka_[m]> i ask because i tried both your 4.9 impl and this custom thing

14:36 <mal> one is global FSRRESTORE and other is context specific

14:37 <kholk> yes that's the reference kernel that I used, mostly sure of that

14:38 <mal> I see FSR being set only in fault handler

14:38 <kholk> actually setting FSR to 0 is a no-op

14:38 <kholk> I just checked on the ARM reference

14:39 <kholk> "A 32-bit RW clear register. A value of 1 written to any non-reserved bit clears that bit. A value of 0 written to any of these bits leaves the bit unchanged."

14:39 <kholk> so that has to either be a write to FSRRESTORE, or iommu_writel(ctx, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);

14:41 <kholk> or both, actually...

14:47 <kholk> mal: I'm pushing a v2 in a few minutes, we tested doing:

14:47 <kholk> iommu_writel(ctx, ARM_SMMU_CB_FAR, 0);

14:47 <kholk> iommu_writel(ctx, ARM_SMMU_CB_FSRRESTORE, 0);

14:47 <kholk> iommu_writel(ctx, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);

14:48 <Marijn[m]> kholk: mal `FSRRESTORE` works indeed, no adverse effects

14:48 <Marijn[m]> aka_: I'll try and hunt down the firmware partition for that verinfo file...

14:49 <mal> kholk: wondering why downstream doesn't write FSR

14:52 <Marijn[m]> Depending on a random BL value?

14:53 <Marijn[m]> This is the context reset, right? Downstream doesn't reset contexts...

14:53 <Marijn[m]> (That is why it can get away with not specifying stream IDs in DT, in turn leaving random devices to die when upstream resets the iommu)

14:55 <calebccff> the 6.1 changes to drm/msm switching to exclusively using drm bridge to control DSI panels has lead to the DSI controller getting switched off before the panel unprepare function is called, this breaks unprepare on panels which expected to send DSI commands there

14:55 <mal> Marijn[m]: downstream does have reset_context function and it is used before programming context

14:55 <calebccff> is this intended and something we need to fix in panels or is this an issue in drm/msm?

14:56 <Marijn[m]> calebccff: that sounds like buggy behaviour

15:00 <kholk> mal: not writing to FSR is actually incorrect - downstream must be relying on always setting up IOMMU contexts "entirely" right after reset

15:02 <kholk> in any case, QSMMU is actually ARM SMMU behind firewall

15:02 <kholk> (plus implementation defined "magic")

15:03 <kholk> (P.S.: firewall == TZ/hypervisor)

15:04 <kholk> mal: also... https://documentation-service.arm.com/static/5f900cc0f86e16515cdc08d4?token=

15:05 <kholk> (but be careful with that document, as it doesn't exactly fully apply to the TZ-backed implementation for these old qcom iommus)

15:16 <mal> kholk: where in that does it say both should be written

15:31 <mal> kholk: some disagreement in mailing list about using FSRRESTORE

16:50 <minecrell> calebccff: fwiw I mentioned this already a couple of weeks ago

16:50 <minecrell> maybe we need a proper place to track regressions as I get the feeling they often end up being forgotten

18:19 <calebccff> minecrell: huh thanks, yeah it would be nice...

18:21 <minecrell> october 19th

18:21 <minecrell> 20:26 <minecrell> lumag: "drm/msm/dsi: switch to DRM_PANEL_BRIDGE" seems to break sending DSI commands in panel unprepare() callback, looks like dsi_mgr_bridge_post_disable() is called before the post_disable() from the panel bridge so the whole DSI host is already powered down when drm_panel_unprepare() is called :/

18:21 <minecrell> 05:23 <lumag> minecrell, ugh.

18:21 <minecrell> 05:26 <lumag> I think this should be fixed once the reorder bridge ops patch is landed. But I'm not sure what is the expected timeline.

18:21 <minecrell> lumag: what's the state of that reorder patch?