RE: omap clock.h question

RE: omap clock.h question

[Woodruff, Richard]

> > What's the correct way to support this?  Define another clock struct
> > with the same name, but setup for 730?
> 
> Yes, just add another clock for 730. BTW, the mmc driver is about to
> change where you just request mmc_ick and mmc_fck on all omaps.

Is that what RMK meant...  I was wondering if he meant you stash away a
number of clocks and a list of them in the dev structure.  That way you
could just call clock enable for all need clocks based on private data.
Who is to say 2 is enough, or 3, in the future.

I wasn't all that clear on exactly what was meant, but that was my first
thought.

Regards,
Richard W.

Re: omap clock.h question

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060207 13:42]:
> 
> > > What's the correct way to support this?  Define another clock struct
> > > with the same name, but setup for 730?
> > 
> > Yes, just add another clock for 730. BTW, the mmc driver is about to
> > change where you just request mmc_ick and mmc_fck on all omaps.
> 
> Is that what RMK meant...  I was wondering if he meant you stash away a
> number of clocks and a list of them in the dev structure.  That way you
> could just call clock enable for all need clocks based on private data.
> Who is to say 2 is enough, or 3, in the future.
> 
> I wasn't all that clear on exactly what was meant, but that was my first
> thought.

I believe he meant just to hide the clock number for mmc 1 or 2. But I
guess we still need to have different naming for omap1 and omap2.

Tony

RE: omap clock.h question

[Woodruff, Richard]

> * Woodruff, Richard <r-woodruff2@ti.com> [060207 14:07]:
> > > I believe he meant just to hide the clock number for mmc 1 or 2.
But I
> > > guess we still need to have different naming for omap1 and omap2.
> >
> > Like I was saying you could hide both the slot and the names.
> >
> >  for(i=data.slot[slot].num_clks; i>0; i--)
> >  {
> > 	ck = clk_get(data.slot.clk_name[i-1])
> > 	if(ck != NULL)
> > 	clk_enabl(ck);
> >  }
> >
> > That way we don't care the name or how many.  It gets rid of some if
> > statements anyway.
> 
> But one of the clocks can be off more often than the other from PM
point
> of view.

Perhaps, but probably not for OMAP2.  The I clocks and the F clock
enables are local to the module. Enabling an F or an I clock doesn't
mean the parent which supplies it is active. It will open up a gate of
sorts and raise a clock request.  If that parent source is running then
it can propagate into the functional block.

I don't think OMAP1 does it quite like this.  The source clock doesn't
have the module level gating.  

Seems like in theory you and run some modules with their I clock off and
the F clock on, though I doubt you would do it much in practice.  You
can just set your I clock to auto idle and it will raise and lower its
clock request automatically as needed, effectively doing the same.

Regards,
Richard W.

Re: omap clock.h question

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060207 14:58]:
> > * Woodruff, Richard <r-woodruff2@ti.com> [060207 14:07]:
> > > > I believe he meant just to hide the clock number for mmc 1 or 2.
> But I
> > > > guess we still need to have different naming for omap1 and omap2.
> > >
> > > Like I was saying you could hide both the slot and the names.
> > >
> > >  for(i=data.slot[slot].num_clks; i>0; i--)
> > >  {
> > > 	ck = clk_get(data.slot.clk_name[i-1])
> > > 	if(ck != NULL)
> > > 	clk_enabl(ck);
> > >  }
> > >
> > > That way we don't care the name or how many.  It gets rid of some if
> > > statements anyway.
> > 
> > But one of the clocks can be off more often than the other from PM
> point
> > of view.
> 
> Perhaps, but probably not for OMAP2.  The I clocks and the F clock
> enables are local to the module. Enabling an F or an I clock doesn't
> mean the parent which supplies it is active. It will open up a gate of
> sorts and raise a clock request.  If that parent source is running then
> it can propagate into the functional block.
> 
> I don't think OMAP1 does it quite like this.  The source clock doesn't
> have the module level gating.  
> 
> Seems like in theory you and run some modules with their I clock off and
> the F clock on, though I doubt you would do it much in practice.  You
> can just set your I clock to auto idle and it will raise and lower its
> clock request automatically as needed, effectively doing the same.

OK, let's do it in two phases then. First I'll just get rid of the clock
numbers, then let's see if we can combine some clocks later on.

Tony

RE: omap clock.h question

[Woodruff, Richard]

> I believe he meant just to hide the clock number for mmc 1 or 2. But I
> guess we still need to have different naming for omap1 and omap2.

Like I was saying you could hide both the slot and the names.

 for(i=data.slot[slot].num_clks; i>0; i--)
 {
	ck = clk_get(data.slot.clk_name[i-1])
	if(ck != NULL)
	clk_enabl(ck);
 }

That way we don't care the name or how many.  It gets rid of some if
statements anyway.

Regards,
Richard W.

Re: omap clock.h question

[Tony Lindgren]

* Woodruff, Richard <r-woodruff2@ti.com> [060207 14:07]:
> > I believe he meant just to hide the clock number for mmc 1 or 2. But I
> > guess we still need to have different naming for omap1 and omap2.
> 
> Like I was saying you could hide both the slot and the names.
> 
>  for(i=data.slot[slot].num_clks; i>0; i--)
>  {
> 	ck = clk_get(data.slot.clk_name[i-1])
> 	if(ck != NULL)
> 	clk_enabl(ck);
>  }
> 
> That way we don't care the name or how many.  It gets rid of some if
> statements anyway.

But one of the clocks can be off more often than the other from PM point
of view.

Tony

omap clock.h question

[Brian Swetland]

I'm trying to get the MMC driver working on OMAP730 -- currently it
fails in probe because it can't obtain "mmc1_ck".  clocks.h has a
definition for this, but only for 1510/16xx/310.  OMAP730 appears to use
a different config register (PERSEUS_PCC_CONF) to enable this clock.

What's the correct way to support this?  Define another clock struct
with the same name, but setup for 730?  

Thanks,

Brian

Re: omap clock.h question

[Tony Lindgren]

* Brian Swetland <swetland@google.com> [060207 11:06]:
> 
> I'm trying to get the MMC driver working on OMAP730 -- currently it
> fails in probe because it can't obtain "mmc1_ck".  clocks.h has a
> definition for this, but only for 1510/16xx/310.  OMAP730 appears to use
> a different config register (PERSEUS_PCC_CONF) to enable this clock.
> 
> What's the correct way to support this?  Define another clock struct
> with the same name, but setup for 730?  

Yes, just add another clock for 730. BTW, the mmc driver is about to
change where you just request mmc_ick and mmc_fck on all omaps.

Tony

Re: omap clock.h question

[Brian Swetland]

[Tony Lindgren <tony@atomide.com>]
> * Brian Swetland <swetland@google.com> [060207 11:06]:
> > 
> > I'm trying to get the MMC driver working on OMAP730 -- currently it
> > fails in probe because it can't obtain "mmc1_ck".  clocks.h has a
> > definition for this, but only for 1510/16xx/310.  OMAP730 appears to use
> > a different config register (PERSEUS_PCC_CONF) to enable this clock.
> > 
> > What's the correct way to support this?  Define another clock struct
> > with the same name, but setup for 730?  
> 
> Yes, just add another clock for 730. BTW, the mmc driver is about to
> change where you just request mmc_ick and mmc_fck on all omaps.

The mach-omap1/clock.h has no reference to _ick or _fck clocks right
now.  This will be coming as part of the change?  

Brian

Re: omap clock.h question

[Tony Lindgren]

* Brian Swetland <swetland@google.com> [060207 13:10]:
> [Tony Lindgren <tony@atomide.com>]
> > * Brian Swetland <swetland@google.com> [060207 11:06]:
> > > 
> > > I'm trying to get the MMC driver working on OMAP730 -- currently it
> > > fails in probe because it can't obtain "mmc1_ck".  clocks.h has a
> > > definition for this, but only for 1510/16xx/310.  OMAP730 appears to use
> > > a different config register (PERSEUS_PCC_CONF) to enable this clock.
> > > 
> > > What's the correct way to support this?  Define another clock struct
> > > with the same name, but setup for 730?  
> > 
> > Yes, just add another clock for 730. BTW, the mmc driver is about to
> > change where you just request mmc_ick and mmc_fck on all omaps.
> 
> The mach-omap1/clock.h has no reference to _ick or _fck clocks right
> now.  This will be coming as part of the change?  

Oh yeah, just call it mmc_ck. It will change to figure out the mmc 1 or
2 clock based on the dev entry.

Tony