[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e58978d6-dc6a-468f-91d5-29d7b0755e79@oss.qualcomm.com>
Date: Tue, 7 Oct 2025 15:55:35 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Alexey Minnekhanov <alexeymin@...lexx.ru>,
Paul Sajna <sajattack@...tmarketos.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley
<conor+dt@...nel.org>, David Heidelberg <david@...t.cz>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
Amir Dahan <system64fumo@...tonmail.com>,
Christopher Brown <crispybrown@...il.com>
Subject: Re: [PATCH v2 09/13] arm64: dts: qcom: sdm845-lg-judyln: Add fb_panel
dimensions
On 9/17/25 4:54 PM, Alexey Minnekhanov wrote:
> On 17.09.2025 16:59, Konrad Dybcio wrote:
>> On 9/17/25 3:09 AM, Paul Sajna wrote:
>>> Add display dimensions for proper scaling
>>>
>>> Signed-off-by: Paul Sajna <sajattack@...tmarketos.org>
>>> ---
>>> arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>>> index e84b45ed82fd13850ea7ec1f34ddac5b59fc1434..8c1692f86e6ceea7b718361965e78f95d39373bb 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
>>> @@ -23,6 +23,13 @@ framebuffer@...00000 {
>>> format = "a8r8g8b8";
>>> lab-supply = <&lab>;
>>> ibb-supply = <&ibb>;
>>> +
>>> + panel = <&fb_panel>;
>>> +
>>> + fb_panel: fb-panel {
>>> + width-mm = <65>;
>>> + height-mm = <140>;
>>
>> It'd be nicer if you moved these properties to the actual panel
>> node (the DSI one) and referenced that one instead (I think that
>> should work)
>>
>> Konrad
>>
>
> Hi!
>
> First of all this code doesn't work well for upstream, because it causes
> errors with dtbs checks like:
>
> framebuffer@...00000 (simple-framebuffer): 'fb-panel' does not match any of the regexes: '^[a-zA-Z0-9-]+-supply$', '^pinctrl-[0-9]+$'
>
> ^^ The subnode is not allowed by bindings.
>
> The whole reasoning for this little hack is that the upstream
> recommended approach to solve the "unknown DPI" for framebuffer issue
> is to put width-mm, height-mm into real panel node and and reference it
> in simple-fb node - sonds very nice in theory, but also doesn't work
> well in practice, and explanation why will take a bit longer, please
> bear with me for a minute.
>
> If we do as recommended, device tree structure will look like this:
>
> framebuffer@...00000 {
> ...
> panel = <&display_panel>;
> };
>
> soc@0 {
> ....
>
> mdss {
> ...
> dsi0 {
> ...
> display_panel: panel@0 {
> reg = <0>;
> compatible = "lg,sw49410";
> ...
> width-mm = <65>;
> height-mm = <140>;
> };
> ...
>
> Then, to my understanding, due to how fw-devlink works, the panel=<&..>
> link from simplefb node to display_panel node creates a probe-time
> dependency, so that the whole display stack probes first: MDSS, DSI
> controller, maybe even Adreno GPU, *AND* panel all probe first, thus
> making the mere existence of simple-framebuffer pointless.
>
> Additionally, simple-framebuffer probes succesfully after that,
> creating "second GPU" entry in as /dev/dri/card1 making it look like
> system has 2 GPUS, which confuses almost every window manager in
> userspace later. Normally, if simplefb probes first, it gets unloaded
> and replaced by MDSS and does not cause any chaos. In the end the whole
> situation looks even more silly than the fake panel subnode hack.
>
> Therefore for upstream I'd recommend to just drop any fb-panel hacks and
> to not use panel=<&...> with reference to real panel either.
>
> It would all be much much easier if we could just specify width-mm/
> height-mm directly in simplefb node, but DT maintainers rejected that idea.
Would adding post-init-providers = <&real_panel> help?
Konrad
Powered by blists - more mailing lists