mfd: Implement devicetree support for AB8500 Btemp

[Rajanikanth HV]

On Monday 10 September 2012 07:31 PM, Arnd Bergmann wrote:
> On Monday 10 September 2012, Rajanikanth HV wrote:
>> +
>> +supplied-to:
>> +       This is a logical binding w.r.t power supply event change
>> +       across energy-management-module drivers where in the
>> +       runtime battery properties are shared along with uevent
>> +       notification.
>> +       ref: di->btemp_psy.external_power_changed =
>> +               ab8500_btemp_external_power_changed;
>> +               ab8500_btemp.c
>> +
>> +       Need for this property:
>> +               btemp, fg and charger updates power-supply properties
>> +               based on the events listed above.
>> +               Event handler invokes power supply change notifier
>> +               which in-turn invokes registered power supply class call-back
>> +               based on the 'supplied_to' string.
>> +               ref:
>> +               power_supply_changed_work(..) ./drivers/power/power_supply_core.c
>> +
>> +       example:
>> +       ab8500-btemp {
>> +               /* Other enery management module */
>> +               supplied-to = "ab8500_chargalg", "ab8500_fg";
>> +               num_supplicants = <2>;
>> +       };
>> +
> This looks like you're doing things the opposite way from everyone else.
> Normally, each device uses phandles to refer to other objects it depends
> on (gpio lines, regulators, clocks, interrupts, ...), rather than listing
> things that depend on it.
>
> Can you turn this around to be more like the others?
We discussed about this on : "13 July 2012 17:05", pasting from that
mail thread.
============================
>> +Supplied-to:
>> +     This shall be power supply class dependency where in the
runtime battery
>> +     properties will be shared across fuel guage and charging
algorithm driver.
>
> I probably don't understand enough of this, but shouldn't the other
devices
> that are supplied by this have a reference to this node rather than doing
> it this way around? Why use strings here instead of phandles?

This is a logical binding w.r.t power supply event change
across energy-management-module drivers where in runtime battery
properties are shared along with uevent notification.
ref: di->btemp_psy.external_power_
changed =
     ab8500_btemp_external_power_changed;
     ref: ab8500_btemp.c

Need for this property:
 btemp, fg and charger updates power-supply properties
 based on the events listed above.
 Event handler invokes power supply change notifier
 which in-turn invokes registered power supply class call-back
 based on the 'supplied_to' string.
 ref:
   power_supply_changed_work(..) ./drivers/power/power_supply_core.c

In this case how to approach through phandle?
============================

>
> Note also that device tree identifiers should use '-' as a word separator,
> not '_', and that a binding document should specify the exact set of
> possible values. If the properties contain strings, please list every
> valid string.
>
>> +               thermister-internal-to-battery = <1>;
>> +               li_ion_9100_battery = <0>;
> Boolean properties should be empty when enabled and not present when
> disabled. In this example, one would just write
>
> 		thermister-internal-to-battery;
>
>
> 	Arnd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120911/f89ae002/attachment-0001.html>