From: Anand Gadiyar <gadiyar@ti.com>
To: Sricharan R <r.sricharan@ti.com>, linux-omap@vger.kernel.org
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
tony@atomide.com, paul@pwsan.com
Subject: RE: [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic.
Date: Sat, 29 Jan 2011 02:19:05 +0530 [thread overview]
Message-ID: <d52d24e46279799c2019f7c297a4e627@mail.gmail.com> (raw)
In-Reply-To: <1296191298-17545-2-git-send-email-r.sricharan@ti.com>
sricharan wrote:
>
> 1) All the pads of a hwmod for the device are classified
> as static/dynamic. If a pad requires remuxing during
> the device transitions between enable/idle transitions
> then it is added to the dynamic list, static otherwise.
>
> 2) Both the static/dynamic pads of a hwmod are initialised
> when the device gets enabled. When the device transitions
> between enable/idle the dynamic pads are remuxed and
> static pads are skipped.
>
> 3) When the driver gets removed both the static and the
> dynamic pads are muxed to safe mode as default.
>
I haven't taken a look at the code. I do have a few
concerns (which may really be non-issues, but I'm
pointing them out anyway):
- Not all pads have a safe mode.
--- And why would you want statically muxed pads to be remuxed
into safe mode anyway? What is the advantage of such a change,
as against leaving them in a functional mode?
- Many signals are muxed on more than one pad.
- Many peripherals need pads to be configured in different
mux modes depending on the way a board is wired up.
With this, moving pad info to hwmod databases does not sound
useful to me. Maybe I do not understand the need for this
change, in place of what we have today.
- Anand
next prev parent reply other threads:[~2011-01-28 20:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-28 5:08 [PATCH 0/5] omap2+: mux: Add support for static and dynamic pads sricharan
2011-01-28 5:08 ` [PATCH 1/5] omap2+: mux: Seperate the pads of a hwmod as static and dynamic sricharan
2011-01-28 20:49 ` Anand Gadiyar [this message]
2011-01-31 14:20 ` Sricharan R
2011-02-23 18:49 ` Tony Lindgren
2011-02-25 13:21 ` Sricharan R
2011-01-28 5:08 ` [PATCH 2/5] omap4: board-4430sdp: Initialise the serial pads sricharan
2011-02-23 18:49 ` Tony Lindgren
2011-02-25 13:21 ` Sricharan R
2011-01-28 5:08 ` [PATCH 3/5] omap3: board-3430sdp: " sricharan
2011-01-28 5:08 ` [PATCH 4/5] omap4: board-omap4panda: " sricharan
2011-01-28 20:53 ` Anand Gadiyar
2011-01-31 14:20 ` Sricharan R
2011-02-23 18:49 ` Tony Lindgren
2011-02-25 13:22 ` Sricharan R
2011-01-28 5:08 ` [PATCH 5/5] omap2+: board-n8x0: Change the flags for " sricharan
2011-02-23 18:49 ` Tony Lindgren
2011-02-25 13:21 ` Sricharan R
2011-02-10 12:04 ` [PATCH 0/5] omap2+: mux: Add support for static and dynamic pads Sricharan R
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=d52d24e46279799c2019f7c297a4e627@mail.gmail.com \
--to=gadiyar@ti.com \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=r.sricharan@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.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.