| Message ID | 20211217125757.1193256-1-balbi@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo | expand |
On 17.12.2021 13:57, Felipe Balbi wrote: > From: Felipe Balbi <felipe.balbi@microsoft.com> > > Hi folks, > > I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking > through some internal docs, it came to my attention that the bootloader > will fill up the framebuffer address and size to a memory node names > splash_region. Adding the node, I can see the address of the > framebuffer. Creating the relevant framebuffer device using > simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom > of=/dev/fb0 and fb-test. None of which manage to get rid of what's > already on the screen, put there by the bootloader (platform Logo). > > Wondering if any of you have seen a behavior such as this and how did > you manage to get framebuffer working on SM8150 (I see at least Sony > Xperia has the node). > > Felipe Balbi (2): > arm64: boot: dts: qcom: sm8150: add a label for reserved-memory > arm64: boot: dts: qcom: surface duo: add minimal framebuffer > > .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++ > arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- > 2 files changed, 20 insertions(+), 1 deletion(-) Hi, this issue is totally unique to the Duo and your bootloader configuration. Gus (CCd, co-author of Lumia 950/XL patches) and I were dissecting this precise issue (albeit for a different usecase) and in our testing it turned out that XBL likely kills the display stack upon exiting Boot Services and jumping to LinuxLoader. This may be a bug that comes from the legacy of this device, as exiting Boot Services would be rather undesirable in that scenario.. One fix would be to ask the bootloader team to look into it and fix it from there, otherwise you'd have to bring up the display using the DPU1 driver, or perhaps in a third-stage-bootloader (pls don't do it for the sanity of us all :D) You can see the thing happening during the boot animation when the Microsoft logo goes black for a split second and then it reappears with the "Powered by Android" splash a short while after. P.S I don't have this device and I'm only speaking on behalf of what we discovered on Gus's one. Konrad
Hi, On Fri, 17 Dec 2021 at 15:58, Felipe Balbi <balbi@kernel.org> wrote: > > From: Felipe Balbi <felipe.balbi@microsoft.com> > > Hi folks, > > I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking > through some internal docs, it came to my attention that the bootloader > will fill up the framebuffer address and size to a memory node names > splash_region. Adding the node, I can see the address of the > framebuffer. Creating the relevant framebuffer device using > simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom > of=/dev/fb0 and fb-test. None of which manage to get rid of what's > already on the screen, put there by the bootloader (platform Logo). > > Wondering if any of you have seen a behavior such as this and how did > you manage to get framebuffer working on SM8150 (I see at least Sony > Xperia has the node). What issues do you have with the DRM_MSM/DPU1 driver? I think it supports 8150. > > Felipe Balbi (2): > arm64: boot: dts: qcom: sm8150: add a label for reserved-memory > arm64: boot: dts: qcom: surface duo: add minimal framebuffer > > .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++ > arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- > 2 files changed, 20 insertions(+), 1 deletion(-) > > -- > 2.34.1
Hi, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes: > Hi, > > On Fri, 17 Dec 2021 at 15:58, Felipe Balbi <balbi@kernel.org> wrote: >> >> From: Felipe Balbi <felipe.balbi@microsoft.com> >> >> Hi folks, >> >> I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking >> through some internal docs, it came to my attention that the bootloader >> will fill up the framebuffer address and size to a memory node names >> splash_region. Adding the node, I can see the address of the >> framebuffer. Creating the relevant framebuffer device using >> simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom >> of=/dev/fb0 and fb-test. None of which manage to get rid of what's >> already on the screen, put there by the bootloader (platform Logo). >> >> Wondering if any of you have seen a behavior such as this and how did >> you manage to get framebuffer working on SM8150 (I see at least Sony >> Xperia has the node). > > What issues do you have with the DRM_MSM/DPU1 driver? I think it supports 8150. I haven't tried using it. I'll give it a shot next week.
Hi Konrad, Konrad Dybcio <konrad.dybcio@somainline.org> writes: > On 17.12.2021 13:57, Felipe Balbi wrote: >> From: Felipe Balbi <felipe.balbi@microsoft.com> >> >> Hi folks, >> >> I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking >> through some internal docs, it came to my attention that the bootloader >> will fill up the framebuffer address and size to a memory node names >> splash_region. Adding the node, I can see the address of the >> framebuffer. Creating the relevant framebuffer device using >> simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom >> of=/dev/fb0 and fb-test. None of which manage to get rid of what's >> already on the screen, put there by the bootloader (platform Logo). >> >> Wondering if any of you have seen a behavior such as this and how did >> you manage to get framebuffer working on SM8150 (I see at least Sony >> Xperia has the node). >> >> Felipe Balbi (2): >> arm64: boot: dts: qcom: sm8150: add a label for reserved-memory >> arm64: boot: dts: qcom: surface duo: add minimal framebuffer >> >> .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++ >> arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- >> 2 files changed, 20 insertions(+), 1 deletion(-) > > Hi, > > > this issue is totally unique to the Duo and your bootloader configuration. > > > Gus (CCd, co-author of Lumia 950/XL patches) and I were dissecting > this precise issue (albeit for a different usecase) and in our testing > it turned out that XBL likely kills the display stack upon exiting > Boot Services and jumping to LinuxLoader. This may be a bug that comes > from the legacy of this device, as exiting Boot Services would be > rather undesirable in that scenario.. This is very nice background information which I didn't have. Thanks :-) > One fix would be to ask the bootloader team to look into it and fix it > from there, otherwise you'd have to bring up the display using the > DPU1 driver, or perhaps in a third-stage-bootloader (pls don't do it I'll give DPU1 a shot, thanks for the pointer > for the sanity of us all :D) no 3rd stages :-)
On 18.12.2021 08:17, Felipe Balbi wrote: > Hi Konrad, > > Konrad Dybcio <konrad.dybcio@somainline.org> writes: > >> On 17.12.2021 13:57, Felipe Balbi wrote: >>> From: Felipe Balbi <felipe.balbi@microsoft.com> >>> >>> Hi folks, >>> >>> I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking >>> through some internal docs, it came to my attention that the bootloader >>> will fill up the framebuffer address and size to a memory node names >>> splash_region. Adding the node, I can see the address of the >>> framebuffer. Creating the relevant framebuffer device using >>> simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom >>> of=/dev/fb0 and fb-test. None of which manage to get rid of what's >>> already on the screen, put there by the bootloader (platform Logo). >>> >>> Wondering if any of you have seen a behavior such as this and how did >>> you manage to get framebuffer working on SM8150 (I see at least Sony >>> Xperia has the node). >>> >>> Felipe Balbi (2): >>> arm64: boot: dts: qcom: sm8150: add a label for reserved-memory >>> arm64: boot: dts: qcom: surface duo: add minimal framebuffer >>> >>> .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++ >>> arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- >>> 2 files changed, 20 insertions(+), 1 deletion(-) >> Hi, >> >> >> this issue is totally unique to the Duo and your bootloader configuration. >> >> >> Gus (CCd, co-author of Lumia 950/XL patches) and I were dissecting >> this precise issue (albeit for a different usecase) and in our testing >> it turned out that XBL likely kills the display stack upon exiting >> Boot Services and jumping to LinuxLoader. This may be a bug that comes >> from the legacy of this device, as exiting Boot Services would be >> rather undesirable in that scenario.. > This is very nice background information which I didn't have. Thanks :-) > >> One fix would be to ask the bootloader team to look into it and fix it >> from there, otherwise you'd have to bring up the display using the >> DPU1 driver, or perhaps in a third-stage-bootloader (pls don't do it > I'll give DPU1 a shot, thanks for the pointer Won't work yet. Your display (well, displays.. hehe) are CMD mode and have DSC. Both of which are unsupported on SM8150. DSC patches by Vinod seem to only work on 845 (or at least don't work on 8250 for me) and Marijn from SoMainline (added to CC) is working on cleaning up CMD mode support, as Qualcomm moved the pingpong functionality (basically the way of SoC telling the panel HEY IT'S TIME TO DRAW A FRAME) to a different hardware block and that needs some care in code). >> for the sanity of us all :D) > no 3rd stages :-) > Good :P Konrad
From: Felipe Balbi <felipe.balbi@microsoft.com> Hi folks, I'm trying to enable the framebuffer on Microsoft Surface Duo. Looking through some internal docs, it came to my attention that the bootloader will fill up the framebuffer address and size to a memory node names splash_region. Adding the node, I can see the address of the framebuffer. Creating the relevant framebuffer device using simple-framebuffer, I can't see it working. Tried dd if=/dev/urandom of=/dev/fb0 and fb-test. None of which manage to get rid of what's already on the screen, put there by the bootloader (platform Logo). Wondering if any of you have seen a behavior such as this and how did you manage to get framebuffer working on SM8150 (I see at least Sony Xperia has the node). Felipe Balbi (2): arm64: boot: dts: qcom: sm8150: add a label for reserved-memory arm64: boot: dts: qcom: surface duo: add minimal framebuffer .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++ arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- 2 files changed, 20 insertions(+), 1 deletion(-)