similar to: [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 should use a spec suggested control method lid device usage model: > register lid notification and use the notified value instead, which is the >

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, > 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

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

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, 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 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

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

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

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 keep intel-gfx list in the loop. Thanks, Jani. -- Jani Nikula, Intel Open Source Technology Center

On Wed, Feb 17, 2010 at 10:42:43AM +0100, Daniel Mack wrote: > Fix the following compile time error: > > drivers/built-in.o: In function `nouveau_connector_detect': > /home/daniel/src/linux/jup/linux-2.6/drivers/gpu/drm/nouveau/nouveau_connector.c:243: undefined reference to `acpi_lid_open' > > Signed-off-by: Daniel Mack <daniel at caiaq.de> > Cc: David Airlie

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch

Some notebook systems provide the EDID for the internal panel via the _DDC method in ACPI, instead of or in addition to providing the EDID via DDC on LVDS/eDP. Add a DRM helper to search for an ACP _DDC method under the ACPI namespace for each VGA/3D controller, and return the first EDID successfully retrieved via _DDC. Update the i915, nouveau, and radeon DRM-KMS drivers to fall back to

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

Hello, This patch series aims at replacing all dummy ->best_encoder() implementations where we have a 1:1 relationship between encoders and connectors. The core already provides the drm_atomic_helper_best_encoder() function which is taking the first encoder attached to the connector (after making sure only one encoder was attached to the connector), but it's not automatically used, and

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Archit Taneja <architt at

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Archit Taneja <architt at