linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Laxman Dewangan <ldewangan@nvidia.com>,
	linus.walleij@stericsson.com, dunlap@xenotime.net, lrg@ti.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration
Date: Mon, 13 Feb 2012 14:06:57 -0800	[thread overview]
Message-ID: <20120213220656.GA11931@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120213211809.GI11077@ponder.secretlab.ca>

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

On Mon, Feb 13, 2012 at 02:18:09PM -0700, Grant Likely wrote:
> On Mon, Feb 13, 2012 at 11:59:47AM +0530, Laxman Dewangan wrote:
> > Adding details of open drain configuration of the gpio so that
> > client can set the pin as open drain at the time of gpio request.

> Implicitly, the gpio api already supports open-drain and several drivers
> make use of it.  Instead of being a separate flag; users who need open
> drain will set the pin to input.  For example, see the i2c-gpio driver.

> I'm not convinced this is needed; but my opinion could be swayed.

The actual idea is to provide support for doing the switch to input to
drivers that just want to set a logic level and don't (at their level)
care one way or another if it's a CMOS or open drain output but instead
leaves it up to board configuration which mode is used.  Laxman posted a
patch for doing this to a regulator driver but looking at it the code
for emulating open drain while also maintaining support for regular CMOS
is fiddly enough that it seemed like it should be factored out of the
individual drivers.

> Also, you should include a patch to make i2c-gpio.c use this new
> functionality as a proof-of-concept.  You may not be able to test it,
> but it will make it a lot easier to justify merging by showing how it
> cleans up a gpio user.

The regulator patch is one example - I think things that could be CMOS
are probably more interesting here than drivers that always want open
drain as they have more of a complexity hit from needing to decide if
they'll use the emulation or not.

We could also at some later point add support for hardware which can
implement open drain mode itself though I'm not sure if there's enough
problem with emulating to make it worth the effort.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-02-13 22:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13  6:29 [PATCH V1 0/3] Support for open drain gpios in gpilib/fixed regulators Laxman Dewangan
2012-02-13  6:29 ` [PATCH V1 1/3] gpio: gpiolib: Support for open drain gpios Laxman Dewangan
2012-02-13  6:29 ` [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration Laxman Dewangan
2012-02-13 21:18   ` Grant Likely
2012-02-13 22:06     ` Mark Brown [this message]
2012-02-14  8:59       ` Laxman Dewangan
     [not found]     ` <20120213211809.GI11077-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2012-02-14  9:16       ` Laxman Dewangan
2012-02-15 22:25     ` Linus Walleij
2012-02-16  8:28       ` Laxman Dewangan
2012-02-16 20:00         ` Linus Walleij
     [not found]           ` <CACRpkdaFyxU-gq5ETnNc4LonTo98PbUs09CmvsPUqzyt0Mg2Cg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-17 10:30             ` Laxman Dewangan
     [not found] ` <1329114588-15430-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-02-13  6:29   ` [PATCH V1 3/3] regulator: fixed: Support for open-drain gpio Laxman Dewangan
2012-02-13 20:02   ` [PATCH V1 0/3] Support for open drain gpios in gpilib/fixed regulators Linus Walleij
2012-02-13 22:10     ` Mark Brown

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=20120213220656.GA11931@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=dunlap@xenotime.net \
    --cc=grant.likely@secretlab.ca \
    --cc=ldewangan@nvidia.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lrg@ti.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).