RE: preparing toshiba_acpi driver release

RE: preparing toshiba_acpi driver release

[Brown, Len]

Hi John,
In general, it it is best to have smaller patches which are single
logical changes so that they can be reviewed as a unit, tested as a
unit, and applied or un-applied as a unit.  However, if the changes are
small, grouping several together is fine.

Also, if the patch applies both to 2.4 and 2.6, but the patch is
different, then I appresiate getting both patches rather than having to
port the patch myself.

Note that the strategy going forward is to create a generic acpi/video
extensions driver that works on all platforms.  When it is available, we
should remove the video functionality from toshiba_extras and
asus_extras.
http://bugzilla.kernel.org/show_bug.cgi?id=1944

If anybody is excited about doing this, I'd be happy to work with a
volunteer.

Thanks,
-Len


> -----Original Message-----
> From: John Belmonte [mailto:john-wanGne27zNesTnJN9+BGXg@public.gmane.org] 
> Sent: Monday, January 26, 2004 11:33 AM
> To: Brown, Len
> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: preparing toshiba_acpi driver release
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Len,
> 
> I'm preparing a new release of the toshiba_acpi driver.  Below is the
> tentative changelog.  I haven't been following the check-in policy of
> the kernel or acpi subsystem lately, so I'm wondering if I 
> can give this
> to you as a single patch or do you need it in several parts.
> 
> 
> ~  * Fix remote chance of invalid buffer access in write_video.
> 
> ~  * Support alternate HCI method path (recent "Phoenix BIOS" 
> Toshiba's).
> 
> ~  * Report more proc-write errors.
> 
> ~  * On proc-reads, report errors via printk instead of proc output.
> 
> ~  * Add level to all printk's.
> 
> ~  * Add missing __init and __exit function attributes.
> 
> 
> Regards,
> - -John Belmonte
> 
> 
> - --
> http:// if  ile.org/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFAFUE35Nfg6kxAQQoRAjQaAKCsdt8QoBH6w2TbtyPSzfpEy1ywMACguflq
> cc6Z79zaEhCmj4C9USs5TBE=
> =oq55
> -----END PGP SIGNATURE-----
> 


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Ducrot Bruno]

On Mon, Jan 26, 2004 at 12:44:36PM -0500, Brown, Len wrote:
> Hi John,
> In general, it it is best to have smaller patches which are single
> logical changes so that they can be reviewed as a unit, tested as a
> unit, and applied or un-applied as a unit.  However, if the changes are
> small, grouping several together is fine.
> 
> Also, if the patch applies both to 2.4 and 2.6, but the patch is
> different, then I appresiate getting both patches rather than having to
> port the patch myself.
> 
> Note that the strategy going forward is to create a generic acpi/video
> extensions driver that works on all platforms.  When it is available, we
> should remove the video functionality from toshiba_extras and
> asus_extras.
> http://bugzilla.kernel.org/show_bug.cgi?id=1944
> 
> If anybody is excited about doing this, I'd be happy to work with a
> volunteer.
> 

ATM I'm more excited with the support of processor _CST (with a patch
I already send to you and Dominik for first testing purpose), but
if nobody else want to volunteer, why not?

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[John Belmonte]

Brown, Len wrote:
> In general, it it is best to have smaller patches which are single 
> logical changes so that they can be reviewed as a unit, tested as a 
> unit, and applied or un-applied as a unit. However, if the changes
> are small, grouping several together is fine.

Although my driver is bundled with the acpi subsystem, I maintain and 
support it independently.  The driver has a version that is independent 
of the acpi subsystem.  In the past, whenever a new version was ready, 
I'd release it to Andrew.  When a problem is reported to me, I want to 
be able to determine exactly what code I'm dealing with from the driver 
version.  For this reason, I'd prefer that you accept my changes as a whole.

> Also, if the patch applies both to 2.4 and 2.6, but the patch is 
> different, then I appresiate getting both patches rather than having
> to port the patch myself.

In the case of my driver, the same driver source is used in both kernels.

> Note that the strategy going forward is to create a generic
> acpi/video extensions driver that works on all platforms. When it is
> available, we should remove the video functionality from
> toshiba_extras and asus_extras. 
> http://bugzilla.kernel.org/show_bug.cgi?id=1944
 >
 > If anybody is excited about doing this, I'd be happy to work with a
 > volunteer.

I already responded about this on acpi-devel, saying I would tentatively 
take stab at it.

Regards,
-John


-- 
http:// if  ile.org/


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: preparing toshiba_acpi driver release

[Brown, Len]

> > Note that the strategy going forward is to create a generic 
> acpi/video
> > extensions driver that works on all platforms.  When it is 
> available, we
> > should remove the video functionality from toshiba_extras and
> > asus_extras.
> > http://bugzilla.kernel.org/show_bug.cgi?id=1944
> > 
> > If anybody is excited about doing this, I'd be happy to work with a
> > volunteer.
> > 
> 
> ATM I'm more excited with the support of processor _CST (with a patch
> I already send to you and Dominik for first testing purpose), but
> if nobody else want to volunteer, why not?

Cool.  Go ahead and "ACCEPT" the bug to let others know you're looking
at it.

I think it would be good to get acpi video standardized to defuse the
need for more platform-specific code...  Indeed, the next piece of the
puzzle it to figure out how to properly do hot-keys correctly.  Surely
Windows doesn't have a driver for each OEM's buttons...

I think video brightness control will be a very popular and visible
feature -- no pun intened;-)

In the back of my head I'm also wondering if we've got a missing piece
of the suspend/resume puzzle here too -- and I'd hate for ACPI to be the
"missing link" to get that key feature working.

Thanks,
-Len


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Ducrot Bruno]

On Mon, Jan 26, 2004 at 01:54:38PM -0500, Brown, Len wrote:
> 
> > > Note that the strategy going forward is to create a generic 
> > acpi/video
> > > extensions driver that works on all platforms.  When it is 
> > available, we
> > > should remove the video functionality from toshiba_extras and
> > > asus_extras.
> > > http://bugzilla.kernel.org/show_bug.cgi?id=1944
> > > 
> > > If anybody is excited about doing this, I'd be happy to work with a
> > > volunteer.
> > > 
> > 
> > ATM I'm more excited with the support of processor _CST (with a patch
> > I already send to you and Dominik for first testing purpose), but
> > if nobody else want to volunteer, why not?
> 
> Cool.  Go ahead and "ACCEPT" the bug to let others know you're looking
> at it.
> 
> I think it would be good to get acpi video standardized to defuse the
> need for more platform-specific code...  Indeed, the next piece of the
> puzzle it to figure out how to properly do hot-keys correctly.  Surely
> Windows doesn't have a driver for each OEM's buttons...

Wait.  I take video, not hotkey :)

> I think video brightness control will be a very popular and visible
> feature -- no pun intened;-)

ATM I much prefer _CST though, even if there is no visible effect other
than people may notice that their laptop will run longer on battery,
and if they don't have some usb driver loaded.

> In the back of my head I'm also wondering if we've got a missing piece
> of the suspend/resume puzzle here too -- and I'd hate for ACPI to be the
> "missing link" to get that key feature working.

IMHO, there is a need at first to glue devices in the ACPI namespace and the
devices enumearted by OS a la pnpbios...

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[John Belmonte]

Brown, Len wrote:
> Indeed, the next piece of the puzzle it to figure out how to properly
> do hot-keys correctly.  Surely Windows doesn't have a driver for each
> OEM's buttons...

I believe that presumption is not correct.  At least for Toshiba, all 
machines are shipped with a hotkey daemon that polls the keys through 
Toshiba's proprietary HCI (with the HCI accessed via special CPU 
registers or ACPI).

-John


-- 
http:// if  ile.org/


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Ducrot Bruno]

On Mon, Jan 26, 2004 at 03:00:14PM -0500, John Belmonte wrote:
> Brown, Len wrote:
> >Indeed, the next piece of the puzzle it to figure out how to properly
> >do hot-keys correctly.  Surely Windows doesn't have a driver for each
> >OEM's buttons...
> 
> I believe that presumption is not correct.  At least for Toshiba, all 
> machines are shipped with a hotkey daemon that polls the keys through 
> Toshiba's proprietary HCI (with the HCI accessed via special CPU 
> registers or ACPI).
> 

Anyway, from _strict_ ACPI point of view, hotkey may be achieved via
_GPE or via _QXX method from the Embedded Controller.  Therefore, in
a well deisgned system, hotkey is already supported.

If now OEM do not respect that kind of stuff even though they are
member of ACPI SIG is another story...

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Karol Kozimor]

Thus wrote Brown, Len:
> I think it would be good to get acpi video standardized to defuse the
> need for more platform-specific code...  Indeed, the next piece of the
> puzzle it to figure out how to properly do hot-keys correctly.  Surely
> Windows doesn't have a driver for each OEM's buttons...

Well, ASUS certainly has one, though supporting hotkeys is here as easy as
installing an appropriate notify handler.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

RE: RE: preparing toshiba_acpi driver release

[Brown, Len]

> Wait.  I take video, not hotkey :)

Yes, I just mentioned hotkeys because that is the other part of the
platform dependent drivers which need a more generic solution.

> > I think video brightness control will be a very popular and visible
> > feature -- no pun intended;-)
> 
> ATM I much prefer _CST though, even if there is no visible 
> effect other
> than people may notice that their laptop will run longer on battery,
> and if they don't have some usb driver loaded.

I was thinking about ergonomics rather than power-savings -- though
probably brightness control has some power savings benefits too -- maybe
somebody on the list has numbers for screen power consumption?

> > In the back of my head I'm also wondering if we've got a 
> missing piece
> > of the suspend/resume puzzle here too -- and I'd hate for 
> ACPI to be the
> > "missing link" to get that key feature working.
> 
> IMHO, there is a need at first to glue devices in the ACPI 
> namespace and the
> devices enumerated by OS a la pnpbios...

For suspend/resume, or for something else?
PNP is only for ISA devices, yes?  Is it really still used?
When we were working on interrupts somebody suggested that we ask the
ISA bus driver about what ISA interrupts where taken rather than using a
table inside the ACPI code containing "conventions".  The conventions
are simple, and so far seem to be functional -- though one could argue
such heuristics are sort of a hack.

-Len


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Karol Kozimor]

Thus wrote Brown, Len:
> I was thinking about ergonomics rather than power-savings -- though
> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?

Last time I checked it was about 6 W for my 15" display (100% brightness,
power consumption goes down linearly).

What I consider more important, is the ability to switch the LCD on / off
by demand -- unfortunately, DPMS is mostly unsupported on modern machines
and a generic approach (provided it works) could make a difference here.

Once I update the acpi4asus driver, I'll take a look on how those generic
methods to manipulate video work here and see where it gets me.

Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Tod Morrison]

I have a Dell Inspiron 8500, I'd be happy to play tester with when you're 
looking for a generalized solution. I did have one thought (quite beyond 
me to implement though), I was looking at the ACPI VID extensions and 
wondered if LCD._DSS could be used to our advantage. It appears that it's 
designed to allow the OS to handle video output switching, i.e. 

  turn off LCD -> turn on CRT

What I thought was that I don't see a reason we couldn't just turn off 
LCD output, i.e. call 

  LCD._DSS(0);

to turn off output, and 

  LCD._DSS(80000001L);

to turn it back on. Anyway, I'm really unqualified to say whether this 
make any sense, it was just a thought.

Tod Morrison <tmorriso-o2OswTf4RFv//ikEAC0814dd74u8MsAO@public.gmane.org>
   http://math.cudenver.edu/~tmorriso

  "Everyone thinks of changing the world,
  but no one thinks of changing himself."
  - Leo Tolstoy

On Tue, 27 Jan 2004, Karol Kozimor wrote:

> Thus wrote Brown, Len:
> > I was thinking about ergonomics rather than power-savings -- though
> > probably brightness control has some power savings benefits too -- maybe
> > somebody on the list has numbers for screen power consumption?
> 
> Last time I checked it was about 6 W for my 15" display (100% brightness,
> power consumption goes down linearly).
> 
> What I consider more important, is the ability to switch the LCD on / off
> by demand -- unfortunately, DPMS is mostly unsupported on modern machines
> and a generic approach (provided it works) could make a difference here.
> 
> Once I update the acpi4asus driver, I'll take a look on how those generic
> methods to manipulate video work here and see where it gets me.
> 
> Best regards,
> 
> -- 
> Karol 'sziwan' Kozimor
> sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Stefan Seyfried]

On Mon, Jan 26, 2004 at 02:29:02PM -0500, Brown, Len wrote:

> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?

my Asus L2400D with cpufrequency down to 500 MHz, machine is idle (but
connected to USB keyboard/mouse and network).

max. brightness (level 15):
charging state:          discharging
present rate:            677 mA

min. brightness (level 1, there is also 0 but then i can't read anything :-)
charging state:          discharging
present rate:            557 mA

medium brightness (level 7, this is actually useable)
charging state:          discharging
present rate:            597 mA

and just for the record: maximum brightness and cpufreq to 1200 MHz:
charging state:          discharging
present rate:            1437 mA

This is no scientific measurement since the machine is not really idle (i'm
writing this mail now :-) and the battery is a blatant liar (if the machine
would draw as little current as /proc/acpi/.../state tells me, it would have
to last twice as long, but it doesnt. So either it lies about capacity or
about current), but it is something to compare.
And yes, when i'm on the road, i always turn down the display as much as
possible to save battery.

I also made the test with an IBM T23 or something like that about a year ago
with Win2k which gave me even bigger savings from the display backlight
(IIRC about 1400 mA with full brightness and 900 mA with minimal).

-- 
Stefan Seyfried



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: RE: preparing toshiba_acpi driver release

[Ducrot Bruno]

On Mon, Jan 26, 2004 at 02:29:02PM -0500, Brown, Len wrote:
> > Wait.  I take video, not hotkey :)
> 
> Yes, I just mentioned hotkeys because that is the other part of the
> platform dependent drivers which need a more generic solution.
> 
> > > I think video brightness control will be a very popular and visible
> > > feature -- no pun intended;-)
> > 
> > ATM I much prefer _CST though, even if there is no visible 
> > effect other
> > than people may notice that their laptop will run longer on battery,
> > and if they don't have some usb driver loaded.
> 
> I was thinking about ergonomics rather than power-savings -- though
> probably brightness control has some power savings benefits too -- maybe
> somebody on the list has numbers for screen power consumption?

backlights are power hungry monster.

> 
> > > In the back of my head I'm also wondering if we've got a 
> > missing piece
> > > of the suspend/resume puzzle here too -- and I'd hate for 
> > ACPI to be the
> > > "missing link" to get that key feature working.
> > 
> > IMHO, there is a need at first to glue devices in the ACPI 
> > namespace and the
> > devices enumerated by OS a la pnpbios...
> 
> For suspend/resume, or for something else?

For enumerating devices, should be usefull for suspend/resume.
The ACPI subsystem then may be able to call specific AML method
for this device, but at first, driver need to know that such
method exist.

> PNP is only for ISA devices, yes?  Is it really still used?

PNP was first designed for PCI device, IIRC.  Anyway, common isa devices
include serial ports, parallel ports, keyboard controller to name
a few.  Now, Linux do have some kind method to glue such devices
with real drivers.  It's more to point to look that kind of code
in order to see if ACPI can do the same, but with all the devices in mind.

> When we were working on interrupts somebody suggested that we ask the
> ISA bus driver about what ISA interrupts where taken rather than using a
> table inside the ACPI code containing "conventions".  The conventions
> are simple, and so far seem to be functional -- though one could argue
> such heuristics are sort of a hack.

ISA devices do have 'well known' interrupts, io ports.  Anyway, isa devices
are enumerated by ACPI and configuration may be retrived for them if
really needed (they are children of the isa bridge function of the
southbridge, in a hopefully well written AML).

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn