ChanServ changed the topic of #linux-msm to:
leezu has joined #linux-msm
<leezu> abhinav_: there's a regression in linux 6.1 for sc7180 / lazor breaking display. Would you mind taking a look at
Danct12 has joined #linux-msm
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-msm
Danct12 has quit [Quit: Quitting]
jhovold has joined #linux-msm
pevik has joined #linux-msm
<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!"
<z3ntu> If it's just that, I'm thinking some driver that uses this irq doesn't clean up properly on probe fail maybe?
Danct12 has joined #linux-msm
<z3ntu> hm seems this thread basically handles the same thing..
<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
<z3ntu> but based on this message it seems like bugs on those two drivers that they don't clean up after themselves
Daanct12 has joined #linux-msm
Daanct12 has quit [Remote host closed the connection]
<kholk> lumag: no, I don't remember of any, sorry
<kholk> aka_: I've just pushed another 18 commits around - notifying you since you're interested in 8976 :-)
<kholk> check the lists :-)
<kholk> ah, nvm, I've just realized that you do know already, as I've Cc'ed you on all of them
<aka_[m]> i have weird hobby of visiting lists 3 to 4 times per day
<kholk> heh, I've practically got an autorefresh on linux-mediatek... lol
<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?
<kholk> mal: no, that's supposed to be FSR, downstream agrees with me :-)
<mal> hmm, really, can you show the sources
<kholk> msm-3.10, check 8976 tags
<aka_[m]> kholk: regarding other patches which are not shipped do you have anything about cpu pll?
<aka_[m]> Because i have some idea but im not sure how will that align with your plans
<aka_[m]> actually, i tested like half of this idea
<kholk> aka_: yes, I do... but scaling the HFPLL (big cluster) is not stable
<aka_[m]> kholk: well i got it to set rate and unixbench appears to be stable
<aka_[m]> but i didn't notice it to change freq
<aka_[m]> i mean i init it on max L
<aka_[m]> and it drops to 1.3Ghz
<aka_[m]> so it manage to change rate
<aka_[m]> maybe im lacking devfreq options in kernel
<aka_[m]> and this is not exactly stuff you made back on 4.9 kernel
<aka_[m]> i just use hfpll.c
<aka_[m]> for all clusters
<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
<kholk> mal: curious. can you check if you get any issues with my reset?
<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
<mal> I just wonder which exact source you checked
<mal> I can't seem to find FSR in any
<aka_[m]> kholk: well perf numbers says i get cci and all clusters up
<kholk> mal: honestly? I checked that ~3 years ago and I've just rebased, cleaned and re-tested the patches before sending again
<aka_[m]> and hf2pll probably is lie
<aka_[m]> because you know its 28nm hpm pll
<kholk> aka_: no it's not a lie :)))
<aka_[m]> layout is almost exactly same like 8974
<kholk> "almost" is what makes it be a hf .. 2
<aka_[m]> qcom just stripped descriptions of fields
<aka_[m]> and all ops of v1 manage to start it.
<aka_[m]> Well, where did you got some such internal data on pll type?
<kholk> I'm also surprised that you could actually do this without programming the ramp controller, or having SAW up
<aka_[m]> i had like 36xx points in unixbench
<aka_[m]> with 1.1 on a53 and 1.3 on a72
<aka_[m]> and cci on max
<aka_[m]> was like 616Mhz/
<aka_[m]> ?
<kholk> check if you can do scaling then
<kholk> because last time I tried, without SPM calls to force ... I don't remember what ... on, I couldn't even *start* the HF2PLL
<kholk> perhaps you've got a different firmware?
<kholk> (different bootloader/tz/something)
<aka_[m]> its LA.BR something
<aka_[m]> 6.0 stock
<mal> kholk: which iommu is that v2 in reality, is it still using the v1 driver
<mal> in downstream
<aka_[m]> mal: its 8916 era one i assume
<kholk> aka_: the "something" is important xD ... but don't bother with that
<kholk> mal: yes still hw_v1.c
<mal> kholk: I was actually thinking what to do with those patches because my msm8974 iommu patches have some overlap with that patchset
<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
<aka_[m]> kholk: /firmware/verinfo says:
<aka_[m]> MSM8976.LA.1.0.1.c5-50024-STD.PROD-1.75233.1.76286.1
<kholk> Marijn: can you please give a verinfo from suzu to aka_?
<kholk> mal: I think that you're right about never seeing FSR but always FSRRESTORE
<kholk> mal: I'm getting Marijn to test with FSRRESTORE instead of FSR, let's see what happens
<mal> kholk: I have been using FSRRESTORE on msm8974 always
<mal> kholk: btw, that link is to reset_iommu, reset_context is here also using FSRRESTORE
<aka_[m]> kholk: out of wonder, how where you unable to start pll, was it throwing errors?
<mal> but a bit different
<aka_[m]> i ask because i tried both your 4.9 impl and this custom thing
<mal> one is global FSRRESTORE and other is context specific
<kholk> yes that's the reference kernel that I used, mostly sure of that
<mal> I see FSR being set only in fault handler
<kholk> actually setting FSR to 0 is a no-op
<kholk> I just checked on the ARM reference
<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."
<kholk> so that has to either be a write to FSRRESTORE, or iommu_writel(ctx, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);
<kholk> or both, actually...
<kholk> mal: I'm pushing a v2 in a few minutes, we tested doing:
<kholk> iommu_writel(ctx, ARM_SMMU_CB_FAR, 0);
<kholk> iommu_writel(ctx, ARM_SMMU_CB_FSRRESTORE, 0);
<kholk> iommu_writel(ctx, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT);
<Marijn[m]> kholk: mal `FSRRESTORE` works indeed, no adverse effects
<Marijn[m]> aka_: I'll try and hunt down the firmware partition for that verinfo file...
<mal> kholk: wondering why downstream doesn't write FSR
<Marijn[m]> Depending on a random BL value?
<Marijn[m]> This is the context reset, right? Downstream doesn't reset contexts...
<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)
<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
<mal> Marijn[m]: downstream does have reset_context function and it is used before programming context
<calebccff> is this intended and something we need to fix in panels or is this an issue in drm/msm?
<Marijn[m]> calebccff: that sounds like buggy behaviour
<kholk> mal: not writing to FSR is actually incorrect - downstream must be relying on always setting up IOMMU contexts "entirely" right after reset
<kholk> in any case, QSMMU is actually ARM SMMU behind firewall
<kholk> (plus implementation defined "magic")
<kholk> (P.S.: firewall == TZ/hypervisor)
<kholk> (but be careful with that document, as it doesn't exactly fully apply to the TZ-backed implementation for these old qcom iommus)
<mal> kholk: where in that does it say both should be written
<mal> kholk: some disagreement in mailing list about using FSRRESTORE
<minecrell> calebccff: fwiw I mentioned this already a couple of weeks ago
<minecrell> maybe we need a proper place to track regressions as I get the feeling they often end up being forgotten
mka has joined #linux-msm
<calebccff> minecrell: huh thanks, yeah it would be nice...
<minecrell> october 19th
<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 :/
<minecrell> 05:23 <lumag> minecrell, ugh.
<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.
<minecrell> lumag: what's the state of that reorder patch?
pespin has joined #linux-msm
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
jhovold has quit [Ping timeout: 480 seconds]
pevik has quit [Ping timeout: 480 seconds]
pespin has quit []
cxl000 has quit [Quit: Leaving]