On Tue, Sep 24, 2024 at 03:54:59PM GMT, John Schulz wrote: > Hi Dmitry, > > I do not have a way of testing this patch. I do see your point in that it may be redundant/unnecessary > since basic/generic drivers should at the very least output a shell interface. > > Upon doing more research, I came across the fact that some X1 GPUs have OEM signing that prevent the > driver from working. I suspect that is what I am running into when I try testing various distros. All > of them exhibit the same behavior of the display halting during the bootloader handoff and the HDMI > port does not output anything. Even the Debian 12 image from Linaro exhibits the same issue. Ok. So you have a device with X1P, which you don't seem to be able to get to work? Could you please try doing the following: - you might need to modify the GPU DT node to use a different ID there. If your guess is right, you might need to specify qcom,adreno-4310c31f (this is from your patch) - you need to define a corresponding entry in a7xx_gpus[]. Try using X1-85 as an inspiration. - only with that in place the x1xx family makes sense. Also it would be nice if you describe your issue. What exactly do you observe and what doesn't seem to work? > > I find this a bit odd given that there is a dts entry for the Asus Vivobook S 15 X1E varient. I > don't see any comments on whether the dts for that laptop was tested. The Vivobook I have is the > X1P varient which, to my knowledge, is identical to the X1E one but a different SoC. > > Perhaps it would be of better use of my (and others) time figuring out if the GPU drivers not > working is due to OEM locking and if so, trying to unlock it. What do y'all think? > > P.S. Apologies for the incorrect prefix, should have done more research instead of trying to > make an educated guess. > > Thanks, > John > > -- With best wishes Dmitry
