From: Seth Forshee <seth.forshee@canonical.com>
To: Lars-Peter Clausen <lars@metafoo.de>,
linux-kernel@vger.kernel.org, Richard Purdie <rpurdie@rpsys.net>,
Matthew Garrett <mjg@redhat.com>
Subject: Re: [PATCH 2/3] apple_bl: Rework in advance of gmux backlight support
Date: Thu, 9 Feb 2012 11:20:39 -0600 [thread overview]
Message-ID: <20120209172039.GB2515@ubuntu-macmini> (raw)
In-Reply-To: <20120206145630.GC6414@ubuntu-macmini>
On Mon, Feb 06, 2012 at 08:56:30AM -0600, Seth Forshee wrote:
> > > Of course there are a couple of ways we could get around this. Not
> > > calling the backlight ops in the gmux case would be an option; then you
> > > don't get the check, but so far as I know right now the check doesn't
> > > work for the gmux backlight anyway. Or allocating the backlight device
> > > first before doing the check, but I don't see that as a good option.
> > >
> >
> > Hm, if that the check doesn't do anything for gmux is there acutally any code
> > shared between the gmux and the legacy path in the driver? If not would make
> > sense to put the gmux backlight support into its own driver?
>
> What I know is that the check doesn't work for the gmux on one
> particular model. On that machine the gmux device is present but doesn't
> control the backlight, yet reads and writes to the backlight ports
> behave the same as if it did control the backlight. That's the only
> model with a gmux that doesn't control the backlight that I've been able
> to get any testing on, so I don't know how other models behave.
>
> But you're right, by and large all the legacy and gmux paths share are
> boilerplate code, other than the fact that they support the same class
> of machines. The way apple_bl is done it seems natural to extended it
> with other backlight interfaces for Apple hardware, but an argument can
> be made for separting it out as well.
I managed to get some more information that will allow me to do a sanity
check on the gmux. This will be completely separate from the check for
the legacy path, meaning they diverge even more. As a result I think I
will go ahead and put the gmux support in its own driver. This probably
makes the most sense anyway as the driver is likely to grow to include
support for the display mux functionality.
But with it being its own driver, I don't think it really belongs in
drivers/video/backlight even though the driver will initially only
supply backlight control. Anyone have suggestions where a driver for a
display mux device should live? I'm not seeing anywhere that looks like
an obviously correct location.
Thanks,
Seth
next prev parent reply other threads:[~2012-02-09 17:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 20:28 [PATCH 0/3] apple_bl: Add support for gmux backlight control Seth Forshee
2012-02-03 20:28 ` [PATCH 1/3] apple_bl: Convert printks to pr_<level> Seth Forshee
2012-02-03 20:39 ` Joe Perches
2012-02-05 23:23 ` Ryan Mallon
2012-02-06 14:35 ` Seth Forshee
2012-02-06 21:47 ` Ryan Mallon
2012-02-03 20:28 ` [PATCH 2/3] apple_bl: Rework in advance of gmux backlight support Seth Forshee
2012-02-03 22:25 ` Lars-Peter Clausen
2012-02-03 22:51 ` Seth Forshee
2012-02-04 17:25 ` Lars-Peter Clausen
2012-02-06 14:56 ` Seth Forshee
2012-02-09 17:20 ` Seth Forshee [this message]
2012-02-10 9:25 ` Lars-Peter Clausen
2012-02-10 14:50 ` Seth Forshee
2012-02-03 20:28 ` [PATCH 3/3] apple_bl: Add support for gmux backlight control Seth Forshee
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=20120209172039.GB2515@ubuntu-macmini \
--to=seth.forshee@canonical.com \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=rpurdie@rpsys.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).