From: Mark Rutland <mark.rutland@arm.com>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
"rob@landley.net" <rob@landley.net>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"rtc-linux@googlegroups.com" <rtc-linux@googlegroups.com>,
"gg@slimlogic.co.uk" <gg@slimlogic.co.uk>,
"kishon@ti.com" <kishon@ti.com>,
Stephen Warren <swarren@nvidia.com>,
Pawel Moll <Pawel.Moll@arm.com>,
"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
"broonie@kernel.org" <broonie@kernel.org>
Subject: Re: [PATCH V4] drivers/rtc/rtc-palmas.c: support for backup battery charging
Date: Thu, 8 Aug 2013 10:33:40 +0100 [thread overview]
Message-ID: <20130808093340.GG14648@e106331-lin.cambridge.arm.com> (raw)
In-Reply-To: <520295F3.2020401@nvidia.com>
On Wed, Aug 07, 2013 at 07:46:11PM +0100, Laxman Dewangan wrote:
> On Wednesday 07 August 2013 10:08 PM, Mark Rutland wrote:
> > On Wed, Aug 07, 2013 at 11:29:52AM +0100, Laxman Dewangan wrote:
> >> +Optional properties:
> >> +- ti,back-battery-charge-enable: The Palmas series device like TPS65913 or
> >> + TPS80036 supports the battery backup for powering the RTC when main
> >> + battery is removed or in very low power state. This flag will enable
> >> + the backup battery charging.
> > I don't like the wording here as it implies that an OS *must* charge the
> > device, rather than that it *can* charge the device. How about:
> >
> > - ti,backup-battery-chargeable: There is a chargeable backup battery
> > present.
> >
>
> The *org* property tells whether charging should be enable or not. This
> is enabled during init and it is not the runtime configuration for
> enable/disable.
> By saying "backup-battery-chargeable" means it need other
> interface/calls to start charging. It does not reflect that charging
> will be enabled by default.
It doesn't mean that the OS needs to provide some interface to control
charging. It simply means that it's up to the OS as to whether it
charges it (for which Linux's choice can be to always charge the
battery). An OS may choose not implement any charging code at all...
>
>
>
> >> +- ti,back-battery-charge-low-current: Configure lower charging current. Device
> >> + supports the charging current as < 100mA or >100mA. Low current will
> >> + set as <100mA.
> > This is somewhat unclear as it reads as a runtime configuration choice,
> > rather than some instances of the device only support being changed at
> > low currents (as I assume is the case?). How about:
> >
> > - ti,backup-battery-low-current: The backup battery is only chargeable
> > at currents below 100mA.
>
> Hmm.. I think even if battery can be charge for more than 100mA, there
> is choice of configure it for less than 100mA.
Ok.
>
> > What happens if we charge at the wrong current?
> Not much sure but I think it can create battery damage.
If we charge a battery supporting >100mA at a current <100mA, will that
cause damage? Or only if we charge above it's supported current?
If the latter's true, it might make sense to invert the condition and
describe that the battery may be charged at a higher current, with the
default being <100mA. That way a missing property in the dt will only
result in sub-optimal charging rather than battery damage.
Thanks,
Mark.
next prev parent reply other threads:[~2013-08-08 9:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-07 10:29 Laxman Dewangan
2013-08-07 16:38 ` Mark Rutland
2013-08-07 18:46 ` Laxman Dewangan
2013-08-08 9:33 ` Mark Rutland [this message]
2013-08-08 17:17 ` Laxman Dewangan
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=20130808093340.GG14648@e106331-lin.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=Pawel.Moll@arm.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gg@slimlogic.co.uk \
--cc=grant.likely@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=kishon@ti.com \
--cc=ldewangan@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=rtc-linux@googlegroups.com \
--cc=swarren@nvidia.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
all inboxes | Powered by JetHome®