Re: [PATCH 4/9] dt-bindings: power: supply: Add device-tree binding for Summit SMB3xx
From: Dmitry Osipenko
Date: Wed Apr 15 2020 - 11:30:30 EST
15.04.2020 17:27, Rob Herring ÐÐÑÐÑ:
> On Fri, Apr 10, 2020 at 2:02 PM Dmitry Osipenko <digetx@xxxxxxxxx> wrote:
>>
>> 10.04.2020 19:49, Rob Herring ÐÐÑÐÑ:
>> ...
>>>> + summit,max-chg-curr:
>>>> + description: Maximum current for charging (in uA)
>>>> + allOf:
>>>> + - $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> + summit,max-chg-volt:
>>>> + description: Maximum voltage for charging (in uV)
>>>> + allOf:
>>>> + - $ref: /schemas/types.yaml#/definitions/uint32
>>>> + minimum: 3500000
>>>> + maximum: 4500000
>>>> +
>>>> + summit,pre-chg-curr:
>>>> + description: Pre-charging current for charging (in uA)
>>>> + allOf:
>>>> + - $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
>>>> + summit,term-curr:
>>>> + description: Charging cycle termination current (in uA)
>>>> + allOf:
>>>> + - $ref: /schemas/types.yaml#/definitions/uint32
>> ...
>>> These are all properties of the battery attached and we have standard
>>> properties for some/all of these.
>>
>> Looks like only four properties seem to be matching the properties of
>> the battery.txt binding.
>>
>> Are you suggesting that these matching properties should be renamed
>> after the properties in battery.txt?
>
> Yes, and that there should be a battery node.
Usually, it's a battery that has a phandle to the power-supply. Isn't it?
> Possibly you should add
> new properties battery.txt. It's curious that different properties are
> needed.
I guess it should be possible to make all these properties generic.
Sebastian, will you be okay if we will add all the required properties
to the power_supply_core?
> Ultimately, for a given battery technology I would expect
> there's a fixed set of properties needed to describe how to charge
> them.
Please notice that the charger doesn't "only charge" the battery,
usually it also supplies power to the whole device.
For example, when battery is fully-charged and charger is connected to
the power source (USB or mains), then battery may not draw any current
at all.
> Perhaps some of these properties can just be derived from other
> properties and folks are just picking what a specific charger wants.
Could be so, but I don't know for sure.
Even if some properties could be derived from the others, it won't hurt
if we will specify everything explicitly in the device-tree.
> Unfortunately, we have just a mess of stuff made up for each charger
> out there. I don't have the time nor the experience in this area to do
> much more than say do better.
I don't think it's a mess in the kernel. For example, it's common that
embedded controllers are exposed to the system as "just a battery",
while in fact it's a combined charger + battery controller and the
charger parameters just couldn't be changed by SW.
In a case of the Nexus 7 devices, the battery controller and charger
controller are two separate entities in the system. The battery
controller (bq27541) only monitors status of the battery (charge level,
temperature and etc).