QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

[jassisinghbrar@gmail.com (jassi brar)]

On Mon, Mar 15, 2010 at 3:32 PM, Viresh KUMAR <viresh.kumar@st.com> wrote:
> On 3/15/2010 11:11 AM, jassi brar wrote:
>> On Mon, Mar 15, 2010 at 2:14 PM, Shiraz HASHIM <shiraz.hashim@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@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.
I didn't suggest your driver be GPIO specific.
A callback can be provided by platform layer(SoC specific) and the
set of GPIOs to use with a controller can be provided by the machine
layer(board specific). The driver only needs to make a call during probe time.


> 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.
For a particular device only relevant modules will be loaded at boot-time.
If two mutually exclusive functionalities are possible only then
rmmod-insmod is needed -- say, AC97 or I2S audio mode.