* [RFC/patch 1/2] arm64: boot: dts: qcom: sm8150: add a label for reserved-memory
2021-12-17 12:57 [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Felipe Balbi
@ 2021-12-17 12:57 ` Felipe Balbi
2021-12-17 12:57 ` [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer Felipe Balbi
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Felipe Balbi @ 2021-12-17 12:57 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio
Cc: Rob Herring, linux-arm-msm, devicetree, linux-kernel, Felipe Balbi
From: Felipe Balbi <felipe.balbi@microsoft.com>
With this label, we can let boards append board-specific memory
regions which should not be mapped.
Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 15348512cf9e..26f9eb8e9b42 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -660,7 +660,7 @@ CLUSTER_PD: cpu-cluster0 {
};
};
- reserved-memory {
+ reserved_memory: reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
2.34.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer
2021-12-17 12:57 [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Felipe Balbi
2021-12-17 12:57 ` [RFC/patch 1/2] arm64: boot: dts: qcom: sm8150: add a label for reserved-memory Felipe Balbi
@ 2021-12-17 12:57 ` Felipe Balbi
2021-12-17 17:32 ` Konrad Dybcio
[not found] ` <92001103-6b29-7ad9-eea3-34fd30c5f767@postmarketos.org>
2021-12-17 17:16 ` [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Konrad Dybcio
2021-12-18 0:24 ` Dmitry Baryshkov
3 siblings, 2 replies; 11+ messages in thread
From: Felipe Balbi @ 2021-12-17 12:57 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio
Cc: Rob Herring, linux-arm-msm, devicetree, linux-kernel, Felipe Balbi
From: Felipe Balbi <felipe.balbi@microsoft.com>
Add a minimal framebuffer device so we can use the display on the
Surface Duo device.
Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
---
.../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
index a73317e1a824..c629ec115fec 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
@@ -25,6 +25,17 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ framebuffer0: framebuffer@9c000000 {
+ compatible = "simple-framebuffer";
+ reg = <0 0x9c000000 0 0x02400000>;
+ status = "okay";
+
+ height = <1800>;
+ width = <1350>;
+ stride = <(1350 * 4)>;
+ format = "a8r8g8b8";
+ };
+
vph_pwr: vph-pwr-regulator {
compatible = "regulator-fixed";
regulator-name = "vph_pwr";
@@ -472,6 +483,14 @@ &pon_resin {
linux,code = <KEY_VOLUMEDOWN>;
};
+&reserved_memory {
+ splash_region: splash_region@9c000000 {
+ /* We expect the bootloader to fill in the size */
+ reg = <0x0 0x9c000000 0x0 0x0>;
+ no-map;
+ };
+};
+
&tlmm {
gpio-reserved-ranges = <126 4>;
--
2.34.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer
2021-12-17 12:57 ` [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer Felipe Balbi
@ 2021-12-17 17:32 ` Konrad Dybcio
2021-12-18 7:19 ` Felipe Balbi
[not found] ` <92001103-6b29-7ad9-eea3-34fd30c5f767@postmarketos.org>
1 sibling, 1 reply; 11+ messages in thread
From: Konrad Dybcio @ 2021-12-17 17:32 UTC (permalink / raw)
To: Felipe Balbi, Andy Gross, Bjorn Andersson
Cc: Rob Herring, linux-arm-msm, devicetree, linux-kernel, Felipe Balbi
On 17.12.2021 13:57, Felipe Balbi wrote:
> From: Felipe Balbi <felipe.balbi@microsoft.com>
>
> Add a minimal framebuffer device so we can use the display on the
> Surface Duo device.
>
> Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
> ---
> .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
> index a73317e1a824..c629ec115fec 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
> @@ -25,6 +25,17 @@ chosen {
> stdout-path = "serial0:115200n8";
> };
>
> + framebuffer0: framebuffer@9c000000 {
> + compatible = "simple-framebuffer";
> + reg = <0 0x9c000000 0 0x02400000>;
You can remove the leading 0 in the size cell.
> + status = "okay";
This line is unnecessary, as it's enabled by default
> +
> + height = <1800>;
> + width = <1350>;
> + stride = <(1350 * 4)>;
> + format = "a8r8g8b8";
> + };
> +
> vph_pwr: vph-pwr-regulator {
> compatible = "regulator-fixed";
> regulator-name = "vph_pwr";
> @@ -472,6 +483,14 @@ &pon_resin {
> linux,code = <KEY_VOLUMEDOWN>;
> };
>
> +&reserved_memory {
> + splash_region: splash_region@9c000000 {
> + /* We expect the bootloader to fill in the size */
Would it be different than the framebuffer size?
> + reg = <0x0 0x9c000000 0x0 0x0>;
> + no-map;
> + };
> +};
> +
> &tlmm {
> gpio-reserved-ranges = <126 4>;
>
Konrad
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer
2021-12-17 17:32 ` Konrad Dybcio
@ 2021-12-18 7:19 ` Felipe Balbi
0 siblings, 0 replies; 11+ messages in thread
From: Felipe Balbi @ 2021-12-18 7:19 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, linux-kernel
Hi,
Konrad Dybcio <konrad.dybcio@somainline.org> writes:
> On 17.12.2021 13:57, Felipe Balbi wrote:
>> From: Felipe Balbi <felipe.balbi@microsoft.com>
>>
>> Add a minimal framebuffer device so we can use the display on the
>> Surface Duo device.
>>
>> Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
>> ---
>> .../dts/qcom/sm8150-microsoft-surface-duo.dts | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
>> index a73317e1a824..c629ec115fec 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
>> +++ b/arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dts
>> @@ -25,6 +25,17 @@ chosen {
>> stdout-path = "serial0:115200n8";
>> };
>>
>> + framebuffer0: framebuffer@9c000000 {
>> + compatible = "simple-framebuffer";
>> + reg = <0 0x9c000000 0 0x02400000>;
>
> You can remove the leading 0 in the size cell.
okay
>> + status = "okay";
>
> This line is unnecessary, as it's enabled by default
understood
>> @@ -472,6 +483,14 @@ &pon_resin {
>> linux,code = <KEY_VOLUMEDOWN>;
>> };
>>
>> +&reserved_memory {
>> + splash_region: splash_region@9c000000 {
>> + /* We expect the bootloader to fill in the size */
>
> Would it be different than the framebuffer size?
honestly, I used this mainly to get the correct base address and size. I
had 0 everywhere and bootloader filled the entire thing for me. I can
just hardcode with the expected values anyway.
--
balbi
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <92001103-6b29-7ad9-eea3-34fd30c5f767@postmarketos.org>]
* Re: [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer
[not found] ` <92001103-6b29-7ad9-eea3-34fd30c5f767@postmarketos.org>
@ 2021-12-18 7:15 ` Felipe Balbi
0 siblings, 0 replies; 11+ messages in thread
From: Felipe Balbi @ 2021-12-18 7:15 UTC (permalink / raw)
To: Alexey Minnekhanov
Cc: Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-kernel
Hi,
Alexey Minnekhanov <alexeymin@postmarketos.org> writes:
> @@ -472,6 +483,14 @@ &pon_resin {
> linux,code = <KEY_VOLUMEDOWN>;
> };
>
> +&reserved_memory {
> + splash_region: splash_region@9c000000 {
> + /* We expect the bootloader to fill in the size */
> + reg = <0x0 0x9c000000 0x0 0x0>;
>
> 0x2400000 should be here as size, maybe?
bootloader is filling that up, but sure I only used this to get the size
and base address from bootloader. I could just hardcode the values now
that I know them :-)
>
> cont_splash_mem: memory@9c000000 {
> reg = <0x0 0x9c000000 0x0 0x2400000>;
> no-map;
> };
>
> FWIW, example above (with similar simple-framebuffer
> node) worked fine for my sm8150 based device.
Oh okay. So it's likely to be something specific to our bootloader.
--
balbi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo
2021-12-17 12:57 [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Felipe Balbi
2021-12-17 12:57 ` [RFC/patch 1/2] arm64: boot: dts: qcom: sm8150: add a label for reserved-memory Felipe Balbi
2021-12-17 12:57 ` [RFC/patch 2/2] arm64: boot: dts: qcom: surface duo: add minimal framebuffer Felipe Balbi
@ 2021-12-17 17:16 ` Konrad Dybcio
2021-12-18 7:17 ` Felipe Balbi
2021-12-18 0:24 ` Dmitry Baryshkov
3 siblings, 1 reply; 11+ messages in thread
From: Konrad Dybcio @ 2021-12-17 17:16 UTC (permalink / raw)
To: Felipe Balbi, Andy Gross, Bjorn Andersson
Cc: Rob Herring, linux-arm-msm, devicetree, linux-kernel,
Felipe Balbi, Gustave Monce
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo
2021-12-17 17:16 ` [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Konrad Dybcio
@ 2021-12-18 7:17 ` Felipe Balbi
2021-12-18 9:13 ` Konrad Dybcio
0 siblings, 1 reply; 11+ messages in thread
From: Felipe Balbi @ 2021-12-18 7:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, linux-kernel, Gustave Monce
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 :-)
--
balbi
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo
2021-12-18 7:17 ` Felipe Balbi
@ 2021-12-18 9:13 ` Konrad Dybcio
0 siblings, 0 replies; 11+ messages in thread
From: Konrad Dybcio @ 2021-12-18 9:13 UTC (permalink / raw)
To: Felipe Balbi
Cc: Andy Gross, Bjorn Andersson, Rob Herring, linux-arm-msm,
devicetree, linux-kernel, Gustave Monce, Marijn Suijten
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo
2021-12-17 12:57 [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Felipe Balbi
` (2 preceding siblings ...)
2021-12-17 17:16 ` [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo Konrad Dybcio
@ 2021-12-18 0:24 ` Dmitry Baryshkov
2021-12-18 7:17 ` Felipe Balbi
3 siblings, 1 reply; 11+ messages in thread
From: Dmitry Baryshkov @ 2021-12-18 0:24 UTC (permalink / raw)
To: Felipe Balbi
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
linux-arm-msm, devicetree, linux-kernel, Felipe Balbi
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
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC/patch 0/2] arm64: boot: dts: qcom: sm8150: enable framebuffer for Surface Duo
2021-12-18 0:24 ` Dmitry Baryshkov
@ 2021-12-18 7:17 ` Felipe Balbi
0 siblings, 0 replies; 11+ messages in thread
From: Felipe Balbi @ 2021-12-18 7:17 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
linux-arm-msm, devicetree, linux-kernel
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.
--
balbi
^ permalink raw reply [flat|nested] 11+ messages in thread