From: Richard Purdie <rpurdie@rpsys.net>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
Antonino Daplas <adaplas@pol.net>, Holger Macht <hmacht@suse.de>
Subject: Re: [PATCH] backlight: do not power off backlight when unregistering
Date: Mon, 06 Nov 2006 00:36:34 +0000 [thread overview]
Message-ID: <1162773394.5473.18.camel@localhost.localdomain> (raw)
In-Reply-To: <20061105225429.GE14295@khazad-dum.debian.net>
On Sun, 2006-11-05 at 20:54 -0200, Henrique de Moraes Holschuh wrote:
> ACPI drivers like ibm-acpi are moving to the backlight sysfs infrastructure.
> During ibm-acpi testing, I have noticed that backlight_device_unregister()
> sets the display brightness and power to zero.
>
> This causes the display to be dimmed on ibm-acpi module removal. It will
> affect all other ACPI drivers that are being converted to use the backlight
> class, as well.
>
> This annoying behaviour in backlight_device_unregister() can either be
> reverted, or it can be worked around on acpi drivers by doing a
> backlightdevice->props->update_status = NULL before calling
> backlight_device_unregister().
>
> Given the, AFAIK, lack of a good reason to disable display backlight as the
> _general_ behaviour for the entire sysfs class, the attached patch changes
> backlight.c to not do so anymore.
The reason the corgi code does this is quite simple. If you don't turn
off the backlight when unloading the backlight driver, nothing can turn
the backlight off. The backlight is the biggest power consumer on corgi
and would cause some power drain even if for example you then suspend
the device. I never want to end up with those bug reports. I reasoned
that other devices would have a similar set of constraints (all the
existing users at the time did). On such hardware, deinitialising
anything you initialised is the norm and makes sense but the PC/ACPI
world is different.
Setting backlightdevice->props->update_status = NULL before
unregistering is a horrible idea and I don't want to see hacks like that
so yes, lets move it back into the drivers.
> Since the commit that introduced this behaviour (commit
> 6ca017658b1f902c9bba2cc1017e301581f7728d) apparently did so because the
> corgi_bl.c driver powered off the backlight, the attached patch also makes
> sure that the corgi_bl.c driver will not have its behaviour changed.
Those commits were designed to standardise several behaviours amongst
several drivers and this specific case was added to the core rather than
coding it in each of several drivers. We therefore really need to update
those other drivers too (locomo at the very least).
Richard
next prev parent reply other threads:[~2006-11-06 0:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-05 22:54 [PATCH] backlight: do not power off backlight when unregistering Henrique de Moraes Holschuh
2006-11-06 0:36 ` Richard Purdie [this message]
2006-11-06 1:26 ` Henrique de Moraes Holschuh
2006-11-10 0:08 ` Henrique de Moraes Holschuh
2006-11-10 0:32 ` [PATCH] backlight: do not power off backlight when unregistering (try 2) Henrique de Moraes Holschuh
2006-11-10 10:44 ` Richard Purdie
2006-11-20 19:31 ` [PATCH] backlight: do not power off backlight when unregistering James Simmons
2006-11-21 3:01 ` Henrique de Moraes Holschuh
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=1162773394.5473.18.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=adaplas@pol.net \
--cc=hmacht@suse.de \
--cc=hmh@hmh.eng.br \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox