All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kahola <mika.kahola@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 2/6] drm/i915: move VBT based LVDS presence check to intel_bios.c
Date: Thu, 14 Jan 2016 14:52:17 +0200	[thread overview]
Message-ID: <1452775937.4104.27.camel@sorvi> (raw)
In-Reply-To: <0323f70aa048b8c236ad25dba58eafdd77513edb.1452541881.git.jani.nikula@intel.com>

On Mon, 2016-01-11 at 21:54 +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
> 
Tested-by: Mika Kahola <mika.kahola@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_bios.c | 50 ++++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_lvds.c | 53 +--------------------------------------
>  3 files changed, 52 insertions(+), 52 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3822c465d3dc..5f0d44b380aa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3348,6 +3348,7 @@ extern void intel_i2c_reset(struct drm_device *dev);
>  int intel_bios_init(struct drm_i915_private *dev_priv);
>  bool intel_bios_is_valid_vbt(const void *buf, size_t size);
>  bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 *i2c_pin);
>  
>  /* intel_opregion.c */
>  #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
> index bb9e8b086b63..099f3f0002a2 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1453,3 +1453,53 @@ bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv)
>  
>  	return false;
>  }
> +
> +/**
> + * intel_bios_is_lvds_present - is LVDS present in VBT
> + * @dev_priv:	i915 device instance
> + * @i2c_pin:	i2c pin for LVDS if present
> + *
> + * Return true if LVDS is present. If no child devices were parsed from VBT,
> + * assume LVDS is present.
> + */
> +bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 *i2c_pin)
> +{
> +	int i;
> +
> +	if (!dev_priv->vbt.child_dev_num)
> +		return true;
> +
> +	for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> +		union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> +		struct old_child_dev_config *child = &uchild->old;
> +
> +		/* If the device type is not LFP, continue.
> +		 * We have to check both the new identifiers as well as the
> +		 * old for compatibility with some BIOSes.
> +		 */
> +		if (child->device_type != DEVICE_TYPE_INT_LFP &&
> +		    child->device_type != DEVICE_TYPE_LFP)
> +			continue;
> +
> +		if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> +			*i2c_pin = child->i2c_pin;
> +
> +		/* However, we cannot trust the BIOS writers to populate
> +		 * the VBT correctly.  Since LVDS requires additional
> +		 * information from AIM blocks, a non-zero addin offset is
> +		 * a good indicator that the LVDS is actually present.
> +		 */
> +		if (child->addin_offset)
> +			return true;
> +
> +		/* But even then some BIOS writers perform some black magic
> +		 * and instantiate the device without reference to any
> +		 * additional data.  Trust that if the VBT was written into
> +		 * the OpRegion then they have validated the LVDS's existence.
> +		 */
> +		if (dev_priv->opregion.vbt)
> +			return true;
> +	}
> +
> +	return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
> index 0da0240caf81..80f8684e5137 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -772,57 +772,6 @@ static const struct dmi_system_id intel_no_lvds[] = {
>  	{ }	/* terminating entry */
>  };
>  
> -/*
> - * Enumerate the child dev array parsed from VBT to check whether
> - * the LVDS is present.
> - * If it is present, return 1.
> - * If it is not present, return false.
> - * If no child dev is parsed from VBT, it assumes that the LVDS is present.
> - */
> -static bool lvds_is_present_in_vbt(struct drm_device *dev,
> -				   u8 *i2c_pin)
> -{
> -	struct drm_i915_private *dev_priv = dev->dev_private;
> -	int i;
> -
> -	if (!dev_priv->vbt.child_dev_num)
> -		return true;
> -
> -	for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> -		union child_device_config *uchild = dev_priv->vbt.child_dev + i;
> -		struct old_child_dev_config *child = &uchild->old;
> -
> -		/* If the device type is not LFP, continue.
> -		 * We have to check both the new identifiers as well as the
> -		 * old for compatibility with some BIOSes.
> -		 */
> -		if (child->device_type != DEVICE_TYPE_INT_LFP &&
> -		    child->device_type != DEVICE_TYPE_LFP)
> -			continue;
> -
> -		if (intel_gmbus_is_valid_pin(dev_priv, child->i2c_pin))
> -			*i2c_pin = child->i2c_pin;
> -
> -		/* However, we cannot trust the BIOS writers to populate
> -		 * the VBT correctly.  Since LVDS requires additional
> -		 * information from AIM blocks, a non-zero addin offset is
> -		 * a good indicator that the LVDS is actually present.
> -		 */
> -		if (child->addin_offset)
> -			return true;
> -
> -		/* But even then some BIOS writers perform some black magic
> -		 * and instantiate the device without reference to any
> -		 * additional data.  Trust that if the VBT was written into
> -		 * the OpRegion then they have validated the LVDS's existence.
> -		 */
> -		if (dev_priv->opregion.vbt)
> -			return true;
> -	}
> -
> -	return false;
> -}
> -
>  static int intel_dual_link_lvds_callback(const struct dmi_system_id *id)
>  {
>  	DRM_INFO("Forcing lvds to dual link mode on %s\n", id->ident);
> @@ -979,7 +928,7 @@ void intel_lvds_init(struct drm_device *dev)
>  	}
>  
>  	pin = GMBUS_PIN_PANEL;
> -	if (!lvds_is_present_in_vbt(dev, &pin)) {
> +	if (!intel_bios_is_lvds_present(dev_priv, &pin)) {
>  		if ((lvds & LVDS_PORT_EN) == 0) {
>  			DRM_DEBUG_KMS("LVDS is not present in VBT\n");
>  			return;


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-14 12:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 19:54 [PATCH v2 0/6] drm/i915: start hiding away vbt structure from the driver Jani Nikula
2016-01-11 19:54 ` [PATCH v2 1/6] drm/i915: move VBT based TV presence check to intel_bios.c Jani Nikula
2016-01-12  9:45   ` Daniel Vetter
2016-01-14 12:51   ` Mika Kahola
2016-01-11 19:54 ` [PATCH v2 2/6] drm/i915: move VBT based LVDS " Jani Nikula
2016-01-14 12:52   ` Mika Kahola [this message]
2016-01-11 19:54 ` [PATCH v2 3/6] drm/i915: move VBT based eDP port " Jani Nikula
2016-01-14 12:52   ` Mika Kahola
2016-01-11 19:54 ` [PATCH v2 4/6] drm/i915: move VBT based DSI presence " Jani Nikula
2016-01-14 12:52   ` Mika Kahola
2016-01-11 19:54 ` [PATCH v2 5/6] drm/i915/panel: setup pwm backlight based on connector type Jani Nikula
2016-01-11 19:54 ` [PATCH v2 6/6] drm/i915: hide away VBT private data in a separate header Jani Nikula
2016-01-14 12:53   ` Mika Kahola
2016-01-11 20:07 ` [PATCH v2 0/6] drm/i915: start hiding away vbt structure from the driver Lukas Wunner
2016-01-12  5:51   ` Jani Nikula
2016-01-12  8:20 ` ✓ success: Fi.CI.BAT Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2016-02-09 15:29 [PATCH v2 1/6] drm/i915: move VBT based TV presence check to intel_bios.c Jani Nikula
2016-02-09 15:29 ` [PATCH v2 2/6] drm/i915: move VBT based LVDS " Jani Nikula

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=1452775937.4104.27.camel@sorvi \
    --to=mika.kahola@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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.