search for: intel_lid_notifi

Since notification side has been changed to always notify kernel listeners using _LID returning value. Now listeners needn't invoke acpi_lid_open(), it should use a spec suggested control method lid device usage model: register lid notification and use the notified value instead, which is the only way to ensure the value is correct for "button.lid_init_state=ignore" mode or other

On Mon, May 15, 2017 at 10:42 AM, Jani Nikula <jani.nikula at linux.intel.com> wrote: > On Mon, 15 May 2017, Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote: >> I'll answer everything in the other thread, where there are slightly >> more other points raised: https://lkml.org/lkml/2017/5/15/10 > > If you are discussing changes impacting i915, please

Both nouveau and i915, the only 2 kernel space lid notification listeners, invoke acpi_lid_open() API to obtain _LID returning value instead of using the notified value. So this patch moves this logic from listeners to lid driver, always notify kernel space listeners using _LID returning value. This is a no-op cleanup, but facilitates administrators to configure to notify kernel drivers with

On Tue, May 9, 2017 at 9:02 AM, Lv Zheng <lv.zheng at intel.com> wrote: > Since notification side has been changed to always notify kernel listeners > using _LID returning value. Now listeners needn't invoke acpi_lid_open(), > it should use a spec suggested control method lid device usage model: > register lid notification and use the notified value instead, which is the >

On Mon, 15 May 2017, Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote: > On Mon, May 15, 2017 at 10:42 AM, Jani Nikula > <jani.nikula at linux.intel.com> wrote: >> On Mon, 15 May 2017, Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote: >>> I'll answer everything in the other thread, where there are slightly >>> more other

Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoires at gmail.com] > Subject: Re: [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations > > On Tue, May 9, 2017 at 9:02 AM, Lv Zheng <lv.zheng at intel.com> wrote: > > Since notification side has been changed to always notify kernel listeners > > using _LID returning value. Now listeners needn't

Hi Lv, On May 27 2017 or thereabouts, Lv Zheng wrote: > Both nouveau and i915, the only 2 kernel space lid notification listeners, > invoke acpi_lid_open() API to obtain _LID returning value instead of using > the notified value. > > So this patch moves this logic from listeners to lid driver, always notify > kernel space listeners using _LID returning value. > > This is

Hi Lv, On Mon, May 15, 2017 at 5:55 AM, Zheng, Lv <lv.zheng at intel.com> wrote: > Hi, Benjamin > >> From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Benjamin >> Tissoires >> Subject: Re: [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations >> >> Hi Lv, >> >> I am trying to reduce

Hi, If my previous reply is not persuasive enough. Let me do that in a different way. > From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Zheng, > Lv > Subject: RE: [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations > > Hi, > > > From: Benjamin Tissoires [mailto:benjamin.tissoires at gmail.com] > >

Hi Lv, I am trying to reduce the number of parallel discussion we have on the same subject, but there is something here I can't let you have. On Fri, May 12, 2017 at 8:08 AM, Zheng, Lv <lv.zheng at intel.com> wrote: > Hi, > > If my previous reply is not persuasive enough. > Let me do that in a different way. > >> From: linux-acpi-owner at vger.kernel.org

Hi, Benjamin > From: linux-acpi-owner at vger.kernel.org [mailto:linux-acpi-owner at vger.kernel.org] On Behalf Of Benjamin > Tissoires > Subject: Re: [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations > > Hi Lv, > > I am trying to reduce the number of parallel discussion we have on the > same subject, but there is something here I can't let you have.

Hi all, First thing first: It works, I now no longer have a few dropped frames every 10s on my testbox here with the pageflip i-g-t tests. Random notes: - New design has per-crtc locks to protect the crtc input-side (pageflip, cursor) for r/w and the output state of the crtc (mode, dpms) as read-only. It also required completely revamped fb lifecycle management, those are now refcounted