Re: Re: Smart Battery System driver

Rich Townsend
2005-01-21T15:01:20Z

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.

cheers,

Rich

-------------------------------------------------------
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