From: Frans Klaver <fransklaver@gmail.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: olof@lixom.net, anton.vorontsov@linaro.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Randy Dunlap <rdunlap@infradead.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [RFC PATCH 1/2] sbs-battery: add forced instantiation from device tree
Date: Wed, 24 Sep 2014 20:59:34 +0200 [thread overview]
Message-ID: <20140924185933.GA2221@gmail.com> (raw)
In-Reply-To: <20140924153431.GJ5729@leverpostej>
On Wed, Sep 24, 2014 at 04:34:32PM +0100, Mark Rutland wrote:
> On Wed, Sep 24, 2014 at 04:14:48PM +0100, Frans Klaver wrote:
> > On Wed, Sep 24, 2014 at 03:38:49PM +0100, Mark Rutland wrote:
> > > On Wed, Sep 24, 2014 at 03:22:22PM +0100, Frans Klaver wrote:
> > > You mention that there's a GPIO that can be used to detect the battery
> > > presence. Why can't the driver always probe and then on check for the
> > > presence of the battery dynamically using that GPIO? That should cover
> > > both cases.
> >
> > I would say that this was the case before [1] was done. The GPIO is
> > optional and if not configured, the presence or absence of the battery
> > is detected by checking a status register much like probe() currently
> > does. It seems all cases were covered before that patch. If you worry
> > about speed, you should use the GPIO. I wonder if we might be able to
> > revert [1] without doing much harm.
>
> But reverting that would re-introduce the lag on some systems, no? Given
> the wording of the original commit I would guess that the GPIO wasn't
> available. Perhaps Olof or Anton can enlighten us?
It probably would yes. The battery_detect gpio was last touched in 2011, the
probe check was added somewhere in 2012.
We could keep it as a compile option.
> In the cases where a GPIO is available, I think we should be able to be
> less pessimistic. Is a GPIO available in your case?
We don't have the battery_detect pin available. Incidentally, a bit of
lag reading out the battery is not a problem for us.
> Mark.
>
> >
> > Thanks,
> > Frans
> >
> > [1] a22b41a31e53 "sbs-battery: Probe should try talking to the device"
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2014-09-24 18:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 13:11 [RFC PATCH 0/2] explicitly instantiate battery from device tree Frans Klaver
2014-09-24 13:11 ` Frans Klaver
2014-09-24 13:11 ` [RFC PATCH 1/2] sbs-battery: add forced instantiation " Frans Klaver
2014-09-24 13:11 ` Frans Klaver
2014-09-24 13:16 ` Mark Rutland
2014-09-24 14:22 ` Frans Klaver
2014-09-24 14:22 ` Frans Klaver
2014-09-24 14:38 ` Mark Rutland
2014-09-24 15:14 ` Frans Klaver
2014-09-24 15:34 ` Mark Rutland
2014-09-24 18:59 ` Frans Klaver [this message]
2014-09-25 9:27 ` Mark Rutland
2014-09-25 9:32 ` Frans Klaver
[not found] ` <CAH6sp9O=Hb3uGk3=5Gc+bb+AAZVZu=xHqNnUBHPG8BJUn==ZzQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-10-07 12:37 ` Frans Klaver
2014-10-07 12:37 ` Frans Klaver
2014-09-24 13:11 ` [PATCH 2/2] sbs-battery: dts: document always-present property Frans Klaver
2014-09-24 13:11 ` Frans Klaver
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=20140924185933.GA2221@gmail.com \
--to=fransklaver@gmail.com \
--cc=Pawel.Moll@arm.com \
--cc=anton.vorontsov@linaro.org \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=olof@lixom.net \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.