Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Rob,

Thank you for the patch.

On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@xxxxxxxxxxxx>
> 
> Now that we can deal gracefully with bootloader (firmware) initialized
> display on aarch64 laptops[1], the next step is to deal with the fact
> that the same model of laptop can have one of multiple different panels.
> (For the yoga c630 that I have, I know of at least two possible panels,
> there might be a third.)

I have to ask the obvious question: why doesn't the boot loader just
pass a correct DT to Linux ? There's no point in passing a list of
panels that are not there, this seems quite a big hack to me. A proper
boot loader should construct the DT based on hardware detection.

> This is actually a scenario that comes up frequently in phones and
> tablets as well, so it is useful to have an upstream solution for this.
> 
> The basic idea is to add a 'panel-id' property in dt chosen node, and
> use that to pick the endpoint we look at when loading the panel driver,
> e.g.
> 
> / {
> 	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";
> 		power-supply = <&vlcm_3v3>;
> 		no-hpd;
> 
> 		ports {
> 			port {
> 				boe_panel_in_edp: endpoint {
> 					remote-endpoint = <&sn65dsi86_out_boe>;
> 				};
> 			};
> 		};
> 	};
> 
> 	sn65dsi86: bridge@2c {
> 		compatible = "ti,sn65dsi86";
> 
> 		...
> 
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			...
> 
> 			port@1 {
> 				#address-cells = <1>;
> 				#size-cells = <0>;
> 				reg = <1>;
> 
> 				endpoint@c4 {
> 					reg = <0xc4>;
> 					remote-endpoint = <&boe_panel_in_edp>;
> 				};
> 
> 				endpoint@c5 {
> 					reg = <0xc5>;
> 					remote-endpoint = <&ivo_panel_in_edp>;
> 				};
> 			};
> 		};
> 	}
> };
> 
> Note that the panel-id is potentially a sparse-int.  The values I've
> seen so far on aarch64 laptops are:
> 
>   * 0xc2
>   * 0xc3
>   * 0xc4
>   * 0xc5
>   * 0x8011
>   * 0x8012
>   * 0x8055
>   * 0x8056
> 
> At least on snapdragon aarch64 laptops, they can be any u32 value.
> 
> However, on these laptops, the bootloader/firmware is not populating the
> chosen node, but instead providing an "UEFIDisplayInfo" variable, which
> contains the panel id.  Unfortunately EFI variables are only available
> before ExitBootServices, so the second patch checks for this variable
> before EBS and populates the /chosen/panel-id variable.
> 
> [1] https://patchwork.freedesktop.org/series/63001/
> 
> Rob Clark (4):
>   dt-bindings: chosen: document panel-id binding
>   efi/libstub: detect panel-id
>   drm: add helper to lookup panel-id
>   drm/bridge: ti-sn65dsi86: use helper to lookup panel-id
> 
>  Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++
>  drivers/firmware/efi/libstub/arm-stub.c      | 49 ++++++++++++++
>  drivers/firmware/efi/libstub/efistub.h       |  2 +
>  drivers/firmware/efi/libstub/fdt.c           |  9 +++
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c        |  5 +-
>  drivers/gpu/drm/drm_of.c                     | 21 ++++++
>  include/drm/drm_of.h                         |  7 ++
>  7 files changed, 160 insertions(+), 2 deletions(-)

-- 
Regards,

Laurent Pinchart



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux