[RFC PATCH 05/11] mfd: omap: control: core system control driver

Cousson, Benoit b-cousson at ti.com
Fri Jun 1 08:43:54 EDT 2012

On 6/1/2012 2:30 PM, Shilimkar, Santosh wrote:
> On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgren<tony at atomide.com>  wrote:
>> * Cousson, Benoit<b-cousson at ti.com>  [120529 06:29]:
>>> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
>>>>> Mmm, we can have up to 4 control module instances in OMAP4.
>>>>> Well, I'm not sure it worth considering them as separate devices. Is
>>>>> that your plan as well?
>>>> At least for now I was focusing on the ctrl_module_core ...
>>> OK, that's a good start already :-)
>>>>> But since they all have different base address, it will be trick to
>>>>> handle them with only a single entry.
>>>> Indeed. We can always add the support latter on.
>>>> I am not sure what would be the best way to handle those instances though,
>>>> and how they are going to expose APIs. Would need to have an instance bound
>>>> to API set?
>>> We should not go to that path I guess. We should have an API at
>>> children level independent of the underlying control module
>>> partitioning.
>> These should be separate driver instances for the control modules.
>> And then the ioremapped area should ignore at least the padconf
>> registers so drivers/pinctrl/pinctrl-simple can handle those. There
>> should not be any dependencies to the SCM driver from pinctrl-simple,
>> the core SCM driver can manage the clocks and trigger the save of
>> padconf regs.
>> Also we should allow MMC driver handle the MMC specific registers
>> and USB driver(s) handle the USB specific registers if possible. Those
>> should not live under drivers/mfd unless there are some dependencies
>> other than trying to ioremap the whole SCM module instead of ioremapping
>> in each driver.
>> We can have a static map for the SCM, so ioremapping each driver
>> individually should not be an issue.
> This sounds a good idea. With this we may not even need a core control
> module drivers if all the individual drivers take care of the registers they
> care. Mapping shouldn't be a problem as you mentioned.

We should keep the MFD for PM / OCP single port correctness. Other than 
that it will be mostly useless, indeed.


More information about the linux-arm-kernel mailing list