From: Laxman Dewangan <ldewangan@nvidia.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"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: Sat, 28 Sep 2013 17:08:20 +0530 [thread overview]
Message-ID: <5246BFAC.5020306@nvidia.com> (raw)
In-Reply-To: <5245AD0C.7070206@wwwdotorg.org>
On Friday 27 September 2013 09:36 PM, Stephen Warren wrote:
> On 09/27/2013 07:30 AM, Laxman Dewangan wrote:
>> On Thursday 26 September 2013 09:08 PM, Stephen Warren wrote:
>>> On 09/26/2013 06:48 AM, Laxman Dewangan wrote:
>>>> Recent movement of all configurations of pin in the single call of
>>>> pin_config_set(), it is aborting configuration if BIAS_PULL_PIN_DEFAULT
>>>> is selected as return of configuration.
>>>>
>>>> The original idea was to just avoid any update on register for pull
>>>> up/down
>>>> configuration if this option is selected.
>>> That doesn't sound correct. If a config option is specified in DT or the
>>> mapping table, it should be applied to HW. If someone doesn't want a
>>> particular config option applied, then it simply shouldn't be mentioned
>>> in DT or the mapping table.
>>>
>>> IIUC, BIAS_DEFAULT should be used only on HW where there is a concept of
>>> a true default bias, and in that case, that is what should be applied.
>>>
>> 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, I will remove this option as I have not seen default option for pins.
>
>
> But what made you come across this issue? Is some pin mapping table or
> DT pinctrl node actually using that value? If so, then presumably that
> needs to be fixed, as well as removing driver support for that option.
When referring the code for the AMSAS3722 pincontrol driver, I just
found that it is breaking the earlier code.
Removing this option makes more reasonable here and will post the next
patch.
next prev parent reply other threads:[~2013-09-28 11:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-26 12:48 [PATCH 1/2] pinctrl: palmas: do not abort pin configuration for BIAS_DEFAULT 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 [this message]
2013-10-02 10:40 ` Linus Walleij
2013-10-02 11:10 ` Laxman Dewangan
2013-10-02 11:20 ` Heiko Stübner
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=5246BFAC.5020306@nvidia.com \
--to=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 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.