From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754153AbeAQRNs (ORCPT ); Wed, 17 Jan 2018 12:13:48 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:44685 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752648AbeAQRNp (ORCPT ); Wed, 17 Jan 2018 12:13:45 -0500 X-Google-Smtp-Source: ACJfBovcoZJ6BpimsYZn0oC+ZUXd1+eiKQcmB9AVqAwnv81FkvMNfcO32WftbdWLaVx9THno60sT4w== Date: Wed, 17 Jan 2018 18:13:40 +0100 From: Daniel Vetter To: Daniel Thompson Cc: Daniel Vetter , DRI Development , LKML , Lee Jones , Jingoo Han , Daniel Vetter Subject: Re: [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state Message-ID: <20180117171340.GZ2759@phenom.ffwll.local> Mail-Followup-To: Daniel Thompson , DRI Development , LKML , Lee Jones , Jingoo Han , Daniel Vetter References: <20180117140159.27611-1-daniel.vetter@ffwll.ch> <20180117140159.27611-2-daniel.vetter@ffwll.ch> <9cbcb5d4-1e7c-5df6-a73c-f93b1d2fdbee@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9cbcb5d4-1e7c-5df6-a73c-f93b1d2fdbee@linaro.org> X-Operating-System: Linux phenom 4.14.0-1-amd64 User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 17, 2018 at 04:44:00PM +0000, Daniel Thompson wrote: > On 17/01/18 14:01, Daniel Vetter wrote: > > Nothing in the entire tree ever sets this, which means this is dead > > code. Remove it. > > > > Cc: Lee Jones > > Cc: Daniel Thompson > > Cc: Jingoo Han > > Signed-off-by: Daniel Vetter > > Not sure whether to ack this one or not. > > There is nothing wrong with the change but having taken a closer look the > driver seems like it exists mostly to allow mach-XXX code to plug in > function pointers and we don't do that sort of thing any more. > > I think the entire driver is dead code! Well I can also supply a patch to outright nuke the code, but figuring out whether that's the right thing to do is definitely way above may pay grade :-) I only really stitched these together after a long discussion with Meghana about why backlight seems to have 3+ different ways to enable/disable a backlight. Just trying to help a bit with getting the backlight_enable/disable stuff going, so that long-term, at least for newer drivers, we have one blessed way to do that. btw that kind of display pm simplification matches what we've done when implementing atomic modesetting about 3 years ago: We've smashed all the various power states drm (and fbdev/fbcon) knew about into a simple "is it on?" boolean. Todays digital hw doesn't really know anything in-between. Ofc there's tons of components to switch on/off to get the entire display pipe up, and they might want different autosuspend delays to optimize the overall system, but that's orthogonal (well, driver internal implementation detail) really. Cheers, Daniel > > > Daniel. > > > > --- drivers/video/backlight/generic_bl.c | 5 ----- 1 file changed, 5 > > deletions(-) > > > > diff --git a/drivers/video/backlight/generic_bl.c > > b/drivers/video/backlight/generic_bl.c index > > 67dfb939a514..4dea91acea13 100644 --- > > a/drivers/video/backlight/generic_bl.c +++ > > b/drivers/video/backlight/generic_bl.c @@ -21,9 +21,6 @@ static int > > genericbl_intensity; static struct backlight_device > > *generic_backlight_device; static struct generic_bl_info *bl_machinfo; > > -/* Flag to signal when the battery is low */ -#define > > GENERICBL_BATTLOW BL_CORE_DRIVER1 - static int > > genericbl_send_intensity(struct backlight_device *bd) { int intensity > > = bd->props.brightness; @@ -34,8 +31,6 @@ static int > > genericbl_send_intensity(struct backlight_device *bd) intensity = 0; > > if (bd->props.state & BL_CORE_SUSPENDED) intensity = 0; - if > > (bd->props.state & GENERICBL_BATTLOW) - intensity &= > > bl_machinfo->limit_mask; bl_machinfo->set_bl_intensity(intensity); > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch