Hi Andrew, thanks for the drill-down on BQ27* chips.
On Mon, Feb 13, 2017 at 8:06 AM, Andrew F. Davis <afd@xxxxxx> wrote:
> On 02/10/2017 08:43 PM, Liam Breck wrote:
>> From: Matt Ranostay <matt@ranostay.consulting>
>>
>> Documentation of static battery characteristics that can be defined
>> for batteries which cannot self-identify. This information is required
>> by fuel-gauge and charger chips for proper handling of the battery.
>
>
> I think some of the confusion about what a "smart-battery" binding would
> look like is due to a miss-understanding what it means to
> "self-identify". Originally the bq27xxx *was* the chip that lived its
> whole life inside a battery (the iphone battery is one such example and
> a good way to test the bq27000). This way it could be factory programmed
> with the battery's basics and then learn about the individual pack over
> time to provide better info on time to empty, discharge rates, etc..
>
> Eventually, people wanted to have the battery become cheap and
> replaceable, so fuel-gauges were made that are "system side", and ride
> along with the device, not the battery. Now this has one big problem,
> how can we learn about a battery when it may be a new battery every time
> we boot up? So we added programmable memory to the devices, and
> programming this memory looks to be what this series is about.
>
> Only the battery design info is programmed in this series, but much more
> battery info can be uploaded, including stuff that is not fixed and
> therefor cannot be added to the DT. Even the design parameters may not
> be fix if one changes the battery as different manufactures of the same
> battery type may have different design capacities.
>
> The ideal use-case in a system with a system side gauge is the OS should
> periodically, or just before shutdown, read the battery's learned info
> and when the device is powered back up, if the battery serial number
> matches from before, re-upload this learned info to the gauge so it
> doesn't have to re-learn everything. All of this will need to happen in
> user-space, so what we really need is a user-space API for manipulating
> these properties.
We would need a feature in the driver to get/set the blob of pack- or
cell-unique data. The userspace api is one sysfs file.
However the DT fixed-battery node could indicate when/how-often the
object is stored, and where, e.g. filename. If the latter is given,
the driver should write/read the file itself.
Is there some documentation about what registers should go in this blob?
That concept is beyond the scope of this patchset (and doesn't
supersede it), but is something I'd like to implement for our chip,
the *425.
> The properties added in this series are okay, and it's good to have some
> sane defaults in DT, but looking forward this may not be enough to get
> full use out of these devices.
I'm relieved you're not opposed to our patch :-) Now I just need that
guidance I mentioned re the chip family...
>> Cc: Rob Herring <robh@xxxxxxxxxx>
>> Cc: devicetree@xxxxxxxxxxxxxxx
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> Signed-off-by: Liam Breck <kernel@xxxxxxxxxxxxxxxxx>
>> ---
>> .../devicetree/bindings/power/supply/battery.txt | 37 ++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/battery.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>> new file mode 100644
>> index 0000000..d78a4aa
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>> @@ -0,0 +1,37 @@
>> +Battery Characteristics
>> +
>> +Required Properties:
>> + - compatible: Must be "fixed-battery"
>> +
>> +Optional Properties:
>> + - voltage-min-design-microvolt: drained battery voltage
>> + - energy-full-design-microwatt-hours: battery design energy
>> + - charge-full-design-microamp-hours: battery design capacity
>> +
>> +Future Properties must be named for the corresponding elements in
>> +enum power_supply_property, defined in include/linux/power_supply.h.
>> +
>> +Batteries must be referenced by chargers and/or fuel-gauges
>> +using a phandle. The phandle's property should be named
>> +"monitored-battery".
>> +
>> +Example:
>> +
>> + bat: battery {
>> + compatible = "fixed-battery";
>> + voltage-min-design-microvolt = <3200000>;
>> + energy-full-design-microwatt-hours = <5290000>;
>> + charge-full-design-microamp-hours = <1430000>;
>> + };
>> +
>> + charger: charger@11 {
>> + ....
>> + monitored-battery = <&bat>;
>> + ...
>> + };
>> +
>> + fuel_gauge: fuel-gauge@22 {
>> + ....
>> + monitored-battery = <&bat>;
>> + ...
>> + };
>>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
