On Tue, Sep 24, 2024 at 8:55 AM John Schulz <john.schulz1@xxxxxxxxxxxxxx> 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.
>
> 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.
I think we'd need an x1p variant of x1e80100.dtsi which has the
description of the SoC itself.. which I guess is similar, but not the
same as, x1e. Maybe someone from qcom or linaro is already working on
this?
> 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?
It is probably not OEM locking that is the issue, but OEM signing of
zap shader. If you look at the x1e laptops, as an example, the GPU
node has the device specific firmware-path for the zap shader, ie. for
the yoga 7x, it is:
&gpu {
status = "okay";
zap-shader {
firmware-name = "qcom/x1e80100/LENOVO/83ED/qcdxkmsuc8380.mbn";
};
};
That qcdxkmsuc8380.mbn file would need to be copied from the windows
partition currently.
BR,
-R
> P.S. Apologies for the incorrect prefix, should have done more research instead of trying to
> make an educated guess.
>
> Thanks,
> John
>
>
>
