QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux
Viresh KUMAR
viresh.kumar at st.com
Mon Mar 15 02:32:14 EDT 2010
On 3/15/2010 11:11 AM, jassi brar wrote:
> On Mon, Mar 15, 2010 at 2:14 PM, Shiraz HASHIM <shiraz.hashim at st.com> wrote:
>> Hello Jassi,
>>
>> On 3/15/2010 10:17 AM, jassi brar wrote:
>>> On Mon, Mar 15, 2010 at 1:31 PM, Viresh KUMAR <viresh.kumar at st.com> wrote:
>>>> In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so
>>>> only few peripherals can be selected in a configuration. This is configurable
>>>> using a set of registers. Now the problem is to make following work:
>>>>
>>>> 1. How to do this selection in kernel in a simple way?
>>>> 2. Based on this selection hardware registers needs to be configured.
>>> Why can't you make the drivers acquire and setup the necessary pins during
>>> probe?
>>> Among other benefits, it enables you to use the same kernel image and device
>>> drivers as modules -- if a GPIO can be used by two different device
>>> controllers, you
>>> can switch the 'mode' of the board by simple rmmod-insmod
>>
>> I think the problem is we cannot change the standard drivers (already in the
>> mainline). So if the standard driver doesn't support this in its probe, then
>> how should we manage this?
> Though the drivers should already have done that, but still you can always
> submit patches to improve.
>
>> Further these configurations are board dependent, so I think driver must be
>> independent of this.
> Don't really understand this. Viresh said that the SoC can configure GPIOs for
> a controller or the other, which is quite common and is handled during probe.
> Also, it's desirable to have one kernel image run on many machines with the
> same SOC.
>
Actually, different peripherals share IO Pads (PL_GPIOs) and GPIO lines. Sending
patch for drivers to support this doesn't look a great idea to me. Further this
may cause problems to users, for example: User have entered a inserted a module
and by mistake or lack of knowledge, he disables already working IP. Now with
Kconfig concept this is taken care of at the beginning only. User can't select
peripherals which can't be enabled simultaneously.
More information about the linux-arm-kernel
mailing list