From: rajanikanth.hv@stericsson•com (Rajanikanth HV)
To: linux-arm-kernel@lists•infradead.org
Subject: mfd: Implement devicetree support for AB8500 Btemp
Date: Tue, 11 Sep 2012 14:15:03 +0530 [thread overview]
Message-ID: <504EFA0F.2090102@stericsson.com> (raw)
In-Reply-To: <201209101401.06859.arnd@arndb.de>
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>
next prev parent reply other threads:[~2012-09-11 8:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-10 11:21 mfd: Implement devicetree support for AB8500 Btemp Rajanikanth HV
2012-09-10 14:01 ` Arnd Bergmann
2012-09-10 15:06 ` Linus Walleij
2012-09-11 8:45 ` Rajanikanth HV [this message]
2012-09-11 11:22 ` Arnd Bergmann
2012-09-12 14:33 ` Rajanikanth HV
2012-09-12 15:36 ` Arnd Bergmann
2012-09-13 13:31 ` Rajanikanth HV
2012-09-13 14:37 ` Arnd Bergmann
2012-09-14 2:04 ` Anton Vorontsov
2012-09-14 8:09 ` Arnd Bergmann
2012-09-14 9:34 ` Rajanikanth HV
2012-09-14 10:17 ` Rajanikanth HV
2012-09-15 11:01 ` mfd: " Francesco Lavra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=504EFA0F.2090102@stericsson.com \
--to=rajanikanth.hv@stericsson$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox