From: "Heiko Stübner" <heiko@sntech.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Laxman Dewangan <ldewangan@nvidia.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] pinctrl: palmas: do not abort pin configuration for BIAS_DEFAULT
Date: Wed, 2 Oct 2013 13:20:51 +0200 [thread overview]
Message-ID: <201310021320.51544.heiko@sntech.de> (raw)
In-Reply-To: <CACRpkdbuetPbxPzJTpKuM4O-mqpqjh7rgGoanfAwad4M2vbZTQ@mail.gmail.com>
Am Mittwoch, 2. Oktober 2013, 12:40:14 schrieb Linus Walleij:
> On Fri, Sep 27, 2013 at 6:06 PM, Stephen Warren <swarren@wwwdotorg.org>
wrote:
> > [Laxman]
> >
> >> Hmm.. When I added the PIN_DEFAULT, I just though that do not update
> >> anything in the register and implemented like that.
> >> There is nothing "default" option in HW.
> >
> > The description of that pinconfig option is:
> >> 7970cb77 (Heiko Stübner 2013-06-06 16:44:25 +0200 43) *
> >> @PIN_CONFIG_BIAS_PULL_PIN_DEFAULT: the pin will be pulled up or down
> >> based 70637a6d (Heiko Stübner 2013-06-25 14:55:42 +0200 44) *
> >> on embedded knowledge of the controller hardware, like current mux
> >> 70637a6d (Heiko Stübner 2013-06-25 14:55:42 +0200 45) *
> >> function. The pull direction and possibly strength too will normally
> >> 70637a6d (Heiko Stübner 2013-06-25 14:55:42 +0200 46) * be
> >> decided completely inside the hardware block and not be readable
> >> 70637a6d (Heiko Stübner 2013-06-25 14:55:42 +0200 47) * from
> >> the kernel side. 5ca3353b (Linus Walleij 2013-06-16 12:43:06 +0200
> >> 48) * If the argument is != 0 pull up/down is enabled, if it is 0,
> >> the 5ca3353b (Linus Walleij 2013-06-16 12:43:06 +0200 49) *
> >> configuration is ignored. The proper way to disable it is to use
> >> 5ca3353b (Linus Walleij 2013-06-16 12:43:06 +0200 50) *
> >> @PIN_CONFIG_BIAS_DISABLE.
> >
> > If the HW doesn't support any concept of a default pull, I think the
> > driver shouldn't support that option; it should return an error if asked
> > to program it.
>
> Yes that's how I remember it and how we specified it.
> Correct Heiko?
Correct. The option was/is meant for hardware that sets pull settings without
telling the kernel specifics and the kernel also not being able to influence
them.
Heiko
next prev parent reply other threads:[~2013-10-02 11:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 12:48 Laxman Dewangan
2013-09-26 12:48 ` [PATCH 2/2] pinctrl: palmas: remove non-require function Laxman Dewangan
2013-09-27 13:53 ` Linus Walleij
2013-09-26 15:38 ` [PATCH 1/2] pinctrl: palmas: do not abort pin configuration for BIAS_DEFAULT Stephen Warren
2013-09-27 13:30 ` Laxman Dewangan
2013-09-27 16:06 ` Stephen Warren
2013-09-28 11:38 ` Laxman Dewangan
2013-10-02 10:40 ` Linus Walleij
2013-10-02 11:10 ` Laxman Dewangan
2013-10-02 11:20 ` Heiko Stübner [this message]
2013-10-02 16:10 ` Stephen Warren
2013-09-27 14:25 ` Linus Walleij
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=201310021320.51544.heiko@sntech.de \
--to=heiko@sntech.de \
--cc=ldewangan@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swarren@wwwdotorg.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
Powered by JetHome