[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CV9ZIJFTEBQE.1035ODUQD2B78@otso>
Date: Mon, 04 Sep 2023 10:19:49 +0200
From: "Luca Weiss" <luca.weiss@...rphone.com>
To: "Konrad Dybcio" <konrad.dybcio@...aro.org>,
<cros-qcom-dts-watchers@...omium.org>,
"Andy Gross" <agross@...nel.org>,
"Bjorn Andersson" <andersson@...nel.org>,
"Rob Herring" <robh+dt@...nel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
"Conor Dooley" <conor+dt@...nel.org>,
"Srinivas Kandagatla" <srinivas.kandagatla@...aro.org>,
"Linus Walleij" <linus.walleij@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
"Viresh Kumar" <viresh.kumar@...aro.org>
Cc: <~postmarketos/upstreaming@...ts.sr.ht>,
<phone-devel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-gpio@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH 11/11] arm64: dts: qcom: qcm6490: Add device-tree for
Fairphone 5
On Sat Sep 2, 2023 at 1:45 PM CEST, Konrad Dybcio wrote:
> On 1.09.2023 16:27, Luca Weiss wrote:
> > On Wed Aug 30, 2023 at 12:45 PM CEST, Konrad Dybcio wrote:
> >> On 30.08.2023 11:58, Luca Weiss wrote:
> >>> Add device tree for the Fairphone 5 smartphone which is based on
> >>> the QCM6490 SoC.
> >>>
> >>> Supported features are, as of now:
> >>> * Bluetooth
> >>> * Debug UART
> >>> * Display via simplefb
> >>> * Flash/torch LED
> >>> * Flip cover sensor
> >>> * Power & volume buttons
> >>> * RTC
> >>> * SD card
> >>> * USB
> >>> * Various plumbing like regulators, i2c, spi, etc
> >>>
> >>> Signed-off-by: Luca Weiss <luca.weiss@...rphone.com>
> >>> ---
> [...]
>
> >>> + panel: panel {
> >>> + compatible = "boe,rm692e5";
> >> Undocumented compatbile
> >
> > Not quite sure how to document this properly. This dummy panel node is
> > used for the simplefb/simpledrm so that user space can get panel
> > dimensions already.
> >
> > This approach of a separate panel node was apparently preferred when the
> > functionality was upstreamed but of course as can be seen this panel
> > node is very barebones where many properties are not present which would
> > be needed with the full panel driver (once it's working).
> >
> > Also for example for the bindings I think width-mm and height-mm won't
> > be needed anymore since that information will be provided by the driver
> > then.
> >
> > Please let me know how/where to document this.
> As discussed offline, the workflow here would be to oneOf: (wink)
>
> - wait until there's a proper driver and create a binding based on
> what you know (because you have a working driver and can test it)
> is necessary for it to function
>
> - create the binding for that display panel + driver ic combo in
> advance and pray that whatever you put there will be enough when
> you take upon yourself to write the driver
>
> I'd suggest dropping these properties (or keeping them downstream or
> something) for now, the display should not be terribly hard to bring
> up properly, let's hope that can be done soon!
Yeah that sounds like a solution for now.
But for other devices I hope something can be figured out so that these
dummy panels can go into upstream dts. Otherwise the functionality added
in the simplefb driver is kinda useless for pure upstream if noone's
allowed to have incomplete bindings for providing the panel dimensions.
>
> > I'm aware, but will work on this later since it's not useful without
> > USB-C role switching and working audio.
> You can still peek at it in like sysfs or so, but up to you.
Yes, later ;)
Regards
Luca
>
>
> Konrad
Powered by blists - more mailing lists