Skip to contentSkip to conversation

RFC] [Patch] [DRM/I915] :Check the LID device to decide whether the LVDS should be initialized

Intel-gfx yakui_zhao 3 participants 8 messages Jun 12, 2009 – Jun 18, 2009 6 messages not in the archive ACPI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 20090609153559.2e93479d@jbarnes-x200

A message that is not in the archive (sent off-list or not yet received): [email protected]

yakui_zhao

author
#6 lore raw

On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
cc: Linux-acpi

Quoted 144 lines

Hi, All

This is a patch that the LID device is checked to decide whether the LVDS should
be initialized. If there is no LID device, it won't initialize the LVDS output device in KMS mode on the boxes based on intel mobile chipset. In such case the pipe occupied by LVDS can be used for other output device.
If the LID device can be found, it will continue the current flowchart.

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 in bug 21496

But unfortunately the LVDS device is still initialized on such 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 had better be added to the quirk table.

Welcome the comments.
Yakui

---
 drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===================================================================

drivers/gpu/drm/i915/intel_lvds.c +79 -0
@@ -36,6 +36,7 @@
 #include "intel_drv.h"
 #include "i915_drm.h"
 #include "i915_drv.h"
+#include <linux/acpi.h>
 
 /**
  * Sets the backlight level.
@@ -503,7 +504,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. 0 is returned.
+ * If the LID device is found, it will return zero.
+ * If no LID device is found, it will return  -ENODEV.
+ */
+static int intel_lvds_find_lid(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 0.
+		 */
+		return 0;
+	}
+
+	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 -ENODEV */
+		return -ENODEV;
+	}
+
+	return 0;
+}
+#else
+static inline int intel_lvds_find_lid(void) { return 0; }
+#endif
 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device
@@ -526,6 +594,17 @@
 	if (dmi_check_system(intel_no_lvds))
 		return;
 
+	if (intel_lvds_find_lid()) {
+		/* 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;

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

#7 lore raw

Hello

Quoted 10 lines · yakui_zhao

On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
cc: Linux-acpi

Quoted 8 lines

Hi, All

    This is a patch that the LID device is checked to decide whether the LVDS should be initialized. If there is no LID device, it won't initialize the LVDS output device in KMS mode on the boxes based on intel mobile chipset. In such case the pipe occupied by LVDS can be used for other output device.
    If the LID device can be found, it will continue the current flowchart.

There is a problem with this strategy. I once had a hardware LID failure and it such cases I don't want to lose my screen output. Perhaps this can be compile-time or runtime option?

Quoted 142 lines
Quoted 132 lines

    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 in bug 21496

But unfortunately the LVDS device is still initialized on such 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 had better be added to the quirk table.

Welcome the comments.
   Yakui
---
 drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++

 1 file changed, 79 insertions(+)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===================================================================

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +1 -0
@@ -36,6 +36,7 @@
  #include "intel_drv.h"
  #include "i915_drm.h"
  #include "i915_drv.h"
+#include <linux/acpi.h>
 
  /**
   * Sets the backlight level.
@@ -503,7 +504,74 @@
 

      { }     /* terminating entry */
 };

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +67 -0
+#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. 0 is returned.
+ * If the LID device is found, it will return zero.
+ * If no LID device is found, it will return  -ENODEV.
+ */
+static int intel_lvds_find_lid(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 0.
+              */
+             return 0;
+     }
+
+     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 -ENODEV */
+             return -ENODEV;
+     }
+
+     return 0;
+}
+#else
+static inline int intel_lvds_find_lid(void) { return 0; }
+#endif

 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +11 -0
@@ -526,6 +594,17 @@
       if (dmi_check_system(intel_no_lvds))
               return;
 
