search for: _lid

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 driver...

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] > > 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> wro...

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 a no-op cleanup, but facilitates administrators to con...

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 > only way to ensure the value is correct for "button.lid_init_state=...

...; 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] >> > 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....

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. OK. So let's stop talking in PATCH 4-5. They are actually cleanups from my point of view. In fact, I...

...on, 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 the number of parallel discussion we have on the >> same subject, but there is something here I can't let you have. > > OK. So let's stop talking in PATCH 4-5. > They are actually cleanups fro...

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" mo...

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 invoke acpi_lid_open(), > > it shoul...

...7/5/15/10 > > If you are discussing changes impacting i915, please keep intel-gfx list > in the loop. > I can add intel-gfx to the other thread if you want, but this will IMO just add more noise to your list. The question is whether or not the kernel should provide a fake state for the _LID acpi call, and until we reach an agreement on how to handle things, there is no point changing the currently working code in i915. It is true that there is an issue in i915 regarding the fact that intel_lid_notify() doesn't use the provided value but calls acpi_lid_open(), but this is somethin...

...iscussing changes impacting i915, please keep intel-gfx list >> in the loop. >> > > I can add intel-gfx to the other thread if you want, but this will IMO > just add more noise to your list. > The question is whether or not the kernel should provide a fake state > for the _LID acpi call, and until we reach an agreement on how to > handle things, there is no point changing the currently working code > in i915. Fair enough. > It is true that there is an issue in i915 regarding the fact that > intel_lid_notify() doesn't use the provided value but calls &gt...

.....ECON.p..`.#. 2920: 1b 93 5e 5e 2f 04 50 43 49 30 4c 50 43 42 48 5f ..^^/.PCI0LPCBH_ 2930: 45 43 41 43 45 58 00 70 0a 1f 60 a1 05 70 0a 0f ECACEX.p..`..p.. 2940: 60 a4 60 5b 82 1b 4c 49 44 30 08 5f 48 49 44 0c `.`[..LID0._HID. 2950: 41 d0 0c 0d 14 0b 5f 4c 49 44 00 a4 4c 49 44 53 A....._LID..LIDS 2960: 5b 82 1b 50 57 52 42 08 5f 48 49 44 0c 41 d0 0c [..PWRB._HID.A.. 2970: 0c 08 5f 50 52 57 12 06 02 0a 1e 0a 04 5b 82 3d .._PRW.......[.= 2980: 44 4d 41 43 08 5f 48 49 44 0c 41 d0 02 00 08 5f DMAC._HID.A...._ 2990: 43 52 53 11 28 0a 25 47 01 00 00 00 00 01 20 47 CRS.(.%G.........