public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Mike Rapoport <mike.rapoport@gmail.com>
Cc: Mike Rapoport <mike@compulab.co.il>, linux-omap@vger.kernel.org
Subject: Re: [PATCH] omap3: mux: add shorthands for OUTPUT_PULL{UP,DOWN}
Date: Mon, 30 Nov 2009 15:10:56 -0800	[thread overview]
Message-ID: <20091130231056.GB4348@atomide.com> (raw)
In-Reply-To: <f870da180911301358t239b1820ia7cdecf932d579d1@mail.gmail.com>

* Mike Rapoport <mike.rapoport@gmail.com> [091130 13:57]:
> On Mon, Nov 30, 2009 at 11:12 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Mike Rapoport <mike@compulab.co.il> [091129 00:10]:
> >> Signed-off-by: Mike Rapoport <mike@compulab.co.il>
> >> ---
> >>  arch/arm/mach-omap2/mux.h |    2 ++
> >>  1 files changed, 2 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
> >> index e09c5d2..02a1b53 100644
> >> --- a/arch/arm/mach-omap2/mux.h
> >> +++ b/arch/arm/mach-omap2/mux.h
> >> @@ -37,6 +37,8 @@
> >>
> >>  /* Active pin states */
> >>  #define OMAP_PIN_OUTPUT                      0
> >> +#define OMAP_PIN_OUTPUT_PULLUP               (OMAP_PULL_ENA | OMAP_PULL_UP)
> >> +#define OMAP_PIN_OUTPUT_PULLDOWN     OMAP_PULL_ENA
> >>  #define OMAP_PIN_INPUT                       OMAP_INPUT_EN
> >>  #define OMAP_PIN_INPUT_PULLUP                (OMAP_PULL_ENA | OMAP_INPUT_EN \
> >>                                               | OMAP_PULL_UP)
> >
> > Hmm, isn't this same as configuring as GPIO with up or
> > down value?
> >
> > Or is there's some need doing it with mux only? Like
> > power savings?
> 
> This is intended for dedicated pins rather than GPIO. Actually, I've
> met only one till now, the HSUSB0_STP.

Hmm, are you sure you need the OMAP_PIN_OUTPUT_PULLUP for HSUSB0_STP?

AFAIK, it's not needed for other boards. I believe the STP should be
down until the MUSB signals STP and pulls it up briefly. Might be
worth checking.

> If you define most of the mux configuration in the kernel you
> eventually run into very long lines in the omap_board_mux array. So,
> shortening at least some of them seems good idea to me.

Yeah nothing wrong with that, I'm just thinking back to when we added
these mux defines originally. It seemed like the the combination of
out and pull should be needed, and pull would only be needed for inputs.

> Take a look at my second patch ([1]) for example of what I mean :)
> 
> [1] http://en.wikipedia.org/wiki/Wikipedia:Tools/Editing_tools

I guess this is a wrong link here to the editing tool. Our mux
code is bloated, but should not be _that_ bloated! :)

Eh, let's hope we don't need to implement kernel based wiki and
editing tools for the muxing :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-11-30 23:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-29  8:07 [PATCH] omap3: cm-t35: add mux initialization Mike Rapoport
2009-11-29  8:07 ` [PATCH] omap3: mux: add shorthands for OUTPUT_PULL{UP,DOWN} Mike Rapoport
2009-11-30 21:12   ` Tony Lindgren
2009-11-30 21:58     ` Mike Rapoport
2009-11-30 23:10       ` Tony Lindgren [this message]
2009-12-01  7:57         ` Mike Rapoport
2009-11-29  8:07 ` [PATCH] omap3: cm-t35: add mux initialization Mike Rapoport
2009-12-06 15:31 ` Mike Rapoport
2009-12-07 16:22   ` Tony Lindgren
2009-12-07 16:35     ` Gadiyar, Anand
2009-12-07 17:44       ` Tony Lindgren
2009-12-08 10:40         ` Mike Rapoport
2009-12-09  6:49         ` [PATCH v2] " Mike Rapoport
2009-12-09 13:27         ` [PATCH] omap3: cm-t35: add mux initialization (was: Re: [PATCH] omap3: cm-t35: add mux initialization) Mike Rapoport
2009-12-09 16:36           ` Tony Lindgren
2009-12-11 22:00           ` [APPLIED] [PATCH] omap3: cm-t35: add mux initialization Tony Lindgren

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=20091130231056.GB4348@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=mike.rapoport@gmail.com \
    --cc=mike@compulab.co.il \
    /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