All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Kępień" <kernel@kempniu.pl>
To: Jonathan Woithe <jwoithe@just42.net>
Cc: Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/4] fujitsu_init() cleanup
Date: Tue, 7 Mar 2017 09:08:07 +0100	[thread overview]
Message-ID: <20170307080807.GA1805@ozzy.nask.waw.pl> (raw)
In-Reply-To: <20170307035016.GY23178@marvin.atrad.com.au>

> Hi Michael
> 
> On Mon, Mar 06, 2017 at 07:47:23PM +0100, Micha?? K??pie?? wrote:
> > > > In light of the above findings, what would you like to do?
> > > 
> > > Thanks for testing, good that we caught this before the patch series was
> > > applied.  I think it is reasonable to skip applying this version of the
> > > series as at least patch 2/4 is faulty and breaks a working feature.
> > > 
> > > Moving on, though, as I do not have access to Fujitsu hardware on which
> > > this feature works, I was hoping you could help me verify whether my
> > > assumptions were reasonable in the first place.  
> > > 
> > > I attached a crude patch to this message.  I would like to understand
> > > how the underlying ACPI variables behave when the FEXT interface is
> > > used, so please apply this patch on top of dvhart/testing (i.e. without
> > > this series applied).  After compiling, please load the module with
> > > debugging enabled, then test backlight control once again by writing 4
> > > and then 0 to bl_power (this should work).  Then please send me all the
> > > messages spit out by the driver into dmesg.  This should shed some light
> > > on the matter.
> 
> I have done this.  Writing 4 to bl_power did indeed turn the backlight off,
> and 0 restored it.  Annotated output from dmesg is at the end of this
> message.
> 
> > Actually, scratch that.  I just ordered a banged up S7020 for ???15 to
> > avoid pestering you with experimental patches and hopefully make the
> > whole driver cleanup process a bit smoother.
> 
> Ok, no problem.  Obviously I'm still happy to test as required.
> 
> > Darren, Andy, please ignore this whole series for now.  I will post v3
> > once I figure out how to clean things up without breaking working
> > features.
> 
> To clarify, I see no reason why the earlier 2-patch cleanup series can't go
> in at this stage.  It's only this 4-part patch which needs revision in light
> of recent findings.

Yes, this is what I meant.  As I mentioned earlier in this thread [1],
v2 of the 2-patch series for acpi_fujitsu_bl_notify() is independent
from this one.

[]

> 
> echo 4 > /sys/devices/virtual/backlight/fujitsu-laptop/bl_power
> 
> [ 3320.168775] fujitsu_laptop: call_fext_func: FUNC 0x1004 (args 0x1, 0x4, 0x3) returned 0x0
> [ 3320.168779] fujitsu_laptop: bl_update_status: Backlight power set to 4
> [ 3320.168793] fujitsu_laptop: bl_update_status: BLCT = 1
> [ 3320.168800] fujitsu_laptop: bl_update_status: NGTM = 3
> [ 3320.168805] fujitsu_laptop: bl_update_status: Got ACPI handle for SBLC
> [ 3320.168808] fujitsu_laptop: set_lcd_level: set lcd level via SBLL [7]
> 
> echo 4 > /sys/devices/virtual/backlight/fujitsu-laptop/bl_power
> 
> [ 3322.774773] fujitsu_laptop: call_fext_func: FUNC 0x1004 (args 0x1, 0x4, 0x0) returned 0x0
> [ 3322.774776] fujitsu_laptop: bl_update_status: Backlight power set to 0
> [ 3322.774790] fujitsu_laptop: bl_update_status: BLCT = 0
> [ 3322.774798] fujitsu_laptop: bl_update_status: NGTM = 0
> [ 3322.774802] fujitsu_laptop: bl_update_status: Got ACPI handle for SBLC
> [ 3322.774804] fujitsu_laptop: set_lcd_level: set lcd level via SBLL [7]

Okay, this is exactly what I feared.  I correctly inferred how BLCT
behaves from the DSDT dump, but it looks like it works in tandem with
NGTM, which can only be set using the FUNC interface.

This means that, to avoid code duplication, we will need to use
call_fext_func() from within the backlight driver.  If we decide to
split backlight-related code and the rest into two separate modules,
this means that the backlight module will depend on the laptop module.
This is not really bad in and of itself, but I was hoping we could do
better than that.  That being said, a part of me is also happy that we
will stick to the "official" interface instead of doing custom low-level
tricks.

Anyway, I will prepare a v3 that does not break backlight control.
Driver untangling will have to wait.

[1] https://www.spinics.net/lists/platform-driver-x86/msg10776.html

-- 
Best regards,
Michał Kępień

      reply	other threads:[~2017-03-07  8:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-01  8:10 [PATCH v2 0/4] fujitsu_init() cleanup Michał Kępień
2017-03-01  8:10 ` [PATCH v2 1/4] platform/x86: fujitsu-laptop: register backlight device in a separate function Michał Kępień
2017-03-01  8:10 ` [PATCH v2 2/4] platform/x86: fujitsu-laptop: do not use call_fext_func() for LCD blanking Michał Kępień
2017-03-01  8:10 ` [PATCH v2 3/4] platform/x86: fujitsu-laptop: only register backlight device if FUJ02B1 is present Michał Kępień
2017-03-01  8:10 ` [PATCH v2 4/4] platform/x86: fujitsu-laptop: cleanup error labels in fujitsu_init() Michał Kępień
     [not found] ` <20170301223912.GF28335@marvin.atrad.com.au>
2017-03-01 23:26   ` [PATCH v2 0/4] fujitsu_init() cleanup [resend due to vger error] Jonathan Woithe
2017-03-02  7:19   ` [PATCH v2 0/4] fujitsu_init() cleanup Michał Kępień
2017-03-03 12:39     ` Jonathan Woithe
2017-03-04  1:47 ` Jonathan Woithe
2017-03-05 23:48   ` Jonathan Woithe
2017-03-06  4:49     ` Michał Kępień
2017-03-06  5:01       ` Jonathan Woithe
2017-03-06  8:10         ` Jonathan Woithe
2017-03-06  9:33           ` Michał Kępień
2017-03-06 18:47             ` Michał Kępień
2017-03-07  3:50               ` Jonathan Woithe
2017-03-07  8:08                 ` Michał Kępień [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170307080807.GA1805@ozzy.nask.waw.pl \
    --to=kernel@kempniu.pl \
    --cc=andy@infradead.org \
    --cc=dvhart@infradead.org \
    --cc=jwoithe@just42.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.