11:16 <calebccff> does anyone know the state of this patch series? DSI displays are broken without it (have been since -rc1 i think) https://lore.kernel.org/lkml/20211201105210.24970-1-angelogioacchino.delregno@collabora.com/T/

11:57 <Marijn[m]> kholk:

12:47 <lumag_> calebccff, the linus's tree does not contain offending commit, it is a part of linux-next only.

12:47 <lumag_> If the master tree is broken, could you please post the dmesG?

15:01 <CosmicPenguin> mani_s: Cool, I'll look at it. My current problem is that my driver seems to successfully use MSI interrupts but then they never interrupt. Moving to legacy works fine. Downstream MSI does seem to work, sort of

15:01 <CosmicPenguin> s/use/allocate/

15:21 <calebccff> lumag_: https://p.calebs.dev/zynebimoce.log some clocks seem to come up in the wrong order without the above patches

15:24 <mani_s> CosmicPenguin, Which driver you are working on?

15:25 <mani_s> If possible please share the pcie node in dts of both upstream and downstream

15:25 <mani_s> the MSI IRQ might be wired up incorrectly in dts

15:29 <CosmicPenguin> mani_s: this is the intel igc driver. This is the eb5 platform but I'm using the rb5 dts - I'll post the deltas in a bit

15:32 <mani_s> CosmicPenguin, okay. so on SM8250 based platform you are using a Intel PCIe graphics card?

15:46 <CosmicPenguin> no, network nic

15:50 <mani_s> CosmicPenguin, ah okay

16:33 <CosmicPenguin> mani_s: The upstream pcie node is https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/arch/arm64/boot/dts/qcom/sm8250.dtsi?h=integration-linux-qcomlt#n1549 and overlayed by https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/tree/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts?h=integration-linux-qcomlt#n717

16:33 <CosmicPenguin> mani_s: I'm using the stock downstream rb5 dts too, if you have access to those (i'm not sure if they are posted anywhere public)

16:35 <mani_s> CosmicPenguin, sounds good. If RB5 pcie node is reused, then MSI IRQ mapping should be correct

16:35 <mani_s> did you make sure the MSI allocation doesn't fail?

16:36 <mani_s> Usually it runs out of MSI if things like parport drivers consumes few

16:36 <CosmicPenguin> yep - they were successful, and I see them in /proc/interrupts

16:36 <mani_s> Hmm

16:36 <CosmicPenguin> Just never actually - interrupt...

16:42 <bamse> z3ntu: not sure why i missed them, i've picked them now...won't update linux-next until -rc1 is out though

16:42 <z3ntu> Thanks!

16:43 <bamse> DavidHeidelberg[m]: you're very welcome to do so :)

19:25 <lumag__> calebccff, "clocks seem to come up in the wron order" -- what does that mean?

19:26 <lumag__> Is dispcc probing deferred?

19:58 <aka_[m]> rebased my msm8976 tree on top of next and WCNSS is crashing me hard and even tusb320.

19:58 <aka_[m]> Wonder if i have forgot to pick something or its something broke.

19:58 <aka_[m]> " fatal error received: halPMU.c:64:haltACK bit not set even after 5 milisceconds" then few crashes and few unable to handle kernel paging requests and mentions about failing memcpy on smd_nv

20:23 <calebccff> lumag_: I'm really not sure what the issue is, all I can tell you is the patches I linked above are required for working DSI on mainline right now, on sdm845 devices like the OnePlus 6. I'm not very familiar with drm/msm so I can't provide more details

20:24 <calebccff> lumag_: if you can provide me with steps to follow or functions to log I'd appreciate it greatly, though I expect the fix is simply to get those patches in mainline

20:26 <calebccff> My current (very limited) understanding of drm/msm and the issues we've had due to fw_devlink are that the probe ordering of various parts of the subsystem is quite delicate as there are implied dependencies on the ordering, when things probe in the wrong order it causes warnings related to clocks like you can see in the log I sent

20:48 <lumag__> calebccff, can you please check /sys/kernel/debug/devices_deferrred?

20:51 <lumag__> calebccff, also see https://lore.kernel.org/lkml/20211125183622.597177-1-dmitry.baryshkov@linaro.org/ and https://lore.kernel.org/lkml/20211126002612.1030246-1-dmitry.baryshkov@linaro.org/

22:40 <CosmicPenguin> mani_s: well, I printked the driver to within a inch of its ilfe - all the msi interrupts are setting up okay but the chained interrupt never fires, not even once. It definately feels like the mapping is wrong, but all the numbers look right in the DTS

22:42 <CosmicPenguin> mani_s: is there an switch in the hardware to switch from the GIC-v3 ITS method to the built-in MSI controller? Looking at the downstream driver, it seems like it just kinda assumes that the GIG-v3 method is enabled - it doesn't even touch the PCI controller hardware at any point, just sets up the interrupts and leaves

23:37 <CosmicPenguin> hmm - actually downstream doesn't seem to use GIC-v3 ITS after all - it seems to be a random third thing