Re: Re: Smart Battery System driver

Pedro Venda
2005-01-21T20:16:28Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:
| Pedro Venda wrote:
|
|> Rich Townsend wrote:
|> | Pedro Venda wrote:
|> |
|> |> Johan Vromans wrote:
|> |> | Rich Townsend <rhdt-OBnUx95tOyn10jlvfTC4gA@public.gmane.org> writes:
|> |> |
|> |> |
|> |> |>I do this because everything in /lib/modules/XXX/kernel/* gets
|> |> |>clobbered when you do a make modules_install from the kernel source
|> |> |>tree;
|> |> |
|> |> |
|> |> | I see.
|> |> |
|> |> |
|> |> |>I have recently realized that the whole SBS functionality can be
|> |> |>implemented in terms of control methods in the DSDT, without the
|> |> |>need for any kernel drivers.
|> |> |
|> |> |
|> |> | Nice. This would require a kernel recompile/reboot for each DSDT
|> |> | modification...
|> |>
|> |> not nice, I guess. 99.9% of the interested (me included) wouldn't be
|> |> able to
|> |> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|> |> language)
|> |> code for their specific case.
|> |
|> |
|> | What if you just had to run a perl script, and then add an "initrd="
|> | line to your kernel boot parameters? Because the code would be *so*
|> much
|> | cleaner if a lot of the tasks were moved to the DSDT; in particular, we
|> | could get rid of i2c_acpi_sbs, and thus remove the dependency of
|> ACPI on
|> | I2C.
|>
|> I'd agree that the i2c-acpi dependency is not pretty.
|>
|> on the other hand... I'm still not liking the CM (dump, limited)
|> interface to
|> control SBS (smart, sophisticated) batteries. yes, CM gets the
|> information from
|> the SBS hardware but I can't stop feeling loosing capabilities.
|
|
| Ah, but there doesn't have to be any loss of capabilities. There are two
| separate issues here:
|
| 1) Implementing the SMBus access through control methods, as described
| by the API in the SMBus-CM specification (which I'll be trying out very
| soon)
|
| 2) Implementing a control-method wrapper for SBS, so that it can be
| accessed using the API described in Sec. 10.2 of the ACPI specification.
|
| Issue (1) basically removes the need for the i2c_acpi_ec module, and
| indeed the need to have any i2c or smbus support in the kernel;
| everything is done through the embedded controller. This is highly
| desirable.
|
| Issue (2) would allow SBS batteries to appear to the kernel as CM
| batteries, meaning that the stock battery.ko module can be used. This,
| however, is obviously a backward-compatibility step, and not the way
| forward; however, it may be a 'clean' interim solution to implementing
| SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM
| batteries through a standard interface.

ahhh, there's a nice explanation. thanks :-)

so, just to clear things up, solution (1) doesn't need DSDT patching?? that'd be
excelent "value-for-money". it'd provide access to SBS information without ugly
acpi-i2c dependencies.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: pjvenda-pQd4kjVL+REh2FBCd0jGRA@public.gmane.org
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8WMceRy7HWZxjWERAhKuAJ9uxEDnia3IOkTJBXWI30jYgCaNHwCeNvJ5
HWHutp6t9GOKO3IHvnHEtqs=
=g4zf
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl