From: armando.visconti@st.com (Armando VISCONTI)
To: linux-arm-kernel@lists.infradead.org
Subject: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux
Date: Mon, 15 Mar 2010 11:10:20 +0100 [thread overview]
Message-ID: <4B9E078C.4010706@st.com> (raw)
In-Reply-To: <4B9DF966.6050504@st.com>
Shiraz,
>> If you do it thru Kconfig still it would be fixed a compilation time.
>> Do you agree or am I missing something?
>>
>
> yes, and if you see, should any one require it dynamically? Each user
> would have his own board with static devices. This configuration (of
> selecting multiplexed devices) depends on his board configuration, which
> is the responsibility of the board configuration file.
>
This was also my understanding at the beginning.
But looking at the response from the community it
looks that it is better to have a single image for all boards
which is capable at runtime to be configured in the proper way.
>> So, probably the correct way is passing peripheral selection information
>> thru
>> bootargs.
>> What do you think?
>>
>
> This is very specific to how an SoC provides multiplexing options and will
> vary greatly. Which option of bootargs are you talking about?
>
Of course not a standard bootargs option.
I was more talking about a new specific option that is
passed thru bootargs and directed to a specific SPEAr function that
can apply the proper cfg and register setting, like someone (Ben?)
was suggesting.
In this option you should pass a bitmap or something like that.
Let me know your opinion on it.
Armando
Shiraz HASHIM wrote:
> Armando,
>
> On 3/15/2010 2:12 PM, Armando VISCONTI wrote:
>
>>> Now, For this we need some interface or channel through which we provide
>>> this information to kernel. This is what precisely i have done. The
>>> channel i
>>> provided is through Kconfig and the function "s300_configure", accepts
>>> this bitmap and configures hardware.
>>>
>>>
>> I'm not getting this point.
>>
>
> yes, Actually this is what we are saying. Seemingly the best option is
> to do it during compilation time, except if we have some standard way
> at booting.
>
>
>> If you do it thru Kconfig still it would be fixed a compilation time.
>> Do you agree or am I missing something?
>>
>
> yes, and if you see, should any one require it dynamically? Each user
> would have his own board with static devices. This configuration (of
> selecting multiplexed devices) depends on his board configuration, which
> is the responsibility of the board configuration file.
>
>
>> So, probably the correct way is passing peripheral selection information
>> thru
>> bootargs.
>> What do you think?
>>
>
> This is very specific to how an SoC provides multiplexing options and will
> vary greatly. Which option of bootargs are you talking about?
>
> regards
> Shiraz
>
--
-- "Every step appears to be the unavoidable consequence of the
-- preceding one." (A. Einstein)
--
Armando Visconti Mobile: (+39) 346 8879146
Senior SW Engineer Fax: (+39) 02 93519290
CPG Work: (+39) 02 93519683
Computer System Division e-mail: armando.visconti at st.com
ST Microelectronics TINA: 051 4683
next prev parent reply other threads:[~2010-03-15 10:10 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 [this message]
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
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=4B9E078C.4010706@st.com \
--to=armando.visconti@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 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.