On Tuesday 08 January 2008 20:47:00 Len Brown wrote:
> FYI,
> I think we may have an issue here where the entire Linux suspend order
> is being proposed to change, when in fact the underlying issue
> may really be that USB is in D3 on S3 for this box when it is
> not supposed to be deeper below D1.
I updated http://bugzilla.kernel.org/show_bug.cgi?id=9663 with some checked
kernel version:
I checked these builds now:
2.6.23-acpi.git (~ Aug/Sep 07) with _and_ without acpi=off -> WORKS
2.6.24-rc6 from git with no cmdline-option -> works NOT
2.6.24-rc6 from git with acpi=off -> WORKS !!
I'
On Tuesday 08 January 2008, Len Brown wrote:
> FYI,
> I think we may have an issue here where the entire Linux suspend order
> is being proposed to change, when in fact the underlying issue
> may really be that USB is in D3 on S3 for this box when it is
> not supposed to be deeper below D1.
>
> ht
On Tuesday, 8 of January 2008, Len Brown wrote:
> FYI,
> I think we may have an issue here where the entire Linux suspend order
> is being proposed to change, when in fact the underlying issue
> may really be that USB is in D3 on S3 for this box when it is
> not supposed to be deeper below D1.
>
>
FYI,
I think we may have an issue here where the entire Linux suspend order
is being proposed to change, when in fact the underlying issue
may really be that USB is in D3 on S3 for this box when it is
not supposed to be deeper below D1.
http://bugzilla.kernel.org/show_bug.cgi?id=9528
-Len
-
To un
On Tue, 08 Jan 2008, Richard Purdie wrote:
> > So be it, then. But my request that we get a way to add the information we
> > are losing to the backlight class still stands.
>
> The thing is does this 0-100 value have a use to userspace? Its
You can request something like "middle brightness plea
On Tue, 2008-01-08 at 14:49 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 08 Jan 2008, Richard Purdie wrote:
> > On Tue, 2008-01-08 at 15:54 +, Matthew Garrett wrote:
> > > On Tue, Jan 08, 2008 at 03:45:02PM +, Richard Purdie wrote:
> > >
> > > > I did't get enough context above but
On Tue, 08 Jan 2008, Richard Purdie wrote:
> On Tue, 2008-01-08 at 15:54 +, Matthew Garrett wrote:
> > On Tue, Jan 08, 2008 at 03:45:02PM +, Richard Purdie wrote:
> >
> > > I did't get enough context above but I went through the archives and it
> > > seems this is about linearising backlig
On 01/06/2008 11:38 AM, Lee Howard wrote:
> Len Brown wrote:
>> On Wednesday 02 January 2008 09:11, Dominique Michel wrote:
>>
>>> Le Sat, 29 Dec 2007 10:40:20 -0800,
>>> Lee Howard <[EMAIL PROTECTED]> a écrit :
>>>
>>>
>>>
# cat /proc/interrupts
CPU00: 1051464247
On Tue, 2008-01-08 at 15:54 +, Matthew Garrett wrote:
> On Tue, Jan 08, 2008 at 03:45:02PM +, Richard Purdie wrote:
>
> > I did't get enough context above but I went through the archives and it
> > seems this is about linearising backlight values.
>
> Indeed. The ACPI spec provides a rang
On Tue, 2008-01-08 at 10:48 -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 08 Jan 2008, Matthew Garrett wrote:
> > On Tue, Jan 08, 2008 at 10:06:53AM -0200, Henrique de Moraes Holschuh wrote:
> > > Is there a *real* technical reason why we can't just round to the nearest?
> > > That will work
On Tue, Jan 08, 2008 at 03:45:02PM +, Richard Purdie wrote:
> I did't get enough context above but I went through the archives and it
> seems this is about linearising backlight values.
Indeed. The ACPI spec provides a range of 0-100, without specifying what
this actually means (it gives bri
On Tue, Jan 08, 2008 at 10:48:20AM -0200, Henrique de Moraes Holschuh wrote:
> Heck, back to the video.c driver, you shouldn't even assume _BCL gives you a
> sorted list after the second element. I admit it takes an special kind of
> weird firmware to screw with _BCL like that, but the ACPI spec
On Tue, 08 Jan 2008, Matthew Garrett wrote:
> On Tue, Jan 08, 2008 at 10:06:53AM -0200, Henrique de Moraes Holschuh wrote:
> > Is there a *real* technical reason why we can't just round to the nearest?
> > That will work well with any firmware, and it will not remove functionality
> > from any box,
Rename defines with IBM in their name that are related to the older
driver name (ibm-acpi) to TPACPI, unless they are specific to IBM
ThinkPads.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 324 +-
1 fil
General cleanup of module glue: Do some code reordering, and add
missing parameter help text.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 83 +-
1 files changed, 50 insertions(+), 33 deletions(-)
diff
Handle some HKEY events that the firmware uses to report the reason for a
wake up, and to also notify that the system could go back to sleep (if it
woke up just to eject something from the bay, or to undock).
The driver will report the reason of the last wake up in the sysfs
attribute "wakeup_reas
Tomas Carnecky reports that events 0x5009 and 0x500a are swivel events, and
that 0x500b/0x500c are tablet pen storage bay events.
Document these events, and avoid nasty messages when they happen.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
Documentation/thinkpad-acpi.txt |
The major code reorganization and cleanups, and new HKEY events, plus
poll()/select() support are good reasons to checkpoint a new version...
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
Documentation/thinkpad-acpi.txt |4 ++--
drivers/misc/thinkpad_acpi.c|2 +-
Reorder code in the file to get rid of more of the forward declarations,
and to make things cleaner and more organized.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 1493 +-
1 files changed, 734 insertion
Remove the header file. Private header files used by a single .c file are
in bad taste, and I know better now.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 632 -
drivers/misc/thinkpad_acpi.h | 656 ---
Update the copyright headers to include 2008.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 91bda31..05f532
When both CONFIG_THINKPAD_ACPI_DOCK and CONFIG_THINKPAD_ACPI_BAY are
undefined, _sta is not used and that causes a gcc warning. Fix it
(and I think this is a regression, I am pretty sure I fixed this once
before, sorry about that).
Issue reported by: Pritt Laes.
Signed-off-by: Henrique de Moraes
Older ThinkPad models do not export some of the hot keys over the
event-based ACPI hot key interface. For these models, one has to poll
the CMOS NVRAM to check the key state at a rate faster than the expected
rate at which the user might repeatedly press the same hot key.
This patch implements th
Move most subdriver-related stuff imported from the header file closer to
their subdriver code. Also, delete unneeded forward declarations.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 613 +-
1 files c
Implement poll()/select() support through sysfs_notify() for some key
attributes which userspace might want to poll() or select() on.
In order to let userspace know poll()/select() support is available for an
attribute, the thinkpad-acpi sysfs interface version is also bumped up.
Further changes t
Fix some of the crap reported by checkpatch.pl.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 291 +-
1 files changed, 175 insertions(+), 116 deletions(-)
diff --git a/drivers/misc/thinkpad_acpi.c b/driv
Use a generic message on hotkey_notify to log unknown and unhandled events,
and cleanup hotkey_notify a little.
Also, document event 0x5010 (brightness changed notification) and do not
log it as an unknown event (even if we do not use it for anything right
now).
Signed-off-by: Henrique de Moraes
Add a handler for suspend events.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index dd6fa81..c6
The NVRAM polling support for hot keys is reason enough to
bump up the version string. Do it.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
Documentation/thinkpad-acpi.txt |4 ++--
drivers/misc/thinkpad_acpi.c|2 +-
2 files changed, 3 insertions(+), 3 deletions(-
Remove dead code, and anything in the old changelog that is not a thank
you credit, or a key point to track down history.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 55 +++--
1 files changed, 4 insertions
Refactor and organize the code a bit for the NVRAM polling support:
1. Split hotkey_get/set into hotkey_status_get/set and hotkey_mask_get/set;
2. Cache the status of hot key mask for later driver use;
3. Make sure the cache of hot key mask is refreshed when needed;
4. log a printk notice when the
Make some small internal thinkpad-acpi changes to the hotkey subdriver code
that will make it easier to add NVRAM polling support.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 82 +
1 files changed, 42
Publish the requirements for keymap changes. This is a documentation
change, only.
Currently, people look at the thinkpad-acpi default keymaps, and think:
"modifying this is a trivial thing, it can't break systems, and there are
keys defined for foo and bar, but the driver has them as KEY_RESERVE
Len,
This patchset has my current thinkpad-acpi queue. The target is 2.6.25.
This set *replaces* the previous batch 1 I sent. I have changed a few of the
patches, and added a few new ones in different points of the stack. It is
simpler to just resubmit them all than to ask you to replace this
On Tue, Jan 08, 2008 at 10:06:53AM -0200, Henrique de Moraes Holschuh wrote:
> Is there a *real* technical reason why we can't just round to the nearest?
> That will work well with any firmware, and it will not remove functionality
> from any box, while at the same time plugging the current issues
On Tue, 08 Jan 2008, Matthew Garrett wrote:
> On Mon, Jan 07, 2008 at 10:32:46PM -0200, Henrique de Moraes Holschuh wrote:
>
> > Should we? Why? We lose information doing that. Instead of a nice linear
> > 0-100% brightness scale, you are now back to an 8 or 16-level non-linear
> > brightness s
37 matches
Mail list logo
