Clock Policy Goes Where?

Clock Policy Goes Where?

[Leo L. Schwab]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

.	I'm working on an implementation of the ARM clock API for the Freescale 
i.MX1 (which is very crufty right now and only works on Zodiacs so there's 
not much point in asking for it (unless you want to critique it; I could use 
the feedback)), and I find myself wondering where the default clock settings 
should come from.

	Looking at the clock API for the TI OMAP (arch/arm/mach-omap/clock.c), I 
see a table of available clock frequencies.  The init code finds the fastest 
one and sets it.  Then it clk_use()s three other clocks.  Doesn't that 
constitute a policy decision?  If so, where should this policy reside?

	The reason I ask is because my first crack at a clock driver implementation 
had the clocks being disabled/spun down until a client showed up.  This 
seems fine until you discover that the serial console gets initialized *way* 
before the clock and serial drivers; that the UART clocks are effectively 
already in use, which in turn depend on PERCLK1, which in turn depends on 
SYSPLL.  OTOH, if you don't have the serial console configured, then you 
don't have to worry about any of that.

	All of which is a long-winded way of observing that the initial state of 
the clocks appears to this novice's eye to be policy-dependent.  In the case 
of the serial console, the policy is encoded in the kernel config and can be 
easily, if hackishly, handled.  Handling of other policies is less obvious 
(sticking them all in the kernel config seems wrong).  I would prefer to do 
The Right Thing here.  Can anyone offer insights on this issue?

					Schwab

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Clock Policy Goes Where?

[tony]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]

Hi,

* Leo L. Schwab <lschwab@tapwave.com> [050623 13:58]:
> .	I'm working on an implementation of the ARM clock API for the 
> Freescale i.MX1 (which is very crufty right now and only works on Zodiacs 
> so there's not much point in asking for it (unless you want to critique it; 
> I could use the feedback)), and I find myself wondering where the default 
> clock settings should come from.
> 
> 	Looking at the clock API for the TI OMAP 
> 	(arch/arm/mach-omap/clock.c), I see a table of available clock frequencies. 
> The init code finds the fastest one and sets it.  Then it clk_use()s three 
> other clocks.  Doesn't that constitute a policy decision?  If so, where 
> should this policy reside?

Well since they're needed for the system to work, I'd say low-level init
of clock.c is where they need to be. Otherwise you cannot use clock.c :)

> 	The reason I ask is because my first crack at a clock driver 
> 	implementation had the clocks being disabled/spun down until a client 
> showed up.  This seems fine until you discover that the serial console gets 
> initialized *way* before the clock and serial drivers; that the UART clocks 
> are effectively already in use, which in turn depend on PERCLK1, which in 
> turn depends on SYSPLL.  OTOH, if you don't have the serial console 
> configured, then you don't have to worry about any of that.

You should call clock init early from board init. Serial port may or may
not be on from the bootloader, and the serial console registers with
clock.c later on during the init.

> 	All of which is a long-winded way of observing that the initial 
> 	state of the clocks appears to this novice's eye to be policy-dependent.  
> In the case of the serial console, the policy is encoded in the kernel 
> config and can be easily, if hackishly, handled.  Handling of other 
> policies is less obvious (sticking them all in the kernel config seems 
> wrong).  I would prefer to do The Right Thing here.  Can anyone offer 
> insights on this issue?

You probably have all the required clocks on already from bootloader. If
they need to be on all the time, I guess you could just leave those clocks
out of the clock.c. But depending on the hardware you may also want to be
able to idle them.

Tony

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Clock Policy Goes Where?

[Leo L. Schwab]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

tony@atomide.com wrote:
> Well since they're needed for the system to work, I'd say low-level init
> of clock.c is where they need to be. Otherwise you cannot use clock.c :)
>
	Ah.  I was using arch_initcall() to setup the clocks, which is far too late 
in the boot sequence.  Looking more closely at the OMAP support, I see their 
clocks are initialized as part of the map_io vector in the ARM machine_desc 
structure.  I'll go fix that.

> You probably have all the required clocks on already from bootloader. If
> they need to be on all the time, I guess you could just leave those clocks
> out of the clock.c. But depending on the hardware you may also want to be
> able to idle them.
>
	The Zodiac only has a 1500mAH battery in it, which we want to last as long 
as possible between visits to the cradle, especially when we're, 
"suspended."  So we need to be able to idle/spin down all unused clocks -- 
essentially turn off everything that's not actually in use.

	Thank you very much for taking the time to respond.

					Schwab

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]