[Intel-gfx] [DRM/I915]: Check the LID device to decide whether the LVDS should be initialized

[yakui]

On Fri, 2009-06-26 at 09:46 +0800, Zhao, Yakui wrote:
> From: Zhao Yakui <yakui.zhao at intel.com>
Hi, Eric
    How about this patch?
    Thanks.
> 
> On some boxes the mobile chipset is used and there is no LVDS device. In such
> case we had better not initialize the LVDS output device so that one pipe can
> be used for other output device. For example: E-TOP.
> 
> But unfortunately the LVDS device is still initialized on the boxes based on
> mobile chipset in KMS mode. It brings that this pipe occupied by LVDS can't be
> used for other output device.
> 
> After checking the acpidump we find that there is no LID device on such boxes.
> In such case we can use the LID device to decide whether the LVDS device should
> be initialized. 
> 
> If there is no LID device, we can think that there is no LVDS device. It is
> unnecessary to initialize the LVDS output device.
> If there exists the LID device, it will continue the current flowchart.
> 
> Maybe on some boxes there is no LVDS device but the LID device is found. In
> such case it should be added to the quirk list. 
> 
> http://bugs.freedesktop.org/show_bug.cgi?id=21496
> http://bugs.freedesktop.org/show_bug.cgi?id=21856
> http://bugs.freedesktop.org/show_bug.cgi?id=21127
> 
> Signed-off-by: Zhao Yakui <yakui.zhao at intel.com>
> Reviewd-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> ---
>    This patch is to decide whether the integrated lVDS should be initialized
> by checking whether there exists the LID device.
>    At the same time I am working on the another feature proposed by Jesse that 
> use the lid state to check whether the LVDS is connected/disconnected. That
> means that the LVDS should be disconnected when LID is closed. When the LID is
> reopened, the LVDS is connected. (But there exists the module dependency. 
> At the same time the LID event will be handled by the acpid. Maybe the system
> will enter the suspend state when the LID is closed. So this feature will be
> deferred for some time.)
> 
>  drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 79 insertions(+)
> 
> Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
> ===================================================================
> --- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c	2009-06-26 08:59:09.000000000 +0800
> +++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c	2009-06-26 09:18:14.000000000 +0800
> @@ -36,6 +36,7 @@
>  #include "intel_drv.h"
>  #include "i915_drm.h"
>  #include "i915_drv.h"
> +#include <linux/acpi.h>
>  
>  #define I915_LVDS "i915_lvds"
>  
> @@ -787,7 +788,74 @@
>  
>  	{ }	/* terminating entry */
>  };
> +#ifdef CONFIG_ACPI
> +/*
> + * check_lid_device -- check whether it is ACPI LID device.
> + * @handle: ACPI device handle
> + * @level : depth in the ACPI namespace tree
> + * @context: the number of LID device when we find the device
> + * @rv: a return value to fill if desired (Not use)
> + *
> + * check whether it is a LID device by comparing the HID. If it is,
> + * increase the number of LID device.
> + */
> +static acpi_status
> +check_lid_device(acpi_handle handle, u32 level, void *context,
> +			void **retyurn_value)
> +{
> +#define		ACPI_HID_LID		"PNP0C0D"
> +	struct acpi_device *acpi_dev;
> +	int *p_lid = (int *)context;
> +
> +	acpi_dev = NULL;
> +	/* Get the acpi device for device handle */
> +	if (acpi_bus_get_device(handle, &acpi_dev) || !acpi_dev) {
> +		/* If there is no ACPI device for handle, return */
> +		return AE_OK;
> +	}
> +	if (!strncmp(acpi_device_hid(acpi_dev), ACPI_HID_LID, 7)) {
> +		/*
> +		 * compare the device HID with "PNP0C0D". If it is equal, the
> +		 * LID device is found. Increase the count
> +		 */
> +		(*p_lid)++;
> +	}
> +	return AE_OK;
> +}
> +/**
> + * check whether there exists the ACPI LID device by enumerating the ACPI
> + * device tree.
> + * If ACPI is disabled, there is no ACPI device tree. one is returned.
> + * If the LID device is found, it will return one.
> + * If no LID device is found, it will return  zero.
> + */
> +static int intel_lid_present(void)
> +{
> +	int lid_count = 0;
> +
> +	if (acpi_disabled) {
> +		/*
> +		 * if ACPI is disabled, there is no ACPI device tree. And
> +		 * we don't know whether there exists the LID device.
> +		 * In such case we will return 1.
> +		 */
> +		return 1;
> +	}
> +
> +	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
> +				ACPI_UINT32_MAX,
> +				check_lid_device, &lid_count, NULL);
> +
> +	if (!lid_count) {
> +		/* No LID device is not found. Return zero */
> +		return 0;
> +	}
>  
> +	return 1;
> +}
> +#else
> +static inline int intel_lid_present(void) { return 1; }
> +#endif
>  /**
>   * intel_lvds_init - setup LVDS connectors on this device
>   * @dev: drm device
> @@ -811,6 +879,17 @@
>  	if (dmi_check_system(intel_no_lvds))
>  		return;
>  
> +	if (!intel_lid_present()) {
> +		/* If there is no LID device, we can think that there is
> +		 * no LVDS output device. In such case it is unnecessary to
> +		 * create the LVDS output device.
> +		 * But maybe on some boxes there is no LVDS device while the
> +		 * LID device is found. If so, it had better be added to
> +		 * the quirk list.
> +		 */
> +		return;
> +	}
> +
>  	if (IS_IGDNG(dev)) {
>  		if ((I915_READ(PCH_LVDS) & LVDS_DETECTED) == 0)
>  			return;