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. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
