On Mon, 2016-06-27 at 03:45 +0200, Rafael J. Wysocki wrote:
> On Mon, Jun 27, 2016 at 3:31 AM, Srinivas Pandruvada
> <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> >
> > On Fri, 2016-06-24 at 02:26 +0200, Rafael J. Wysocki wrote:
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > On Fri, Jun 24, 2016 at 1:19 AM, Srinivas Pandruvada
> > > <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> > > >
> > > > On Fri, 2016-06-24 at 00:31 +0200, Rafael J. Wysocki wrote:
> > > > >
> > > > > On Thu, Jun 23, 2016 at 11:42 PM, Srinivas Pandruvada
> > > > > <srinivas.pandruvada@xxxxxxxxxxxxxxx> wrote:
> > [...]
> >
> > >
> > > I think what you need is that if acpi_battery is bound to at
> > > least
> > > one
> > > device, you don't want to bind dptf_power to
> > > anything. Conversely,
> > > if
> > > dptf_power has been bound to at least one device, you don't want
> > > to
> > > bind acpi_battery to anything.
> > >
> > > That may be achieved with a lock and two counters, one (A)
> > > incremented
> > > only by acpi_battery and the other (B) incremented only by
> > > dptf_power
> > > and such that you can't increment A if B is different from 0 and
> > > you
> > > can't increment B if A is different from 0. Of course, each
> > > driver
> > > would need to specify which counter it wants to use (A or B), so
> > > that
> > > would take an additional argument to acpi_battery_common_add()
> > > and an
> > > additional field in struct acpi_battery (for the remove
> > > operation).
> > >
> > > With that, I think it should only be possible to build both
> > > acpi_battery and dptf_power if they are both modules. IOW,
> > > DPTF_POWER
> > > should depend on (!ACPI_BATTERY || ACPI_BATTERY=m) or
> > > similar. And
> > > if
> > > they are both modules, let user space manage that.
> > >
> > > And the waiting itself doesn't add any value then IMO.
> > Yes. I think the best solution is not to let define DPTF_POWER when
> > the
> > ACPI_BATTERY is defined same as my first version of the patch or
> > let
> > both add as there is no harm as they will show same levels. The
> > reason
> > is:
> > We have some devices with two ACPI_BATTERIES (primary and
> > secondary/backup) and they must be presented as two power supply
> > devices to user space. In those devices DPTF_POWER may be
> > equivalent to
> > only one of the ACPI_BATTERY (Will point to same battery for
> > Battery
> > levels). So we can't simply refuse to add ACPI_BATTERY device
> > addition
> > because DPTF_POWER device is registered before.
> OK
>
> Say dptf_power points to the same battery device as acpi_battery. Is
> there any way to tell when that happens?
May be we can memcmp the output of _BIX (Battery Information Extended).
If they are same it belongs to same battery.
If there are two ACPI batteries, hope atleast they have difference in
one element in the following package.
Package {
// ASCIIZ is ASCII character string terminated with a 0x00.
Revision
//Integer
Power Unit
//Integer (DWORD)
Design Capacity
//Integer (DWORD)
Last Full Charge Capacity
//Integer (DWORD)
Battery Technology
//Integer (DWORD)
Design Voltage
//Integer (DWORD)
Design Capacity of Warning
//Integer (DWORD)
Design Capacity of Low
//Integer (DWORD)
Cycle Count
//Integer (DWORD)
Measurement Accuracy
Max Sampling Time
Min Sampling Time
Max Averaging Interval
Min Averaging Interval //Integer
//Integer
//Integer
//Integer
//Integer
(DWORD)
(DWORD)
(DWORD)
(DWORD)
(DWORD)
Battery Capacity Granularity 1
Battery Capacity Granularity 2
Model Number
Serial Number
Battery Type
OEM Information
}
Thanks,
Srinivas
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
