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

Vladimir 'phcoder' Serbinenko
2009-06-15T18:33:21Z

Hello

On Fri, Jun 12, 2009 at 3:00 AM, yakui_zhao<yakui.zhao@intel.com> wrote:
> On Thu, 2009-06-11 at 18:03 +0800, yakui_zhao wrote:
> cc: Linux-acpi
>> 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?
>>     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
>> ===================================================================
>> --- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c  2009-06-11 15:27:07.000000000 +0800
>> +++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c       2009-06-11 17:42:07.000000000 +0800
>> @@ -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
>> Intel-gfx@lists.freedesktop.org
>> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
Regards
Vladimir 'phcoder' Serbinenko