All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Mike Rapoport <mike@compulab.co.il>
Subject: Re: [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
Date: Mon, 30 Nov 2009 10:54:15 -0800	[thread overview]
Message-ID: <20091130185415.GT4348@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02BBE6475E@dbde02.ent.ti.com>

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [091129 02:02]:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Thursday, November 26, 2009 5:49 AM
> > To: linux-arm-kernel@lists.infradead.org
> > Cc: linux-omap@vger.kernel.org; Mike Rapoport
> > Subject: [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
> > 
> > From: Mike Rapoport <mike@compulab.co.il>
> > 
> > intoduce omap_mux_{read,write}

<snip>
 
> >  int __init omap2_mux_init(void)
> >  {
> > +	u32 mux_pbase;
> > +
> > +	if (cpu_is_omap2420())
> > +		mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +	else if (cpu_is_omap2430())
> > +		mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +	else if (cpu_is_omap34xx())
> > +		mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +
> > +	mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
> 
> The control modules on OMAP's divided into 2 domains with different base address
> 1. pads in CORE power domain
> 2. Pads in wakeup domain.
> 
> If we map these two separately, then we can differentiate the wakeup capable pads.
> Not sure whether I am making any sense here but just thought it would be useful.

OK, maybe we can consider doing that later on.

If we separate the core and wakeup domains for muxing, we should
do it in a way where it's transparent to the users. Otherwise
the the muxing again gets confusing easily if we have separate sets
of functions for the core and wakeup domains.

Regards,

Tony


WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
Date: Mon, 30 Nov 2009 10:54:15 -0800	[thread overview]
Message-ID: <20091130185415.GT4348@atomide.com> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02BBE6475E@dbde02.ent.ti.com>

* Shilimkar, Santosh <santosh.shilimkar@ti.com> [091129 02:02]:
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> > owner at vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Thursday, November 26, 2009 5:49 AM
> > To: linux-arm-kernel at lists.infradead.org
> > Cc: linux-omap at vger.kernel.org; Mike Rapoport
> > Subject: [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write}
> > 
> > From: Mike Rapoport <mike@compulab.co.il>
> > 
> > intoduce omap_mux_{read,write}

<snip>
 
> >  int __init omap2_mux_init(void)
> >  {
> > +	u32 mux_pbase;
> > +
> > +	if (cpu_is_omap2420())
> > +		mux_pbase = OMAP2420_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +	else if (cpu_is_omap2430())
> > +		mux_pbase = OMAP243X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +	else if (cpu_is_omap34xx())
> > +		mux_pbase = OMAP343X_CTRL_BASE + OMAP_MUX_BASE_OFFSET;
> > +
> > +	mux_base = ioremap(mux_pbase, OMAP_MUX_BASE_SZ);
> 
> The control modules on OMAP's divided into 2 domains with different base address
> 1. pads in CORE power domain
> 2. Pads in wakeup domain.
> 
> If we map these two separately, then we can differentiate the wakeup capable pads.
> Not sure whether I am making any sense here but just thought it would be useful.

OK, maybe we can consider doing that later on.

If we separate the core and wakeup domains for muxing, we should
do it in a way where it's transparent to the users. Otherwise
the the muxing again gets confusing easily if we have separate sets
of functions for the core and wakeup domains.

Regards,

Tony

  reply	other threads:[~2009-11-30 18:54 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-26  0:18 [PATCH 0/8] Series short description Tony Lindgren
2009-11-26  0:18 ` Tony Lindgren
2009-11-26  0:18 ` [PATCH 1/8] omap2: mux: intoduce omap_mux_{read,write} Tony Lindgren
2009-11-26  0:18   ` Tony Lindgren
2009-11-29 10:03   ` Shilimkar, Santosh
2009-11-29 10:03     ` Shilimkar, Santosh
2009-11-30 18:54     ` Tony Lindgren [this message]
2009-11-30 18:54       ` Tony Lindgren
2009-11-26  0:19 ` [PATCH 2/8] omap: mux: Add new style pin multiplexing code for omap3 Tony Lindgren
2009-11-26  0:19   ` Tony Lindgren
2009-11-26  0:19 ` [PATCH 3/8] omap: mux: Add new style pin multiplexing data for 34xx Tony Lindgren
2009-11-26  0:19   ` Tony Lindgren
2009-11-26  0:19 ` [PATCH 4/8] omap: mux: Add new style init functions to omap3 board-*.c files Tony Lindgren
2009-11-26  0:19   ` Tony Lindgren
2009-11-26  0:19 ` [PATCH 5/8] omap: mux: Add debugfs support for new mux code Tony Lindgren
2009-11-26  0:19   ` Tony Lindgren
2009-11-26  0:19 ` [PATCH 6/8] omap: Split i2c platform init for mach-omap1 and mach-omap2 Tony Lindgren
2009-11-26  0:19   ` Tony Lindgren
2009-11-27 17:44   ` Tony Lindgren
2009-11-27 17:44     ` Tony Lindgren
2009-11-26  0:20 ` [PATCH 7/8] omap: mux: Replace omap_cfg_reg() with new style signal or gpio functions Tony Lindgren
2009-11-26  0:20   ` Tony Lindgren
2009-11-26  0:20 ` [PATCH 8/8] omap: mux: Remove old mux code for 34xx Tony Lindgren
2009-11-26  0:20   ` Tony Lindgren
2009-11-26  0:20 ` [PATCH 0/8] Omap mux changes for v2.6.33 merge window (Series short description) Tony Lindgren
2009-11-26  0:20   ` Tony Lindgren
2009-11-26 11:20   ` Mike Rapoport
2009-11-26 11:20     ` Mike Rapoport
2009-11-26 18:15     ` Tony Lindgren
2009-11-26 18:15       ` Tony Lindgren
2009-11-27 16:16   ` Tony Lindgren
2009-11-27 16:16     ` Tony Lindgren
2009-11-26  6:44 ` [PATCH 0/8] Series short description Hemanth V
2009-11-26  6:44   ` Hemanth V
2009-11-26  8:27   ` Tony Lindgren
2009-11-26  8:27     ` Tony Lindgren
2009-11-29 10:03 ` Shilimkar, Santosh
2009-11-29 10:03   ` Shilimkar, Santosh

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=20091130185415.GT4348@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mike@compulab.co.il \
    --cc=santosh.shilimkar@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 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.