14:43 <marc|gonzalez> bryanodonoghue: I'm having a problem with adreno SMMU on msm8998.

14:44 <marc|gonzalez> msm_dpu c901000.display-controller: failed to load adreno gpu

14:45 <marc|gonzalez> after adding 42 million printks, it comes from iommu_attach_device(iommu->domain, dev) failing because dev->iommu_group is NULL

14:46 <marc|gonzalez> I'm pretty sure this error did not occur in phh's branch, but I don't see which patch would fix that

14:47 <marc|gonzalez> I could blindly add them and bisect, it would be faster than poking at random...

15:14 <marc|gonzalez> FFS, the node was disabled...

15:14 <marc|gonzalez> I don't quite understand the logic behind marking everything disabled in the SoC and requiring even board DTS to re-enable every piece of silicon...

15:15 <marc|gonzalez> I mean, if there's an IOMMU, it's expected to work normally all the time?

15:22 <z3ntu> marc|gonzalez: Afaik normally iommu is not disabled in dtsi file. Maybe it's just 8998 being weird?

15:23 <marc|gonzalez> Weird or sneaky...

15:24 <marc|gonzalez> 87cd46d68aeac8 = adreno_smmu disabled

15:25 <z3ntu> I'm quite sure that if you send a patch removing that status=disabled from dtsi for this node that nobody will mind. I checked all other adreno_smmu: and none apart from 8998 are disabled

15:27 <marc|gonzalez> jhugo: bamse: do you confirm that the adreno_smmu node should not be disabled?

15:28 <jhugo> marc|gonzalez: uhh, why would that be disabled? Its required for the adreno

15:29 <marc|gonzalez> IN...DEEEEED :)

15:29 <marc|gonzalez> I confirm that Adreno stubbornly tells me to F off if it doesn't find its smmu

15:29 <jhugo> got a lore link or something?

15:29 <marc|gonzalez> and it's not even an explicit F off, it just whimpers quietly and rolls over and dies

15:29 <z3ntu> Generally to my knowledge nodes are disabled in dtsi if they 1. need device-specific things configured, e.g. vdd-supply or some extra properties etc or extra firmware provided in rootfs, or 2. if the part on the SoC or PMIC are just plainly not used e.g. wled or vibra

15:30 <marc|gonzalez> you mean more than 87cd46d68aeac8 ?

15:30 <z3ntu> Maybe also time to add a loud print in adreno driver that it must get its iommu :)

15:30 <jhugo> oh, this is old

15:30 <marc|gonzalez> z3ntu: you're probably right

15:30 <marc|gonzalez> everything about the msm8998 is old

15:31 <marc|gonzalez> it's an 8 year old Soc :p

15:31 <jhugo> I had thought this was a change queued for -next

15:31 <z3ntu> 8998 is new compared to 8974 for example :P

15:31 <marc|gonzalez> it's a change queued for: let's piss of marc|gonzalez

15:31 <marc|gonzalez> *off

15:32 <marc|gonzalez> OK, patches on the way then

16:11 <marc|gonzalez> z3ntu: in fact, there's a if (gpu->aspace == NULL) DRM_DEV_INFO(drm->dev, "%s: no IOMMU, fallback to VRAM carveout!\n", name);

16:11 <marc|gonzalez> else if (IS_ERR(gpu->aspace)) silent return

16:12 <marc|gonzalez> so I think not having an iommus node is supported, but having a disabled iommus node is a weird corner case

16:17 <bryanodonoghue> marc|gonzalez what's your base SHA ?

16:24 <marc|gonzalez> wut?

16:25 <marc|gonzalez> I have a dozen patches on top of v6.9-rc1 aka 4cece76496502

16:28 <marc|gonzalez> bryanodonoghue: I'm not sure what "base SHA" means.

16:36 <aka_[m]> Take last tree commit Sha?

16:42 <marc|gonzalez> aka_[m]: last public object is the tag :)

16:43 <marc|gonzalez> then I have a dozen fixups, some accepted by maintainers, some not yet

16:59 <z3ntu> marc|gonzalez: the vram carveout is used on 8974 and 8226 ;)

17:00 <z3ntu> But yeah probably the other path should get a print

17:05 <marc|gonzalez> Something like "broken IOMMU setup" ?

17:06 <marc|gonzalez> I posted a patch for the DTSI

17:56 <aka_[m]> 8998 and 660 had disabled iommu because it was 'broken'

18:20 <luka177[m]> I did already compare pps payload, and it is identical. What is "other DCS "? i thought only pps payload is sent to panel. Will check DSC block, DSI host, CTL and PP registers

19:02 <Marijn[m]> luka177: the pps is only sent to the panel if your driver does it (when generated with the latest lmdpdg). "other DCS" is any arbitrary (vendor magic) command that is (not) sent that might cause the panel to (mis)interpret the compressed data wrongly

19:26 <luka177[m]> <Marijn[m]> "luka177: the pps is only sent to..." <- yes my driver do send PPS and its identical to one sent on downstream, as for vendor magic commands, i wound nothing except blac/unblack on panel suspend/unsuspend