Re: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Sripathy, Vishwanath" <vishwanath.bs@xxxxxx> writes:

> Kevin,
>
>> -----Original Message-----
>> From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-
>> owner@xxxxxxxxxxxxxxx] On Behalf Of Kevin Hilman
>> Sent: Tuesday, December 22, 2009 9:26 PM
>> To: Reddy, Teerth
>> Cc: Dasgupta, Romit; linux-omap@xxxxxxxxxxxxxxx
>> Subject: Re: [PATCH] OMAP3: PM: Dynamic calculation of SDRC clock stabilization
>> delay
>> 
>> "Reddy, Teerth" <teerth@xxxxxx> writes:
>> 
>> > Kevin,
>> >
>> >>
>> >> Here's an uncompiled, untested version of 'measure_sram_delay' using
>> >> the DM Timer API:
>> >>
>> >> unsigned int measure_sram_delay(unsigned int loop)
>> >> {
>> >>     unsigned long start, end, flags;
>> >>     void (*_omap3_sram_delay)(unsigned long);
>> >>     _omap3_sram_delay = omap_sram_push(__sram_wait_delay,
>> >>                                   __sram_wait_delay_sz);
>> >>
>> >>     gpt = omap_dm_timer_request();
>> >>     if (!gpt)
>> >>           pr_err("foo");
>> >>     omap_dm_timer_set_source(gpt, OMAP_TIMER_SRC_SYS_CLK);
>> >>     omap_dm_timer_set_load_start(gptimer, 0, 0);
>> >>
>> >>         local_irq_save(flags);
>> >>         start = omap_dm_timer_read_counter(gpt);
>> >>     _omap3_sram_delay(loop);
>> >>         end = omap_dm_timer_read_counter(gpt);
>> >>         local_irq_restore(flags);
>> >>
>> >>     omap_dm_timer_stop(gpt);
>> >>         omap_dm_timer_free(gpt);
>> >>
>> >>     return end - start;
>> >> }
>> >>
>> >
>> > I see one shortcoming with this approach. The DVFS happens even
>> > before the gp timers are initialized, while the kernel boots.
>> 
>> This is a bug.  DVFS should be prevented until system is initialized.
>> 
>
>
> I think DVFS is triggered when CPU Freq driver gets
> initialized. Depending on the default governor cpufreq tries to
> scale the frequency which triggers DVFS.

Correct.

> So do you mean to say that cpufreq initialization should be
> prevented till GPTimer is initialized?

Basically, yes.  

You need to calibrate the delay before you can do DVFS, so what I mean
is that you need to request your GPtimer, and do your delay
measurements using the GPtimer before you enable DVFS (register
CPUfreq.)

Also, please be sure to stop/free the GPtimer when done, otherwise
it will prevent idle.

Kevin





--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux