On Mon, Jul 1, 2019 at 7:03 AM Rob Herring robh+dt@kernel.org wrote:
On Sun, Jun 30, 2019 at 2:36 PM Rob Clark robdclark@gmail.com wrote:
From: Rob Clark robdclark@chromium.org
The panel-id property in chosen can be used to communicate which panel, of multiple possibilities, is installed.
Signed-off-by: Rob Clark robdclark@chromium.org
Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++ 1 file changed, 69 insertions(+)
I need to update this file to say it's moved to the schema repository...
But I don't think that will matter...
diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index 45e79172a646..d502e6489b8b 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found. However, the "linux,stdout-path" and "stdout" properties are deprecated. New platforms should only use the "stdout-path" property.
+panel-id +--------
+For devices that have multiple possible display panels (multi-sourcing the +display panels is common on laptops, phones, tablets), this allows the +bootloader to communicate which panel is installed, e.g.
How does the bootloader figure out which panel? Why can't the kernel do the same thing?
see jhugo's response, he has I guess more access to the bootloader than I
+/ {
chosen {panel-id = <0xc4>;};ivo_panel {compatible = "ivo,m133nwf4-r0";power-supply = <&vlcm_3v3>;no-hpd;ports {port {ivo_panel_in_edp: endpoint {remote-endpoint = <&sn65dsi86_out_ivo>;};};};};boe_panel {compatible = "boe,nv133fhm-n61";Both panels are going to probe. So the bootloader needs to disable the not populated panel setting 'status' (or delete the node). If you do that, do you even need 'panel-id'?
I don't think we can rely on bootloader knowing a thing about DT on these devices..
OTOH I don't really think it is a big problem for both panels to probe. But I suppose it might be possible to have something somewhere in the kernel that realizes and disables the unused panels.
power-supply = <&vlcm_3v3>;no-hpd;ports {port {boe_panel_in_edp: endpoint {remote-endpoint = <&sn65dsi86_out_boe>;};};};};display_or_bridge_device {ports {#address-cells = <1>;#size-cells = <0>;...port@0 {#address-cells = <1>;#size-cells = <0>;reg = <0>;endpoint@c4 {reg = <0xc4>;What does this number represent? It is supposed to be defined by the display_or_bridge_device, not a specific panel.
it matches /chosen/panel-id.. in this case I'm not sure how the panel-id's are assigned, but for our purposes all that matters is that they are assigned.
We also need to consider how the DSI case with panels as children of the DSI controller would work and how this would work with multiple displays each having multiple panel options.
In the non-bridge case (panel hooked directly to dsi controller), the dsi controller could use the same ports {} mechanism.
For multiple displays, we could extend, I suppose, /chosen/panel-id to be an array of id's indexed by display. I think this is the type of extension we could do later when the use-case comes up. Just having this solved upstream for single display would already be a huge advancement. (You don't want to look at how this is solved downstream for android phones.)
Btw, if you are curious how this works on windows/ACPI, the ACPI tables have entries for each of the panels. The kernel is expected to take the panel-id from that EFI variable that jhugo mentioned, and pass it to a _ROM method which returns the appropriate panel table. (Not entirely sure how the orchestrate reading the EFI variable early, since it does not appear to be available after ExitBootServices)
BR, -R