[PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree

[Guangyu.Chen@freescale.com (Nicolin Chen)]

On Thu, Jan 09, 2014 at 08:58:28AM +0100, Sascha Hauer wrote:
> On Thu, Jan 09, 2014 at 03:41:38PM +0800, Nicolin Chen wrote:
> > On Thu, Jan 09, 2014 at 02:57:42PM +0800, Shawn Guo wrote:
> > > On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > > > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > > >  static struct clk *clk[clk_max];
> > > > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > > > >  	clk[ecspi5]       = imx_clk_gate2("ecspi5",        "ecspi_root",        base + 0x6c, 8);
> > > > > >  	clk[enet]         = imx_clk_gate2("enet",          "ipg",               base + 0x6c, 10);
> > > > > >  	clk[esai]         = imx_clk_gate2("esai",          "esai_podf",         base + 0x6c, 16);
> > > > > > +	clk[esai_ahb]     = imx_clk_gate2("esai_ahb",      "ahb",               base + 0x6c, 16);
> > > > > 
> > > > > Hmm, having two clocks operating on the same gate bit will get us
> > > > > problem in clock disabling.  Clock enabling is fine, since either
> > > > > one who calls clk_enable() first will just set the gate bit.  But in
> > > > > case that clk_enable() is called on both clocks, and then when either
> > > > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > > > the other one that might still be in use.
> > > > 
> > > > Understood. But how could we handle this situation? The only way I can figure
> > > > out is to make sure the driver open/close them at the same time, it's not a
> > > > perfect way though.
> > > 
> > > Hmm, we generally leave the gate bit to the clock used to access
> > > register, because usually it's the first one to be on and the last one
> > > to be off.
> > 
> > Then we should attach CLK_IGNORE_UNUSED to clk[esai] since clk[esai_ahb] is
> > the clock used to access memory, shouldn't we?
> 
> Please wait for Mikes input or let's look how a proper solution can look
> like. I've already seen the case that a single bit controls multiple
> clocks. Hacking around this issue each time is not a solution.

Okay.

Thank you, Sascha.