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.

Thierry

Attachment: pgpspZDdpld8u.pgp
Description: PGP signature

_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss

Reply via email to