On 2021-06-02 04:01, Vinod Koul wrote:

On 27-05-21, 16:30, Rob Clark wrote:

quoted

On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo 
[off-list ref] wrote:

quoted

On Tue, May 25, 2021 at 11:46 PM Vinod Koul [off-list ref] wrote:

quoted

quoted

Frankly, I don't like the MSM ACPI solution that I've seen on the laptops.
The ACPI assumes the entire MDSS (including DSI parts) and GPU is one
device, and ultimately handled by one driver.  That driver needs to
get a value from UEFI (set by the bootloader) that is the "panel id".
Then the driver calls into ACPI (I think its _ROM, but I might be
mistaken, doing this from memory) with that id.  It gets back a binary
blob which is mostly an xml file (format is publicly documented) that
contains the panel timings and such.

tbh, I kinda suspect that having a single "gpu" device (which also
includes venus, in addition to display, IIRC) in the ACPI tables is a
windowsism, trying to make things look to userspace like a single "GPU
card" in the x86 world.. but either way, I think the ACPI tables on
the windows arm laptops which use dsi->bridge->edp is too much of a
lost cause to even consider here.  Possibly ACPI boot on these devices
would be more feasible on newer devices which have direct eDP out of
the SoC without requiring external bridge/panel glue.

yeah that is always a very different world. although it might make 
sense
to use information in tables and try to deduce information about the
system can be helpful...

quoted

I'd worry more about what makes sense in a DT world, when it comes to
DT bindings.

And do you have thoughts on that..?

At the moment, I will comment on the bindings first and my idea on how 
to proceed.
The bindings mentioned here: 
https://lore.kernel.org/dri-devel/20210521124946.3617862-3-vkoul@kernel.org/ (local) 
seem to be just
taken directly from downstream which was not the plan.

I think all of these should be part of the generic panel bindings as 
none of these are QC specific:

@@ -188,6 +195,14 @@ Example:
  		qcom,master-dsi;
  		qcom,sync-dual-dsi;

+		qcom,mdss-dsc-enabled;
+		qcom,mdss-slice-height = <16>;
+		qcom,mdss-slice-width = <540>;
+		qcom,mdss-slice-per-pkt = <1>;
+		qcom,mdss-bit-per-component = <8>;
+		qcom,mdss-bit-per-pixel = <8>;
+		qcom,mdss-block-prediction-enable;
+

How about having a panel-dsc.yaml which will have these properties and 
have a panel-dsc node to have this information?

I would like to hear the feedback on this proposal then the series can 
be reworked.

Thanks

Abhinav