On Tue, Oct 09, 2012 at 12:36:53PM +0000, Philip, Avinash wrote: > On Mon, Oct 08, 2012 at 19:09:51, Thierry Reding wrote: > > On Mon, Oct 08, 2012 at 01:31:19PM +0000, Philip, Avinash wrote: > > > On Tue, Oct 02, 2012 at 11:30:14, Thierry Reding wrote: > > > > On Wed, Sep 26, 2012 at 04:57:42PM +0530, Philip, Avinash wrote: > > [...] > > > > > @@ -231,13 +290,56 @@ static int __devinit ecap_pwm_probe(struct > > > > > platform_device *pdev) > > > > > } > > > > > > > > > > pm_runtime_enable(&pdev->dev); > > > > > + > > > > > + /* > > > > > + * Some platform has extra PWM-subsystem common config space > > > > > + * and requires special handling of clock gating. > > > > > + */ > > > > > + if (pdata && pdata->has_configspace) { > > > > > + r = platform_get_resource(pdev, IORESOURCE_MEM, 1); > > > > > + if (!r) { > > > > > + dev_err(&pdev->dev, "no memory resource > > > > > defined\n"); > > > > > + ret = -ENODEV; > > > > > + goto err_disable_clock; > > > > > + } > > > > > + > > > > > + pc->config_base = devm_ioremap(&pdev->dev, r->start, > > > > > + resource_size(r)); > > > > > + if (!pc->config_base) { > > > > > + dev_err(&pdev->dev, "failed to ioremap() > > > > > registers\n"); > > > > > + ret = -EADDRNOTAVAIL; > > > > > + goto err_disable_clock; > > > > > + } > > > > > > > > Isn't this missing a request_mem_region()? I assume you don't do that > > > > here because you need the same region in the EHRPWM driver, right? > > > > > > request_mem_region() is avoided as this region is shared across PWM > > > sub modules ECAP & EHRPWM. > > > > > > > This should be indication enough that the design is not right here. > > > > I think we need a proper abstraction here. Can this not be done via > > > > PM runtime support? If not, maybe this should be represented by > > > > clock objects since the bit obviously enables a clock. > > > > > > It is not done as part of PM runtime as this is has nothing to > > > do with clock tree of the SOC. The bits we were enabling here > > > should consider as an enable of the individual sub module as > > > part of IP integration. Hence we were handling these subsystem > > > module enable in the driver itself. > > > > My point remains valid: you shouldn't be able to access the same > > register through two different drivers. That's one of the reasons, if > > not the only reasen, why the request_mem_region() function exists. I > > think you should add some abstraction to provide this functionality to > > the drivers. I assume that eventually there will be more than just the > > PWM cores that require access to this register. > > Enabling of PWM sub modules from CONFIG space is only present in AM33xx > as part of IP integration (ECAP, EHRPWM & EQEP). > > Enabling of sub modules (ECAP, EHRPWM & EQEP) should do in CONFIG space. > Hence sub module drivers are accessing CONFIG space without reserving it > Individually from drivers (request_mem_region()). > > Can you describe/point how it can be handled in a separate Abstraction layer > as this is shared across ECAP, EHRPWM & EQEP (EQEP driver is not yet > available).
Perhaps something like a global function to enable and disable the clocks would be enough. You could for instance have a driver that requests the config space memory region and provides this global function so that it can be used by the ECAP, EHRPWM and EQEP. A more elaborate scheme would possibly involve making the new device a parent of the ECAP, EHRPWM and EQEP devices and have their drivers lookup the parent to determine which configurator device to operate on. Thierry
pgpMrCPnQnQ9Q.pgp
Description: PGP signature