From: Tony Lindgren <tony@atomide.com>
To: Benoit Cousson <b-cousson@ti.com>
Cc: linux-omap@vger.kernel.org, Paul Walmsley <paul@pwsan.com>,
Kevin Hilman <khilman@deeprootsystems.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>
Subject: Re: [RFC 1/5] OMAP: mux: Add support for control module split in several partitions
Date: Fri, 24 Sep 2010 17:22:28 -0700 [thread overview]
Message-ID: <20100925002228.GP4211@atomide.com> (raw)
In-Reply-To: <1285319748-28976-2-git-send-email-b-cousson@ti.com>
Hi Benoit,
* Benoit Cousson <b-cousson@ti.com> [100924 02:07]:
> Starting on OMAP4, the pin mux configuration is located in two
> different partitions of the control module (CODE_PAD and WKUP_PAD).
> The first one is inside the core power domain whereas the second
> one is inside the wakeup.
> Since each partition has a different physical base address, an
> ID is added for each mux entry in order to identify the proper
> partition and thus the correct base address.
Few comments below..
> /**
> * struct omap_mux - data for omap mux register offset and it's value
> * @reg_offset: mux register offset from the mux base
> * @gpio: GPIO number
> + * @id: Partition identifier
> * @muxnames: available signal modes for a ball
> */
> struct omap_mux {
> u16 reg_offset;
> u16 gpio;
> + u8 id;
> #ifdef CONFIG_OMAP_MUX
> char *muxnames[OMAP_MUX_NR_MODES];
> #ifdef CONFIG_DEBUG_FS
We might want to think a bit more how we want to handle the various
partitions for registers.
What do you think of the following:
We could convert u16 reg_offset into u32 reg_phys, and build the ioremap
areas based on those ranges.
After ioremap we're copying the data for used pins anyways, so we could
write them as virtual addresses.
struct omap_mux {
union mux_reg_union {
u32 reg_phys;
void __iomem *reg_virt;
};
u16 gpio;
#ifdef CONFIG_OMAP_MUX
char *muxnames[OMAP_MUX_NR_MODES];
#ifdef CONFIG_DEBUG_FS
char *balls[OMAP_MUX_NR_SIDES];
#endif
#endif
};
This would make the code more generic and simplify some parts of the
code. Muxing signals based on the signal name or gpio number would
work transparently
Then omapX_mux_init(board_mux, OMAP_PACKAGE_XYZ) would work
in a transparent way, but would have to figure out the partition
from the define.
If we wanted to use only the offset in the data, we could initialize
the various sections separately. But then omapX_mux_init() would have
to know the partition number somehow..
Regards,
Tony
next prev parent reply other threads:[~2010-09-25 0:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-24 9:15 [RFC 0/5] OMAP4: mux: Add the OMAP4430 ES1 support Benoit Cousson
2010-09-24 9:15 ` [RFC 1/5] OMAP: mux: Add support for control module split in several partitions Benoit Cousson
2010-09-25 0:22 ` Tony Lindgren [this message]
2010-09-27 15:46 ` Tony Lindgren
2010-09-27 17:24 ` Cousson, Benoit
2010-09-27 17:36 ` Tony Lindgren
2010-09-27 20:03 ` Cousson, Benoit
2010-09-27 20:06 ` Tony Lindgren
2010-09-24 9:15 ` [RFC 2/5] OMAP: mux: Make low level function private Benoit Cousson
2010-09-24 23:09 ` Gadiyar, Anand
2010-09-24 23:50 ` Tim Nordell
2010-09-25 0:07 ` Anand Gadiyar
2010-09-25 6:48 ` Tim Nordell
2010-09-24 9:15 ` [RFC 3/5] OMAP4: mux: Add data for OMAP4430 ES1 Benoit Cousson
2010-09-24 23:18 ` Anand Gadiyar
2010-09-27 9:31 ` Cousson, Benoit
2010-09-24 9:15 ` [RFC 4/5] OMAP4: mux: Select CBL package for SDP4430 with ES1 Benoit Cousson
2010-09-24 23:14 ` Anand Gadiyar
2010-09-27 7:24 ` Cousson, Benoit
2010-09-24 9:15 ` [RFC 5/5] OMAP4: mux: Temporary initial SDP4430 mux settings Benoit Cousson
2010-10-18 18:09 ` [RFC 0/5] OMAP4: mux: Add the OMAP4430 ES1 support Menon, Nishanth
2010-10-18 20:51 ` Cousson, Benoit
2010-10-18 20:53 ` Menon, Nishanth
2010-10-18 20:57 ` Cousson, Benoit
2010-10-18 21:08 ` Menon, Nishanth
2010-10-18 23:00 ` Tony Lindgren
2010-10-18 23:12 ` Cousson, Benoit
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=20100925002228.GP4211@atomide.com \
--to=tony@atomide.com \
--cc=b-cousson@ti.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--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.