Re: [PATCH v2] arm64: dts: qcom: sm8250-edo: Panel framebuffer is 2.5k instead of 4k

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 14/06/23 14:43, Konrad Dybcio ha scritto:
On 14.06.2023 14:40, Marijn Suijten wrote:
On 2023-06-07 09:15:08, AngeloGioacchino Del Regno wrote:
Il 07/06/23 00:52, Konrad Dybcio ha scritto:


On 6.06.2023 23:14, Marijn Suijten wrote:
The framebuffer configuration for edo pdx203, written in edo dtsi (which
is overwritten in pdx206 dts for its smaller panel) has to use a
1096x2560 configuration as this is what the panel (and framebuffer area)
has been initialized to.  Downstream userspace also has access to (and
uses) this 2.5k mode by default, and only switches the panel to 4k when
requested.

This is similar to commit be8de06dc397 ("arm64: dts: qcom:
sm8150-kumano: Panel framebuffer is 2.5k instead of 4k") which fixed the
same for the previous generation Sony platform.

Fixes: 69cdb97ef652 ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)")
Signed-off-by: Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx>
---
And so I derped again.

Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>

I would've liked more to see a commit saying "replace simple-framebuffer with xxxx"
(where xxxx is DSI panel, etc) but that will as well do for now... :-)

Fwiw we could keep it around as MDSS "gracefully" takes over when it
probes a little bit later with fbcon over DRM/KMS, and it sometimes
helps reading what is up when something fails before or during MDSS
probe.
I believe we should do this. Perhaps even add some early code to drm/msm
that'd read out the address (and other configuration) from the mdp hw and
set it up automagically.


As far as I remember, some bootloaders are reading devicetrees to setup the display
at boot with "continuous splash", that's why I would be for *replacing* the simple
framebuffer with the mdss-dsi.

Adding early code to drm/msm to read out the address and check the state of the HW
before pushing an early framebuffer would be a definitive solution for that corner
case. Good call, Konrad.

Cheers,
Angelo

Konrad

- Marijn

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>


Konrad

Changes since v2:
- Rename griffin (copy-paste from related patch) to pdx203 in comment.

   arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi | 7 ++++---
   1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
index 3d22be747f042..8f867f841cb83 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo.dtsi
@@ -54,9 +54,10 @@ chosen {
   		framebuffer: framebuffer@9c000000 {
   			compatible = "simple-framebuffer";
   			reg = <0 0x9c000000 0 0x2300000>;
-			width = <1644>;
-			height = <3840>;
-			stride = <(1644 * 4)>;
+			/* pdx203 BL initializes in 2.5k mode, not 4k */
+			width = <1096>;
+			height = <2560>;
+			stride = <(1096 * 4)>;
   			format = "a8r8g8b8";
   		};
   	};







[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux