smartbattery support
hi everyone,
i decided to change the subject so that the thread could more easily be followed by others.
i read some things also, but i disagree with christian. i think that smbus patch is not the way to go. don't get me wrong! i'm also just scratching the surface. for what i read, those patches put smbus bios support into the kernel.
i feel that the i2c approach would be much more productive. now i have some doubts...
1. is this a "sensor" i2c driver? i mean, should we find help with the lmsensors team? there are some debugging tools for i2c developed by the lm-sensors people (i guess). this document (http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/chips/SUMMARY) refers some smartbattery support, but i don't think it solves our problem.
2. what exactly should the i2c driver do? should it just know the smartbattery address and ask generic questions made by userland programs? or should it do all the work and retrive charge rates and capacity information and such?
enough questions for now.
again, don't take me wrong. it is possible that i am thinking in a totally wrong direction.
regards,
pedro venda.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Pedro Venda
i read some things also, but i disagree with christian. i think that smbus patch is not the way to go. don't get me wrong! i'm also just scratching the surface. for what i read, those patches put smbus bios support into the kernel.
yep
Quoted 1 line
1. is this a "sensor" i2c driver? i mean, should we find help with the lmsensors team? there are some debugging tools for i2c developed by the lm-sensors people (i guess). this document (http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/chips/SUMMARY) refers some smartbattery support, but i don't think it solves our problem.
I cant get the detect-thingies to see any i2c-bus and Im not aware of any sensorchip in my laptop (but I would be happy to be proven wrong).
Quoted 1 line
2. what exactly should the i2c driver do? should it just know the smartbattery address and ask generic questions made by userland programs? or should it do all the work and retrive charge rates and capacity information and such?
I think it should publish as much generic info (info thats avaible on all smartbatteries) as possible into sysfs.
Signature · 9 lines
Regards, Christian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl
A message that is not in the archive (sent off-list or not yet received): 41631809.7020204-pw/8oln/[email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christian Axelsson wrote:
| Pedro Venda wrote: | |> i read some things also, but i disagree with christian. i think that |> smbus patch is not the way to go. don't get me wrong! i'm also just |> scratching the surface. for what i read, those patches put smbus bios |> support into the kernel. | | | yep
sorry... do you agree or not? i meant that we should be creating an i2c module to talk specifically to the smart battery independently of the bios...
| |> 1. is this a "sensor" i2c driver? i mean, should we find help with the |> lmsensors team? there are some debugging tools for i2c developed by |> the lm-sensors people (i guess). this document |> (http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/chips/SUMMARY) |> refers some smartbattery support, but i don't think it solves our |> problem. | | | I cant get the detect-thingies to see any i2c-bus and Im not aware of | any sensorchip in my laptop (but I would be happy to be proven wrong). |
again i should have explained myself better... my laptop can see 5 busses... although i cannot yet interpret that information well. anyway, what i wanted to ask was: should we be using some of the sensors code?
|> 2. what exactly should the i2c driver do? should it just know the |> smartbattery address and ask generic questions made by userland |> programs? or should it do all the work and retrive charge rates and |> capacity information and such? | | | I think it should publish as much generic info (info thats avaible on | all smartbatteries) as possible into sysfs.
agree. then useland programs could use that information. but i see a pitfall here... if it is so, how will it be hooked into ACPI?
[]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBY9xyeRy7HWZxjWERAtW9AKCI/UBkin8Q+U/xiYAuX/Vkv0adogCeLsH6 t1/108wqCrKYGP6bRWrWwXc=
=54Fs
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Hi!
Quoted 7 lines
i decided to change the subject so that the thread could more easily be followed by others.
i read some things also, but i disagree with christian. i think that smbus patch is not the way to go. don't get me wrong! i'm also just scratching the surface. for what i read, those patches put smbus bios support into the kernel.
Agreed, we do not want to touch BIOS.
Quoted 4 lines
2. what exactly should the i2c driver do? should it just know the smartbattery address and ask generic questions made by userland programs? or should it do all the work and retrive charge rates and capacity information and such?
I believe doing all the work is right.
Signature · 9 lines
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl
A message that is not in the archive (sent off-list or not yet received): 20041007094109.GA534-u08AdweFZfgxtPtxi4kahqVXKuFTiq87@public.gmane.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
i have joined the lmsensors mailing list and the sbs-forum to get some more help but i'm still waiting for feedback there, so... mean while i'll just study i2c protocols.
i'm thinking in writing a sensor driver to read the battery information and then a userland program could format it and do whatever it likes.
as far as acpi goes, i still need some information on how will the i2c driver be plugged into the ACPI framework.
regards,
pedro venda.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBZTeseRy7HWZxjWERAhruAKD2+1WfdGmnVTK0D193UI/0McnRqwCcCWwL xJ8po5VdwLyS2/pMP25drh8=
=dQP1
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl