00:00 <qzed> that doesn't seem to work

00:00 <qzed> what I think is a bit weird: I can blacklist msm, the distcc and gpucc modules and I still get a black screen

00:02 <robclark> black from start of boot, or goes off somewhere in the middle? I guess iommu (arm_smmu) is another candidate, perhaps? gpucc shouldn't have much to do with anything but dispcc could

00:03 <qzed> it's on for short while, as far as I can tell it turns black even before it's done with the initram

00:04 <qzed> it's been a problem before, which at that point I've fixed by not building the distcc and gpucc modules (at all)

00:05 <qzed> but things have changed in the DT and blacklisting them (which should have worked before) doesn't any longer

00:05 <qzed> IIRC not having those blocked the smmu from loading

00:15 <qzed> *dispcc of course, not distcc

00:21 <qzed> also another weird thing: having gcc_8180 built into the kernel causes a stall

00:21 <qzed> whereas having it as module included in the initram does not

00:22 <qzed> I assume that's some power-up sequence problem

00:41 <qzed> so I tried blacklisting arm_smmu and that results in a boot failure

00:42 <qzed> even before I can get anything off the device via usb-serial

00:42 <qzed> and also a black screen, just like before

01:39 <robclark> if it gets to initramfs, I guess you can try to figure out which module kill it.. there are basically a lot more ways for it to go wrong than to go right (ie. some unrelated driver could enable then disable a clock with the disable propagating up the tree until it disables some parent clk that display indirectly depends on, and things like that)

01:43 <qzed> I don't think it even gets that far...

01:48 <qzed> not sure if this is works well with IRC, but here's a video of what's currently happening wrt. black screen

01:48 <qzed> seems like it flashes white for a bit

02:00 <robclark> could be when arm-smmu takes over, or at least it looks fairly early in boot.. not sure how much you should worry about it, since it wouldn't really be a problem once more of the platform enablement is in place and display driver works

02:05 <qzed> yeah, just can't figure out why it stays black... so I thought this might be related, but it might also just be a red herring

02:06 <robclark> probably red herring.. the real question is why it doesn't come back ;-)

02:20 <qzed> I briefly thought it might be a power thing but the kernel (and I) can read the edid from the aux i2c just fine

02:20 <qzed> so I guess that works?

02:22 <robclark> I suspect reading edid means dp block has power which probably means display block has power.. so could be something as simple as backlight?

02:23 <qzed> that works too, can control that and change brightness

02:26 <robclark> if dpu thinks it did modeset and it wasn't powered, it would be insta-reboot.. if you can read edid over dp aux channel, that should mean that panel has power... so idk

20:19 <qzed> is it possibel for edp panels to use only 2 of the 4 lanes?

20:20 <qzed> if I have 4 specified in the DT, it fails 2 times when trying to train the link

20:20 <qzed> it eventually succeeds but when I look in debugfs, it shows that only 2 lanes are used in the connector

20:21 <qzed> when I specify 2 lanes in the dt, there are no link training errors

20:21 <qzed> also there's still the "disp_cc_mdss_edp_pixel_clk_src: rcg didn't update its configuration."

20:22 <qzed> that's only printed once though, and if I check the clock is set each link training try, so the subsequent tries it seems to work

20:53 <HdkR> Definitely yes, you don't need four lanes unless you're pushing high BW

20:55 <qzed> okay thanks, so then that shouldn't cause any problems...

23:15 <qzed> robclark: so I figured out what the issue regarding the early blank screen is...

23:15 <qzed> and as you've said it seems to be unrelated

23:16 <qzed> during boot, panel and display are driven by the embedded controller

23:17 <qzed> and as soon as it "detects" that we're trying to drive them it more or less hands them over to us

23:18 <qzed> and it seems to detect that via a panel enable GPIO, which also controls the soc-driven power

23:18 <qzed> so my current setup is to use the enable pin in a voltage regulator which is then provided as supply to the panel node

23:19 <qzed> turns out that if I drop the GPIO from the voltage regulator spec and make it fixed instead, the panel stays on until the GPU boots up (or something happens around that time)

23:21 <qzed> so the EC detects something even though the panel regulator shouldn't be on yet

23:21 <qzed> maybe the regulator somehow power-cycles?

23:22 <qzed> anyways, it looks like the EC detects us fiddling with the panel-enable pin and decides it can drop its panel-enable signal

23:22 <qzed> (both are essentially or-ed together)

23:23 <qzed> and that then likely results in the panel being off, until we actually turn it back on later, at which point the second issue kicks in