handling clock nodes with both parent and divider selection

handling clock nodes with both parent and divider selection

[Rajendra Nayak]

Hi Paul,

On OMAP4, some aux clk nodes (part of SCRM) have control
for both parent and divider selection. Is there a way in the
current clock framework for OMAP's to handle this?

Regards,
Rajendra

Re: handling clock nodes with both parent and divider selection

[Paul Walmsley]

On Mon, 31 Jan 2011, Rajendra Nayak wrote:

> Hi Paul,
> 
> On OMAP4, some aux clk nodes (part of SCRM) have control
> for both parent and divider selection. Is there a way in the
> current clock framework for OMAP's to handle this?

For these clocks on OMAP3, we split the clock into two struct clks.  For 
example, clkout2_src_ck handles source selection, and sys_clkout2 handles 
rate selection.  clock3xxx_data.c has the details.

At some point in the future, hopefully we'll be able to split all of the 
multiplexers and dividers into their own struct clks, or struct omap_clks, 
or something, so we don't have to implement these hacks.  As I understand 
it, that would be closer to the actual hardware, anyway.  The right time 
to do that would be after the clktype conversion...


- Paul

RE: handling clock nodes with both parent and divider selection

[Rajendra Nayak]

Hi Paul,

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, February 01, 2011 4:43 AM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: Re: handling clock nodes with both parent and divider selection
>
> On Mon, 31 Jan 2011, Rajendra Nayak wrote:
>
> > Hi Paul,
> >
> > On OMAP4, some aux clk nodes (part of SCRM) have control
> > for both parent and divider selection. Is there a way in the
> > current clock framework for OMAP's to handle this?
>
> For these clocks on OMAP3, we split the clock into two struct clks.  For
> example, clkout2_src_ck handles source selection, and sys_clkout2
handles
> rate selection.  clock3xxx_data.c has the details.

Ok, that's pretty much how I was thinking of handling it too. Did'nt know
this is already done for a few nodes on OMAP3.
The only downside of this approach, I feel, is that the users of these
clks
(aux clks on omap4) would have to deal with 2 different nodes, one for
source selection and another for divider.

>
> At some point in the future, hopefully we'll be able to split all of the
> multiplexers and dividers into their own struct clks, or struct
omap_clks,
> or something, so we don't have to implement these hacks.  As I
understand
> it, that would be closer to the actual hardware, anyway.  The right time
> to do that would be after the clktype conversion...

Ok, I am not completely sure what clktype conversion means, but will wait
for
it.

Regards,
Rajendra

>
>
> - Paul

RE: handling clock nodes with both parent and divider selection

[Paul Walmsley]

On Tue, 1 Feb 2011, Rajendra Nayak wrote:

> > -----Original Message-----
> > From: Paul Walmsley [mailto:paul@pwsan.com]
> > Sent: Tuesday, February 01, 2011 4:43 AM
>
> > At some point in the future, hopefully we'll be able to split all of the
> > multiplexers and dividers into their own struct clks, or struct
> omap_clks,
> > or something, so we don't have to implement these hacks.  As I
> understand
> > it, that would be closer to the actual hardware, anyway.  The right time
> > to do that would be after the clktype conversion...
> 
> Ok, I am not completely sure what clktype conversion means, but will 
> wait for it.

I'd suggest not waiting for it, but implementing something now, similar to 
OMAP3, if it won't be too big of a hack.


- Paul

RE: handling clock nodes with both parent and divider selection

[Rajendra Nayak]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Tuesday, February 01, 2011 10:03 PM
> To: Rajendra Nayak
> Cc: linux-omap@vger.kernel.org
> Subject: RE: handling clock nodes with both parent and divider selection
>
> On Tue, 1 Feb 2011, Rajendra Nayak wrote:
>
> > > -----Original Message-----
> > > From: Paul Walmsley [mailto:paul@pwsan.com]
> > > Sent: Tuesday, February 01, 2011 4:43 AM
> >
> > > At some point in the future, hopefully we'll be able to split all of
the
> > > multiplexers and dividers into their own struct clks, or struct
> > omap_clks,
> > > or something, so we don't have to implement these hacks.  As I
> > understand
> > > it, that would be closer to the actual hardware, anyway.  The right
time
> > > to do that would be after the clktype conversion...
> >
> > Ok, I am not completely sure what clktype conversion means, but will
> > wait for it.
>
> I'd suggest not waiting for it, but implementing something now, similar
to
> OMAP3, if it won't be too big of a hack.

Yup, I will. I just meant to say will wait for your patches to see what
clktype conversion meant, since I did not know of it.
Did not mean to say will wait for it to add the divider control
for aux clks :)

>
>
> - Paul