+     if (intel_lvds_find_lid()) {
+             /* 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;
Quoted 4 lines

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signature · 6 lines
Regards
Vladimir 'phcoder' Serbinenko
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#8 lore raw
Quoted 13 lines · Vladimir 'phcoder' Serbinenko

Hello

Quoted 10 lines · yakui_zhao

On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
cc: Linux-acpi

Quoted 8 lines

Hi, All

This is a patch that the LID device is checked to decide whether the LVDS should
be initialized. If there is no LID device, it won't initialize the LVDS output device in KMS mode on the boxes based on intel mobile chipset. In such case the pipe occupied by LVDS can be used for other output device.
If the LID device can be found, it will continue the current flowchart.

Quoted 3 lines

There is a problem with this strategy. I once had a hardware LID failure and it such cases I don't want to lose my screen output. Perhaps this can be compile-time or runtime option?

Do you confirm whether there exists the hardware LID failure?
Will you please send me the acpidump about this failure?

In the patch it only depends on whether the exists the LID device. And it won't check whether the LID state is correct.

Thanks.

Quoted 145 lines
Quoted 142 lines
Quoted 132 lines

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 in bug 21496

But unfortunately the LVDS device is still initialized on such 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 had better be added to the quirk table.

Welcome the comments.
Yakui

---
 drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===================================================================

drivers/gpu/drm/i915/intel_lvds.c 2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c 2009-06-11 15:27:07.000000000 +0800 +79 -0
@@ -36,6 +36,7 @@
 #include "intel_drv.h"
 #include "i915_drm.h"
 #include "i915_drv.h"
+#include <linux/acpi.h>
 
 /**
  * Sets the backlight level.
@@ -503,7 +504,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. 0 is returned.
+ * If the LID device is found, it will return zero.
+ * If no LID device is found, it will return  -ENODEV.
+ */
+static int intel_lvds_find_lid(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 0.
+              */
+             return 0;
+     }
+
+     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 -ENODEV */
+             return -ENODEV;
+     }
+
+     return 0;
+}
+#else
+static inline int intel_lvds_find_lid(void) { return 0; }
+#endif
 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device
@@ -526,6 +594,17 @@
      if (dmi_check_system(intel_no_lvds))
              return;
 
+     if (intel_lvds_find_lid()) {
+             /* 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;
Quoted 4 lines

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#9 lore raw
Quoted 14 lines · yakui_zhao
Quoted 13 lines · Vladimir 'phcoder' Serbinenko

Hello

Quoted 10 lines · yakui_zhao

On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
cc: Linux-acpi

Quoted 8 lines

Hi, All

    This is a patch that the LID device is checked to decide whether the LVDS should be initialized. If there is no LID device, it won't initialize the LVDS output device in KMS mode on the boxes based on intel mobile chipset. In such case the pipe occupied by LVDS can be used for other output device.
    If the LID device can be found, it will continue the current flowchart.

Quoted 6 lines
Quoted 3 lines

There is a problem with this strategy. I once had a hardware LID failure and it such cases I don't want to lose my screen output. Perhaps this can be compile-time or runtime option?

Do you confirm whether there exists the hardware LID failure? Will you please send me the acpidump about this failure?

Well it's too late since I repaired it long since then.

Quoted 2 lines

In the patch it only depends on whether the exists the LID device. And it won't check whether the LID state is correct.

Yes I understand. However I'm always doubt what firmware passes to my code. We all know all kinds of BIOS quirks. I'm not against trying to autodetect but user should be able to override this autodetection in case it detects wrong

Quoted 149 lines

Thanks.

Quoted 145 lines
Quoted 142 lines
Quoted 132 lines

    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 in bug 21496

But unfortunately the LVDS device is still initialized on such 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 had better be added to the quirk table.

Welcome the comments.
   Yakui
---
 drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++

 1 file changed, 79 insertions(+)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===================================================================

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +1 -0
@@ -36,6 +36,7 @@
  #include "intel_drv.h"
  #include "i915_drm.h"
  #include "i915_drv.h"
+#include <linux/acpi.h>
 
  /**
   * Sets the backlight level.
@@ -503,7 +504,74 @@
 

      { }     /* terminating entry */
 };

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +67 -0
+#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. 0 is returned.
+ * If the LID device is found, it will return zero.
+ * If no LID device is found, it will return  -ENODEV.
+ */
+static int intel_lvds_find_lid(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 0.
+              */
+             return 0;
+     }
+
+     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 -ENODEV */
+             return -ENODEV;
+     }
+
+     return 0;
+}
+#else
+static inline int intel_lvds_find_lid(void) { return 0; }
+#endif

 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device

drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800 +11 -0
@@ -526,6 +594,17 @@
       if (dmi_check_system(intel_no_lvds))
               return;
 
