From: Rajanikanth HV <rajanikanth.hv@stericsson.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Anton Vorontsov <anton.vorontsov@linaro.org>,
Rajanikanth HV <rajanikanth.hv@linaro.org>,
Lee Jones <lee.jones@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
STEricsson_nomadik_linux <STEricsson_nomadik_linux@list.st.com>,
"linaro-dev@lists.linaro.org" <linaro-dev@lists.linaro.org>,
Patch Tracking <patches@linaro.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>
Subject: Re: Implement devicetree support for AB8500 Btemp
Date: Fri, 14 Sep 2012 15:04:38 +0530 [thread overview]
Message-ID: <5052FA2E.20406@stericsson.com> (raw)
In-Reply-To: <201209140809.31045.arnd@arndb.de>
On Friday 14 September 2012 01:39 PM, Arnd Bergmann wrote:
> On Friday 14 September 2012, Anton Vorontsov wrote:
>> Power supply subsystem's supplied_to describes not just how driver
>> should notify other devices, supplied_to is more generic stuff, in terms
>> that it describes power supply hierarchy. It's like a directed graph,
>> e.g.:
>>
>> <AC power> supplied_to <main battery> and <backup battery>
>> <USB power> supplied_to <main battery> and <backup battery>
>> <main battery> supplied_to <system>
>> <backup battery> supplied_to <system>
>> <cmos battery> supplied_to <southbridge pci device>
>> <mice battery> supplied_to <mice wireless hid>
>>
>> How things interact in linux are just implementations details.
>> So, device tree is surely a perfect place to describe these things.
>>
>> Although, in current bindings I see this:
>>
>> + ab8500-fg {
>> + /* Other enery management module */
>> + supplied_to = "ab8500_chargalg", "ab8500_usb";
>> + num_supplicants = <2>;
>> + };
>>
>> Instead of addressing supplicants by name, it's better to address
>> via phandles. And, of course, num_supplicants is not needed, it can
>> be derived.
>
> Right. that's what I thought. The other comment I made initially is
> that it would be more in the spirit of the existing bindings to have
> the supply property in the opposite directory, if we need it, like
> (picking up your above example):
>
>
> / {
> /* power supply property in the root node is used by default */
> power-supply = <&main-battery>, <&backup-battery>;
>
> ac-power: power@... {
> ...
> };
>
> usb-power: power@... {
> ...
> };
>
> main-battery: battery@... {
> power-supply = <&ac-power>, <&usb-power};
> ;
>
> ...
> };
>
> It's the same information and absolutely equivalent as far as I can tell,
> but it feel more logical in the way we tend to describe things.
>
> Arnd
>
phandle'd supplied-to will looks like:
usb: ab8500-usb {
};
battery : ab8500-bat-type {
battery-name = "unknown|NiMH|LION|LIPO|LiFe|NiCd|LiMn";
thermistor_on_batctrl = <1>;
};
chargalg: ab8500-chargalg {
compatible = "stericsson,ab8500-chargalg";
interface-name = "ab8500_chargalg";
battery-info = <&ab8500-bat-type>
supplied-to = <&ab8500_fg>;
...
};
fuelguage: ab8500-fg {
compatible = "stericsson,ab8500-fg";
interface-name = "ab8500_fg";
battery-info = <&ab8500-bat-type>
supplied-to = <&ab8500_chargalg &ab8500_usb>;
...
};
btemp: ab8500-btemp {
compatible = "stericsson,ab8500-fg";
interface-name = "ab8500_btemp";
battery-info = <&ab8500-bat-type>
supplied-to = <&ab8500_chargalg &ab8500_fg>;
...
};
charger: ab8500-charger {
compatible = "stericsson,ab8500-charger";
interface-name = "ab8500_charger";
battery-info = <&ab8500-bat-type>
supplied-to = <&ab8500_chargalg &ab8500_fg &ab8500_btemp>;
...
};
next prev parent reply other threads:[~2012-09-14 9:35 UTC|newest]
Thread overview: 13+ 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
[not found] ` <504EFA0F.2090102@stericsson.com>
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 [this message]
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=5052FA2E.20406@stericsson.com \
--to=rajanikanth.hv@stericsson.com \
--cc=STEricsson_nomadik_linux@list.st.com \
--cc=anton.vorontsov@linaro.org \
--cc=arnd@arndb.de \
--cc=lee.jones@linaro.org \
--cc=linaro-dev@lists.linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=patches@linaro.org \
--cc=rajanikanth.hv@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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