All of lore.kernel.org
 help / color / mirror / Atom feed
From: Caleb Connolly <caleb@connolly.tech>
To: Konrad Dybcio <konrad.dybcio@somainline.org>,
	Joel Selvaraj <jo@jsfamily.in>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht,
	phone-devel@vger.kernel.org
Subject: Re: [PATCH 0/5] Add support for Xiaomi Poco F1 EBBG variant
Date: Fri, 19 Aug 2022 02:45:10 +0000	[thread overview]
Message-ID: <bf2296e4-aa05-5b71-6217-e15e6a300ab3@connolly.tech> (raw)
In-Reply-To: <bb78f8fb-d6ea-5c37-0531-8d7584bc897b@somainline.org>



On 08/07/2022 21:43, Konrad Dybcio wrote:
>
>
> On 8.07.2022 13:12, Joel Selvaraj wrote:
>> There are two variants of Xiaomi Poco F1.
>> - Tianma variant with NOVATEK NT36672A panel + touchscreen manufactured
>>    by Tianma
>> - EBBG variant with Focaltech FT8719 panel + touchscreen manufactured
>>    by EBBG
>>
>> The current sdm845-xiaomi-beryllium.dts represents tianma panel variant.
>>
>> To add support for the EBBG variant, let's split this into 3 files,
>> - sdm845-xiaomi-beryllium-common.dtsi which contains all the common nodes
>> - sdm845-xiaomi-beryllium-tianma.dts for the tianma variant
>> - sdm845-xiaomi-beryllium-ebbg.dts for the ebbg variant
>>
>> Note:
>> -----
>> Both the panels are already upstreamed and the split is based on them.
>> There were patches earlier for both the touchscreens, but they are not
>> accepted upstream yet. Once they are accepted, we will add them to
>> respective variants.
> Hi,
>
> I believe this is not the correct approach. This may work short-term, but
> you will have to prepare 2 separate images for the device and mistaking them
> may cause irreversible hw damage at worst, or lots of user complaining at best.
> Instead, I think it's about time we should look into implementing dynamic panel
> detection.
>
> Qualcomm devices do this by parsing the command line [1], as LK/XBL
> gives you a nice-ish string to work with that you can simply match
> against a label. Other vendors may use custom mechanisms, such as
> a resistor / GPIO to determine which panel (or generally hw config),
> but implementing this mechanism would make upstreaming of lots of other
> devices easier..

Regarding dynamic panel detection. A mechanism for choosing DT nodes based on some
generic (read: extensible) matching feature would be pretty neat....

e.g. matching cmdline:

panel {
	compatible = "some,w3ird-panel";
	/* Only attempt to probe a driver for this node if cmdline contains
	 * this string. How this is described and the type(s) of matching to
	 * use could be defined.
	 */
	match-if-cmdline = "msm_drm.dsi_display0=some_w3ird-panel";
};

or perhaps GPIO state:

panel {
	compatible = "some,w3ird-panel";
	/* Only attempt to probe a driver for this node if GPIO 43 on tlmm is high,
	 * and GPIO 44 is low.
	 */
	match-if-gpios = <&tlmm 43 GPIO_ACTIVE_HIGH>, <&tlmm 44 GPIO_ACTIVE_LOW>;
};

This certainly introduces the temptation to do awful things...

>
> This issue concerns many phones (and well, devices in general), as
> they are seldom made with only one configuration due to supply chain
> strategies.

It would be really nice to solve this in-kernel, chainloading a bootloader sometimes kinda sucks.
>
>
> Konrad
>
> [1] https://github.com/LineageOS/android_kernel_xiaomi_sdm845/blob/lineage-19.1/drivers/gpu/drm/msm/dsi-staging/dsi_display.c

--
Kind Regards,
Caleb


  parent reply	other threads:[~2022-08-19  2:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 11:12 [PATCH 0/5] Add support for Xiaomi Poco F1 EBBG variant Joel Selvaraj
2022-07-08 20:43 ` Konrad Dybcio
2022-07-09 11:15   ` Joel Selvaraj
2022-08-04 16:21   ` Pavel Machek
2022-08-19  2:45   ` Caleb Connolly [this message]
2022-07-12 13:27 ` Krzysztof Kozlowski
2022-07-13  4:35   ` Joel Selvaraj
2022-07-13  6:51     ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf2296e4-aa05-5b71-6217-e15e6a300ab3@connolly.tech \
    --to=caleb@connolly.tech \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jo@jsfamily.in \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phone-devel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.