[PATCH 3/3] mtd: gpmi: change the code for clocks

Dong Aisheng aisheng.dong at freescale.com
Fri Jun 29 05:34:38 EDT 2012


On Fri, Jun 29, 2012 at 05:29:26PM +0800, Lothar Waßmann wrote:
> Hi,
> 
> Dong Aisheng writes:
> > On Fri, Jun 29, 2012 at 10:06:52AM +0800, Shawn Guo wrote:
> > > On Thu, Jun 28, 2012 at 11:52:05PM -0400, Huang Shijie wrote:
> > > > From: Huang Shijie <b32955 at freescale.com>
> > > > 
> > > > The gpmi nand driver may needs several clocks(MX6Q needs five clocks).
> > > > 
> > > > In the old clock framework, all these clocks are chained together,
> > > > all you need is to manipulate the first clock.
> > > > 
> > > > But the kernel uses the common clk framework now, which forces us to
> > > > get the clocks one by one. When we use them, we have to enable them
> > > > one by one too.
> > > > 
> [...]
> > > > +static char *extra_clks_for_mx6q[] = {
> > > > +	"gpmi_apb", "gpmi_bch", "gpmi_bch_apb", "per1_bch",
> > > > +};
> > > > +
> > > > +static int __devinit gpmi_get_clks(struct gpmi_nand_data *this)
> > > > +{
> > > > +	struct resources *r = &this->resources;
> > > > +	char **extra_clks = NULL;
> > > > +	struct clk *clk;
> > > > +	int i;
> > > > +
> > > > +	r->clock[0] = clk_get(&this->pdev->dev, NULL);
> > > > +	if (IS_ERR(r->clock[0]))
> > > > +		goto err_clock;
> > > > +
> > > > +	/* Get extra clocks */
> > > > +	if (GPMI_IS_MX6Q(this))
> > > > +		extra_clks = extra_clks_for_mx6q;
> > > 
> > > We probably do not need this tweaking.  We can have the driver always
> > > take all those 5 clocks, and I think the current imx28 clock driver
> > > can just work with it, because the gpmi-nand clkdev lookup has NULL
> > > con_id and all those 5 clocks can match the same one on imx28.
> > > 
> > Will mx28 fail if doing like that?
> > clk_get will fail if no clock found.
> > struct clk *clk_get_sys(const char *dev_id, const char *con_id)
> > {
> >         struct clk_lookup *cl;
> > 
> >         mutex_lock(&clocks_mutex);
> >         cl = clk_find(dev_id, con_id);
> >         if (cl && !__clk_get(cl->clk))
> >                 cl = NULL;
> >         mutex_unlock(&clocks_mutex);
> > 
> >         return cl ? cl->clk : ERR_PTR(-ENOENT);
> > }
> > EXPORT_SYMBOL(clk_get_sys);
> > 
> > Furthermore, find unnecessary clock for mx28 seems not a good choice.
> > Probably a better way is to define each SoC required clocks and get them
> > respectively. It's explicit and clear.
> > 
> No, that's silly. You would have to change the driver for each
> new platform that the driver can support.
> 
If the new platform is fully compatible with exist platforms, then no.
If need more clocks, then in either way, we have to add support in driver.

> Instead the driver should request the maximum number of clocks that
> the existing set of platforms provide and all platforms with fewer
> clocks should provide an appropriate number of dummy clocks.
> 
I wish we can not use dummy since it's easy causing misleading until
we have no other better way to go.

> This way new platforms can be supported without any change to the
> driver and only if a platform requires even more clocks (like in this
> particular case) would some code outside that platform have to be
> changed at all.

Regards
Dong Aisheng




More information about the linux-arm-kernel mailing list