On 6/1/2012 2:30 PM, Shilimkar, Santosh wrote:
On Fri, Jun 1, 2012 at 7:29 PM, Tony Lindgren<tony@xxxxxxxxxxx> wrote:
* Cousson, Benoit<b-cousson@xxxxxx> [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.
Regards,
Benoit
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
