All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org,
	aarch64-laptops@lists.linaro.org,
	Rob Clark <robdclark@chromium.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Julien Thierry <julien.thierry@arm.com>,
	"open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)" 
	<linux-efi@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	Lukas Wunner <lukas@wunner.de>,
	Steve Capper <steve.capper@arm.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels
Date: Sun, 30 Jun 2019 23:47:23 +0300	[thread overview]
Message-ID: <20190630204723.GH7043@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190630203614.5290-1-robdclark@gmail.com>

Hi Rob,

Thank you for the patch.

On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> 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

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
To: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Rob Clark <robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	aarch64-laptops-cunTk1MwBs8s++Sfvej+rw@public.gmane.org,
	"open list:EXTENSIBLE FIRMWARE INTERFACE (EFI)"
	<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Will Deacon <will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Ard Biesheuvel
	<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Julien Thierry <julien.thierry-5wv7dgnIgG8@public.gmane.org>,
	open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>,
	Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
	freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Steve Capper <steve.capper-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels
Date: Sun, 30 Jun 2019 23:47:23 +0300	[thread overview]
Message-ID: <20190630204723.GH7043@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190630203614.5290-1-robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hi Rob,

Thank you for the patch.

On Sun, Jun 30, 2019 at 01:36:04PM -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
> 
> 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
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

  parent reply	other threads:[~2019-06-30 20:47 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark
2019-06-30 20:36 ` Rob Clark
2019-06-30 20:36 ` [PATCH 1/4] dt-bindings: chosen: document panel-id binding Rob Clark
2019-06-30 20:36   ` Rob Clark
2019-07-01 14:03   ` Rob Herring
2019-07-01 14:03     ` Rob Herring
2019-07-01 14:28     ` Jeffrey Hugo
2019-07-01 14:28       ` Jeffrey Hugo
2019-07-01 14:41     ` Rob Clark
2019-07-01 15:11       ` Rob Herring
2019-11-30 18:37     ` Rob Clark
2019-11-30 18:37       ` Rob Clark
2019-11-30 18:39       ` Rob Clark
2019-11-30 18:39         ` Rob Clark
2019-11-30 18:39         ` Rob Clark
2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark
2019-06-30 20:36   ` Rob Clark
2019-07-02 20:26   ` Ard Biesheuvel
2019-07-02 20:26     ` Ard Biesheuvel
2019-07-02 20:35     ` Ard Biesheuvel
2019-07-02 20:35       ` Ard Biesheuvel
2019-07-02 21:01       ` Rob Clark
2019-07-02 21:01         ` Rob Clark
2019-07-02 21:53         ` Ard Biesheuvel
2019-07-02 21:53           ` Ard Biesheuvel
2019-07-02 22:36           ` Rob Clark
2019-07-02 22:36             ` Rob Clark
2019-07-02 21:59         ` Leif Lindholm
2019-07-02 21:59           ` Leif Lindholm
2019-07-02 22:48           ` Rob Clark
2019-07-02 22:48             ` Rob Clark
2019-07-03 16:33             ` Leif Lindholm
2019-07-03 17:41               ` Rob Clark
2019-07-03 17:54                 ` Ard Biesheuvel
2019-06-30 20:36 ` [PATCH 3/4] drm: add helper to lookup panel-id Rob Clark
2019-06-30 20:36   ` Rob Clark
2019-06-30 20:36 ` [PATCH 4/4] drm/bridge: ti-sn65dsi86: use " Rob Clark
2019-06-30 20:36   ` Rob Clark
2019-06-30 21:17   ` Laurent Pinchart
2019-06-30 21:17     ` Laurent Pinchart
2019-06-30 21:50     ` Rob Clark
2019-06-30 21:57       ` Laurent Pinchart
2019-06-30 22:04         ` Rob Clark
2019-06-30 22:04           ` Rob Clark
2019-06-30 20:47 ` Laurent Pinchart [this message]
2019-06-30 20:47   ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart
2019-06-30 21:05   ` Rob Clark
2019-06-30 21:15     ` Laurent Pinchart
2019-06-30 21:15       ` Laurent Pinchart
2019-06-30 21:35       ` Rob Clark
2019-06-30 21:35         ` Rob Clark
2019-07-02 12:50 ` Rob Clark
2019-07-02 12:50   ` Rob Clark

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=20190630204723.GH7043@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=aarch64-laptops@lists.linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mingo@kernel.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=steve.capper@arm.com \
    --cc=will@kernel.org \
    /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.