linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: shiraz.hashim@st.com (Shiraz HASHIM)
To: linux-arm-kernel@lists.infradead.org
Subject: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux
Date: Tue, 16 Mar 2010 19:09:55 +0530	[thread overview]
Message-ID: <4B9F8A2B.9020307@st.com> (raw)
In-Reply-To: <63386a3d1003151055v6d3e2ee0q848fcbb4c7a29a06@mail.gmail.com>

Hello Linus,

On 3/15/2010 11:25 PM, Linus Walleij wrote:
> Please contemplate arch/arm/mach-u300/padmux.[c|h] if you have time.
> We have there a runtime padmuxing API similar to what is used for regulators
> and clocks. E.g in arch/arm/mach-u300/mmc.c:
> 
> /*
>  * Setup padmuxing for MMC. Since this must always be
>  * compiled into the kernel, pmx is never released.
>  */
> pmx = pmx_get(mmcsd_device, U300_APP_PMX_MMC_SETTING);
> 
> if (IS_ERR(pmx))
>       pr_warning("Could not get padmux handle\n");
> else {
>     ret = pmx_activate(mmcsd_device, pmx);
>     if (IS_ERR_VALUE(ret))
>          pr_warning("Could not activate padmuxing\n");
> }
> 
> This API can be used to switch in/out padmux settings in runtime. I think
> these things will always be platform-specific because people will always have
> their favourite way of configuring GPIO pins etc. (Note: we're not *just*
> muxing GPIO with this framework, far from, as you see above also the entire
> MMC/SD block connections can be muxed in/out.)

I was trying to go through u300 code and it looks clean enough. I need your
help in understanding it better. In your case you try to configure the pin mux
and then, even if it fails the device (through amba_device_register) is registered.
Now if the driver is enabled in the kernel (or it is insmod) then the driver in
its "probe" would stuck somewhere.
Do we need to handle such scenarios. Am I missing something?
Further, if you can describe what is onmask field (of pmx) and what
devices/options are multiplexed with (say) spi, it would help me better understand
the code.
 
> We've actually seen usecases where you need to dynamically remux while
> drivers are running but these have been rare and on older chips I think.

You mean to say dynamically remapping pins to achieve some function with
the same driver? or taking out one driver and inserting another after changing
mux config.
In any case one of the objective is to keep same linux image for different
configurations/boards. Isn't it ?

thanks a lot.
regards
Shiraz

  reply	other threads:[~2010-03-16 13:39 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15  4:31 QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux Viresh KUMAR
2010-03-15  4:47 ` jassi brar
2010-03-15  5:14   ` Shiraz HASHIM
2010-03-15  5:41     ` jassi brar
2010-03-15  6:32       ` Viresh KUMAR
2010-03-15  6:46         ` jassi brar
2010-03-15 12:55         ` Bill Gatliff
2010-03-15 13:15         ` Russell King - ARM Linux
2010-03-15 13:22           ` Bill Gatliff
2010-03-16  2:01           ` jassi brar
2010-03-15 12:52     ` Bill Gatliff
2010-03-15 16:02       ` Armando VISCONTI
2010-03-15 16:53         ` Nicolas Pitre
2010-03-15 16:53         ` Bill Gatliff
2010-03-15 17:09           ` Mark Brown
2010-03-15 18:57             ` Tony Lindgren
2010-03-15 18:58               ` Bill Gatliff
2010-03-15 16:58         ` Russell King - ARM Linux
2010-03-15  4:57 ` Shilimkar, Santosh
2010-03-15  5:15   ` Shiraz HASHIM
2010-03-15  5:28     ` Shilimkar, Santosh
2010-03-15  6:34       ` Viresh KUMAR
2010-03-15  6:20 ` Ben Dooks
2010-03-15  6:28   ` Viresh KUMAR
2010-03-15  8:42     ` Armando VISCONTI
2010-03-15  9:09       ` Shiraz HASHIM
2010-03-15  9:37         ` jassi brar
2010-03-15 10:22           ` Shiraz HASHIM
2010-03-15 10:34             ` jassi brar
2010-03-15 10:55               ` Russell King - ARM Linux
2010-03-15 10:37             ` Russell King - ARM Linux
2010-03-15 10:10         ` Armando VISCONTI
2010-03-15 10:27           ` Shiraz HASHIM
2010-03-15  7:06   ` Viresh KUMAR
2010-03-17 16:30     ` Ben Dooks
2010-03-19  4:45       ` Viresh KUMAR
2010-03-15 17:55 ` Linus Walleij
2010-03-16 13:39   ` Shiraz HASHIM [this message]
2010-03-16 21:55     ` Linus Walleij

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=4B9F8A2B.9020307@st.com \
    --to=shiraz.hashim@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).