Message ID | 20090521093418.3f1a03d5@jbarnes-g45 (mailing list archive) |
---|---|
State | RFC, archived |
Headers | show |
Jesse Barnes wrote: > On Thu, 21 May 2009 16:57:53 +0800 > Zhang Rui <rui.zhang@intel.com> wrote: > > >> On Wed, 2009-05-20 at 01:15 +0800, Matthew Garrett wrote: >> >>>>> There's also a policy question here. On some machines, a lid >>>>> close will cause the ACPI firmware to program the GPU, >>>>> disabling the pipe associated with the panel. Should we detect >>>>> this and turn it back on at open time? That could be dangerous >>>>> if userspace has received the LVDS hotplug event and changed >>>>> the config out from under us... >>>>> >>>>> Comments? >>>>> >>>> It seems that the LID status is used to determine whether the >>>> LVDS is connected. >>>> It is not reliable. On some boxes the initial LID status is >>>> incorrect. Maybe the LID status is open. But the ACPI returns >>>> that the LID is close. In such case the LVDS is not initialized >>>> and user can't get the output. >>>> >>> Really? I haven't seen any cases of this. They'll fail in all sorts >>> of fun ways with modern userland. >>> >>> >> This is rare, and if this happens, a bug should be filed against ACPI. >> BTW: we have fixed/root caused all such kind of bugs that have been >> reported. >> So I think it makes sense to trust the Lid state reported by ACPI >> button driver. >> > > So is that two acks for the patch? If so, should it be split or can it > just go in through the i915 driver tree? > > Len? (Patch attached for reference.) > > Thanks, > Jesse, Just talked with Rui, the above status is based on "BIOS upgrade or FW fix is acceptable as a bug fix solution". are you ok with this? :) Many lid status has to be fixed via action such as DSDT upgrade... > ------------------------------------------------------------------------ > > _______________________________________________ > 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
On Fri, May 22, 2009 at 09:22:31AM +0800, Fu Michael wrote: > Jesse Barnes wrote: >> So is that two acks for the patch? If so, should it be split or can it >> just go in through the i915 driver tree? >> >> Len? (Patch attached for reference.) >> >> Thanks, >> > Jesse, Just talked with Rui, the above status is based on "BIOS upgrade > or FW fix is acceptable as a bug fix solution". are you ok with this? :) > Many lid status has to be fixed via action such as DSDT upgrade... Really? As I said, I'd be surprised if this is in any way common. What's the exact problem description?
On Fri, 2009-05-22 at 09:26 +0800, Matthew Garrett wrote: > On Fri, May 22, 2009 at 09:22:31AM +0800, Fu Michael wrote: > > Jesse Barnes wrote: > >> So is that two acks for the patch? If so, should it be split or can it > >> just go in through the i915 driver tree? > >> > >> Len? (Patch attached for reference.) > >> > >> Thanks, > >> > > Jesse, Just talked with Rui, the above status is based on "BIOS upgrade > > or FW fix is acceptable as a bug fix solution". are you ok with this? :) > > Many lid status has to be fixed via action such as DSDT upgrade... > > Really? As I said, I'd be surprised if this is in any way common. What's > the exact problem description? > for example, http://bugzilla.kernel.org/show_bug.cgi?id=13263 http://bugzilla.kernel.org/show_bug.cgi?id=5809 http://bugzilla.kernel.org/show_bug.cgi?id=5904 and https://bugs.launchpad.net/ubuntu/+bug/34389 thanks, rui -- 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
On Fri, 22 May 2009 09:22:31 +0800 Fu Michael <michael_fu@linux.intel.com> wrote: > Jesse Barnes wrote: > > On Thu, 21 May 2009 16:57:53 +0800 > > Zhang Rui <rui.zhang@intel.com> wrote: > > > > > >> On Wed, 2009-05-20 at 01:15 +0800, Matthew Garrett wrote: > >> > >>>>> There's also a policy question here. On some machines, a lid > >>>>> close will cause the ACPI firmware to program the GPU, > >>>>> disabling the pipe associated with the panel. Should we detect > >>>>> this and turn it back on at open time? That could be dangerous > >>>>> if userspace has received the LVDS hotplug event and changed > >>>>> the config out from under us... > >>>>> > >>>>> Comments? > >>>>> > >>>> It seems that the LID status is used to determine whether the > >>>> LVDS is connected. > >>>> It is not reliable. On some boxes the initial LID status is > >>>> incorrect. Maybe the LID status is open. But the ACPI returns > >>>> that the LID is close. In such case the LVDS is not initialized > >>>> and user can't get the output. > >>>> > >>> Really? I haven't seen any cases of this. They'll fail in all > >>> sorts of fun ways with modern userland. > >>> > >>> > >> This is rare, and if this happens, a bug should be filed against > >> ACPI. BTW: we have fixed/root caused all such kind of bugs that > >> have been reported. > >> So I think it makes sense to trust the Lid state reported by ACPI > >> button driver. > >> > > > > So is that two acks for the patch? If so, should it be split or > > can it just go in through the i915 driver tree? > > > > Len? (Patch attached for reference.) > > > > Thanks, > > > Jesse, Just talked with Rui, the above status is based on "BIOS > upgrade or FW fix is acceptable as a bug fix solution". are you ok > with this? :) Many lid status has to be fixed via action such as DSDT > upgrade... Yeah, I think that's ok, even if we need quirks for some platforms. I really hate relying on BIOS vendors/OEMs to provide BIOS updates in general: if Windows works on a given platform, why should Linux require a BIOS "fix" on it? In this case though, we can work around broken platforms by just returning "open" all the time, if it comes to that. Jesse -- 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
Jesse Barnes wrote: > On Fri, 22 May 2009 09:22:31 +0800 > Fu Michael <michael_fu@linux.intel.com> wrote: > > >> Jesse Barnes wrote: >> >>> On Thu, 21 May 2009 16:57:53 +0800 >>> Zhang Rui <rui.zhang@intel.com> wrote: >>> >>> >>> >>>> On Wed, 2009-05-20 at 01:15 +0800, Matthew Garrett wrote: >>>> >>>> >>>>>>> There's also a policy question here. On some machines, a lid >>>>>>> close will cause the ACPI firmware to program the GPU, >>>>>>> disabling the pipe associated with the panel. Should we detect >>>>>>> this and turn it back on at open time? That could be dangerous >>>>>>> if userspace has received the LVDS hotplug event and changed >>>>>>> the config out from under us... >>>>>>> >>>>>>> Comments? >>>>>>> >>>>>>> >>>>>> It seems that the LID status is used to determine whether the >>>>>> LVDS is connected. >>>>>> It is not reliable. On some boxes the initial LID status is >>>>>> incorrect. Maybe the LID status is open. But the ACPI returns >>>>>> that the LID is close. In such case the LVDS is not initialized >>>>>> and user can't get the output. >>>>>> >>>>>> >>>>> Really? I haven't seen any cases of this. They'll fail in all >>>>> sorts of fun ways with modern userland. >>>>> >>>>> >>>>> >>>> This is rare, and if this happens, a bug should be filed against >>>> ACPI. BTW: we have fixed/root caused all such kind of bugs that >>>> have been reported. >>>> So I think it makes sense to trust the Lid state reported by ACPI >>>> button driver. >>>> >>>> >>> So is that two acks for the patch? If so, should it be split or >>> can it just go in through the i915 driver tree? >>> >>> Len? (Patch attached for reference.) >>> >>> Thanks, >>> >>> >> Jesse, Just talked with Rui, the above status is based on "BIOS >> upgrade or FW fix is acceptable as a bug fix solution". are you ok >> with this? :) Many lid status has to be fixed via action such as DSDT >> upgrade... >> > > Yeah, I think that's ok, even if we need quirks for some platforms. I > really hate relying on BIOS vendors/OEMs to provide BIOS updates in > general: if Windows works on a given platform, why should Linux > require a BIOS "fix" on it? In this case though, we can work around > broken platforms by just returning "open" all the time, if it comes to > that. > > I'm not sure if acpi module has this kind of quirk for lid detection, if we prepare to take this way, we'd better to quirk from our driver directly... > Jesse > > -- 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
On Wed, 2009-05-27 at 16:58 +0800, Jesse Barnes wrote: > > > > > Jesse, Just talked with Rui, the above status is based on "BIOS > > upgrade or FW fix is acceptable as a bug fix solution". are you ok > > with this? :) Many lid status has to be fixed via action such as DSDT > > upgrade... > > Yeah, I think that's ok, even if we need quirks for some platforms. I > really hate relying on BIOS vendors/OEMs to provide BIOS updates in > general: if Windows works on a given platform, why should Linux > require a BIOS "fix" on it? In this case though, we can work around > broken platforms by just returning "open" all the time, if it comes to > that. Hi, It is a good point that the LID status is used to decide whether the LVDS is connected or not. As Rui said in the previous thread, sometimes the initial status of LID is incorrect on some laptops. If we expect that LVDS can be initialized correctly on such boxes, we will have to add the quirk so that the LID status is not used for LVDS detection. But maybe on such boxes the LID initial status is correct after BIOS upgrading or using custom DSDT. Do we need to delete the quirk for such box? It is difficult to manage. So IMO we had better not use the LID status to determine whether the LVDS is connected or not. Thanks. > > Jesse > _______________________________________________ > 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
On Thu, 11 Jun 2009 15:16:27 +0800 yakui_zhao <yakui.zhao@intel.com> wrote: > On Wed, 2009-05-27 at 16:58 +0800, Jesse Barnes wrote: > > > > > > > Jesse, Just talked with Rui, the above status is based on "BIOS > > > upgrade or FW fix is acceptable as a bug fix solution". are you ok > > > with this? :) Many lid status has to be fixed via action such as > > > DSDT upgrade... > > > > Yeah, I think that's ok, even if we need quirks for some > > platforms. I really hate relying on BIOS vendors/OEMs to provide > > BIOS updates in general: if Windows works on a given platform, why > > should Linux require a BIOS "fix" on it? In this case though, we > > can work around broken platforms by just returning "open" all the > > time, if it comes to that. > Hi, > It is a good point that the LID status is used to decide whether > the LVDS is connected or not. > As Rui said in the previous thread, sometimes the initial status > of LID is incorrect on some laptops. If we expect that LVDS can be > initialized correctly on such boxes, we will have to add the quirk so > that the LID status is not used for LVDS detection. > But maybe on such boxes the LID initial status is correct after > BIOS upgrading or using custom DSDT. Do we need to delete the quirk > for such box? It is difficult to manage. > > So IMO we had better not use the LID status to determine whether > the LVDS is connected or not. Well, what should we use then? Think of a common use case: you plug in an external monitor and shut your lid. Do we want to make the user manually change their configuration? Or detect that the lid is no longer in use? And what about the case where they boot with the lid closed (e.g. in a docked scenario)? We want to support that automatically too... If we can solve these issues some other way, that's fine, but right now we have nothing; I think my patch is an improvement over that, even if it won't work everywhere w/o quirks. Len or Matthew, any comments?
On Tue, Jun 16, 2009 at 8:33 PM, Jesse Barnes<jbarnes@virtuousgeek.org> wrote: > On Thu, 11 Jun 2009 15:16:27 +0800 > yakui_zhao <yakui.zhao@intel.com> wrote: > >> On Wed, 2009-05-27 at 16:58 +0800, Jesse Barnes wrote: >> > > > >> > > Jesse, Just talked with Rui, Â the above status is based on "BIOS >> > > upgrade or FW fix is acceptable as a bug fix solution". are you ok >> > > with this? :) Many lid status has to be fixed via action such as >> > > DSDT upgrade... >> > >> > Yeah, I think that's ok, even if we need quirks for some >> > platforms. Â I really hate relying on BIOS vendors/OEMs to provide >> > BIOS updates in general: Â if Windows works on a given platform, why >> > should Linux require a BIOS "fix" on it? Â In this case though, we >> > can work around broken platforms by just returning "open" all the >> > time, if it comes to that. >> Hi, >> Â Â It is a good point that the LID status is used to decide whether >> the LVDS is connected or not. >> Â Â As Rui said in the previous thread, sometimes the initial status >> of LID is incorrect on some laptops. If we expect that LVDS can be >> initialized correctly on such boxes, we will have to add the quirk so >> that the LID status is not used for LVDS detection. >> Â Â But maybe on such boxes the LID initial status is correct after >> BIOS upgrading or using custom DSDT. Do we need to delete the quirk >> for such box? Â It is difficult to manage. >> >> Â Â So IMO we had better not use the LID status to determine whether >> the LVDS is connected or not. > > Well, what should we use then? Â Think of a common use case: you plug in > an external monitor and shut your lid. Â Do we want to make the user > manually change their configuration? Â Or detect that the lid is no > longer in use? Â And what about the case where they boot with the lid > closed (e.g. in a docked scenario)? Â We want to support that > automatically too... Just another use case for this patch : Michael Ringe recently sended me a patch to handle backlight power in eeepc-laptop. > There is another minor problem I could not solve. When the lid is closed, the > status of the backlight device driver is not updated, so reading from > /sys/class/backlight/eeepc/bl_power still yields 0 (=power on). Or, if you > switch off the backlight and then close and reopen the lid, the backlight is on, > but the driver still thinks it's off. If you reboot in this status, the notebook > will come up with the backlight switched off, and you have to press Fn-F7 to > switch it on. > To solve this problem, eeepc-laptop would need to register a notification handler > with \_SB.LIB. But this is not possible because a handler is already registered by > the acpi button driver. Maybe there is a way too register a handler with the button driver? We ended up with an input handler, checking on SW_LID, but it's not very clean, and I'd better use your patch.
On Wed, 2009-06-17 at 02:33 +0800, Jesse Barnes wrote: > Well, what should we use then? Think of a common use case: you plug > in > an external monitor and shut your lid. Do we want to make the user > manually change their configuration? Or detect that the lid is no > longer in use? And what about the case where they boot with the lid > closed (e.g. in a docked scenario)? We want to support that > automatically too... This feature should work on most laptops. When the LID is closed, the LVDS is marked as disconnected. But this can't work for some boxes on which the initial Lid state is incorrect. We see such an exception on several laptops in ACPI bugzilla. If we expect this feature for most laptops, how about adding the exception boxes into the blacklist that doesn't support this feature? Thanks. > > If we can solve these issues some other way, that's fine, but right > now > we have nothing; I think my patch is an improvement over that, even if > it won't work everywhere w/o quirks. > > Len or Matthew, any comments -- 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
On Wed, 17 Jun 2009 10:32:31 +0800 yakui_zhao <yakui.zhao@intel.com> wrote: > On Wed, 2009-06-17 at 02:33 +0800, Jesse Barnes wrote: > > Well, what should we use then? Think of a common use case: you plug > > in > > an external monitor and shut your lid. Do we want to make the user > > manually change their configuration? Or detect that the lid is no > > longer in use? And what about the case where they boot with the lid > > closed (e.g. in a docked scenario)? We want to support that > > automatically too... > This feature should work on most laptops. When the LID is closed, the > LVDS is marked as disconnected. > > But this can't work for some boxes on which the initial Lid state is > incorrect. We see such an exception on several laptops in ACPI > bugzilla. > > If we expect this feature for most laptops, how about adding the > exception boxes into the blacklist that doesn't support this feature? Yeah, that's fine with me. Is there a list somewhere? Please don't make me troll through ACPI bugzilla! :)
On Tuesday 16 June 2009 20:33:20 Jesse Barnes wrote: > On Thu, 11 Jun 2009 15:16:27 +0800 > yakui_zhao <yakui.zhao@intel.com> wrote: > > > On Wed, 2009-05-27 at 16:58 +0800, Jesse Barnes wrote: > > > > > > > > > Jesse, Just talked with Rui, the above status is based on "BIOS > > > > upgrade or FW fix is acceptable as a bug fix solution". are you ok > > > > with this? :) Many lid status has to be fixed via action such as > > > > DSDT upgrade... > > > > > > Yeah, I think that's ok, even if we need quirks for some > > > platforms. I really hate relying on BIOS vendors/OEMs to provide > > > BIOS updates in general: if Windows works on a given platform, why > > > should Linux require a BIOS "fix" on it? In this case though, we > > > can work around broken platforms by just returning "open" all the > > > time, if it comes to that. > > Hi, > > It is a good point that the LID status is used to decide whether > > the LVDS is connected or not. > > As Rui said in the previous thread, sometimes the initial status > > of LID is incorrect on some laptops. If we expect that LVDS can be > > initialized correctly on such boxes, we will have to add the quirk so > > that the LID status is not used for LVDS detection. > > But maybe on such boxes the LID initial status is correct after > > BIOS upgrading or using custom DSDT. Do we need to delete the quirk > > for such box? It is difficult to manage. > > > > So IMO we had better not use the LID status to determine whether > > the LVDS is connected or not. > > Well, what should we use then? Think of a common use case: you plug in > an external monitor and shut your lid. Do we want to make the user > manually change their configuration? Or detect that the lid is no > longer in use? And what about the case where they boot with the lid > closed (e.g. in a docked scenario)? We want to support that > automatically too... > > If we can solve these issues some other way, that's fine, but right now > we have nothing; I think my patch is an improvement over that, even if > it won't work everywhere w/o quirks. Not sure whether it matters here, but Acer (One?) netbooks seem to only throw a lid close and not a lid open event. Suspend/resume still seem to work, something seem to wake the machine up, but a Lid open ACPI notification event is not triggered. Thomas -- 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
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index 9195deb..ebb593e 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -113,6 +113,9 @@ static const struct file_operations acpi_button_state_fops = { .release = single_release, }; +static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier); +static struct acpi_device *lid_device; + /* -------------------------------------------------------------------------- FS Interface (/proc) -------------------------------------------------------------------------- */ @@ -229,11 +232,38 @@ static int acpi_button_remove_fs(struct acpi_device *device) /* -------------------------------------------------------------------------- Driver Interface -------------------------------------------------------------------------- */ +int acpi_lid_notifier_register(struct notifier_block *nb) +{ + return blocking_notifier_chain_register(&acpi_lid_notifier, nb); +} +EXPORT_SYMBOL(acpi_lid_notifier_register); + +int acpi_lid_notifier_unregister(struct notifier_block *nb) +{ + return blocking_notifier_chain_unregister(&acpi_lid_notifier, nb); +} +EXPORT_SYMBOL(acpi_lid_notifier_unregister); + +int acpi_lid_open(void) +{ + acpi_status status; + unsigned long long state; + + status = acpi_evaluate_integer(lid_device->handle, "_LID", NULL, + &state); + if (ACPI_FAILURE(status)) + return -ENODEV; + + return !!state; +} +EXPORT_SYMBOL(acpi_lid_open); + static int acpi_lid_send_state(struct acpi_device *device) { struct acpi_button *button = acpi_driver_data(device); unsigned long long state; acpi_status status; + int ret; status = acpi_evaluate_integer(device->handle, "_LID", NULL, &state); if (ACPI_FAILURE(status)) @@ -242,7 +272,12 @@ static int acpi_lid_send_state(struct acpi_device *device) /* input layer checks if event is redundant */ input_report_switch(button->input, SW_LID, !state); input_sync(button->input); - return 0; + + ret = blocking_notifier_call_chain(&acpi_lid_notifier, state, device); + if (ret == NOTIFY_DONE) + ret = blocking_notifier_call_chain(&acpi_lid_notifier, state, + device); + return ret; } static void acpi_button_notify(struct acpi_device *device, u32 event) @@ -364,8 +399,14 @@ static int acpi_button_add(struct acpi_device *device) error = input_register_device(input); if (error) goto err_remove_fs; - if (button->type == ACPI_BUTTON_TYPE_LID) + if (button->type == ACPI_BUTTON_TYPE_LID) { acpi_lid_send_state(device); + /* + * This assumes there's only one lid device, or if there are + * more we only care about the last one... + */ + lid_device = device; + } if (device->wakeup.flags.valid) { /* Button's GPE is run-wake GPE */ diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3a22eb9..dde56b6 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -71,6 +71,7 @@ config DRM_I915 select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT select FB + select ACPI_BUTTON tristate "i915 driver" help Choose this option if you have a system that has Intel 830M, 845G, diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2506592..fb12fb9 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -190,6 +190,8 @@ typedef struct drm_i915_private { unsigned int lvds_use_ssc:1; int lvds_ssc_freq; + struct notifier_block lid_notifier; + struct drm_i915_fence_reg fence_regs[16]; /* assume 965 */ int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */ int num_fence_regs; /* 8 on pre-965, 16 otherwise */ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index bdcda36..08c1260 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -24,6 +24,8 @@ * Eric Anholt <eric@anholt.net> */ +#include <linux/module.h> +#include <linux/input.h> #include <linux/i2c.h> #include "drmP.h" #include "intel_drv.h" diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 6619f26..8f05b09 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -27,6 +27,7 @@ * Jesse Barnes <jesse.barnes@intel.com> */ +#include <acpi/button.h> #include <linux/dmi.h> #include <linux/i2c.h> #include "drmP.h" @@ -277,12 +278,18 @@ static void intel_lvds_mode_set(struct drm_encoder *encoder, /** * Detect the LVDS connection. * - * This always returns CONNECTOR_STATUS_CONNECTED. This connector should only have - * been set up if the LVDS was actually connected anyway. + * Since LVDS doesn't have hotlug, we use the lid as a proxy. Open means + * connected and closed means disconnected. We also send hotplug events as + * needed, using lid status notification from the input layer. */ static enum drm_connector_status intel_lvds_detect(struct drm_connector *connector) { - return connector_status_connected; + enum drm_connector_status status = connector_status_connected; + + if (!acpi_lid_open()) + status = connector_status_disconnected; + + return status; } /** @@ -321,6 +328,17 @@ static int intel_lvds_get_modes(struct drm_connector *connector) return 0; } +static int intel_lid_notify(struct notifier_block *nb, unsigned long val, + void *unused) +{ + struct drm_i915_private *dev_priv = + container_of(nb, struct drm_i915_private, lid_notifier); + + drm_sysfs_hotplug_event(dev_priv->dev); + + return NOTIFY_OK; +} + /** * intel_lvds_destroy - unregister and free LVDS structures * @connector: connector to free @@ -330,10 +348,14 @@ static int intel_lvds_get_modes(struct drm_connector *connector) */ static void intel_lvds_destroy(struct drm_connector *connector) { + struct drm_device *dev = connector->dev; struct intel_output *intel_output = to_intel_output(connector); + struct drm_i915_private *dev_priv = dev->dev_private; if (intel_output->ddc_bus) intel_i2c_destroy(intel_output->ddc_bus); + if (dev_priv->lid_notifier.notifier_call) + acpi_lid_notifier_unregister(&dev_priv->lid_notifier); drm_sysfs_connector_remove(connector); drm_connector_cleanup(connector); kfree(connector); @@ -508,6 +530,11 @@ void intel_lvds_init(struct drm_device *dev) goto failed; out: + dev_priv->lid_notifier.notifier_call = intel_lid_notify; + if (acpi_lid_notifier_register(&dev_priv->lid_notifier)) { + DRM_DEBUG("lid notifier registration failed\n"); + dev_priv->lid_notifier.notifier_call = NULL; + } drm_sysfs_connector_add(connector); return; diff --git a/include/acpi/button.h b/include/acpi/button.h new file mode 100644 index 0000000..bb643a7 --- /dev/null +++ b/include/acpi/button.h @@ -0,0 +1,10 @@ +#ifndef ACPI_BUTTON_H +#define ACPI_BUTTON_H + +#include <linux/notifier.h> + +extern int acpi_lid_notifier_register(struct notifier_block *nb); +extern int acpi_lid_notifier_unregister(struct notifier_block *nb); +extern int acpi_lid_open(void); + +#endif /* ACPI_BUTTON_H */