linux-kernel - Re: [PATCH 1/2] pwm: pwm-tiecap: Add device-tree binding support for APWM driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20121009124830.GA25493@avionic-0098.mockup.avionic-design.de>
Date:	Tue, 9 Oct 2012 14:48:30 +0200
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	"Philip, Avinash" <avinashphilip@...com>
Cc:	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"Nori, Sekhar" <nsekhar@...com>,
	"Hebbar, Gururaja" <gururaja.hebbar@...com>,
	"Hiremath, Vaibhav" <hvaibhav@...com>
Subject: Re: [PATCH 1/2] pwm: pwm-tiecap: Add device-tree binding support for
 APWM driver

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

Content of type "application/pgp-signature" skipped