linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Rajanikanth HV <rajanikanth.hv@stericsson.com>,
	Anton Vorontsov <anton.vorontsov@linaro.org>
Cc: 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>
Subject: Re: Implement devicetree support for AB8500 Btemp
Date: Thu, 13 Sep 2012 14:37:38 +0000	[thread overview]
Message-ID: <201209131437.38666.arnd@arndb.de> (raw)
In-Reply-To: <5051E02B.5040703@stericsson.com>

On Thursday 13 September 2012, Rajanikanth HV wrote:
> On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> > 
> > If this is true, I don't understand what makes the 'supplied-to'
> > properties you list in the device tree binding board specific. Are
> > they not always done the same way? If so, you could just leave them
> > out.
> Precisely 'supplied-to' is not board specific, it was maintained as
> platform_data which i migrated to dt-node. It is meant to establish
> dependency across bm drivers based on power_supply property and
> runtime battery attributes.
> Basically, 'supplied-to' provides a way of exporting change in
> power_supply_property and runtime batter characteristics so that other
> bm devs shall make use or refer the updated values.
> Ref: external_power_changed(...) call back api.
> Note: all the bm drivers handles subset of power_supply property and
>       battery attributes,
>       ref: include/linux/power_supply.h and get_property(...) call back
>       api across bm drivers.

Ok, so you want to just remove the property from the device tree,
or do you want to establish a different method to specify these
connections?

> > What does indeed seem to be needed is a place to identify the battery
> > type, but it's not clear if the btemp device is the best place for
> > that (maybe it is). 
> I am not clear whether you are trying to correlate battery-type with
> supplied-to. however, battery type is identified based on the
> resistance value measured at batctrl pin which is expected to be in the
> allowable limit of ab8500 device. This resistance limit varies across
> battery types. This happens in btemp driver.

I wasn't correlating them. I just mentioned that unlike the supplied-to
property, the battery type property does seem to belong into the device
tree.

> For this, I would suggest you give a list of
> > possible batteries and require a property such as
> > 
> >  st-ericsson,battery-type: A string identifier for the type of battery,
> > 			   which impacts how an operating system interpret
> > 			   the sensor readings. Possible values include:
> > 	* "none"	-- no battery connected
> > 	* "li-ion-9100" -- Type 9100 Li-ION battery
> > 	* <add any others that apply here>
> Can do this, not precisely as "st-ericsson,battery-type", it will be as
> battery-type = [unknown|NiMH|LION|...|]], reason being
> allowable battery type is based on technology, as you can see the
> possible types as:
> POWER_SUPPLY_TECHNOLOGY_UNKNOWN = 0,
>         POWER_SUPPLY_TECHNOLOGY_NiMH,
>         POWER_SUPPLY_TECHNOLOGY_LION,
>         POWER_SUPPLY_TECHNOLOGY_LIPO,
>         POWER_SUPPLY_TECHNOLOGY_LiFe,
>         POWER_SUPPLY_TECHNOLOGY_NiCd,
>         POWER_SUPPLY_TECHNOLOGY_LiMn
> Ref: include/linux/power_supply.h
> Note: doing this will impact my of_probe(...), may slightly bloat the
> code.

Ok.

If you want to make the battery type a generic property, it's probably
best to start a separate binding document for this in
Documentation/devicetree/bindings/power-supply/common.txt
and document a string for each of these.

If we expect the property to be needed only for ab8500, please use
a vendor prefix like 'stericsson,'.

	Arnd

  reply	other threads:[~2012-09-13 14:37 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 [this message]
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=201209131437.38666.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=STEricsson_nomadik_linux@list.st.com \
    --cc=anton.vorontsov@linaro.org \
    --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=patches@linaro.org \
    --cc=rajanikanth.hv@linaro.org \
    --cc=rajanikanth.hv@stericsson.com \
    /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;
as well as URLs for NNTP newsgroup(s).