handling clock nodes with both parent and divider selection
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
Quoted 5 lines · 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?
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
Hi Paul,
Quoted 9 lines
-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, February 01, 2011 4:43 AM
To: Rajendra Nayak
Cc: [email protected]
Subject: Re: handling clock nodes with both parent and divider selectionOn Mon, 31 Jan 2011, Rajendra Nayak wrote:
Quoted 8 lines
Quoted 5 lines
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_ckhandles source selection, andsys_clkout2
handles
Quoted 1 line
rate selection.
clock3xxx_data.chas 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.
Quoted 3 lines
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,
Quoted 1 line
or something, so we don't have to implement these hacks. As I
understand
Quoted 2 lines
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
Quoted 3 lines
- Paul
Quoted 6 lines · Rajendra Nayak
Quoted 6 lines
-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, February 01, 2011 4:43 AMAt 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
Quoted 8 lines
omap_clks,Quoted 1 line
or something, so we don't have to implement these hacks. As I
understand
Quoted 2 lines
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
Quoted 7 lines
-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, February 01, 2011 10:03 PM
To: Rajendra Nayak
Cc: [email protected]
Subject: RE: handling clock nodes with both parent and divider selection
Quoted 7 lines
Quoted 5 lines · Rajendra Nayak
Quoted 5 lines
-----Original Message-----
From: Paul Walmsley [mailto:[email protected]]
Sent: Tuesday, February 01, 2011 4:43 AMAt some point in the future, hopefully we'll be able to split all of
the
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
multiplexers and dividers into their own struct clks, or struct
omap_clks,Quoted 1 line
or something, so we don't have to implement these hacks. As I
understand
Quoted 1 line
it, that would be closer to the actual hardware, anyway. The right
time
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
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
Quoted 1 line
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 :)
Quoted 3 lines
- Paul