+     if (intel_lvds_find_lid()) {
+             /* 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;
Quoted 4 lines

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Signature · 6 lines
Regards
Vladimir 'phcoder' Serbinenko
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#10 lore raw
Quoted 21 lines · Vladimir 'phcoder' Serbinenko
Quoted 14 lines · yakui_zhao
Quoted 13 lines · Vladimir 'phcoder' Serbinenko

Hello

Quoted 10 lines · yakui_zhao

On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
cc: Linux-acpi

Quoted 8 lines

Hi, All

This is a patch that the LID device is checked to decide whether the LVDS should
be initialized. If there is no LID device, it won't initialize the LVDS output device in KMS mode on the boxes based on intel mobile chipset. In such case the pipe occupied by LVDS can be used for other output device.
If the LID device can be found, it will continue the current flowchart.

Quoted 6 lines
Quoted 3 lines

There is a problem with this strategy. I once had a hardware LID failure and it such cases I don't want to lose my screen output. Perhaps this can be compile-time or runtime option?

Do you confirm whether there exists the hardware LID failure?
Will you please send me the acpidump about this failure?

Quoted 7 lines

Well it's too late since I repaired it long since then.

Quoted 2 lines

In the patch it only depends on whether the exists the LID device. And it won't check whether the LID state is correct.

Yes I understand. However I'm always doubt what firmware passes to my code. We all know all kinds of BIOS quirks. I'm not against trying to autodetect but user should be able to override this autodetection in case it detects wrong

Do you mean that there is no LID device while there exists the LVDS device? In such case the LVDS is detected incorrectly. Maybe we can add it the quirk list.

Thanks.

Quoted 152 lines
Quoted 149 lines

Thanks.

Quoted 145 lines
Quoted 142 lines
Quoted 132 lines

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 in bug 21496

But unfortunately the LVDS device is still initialized on such 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 had better be added to the quirk table.

Welcome the comments.
Yakui

---
 drivers/gpu/drm/i915/intel_lvds.c |   79 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===================================================================

drivers/gpu/drm/i915/intel_lvds.c 2009-06-11 17:42:07.000000000 +0800 renamed from drivers/gpu/drm/i915/intel_lvds.c 2009-06-11 15:27:07.000000000 +0800 +79 -0
@@ -36,6 +36,7 @@
 #include "intel_drv.h"
 #include "i915_drm.h"
 #include "i915_drv.h"
+#include <linux/acpi.h>
 
 /**
  * Sets the backlight level.
@@ -503,7 +504,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. 0 is returned.
+ * If the LID device is found, it will return zero.
+ * If no LID device is found, it will return  -ENODEV.
+ */
+static int intel_lvds_find_lid(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 0.
+              */
+             return 0;
+     }
+
+     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 -ENODEV */
+             return -ENODEV;
+     }
+
+     return 0;
+}
+#else
+static inline int intel_lvds_find_lid(void) { return 0; }
+#endif
 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device
@@ -526,6 +594,17 @@
      if (dmi_check_system(intel_no_lvds))
              return;
 
+     if (intel_lvds_find_lid()) {
+             /* 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;
Quoted 4 lines

_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#11 lore raw
In reply to a message not in the archive

2009/6/11 yakui_zhao <[email protected]>:

Quoted 8 lines

+       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 0.
+                */
+               return 0;
+       }

Won't this prevent people from debugging ACPI problems on laptops by disabling ACPI on the kernel command line? Does this patch mean that, in such case, there will be no output at all? Maybe, without ACPI, we should initialize LVDS if and only if there are no other output devices connected?

Signature · 5 lines
Alexander E. Patrakov
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#12 lore raw

2009/6/13 Alexander E. Patrakov <[email protected]>:

Quoted 10 lines

2009/6/11 yakui_zhao <[email protected]>:

Quoted 8 lines

+       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 0.
+                */
+               return 0;
+       }

Quoted 5 lines

Won't this prevent people from debugging ACPI problems on laptops by disabling ACPI on the kernel command line? Does this patch mean that, in such case, there will be no output at all? Maybe, without ACPI, we should initialize LVDS if and only if there are no other output devices connected?

Oops, I misread the code. If ACPI is disabled, we return 0, not -ENODEV. That's right.

Signature · 5 lines
Alexander E. Patrakov
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#13 lore raw
In reply to Alexander E. Patrakov
Quoted 10 lines · Alexander E. Patrakov

2009/6/11 yakui_zhao <[email protected]>:

Review

Quoted 8 lines
(quoted diff) +8 -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 0.
+                */
+               return 0;
+       }
Quoted 5 lines

Won't this prevent people from debugging ACPI problems on laptops by disabling ACPI on the kernel command line? Does this patch mean that, in such case, there will be no output at all? Maybe, without ACPI, we should initialize LVDS if and only if there are no other output devices connected?

No. It has no effect on LVDS output device if ACPI is disabled.
If the system is booted with acpi disabled, the function of intel_lvds_find_lid will return zero and it will continue the current flowchart of LVDS output device.

Thanks.