All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off
Date: Mon, 16 Dec 2019 16:14:50 +0200	[thread overview]
Message-ID: <20191216141450.GU1208@intel.com> (raw)
In-Reply-To: <c7fe3911-be20-33dd-96c1-58eccd0f323f@redhat.com>

On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
> Hi,
> 
> Thank you for the reviews.
> 
> On 16-12-2019 14:45, Ville Syrjälä wrote:
> > On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
> >> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> >> device was booted with an external monitor connected over HDMI, we should
> >> not turn on the panel-enable GPIO when we request it.
> >>
> >> Turning on the panel-enable GPIO when we request it, means we turn it on
> >> too early in the init-sequence, which causes some panels to not correctly
> >> light up.
> >>
> >> This commits adds a panel_is_on parameter to intel_dsi_vbt_gpio_init()
> >> and makes intel_dsi_vbt_gpio_init() set the initial GPIO value accordingly.
> >>
> >> This fixes the panel not lighting up on a Thundersoft TST168 tablet when
> >> booted with an external monitor connected over HDMI.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_dsi.h     | 2 +-
> >>   drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 +++----
> >>   drivers/gpu/drm/i915/display/vlv_dsi.c       | 2 +-
> >>   3 files changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> index de7e51cd3460..675771ea91aa 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> @@ -203,7 +203,7 @@ void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
> >>   
> >>   /* intel_dsi_vbt.c */
> >>   bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi);
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on);
> >>   void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
> >>   void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
> >>   				 enum mipi_seq seq_id);
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> index 5352e8c9eca5..027970348b22 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> @@ -688,17 +688,16 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
> >>    * On some BYT/CHT devs some sequences are incomplete and we need to manually
> >>    * control some GPIOs.
> >>    */
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi)
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on)
> >>   {
> >>   	struct drm_device *dev = intel_dsi->base.base.dev;
> >>   	struct drm_i915_private *dev_priv = to_i915(dev);
> >>   	struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
> >> +	enum gpiod_flags flags = panel_is_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> > 
> > Can't we just tell it not to change the current setting?
> 
> We could use GPIOD_ASIS for that, but with the SoC pins (when the PMIC is
> not used for backlight control) things get a bit muddy, I've seen several
> instances of this message from drivers/pinctrl/intel/pinctrl-baytrail.c
> trigger when the GOP did not init the panel:
> 
> dev_warn(vg->dev, FW_BUG "pin %u forcibly re-configured as GPIO\n", offset);
> 
> And in that case with GPIOD_ASIS I have no idea which we initially get,
> so this approach, where we clearly define which initial value we want,
> seems better.

I suppose. Probably better to not abuse the current_mode pointer for
that though and just explicitly call encoder->get_hw_state() instead.

> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> The intel-gfx CI seems to seriously dislike my patches lately, almost
> always failing them; and usually on what at least seem to be unrelated
> test-cases. Any advice on how to deal with this?

Yeah, CI is snafu. I keep smashing retest until it gets through BAT
and then just double check the shard results to make sure nothing
relevant has tripped. If things look OK I recommend replying to the
result mail and provide a few short log snippets/other details on
what failed so that it's clear that it's irrelevant.

> 
> 
> 
> 
> > 
> >>   
> >>   	if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> >>   	    (mipi_config->pwm_blc == PPS_BLC_PMIC)) {
> >> -		intel_dsi->gpio_panel =
> >> -			gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
> >> -
> >> +		intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", flags);
> >>   		if (IS_ERR(intel_dsi->gpio_panel)) {
> >>   			DRM_ERROR("Failed to own gpio for panel control\n");
> >>   			intel_dsi->gpio_panel = NULL;
> >> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> index 178d0fffba5b..e86e4a11e199 100644
> >> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> @@ -1910,7 +1910,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> >>   
> >>   	vlv_dphy_param_init(intel_dsi);
> >>   
> >> -	intel_dsi_vbt_gpio_init(intel_dsi);
> >> +	intel_dsi_vbt_gpio_init(intel_dsi, current_mode != NULL);
> >>   
> >>   	drm_connector_init(dev, connector, &intel_dsi_connector_funcs,
> >>   			   DRM_MODE_CONNECTOR_DSI);
> >> -- 
> >> 2.23.0
> > 

-- 
Ville Syrjälä
Intel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off
Date: Mon, 16 Dec 2019 16:14:50 +0200	[thread overview]
Message-ID: <20191216141450.GU1208@intel.com> (raw)
In-Reply-To: <c7fe3911-be20-33dd-96c1-58eccd0f323f@redhat.com>

On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
> Hi,
> 
> Thank you for the reviews.
> 
> On 16-12-2019 14:45, Ville Syrjälä wrote:
> > On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
> >> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> >> device was booted with an external monitor connected over HDMI, we should
> >> not turn on the panel-enable GPIO when we request it.
> >>
> >> Turning on the panel-enable GPIO when we request it, means we turn it on
> >> too early in the init-sequence, which causes some panels to not correctly
> >> light up.
> >>
> >> This commits adds a panel_is_on parameter to intel_dsi_vbt_gpio_init()
> >> and makes intel_dsi_vbt_gpio_init() set the initial GPIO value accordingly.
> >>
> >> This fixes the panel not lighting up on a Thundersoft TST168 tablet when
> >> booted with an external monitor connected over HDMI.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_dsi.h     | 2 +-
> >>   drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 +++----
> >>   drivers/gpu/drm/i915/display/vlv_dsi.c       | 2 +-
> >>   3 files changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> index de7e51cd3460..675771ea91aa 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> @@ -203,7 +203,7 @@ void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
> >>   
> >>   /* intel_dsi_vbt.c */
> >>   bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi);
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on);
> >>   void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
> >>   void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
> >>   				 enum mipi_seq seq_id);
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> index 5352e8c9eca5..027970348b22 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> @@ -688,17 +688,16 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
> >>    * On some BYT/CHT devs some sequences are incomplete and we need to manually
> >>    * control some GPIOs.
> >>    */
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi)
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on)
> >>   {
> >>   	struct drm_device *dev = intel_dsi->base.base.dev;
> >>   	struct drm_i915_private *dev_priv = to_i915(dev);
> >>   	struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
> >> +	enum gpiod_flags flags = panel_is_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> > 
> > Can't we just tell it not to change the current setting?
> 
> We could use GPIOD_ASIS for that, but with the SoC pins (when the PMIC is
> not used for backlight control) things get a bit muddy, I've seen several
> instances of this message from drivers/pinctrl/intel/pinctrl-baytrail.c
> trigger when the GOP did not init the panel:
> 
> dev_warn(vg->dev, FW_BUG "pin %u forcibly re-configured as GPIO\n", offset);
> 
> And in that case with GPIOD_ASIS I have no idea which we initially get,
> so this approach, where we clearly define which initial value we want,
> seems better.

I suppose. Probably better to not abuse the current_mode pointer for
that though and just explicitly call encoder->get_hw_state() instead.

> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> The intel-gfx CI seems to seriously dislike my patches lately, almost
> always failing them; and usually on what at least seem to be unrelated
> test-cases. Any advice on how to deal with this?

Yeah, CI is snafu. I keep smashing retest until it gets through BAT
and then just double check the shard results to make sure nothing
relevant has tripped. If things look OK I recommend replying to the
result mail and provide a few short log snippets/other details on
what failed so that it's clear that it's irrelevant.

> 
> 
> 
> 
> > 
> >>   
> >>   	if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> >>   	    (mipi_config->pwm_blc == PPS_BLC_PMIC)) {
> >> -		intel_dsi->gpio_panel =
> >> -			gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
> >> -
> >> +		intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", flags);
> >>   		if (IS_ERR(intel_dsi->gpio_panel)) {
> >>   			DRM_ERROR("Failed to own gpio for panel control\n");
> >>   			intel_dsi->gpio_panel = NULL;
> >> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> index 178d0fffba5b..e86e4a11e199 100644
> >> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> @@ -1910,7 +1910,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> >>   
> >>   	vlv_dphy_param_init(intel_dsi);
> >>   
> >> -	intel_dsi_vbt_gpio_init(intel_dsi);
> >> +	intel_dsi_vbt_gpio_init(intel_dsi, current_mode != NULL);
> >>   
> >>   	drm_connector_init(dev, connector, &intel_dsi_connector_funcs,
> >>   			   DRM_MODE_CONNECTOR_DSI);
> >> -- 
> >> 2.23.0
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	dri-devel@lists.freedesktop.org, Lee Jones <lee.jones@linaro.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off
Date: Mon, 16 Dec 2019 16:14:50 +0200	[thread overview]
Message-ID: <20191216141450.GU1208@intel.com> (raw)
In-Reply-To: <c7fe3911-be20-33dd-96c1-58eccd0f323f@redhat.com>

On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
> Hi,
> 
> Thank you for the reviews.
> 
> On 16-12-2019 14:45, Ville Syrjälä wrote:
> > On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
> >> When the LCD has not been turned on by the firmware/GOP, because e.g. the
> >> device was booted with an external monitor connected over HDMI, we should
> >> not turn on the panel-enable GPIO when we request it.
> >>
> >> Turning on the panel-enable GPIO when we request it, means we turn it on
> >> too early in the init-sequence, which causes some panels to not correctly
> >> light up.
> >>
> >> This commits adds a panel_is_on parameter to intel_dsi_vbt_gpio_init()
> >> and makes intel_dsi_vbt_gpio_init() set the initial GPIO value accordingly.
> >>
> >> This fixes the panel not lighting up on a Thundersoft TST168 tablet when
> >> booted with an external monitor connected over HDMI.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >> ---
> >>   drivers/gpu/drm/i915/display/intel_dsi.h     | 2 +-
> >>   drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 +++----
> >>   drivers/gpu/drm/i915/display/vlv_dsi.c       | 2 +-
> >>   3 files changed, 5 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> index de7e51cd3460..675771ea91aa 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi.h
> >> @@ -203,7 +203,7 @@ void bxt_dsi_reset_clocks(struct intel_encoder *encoder, enum port port);
> >>   
> >>   /* intel_dsi_vbt.c */
> >>   bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id);
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi);
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on);
> >>   void intel_dsi_vbt_gpio_cleanup(struct intel_dsi *intel_dsi);
> >>   void intel_dsi_vbt_exec_sequence(struct intel_dsi *intel_dsi,
> >>   				 enum mipi_seq seq_id);
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> index 5352e8c9eca5..027970348b22 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> >> @@ -688,17 +688,16 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 panel_id)
> >>    * On some BYT/CHT devs some sequences are incomplete and we need to manually
> >>    * control some GPIOs.
> >>    */
> >> -void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi)
> >> +void intel_dsi_vbt_gpio_init(struct intel_dsi *intel_dsi, bool panel_is_on)
> >>   {
> >>   	struct drm_device *dev = intel_dsi->base.base.dev;
> >>   	struct drm_i915_private *dev_priv = to_i915(dev);
> >>   	struct mipi_config *mipi_config = dev_priv->vbt.dsi.config;
> >> +	enum gpiod_flags flags = panel_is_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW;
> > 
> > Can't we just tell it not to change the current setting?
> 
> We could use GPIOD_ASIS for that, but with the SoC pins (when the PMIC is
> not used for backlight control) things get a bit muddy, I've seen several
> instances of this message from drivers/pinctrl/intel/pinctrl-baytrail.c
> trigger when the GOP did not init the panel:
> 
> dev_warn(vg->dev, FW_BUG "pin %u forcibly re-configured as GPIO\n", offset);
> 
> And in that case with GPIOD_ASIS I have no idea which we initially get,
> so this approach, where we clearly define which initial value we want,
> seems better.

I suppose. Probably better to not abuse the current_mode pointer for
that though and just explicitly call encoder->get_hw_state() instead.

> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> The intel-gfx CI seems to seriously dislike my patches lately, almost
> always failing them; and usually on what at least seem to be unrelated
> test-cases. Any advice on how to deal with this?

Yeah, CI is snafu. I keep smashing retest until it gets through BAT
and then just double check the shard results to make sure nothing
relevant has tripped. If things look OK I recommend replying to the
result mail and provide a few short log snippets/other details on
what failed so that it's clear that it's irrelevant.

> 
> 
> 
> 
> > 
> >>   
> >>   	if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> >>   	    (mipi_config->pwm_blc == PPS_BLC_PMIC)) {
> >> -		intel_dsi->gpio_panel =
> >> -			gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
> >> -
> >> +		intel_dsi->gpio_panel = gpiod_get(dev->dev, "panel", flags);
> >>   		if (IS_ERR(intel_dsi->gpio_panel)) {
> >>   			DRM_ERROR("Failed to own gpio for panel control\n");
> >>   			intel_dsi->gpio_panel = NULL;
> >> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> index 178d0fffba5b..e86e4a11e199 100644
> >> --- a/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> +++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
> >> @@ -1910,7 +1910,7 @@ void vlv_dsi_init(struct drm_i915_private *dev_priv)
> >>   
> >>   	vlv_dphy_param_init(intel_dsi);
> >>   
> >> -	intel_dsi_vbt_gpio_init(intel_dsi);
> >> +	intel_dsi_vbt_gpio_init(intel_dsi, current_mode != NULL);
> >>   
> >>   	drm_connector_init(dev, connector, &intel_dsi_connector_funcs,
> >>   			   DRM_MODE_CONNECTOR_DSI);
> >> -- 
> >> 2.23.0
> > 

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-12-16 14:14 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15 16:38 [PATCH 0/5] drm/i915/dsi: Control panel and backlight enable GPIOs from VBT Hans de Goede
2019-12-15 16:38 ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38 ` Hans de Goede
2019-12-15 16:38 ` [PATCH 1/5] pinctrl: Export pinctrl_unregister_mappings Hans de Goede
2019-12-15 16:38   ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38   ` Hans de Goede
2019-12-15 16:38 ` [PATCH 2/5] drm/i915/dsi: Move poking of panel-enable GPIO to intel_dsi_vbt.c Hans de Goede
2019-12-15 16:38   ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38   ` Hans de Goede
2019-12-16 10:27   ` Linus Walleij
2019-12-16 10:27     ` [Intel-gfx] " Linus Walleij
2019-12-16 10:27     ` Linus Walleij
2019-12-16 13:51   ` Ville Syrjälä
2019-12-16 13:51     ` [Intel-gfx] " Ville Syrjälä
2019-12-16 13:51     ` Ville Syrjälä
2019-12-15 16:38 ` [PATCH 3/5] drm/i915/dsi: Init panel-enable GPIO to low when the LCD is initially off Hans de Goede
2019-12-15 16:38   ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38   ` Hans de Goede
2019-12-16 10:28   ` Linus Walleij
2019-12-16 10:28     ` [Intel-gfx] " Linus Walleij
2019-12-16 10:28     ` Linus Walleij
2019-12-16 13:45   ` Ville Syrjälä
2019-12-16 13:45     ` [Intel-gfx] " Ville Syrjälä
2019-12-16 13:45     ` Ville Syrjälä
2019-12-16 13:51     ` Hans de Goede
2019-12-16 13:51       ` [Intel-gfx] " Hans de Goede
2019-12-16 13:51       ` Hans de Goede
2019-12-16 14:14       ` Ville Syrjälä [this message]
2019-12-16 14:14         ` [Intel-gfx] " Ville Syrjälä
2019-12-16 14:14         ` Ville Syrjälä
2019-12-16 14:59         ` Hans de Goede
2019-12-16 14:59           ` [Intel-gfx] " Hans de Goede
2019-12-16 14:59           ` Hans de Goede
2019-12-15 16:38 ` [PATCH 4/5] drm/i915/dsi: Move Crystal Cove PMIC panel GPIO lookup from mfd to the i915 driver Hans de Goede
2019-12-15 16:38   ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38   ` Hans de Goede
2019-12-16 10:30   ` Linus Walleij
2019-12-16 10:30     ` [Intel-gfx] " Linus Walleij
2019-12-16 10:30     ` Linus Walleij
2019-12-16 12:16   ` Andy Shevchenko
2019-12-16 12:16     ` [Intel-gfx] " Andy Shevchenko
2019-12-16 12:16     ` Andy Shevchenko
2019-12-16 13:13     ` Hans de Goede
2019-12-16 13:13       ` [Intel-gfx] " Hans de Goede
2019-12-16 13:13       ` Hans de Goede
2019-12-16 13:56   ` Ville Syrjälä
2019-12-16 13:56     ` [Intel-gfx] " Ville Syrjälä
2019-12-16 13:56     ` Ville Syrjälä
2019-12-16 14:16     ` Hans de Goede
2019-12-16 14:16       ` [Intel-gfx] " Hans de Goede
2019-12-16 14:16       ` Hans de Goede
2019-12-15 16:38 ` [PATCH 5/5] drm/i915/dsi: Control panel and backlight enable GPIOs on BYT Hans de Goede
2019-12-15 16:38   ` [Intel-gfx] " Hans de Goede
2019-12-15 16:38   ` Hans de Goede
2019-12-16 10:29   ` Linus Walleij
2019-12-16 10:29     ` [Intel-gfx] " Linus Walleij
2019-12-16 10:29     ` Linus Walleij
2019-12-16 14:04   ` Ville Syrjälä
2019-12-16 14:04     ` [Intel-gfx] " Ville Syrjälä
2019-12-16 14:04     ` Ville Syrjälä
2019-12-16 14:28     ` Hans de Goede
2019-12-16 14:28       ` [Intel-gfx] " Hans de Goede
2019-12-16 14:28       ` Hans de Goede
2019-12-15 17:11 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dsi: Control panel and backlight enable GPIOs from VBT Patchwork
2019-12-15 17:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2019-12-15 18:55 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2019-12-16 10:26 ` [PATCH 0/5] " Linus Walleij
2019-12-16 10:26   ` [Intel-gfx] " Linus Walleij
2019-12-16 10:26   ` Linus Walleij
2019-12-16 10:59   ` Hans de Goede
2019-12-16 10:59     ` [Intel-gfx] " Hans de Goede
2019-12-16 10:59     ` Hans de Goede
2019-12-16 11:11   ` Hans de Goede
2019-12-16 11:11     ` [Intel-gfx] " Hans de Goede
2019-12-16 11:11     ` Hans de Goede
2019-12-16 12:16     ` Linus Walleij
2019-12-16 12:16       ` [Intel-gfx] " Linus Walleij
2019-12-16 12:16       ` Linus Walleij
2019-12-16 13:25       ` Hans de Goede
2019-12-16 13:25         ` [Intel-gfx] " Hans de Goede
2019-12-16 13:25         ` Hans de Goede
2019-12-16 12:18 ` Andy Shevchenko
2019-12-16 12:18   ` [Intel-gfx] " Andy Shevchenko
2019-12-16 12:18   ` Andy Shevchenko
2019-12-16 16:10   ` Lee Jones
2019-12-16 16:10     ` [Intel-gfx] " Lee Jones
2019-12-16 16:10     ` Lee Jones

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=20191216141450.GU1208@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=lee.jones@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    /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.