Re: [PATCH] clk: samsung: Fix PLL35XX lock time

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

 



Tomasz,

On Wed, Oct 9, 2013 at 10:20 PM, Tomasz Figa <t.figa@xxxxxxxxxxx> wrote:
>> > I don't think this is right.  I believe that it needs to be passed in
>> > by the SoC.  On exynos5250 I see 250 in both the manual and in our
>> > code.  On exynos5420 manual I actually see 200 now.  I'm not actually
>> > sure where the 270 came from, now that I search for it.
>>
>> The manual I referred gives 250 for both 5250 and 5420 and thats why I
>> concluded on this fix. I will check other versions of the manual to see if
>> the value is changing.
>
> 270 is the value taken from Exynos 4412 User's Manual rev. 1.1.
>
> I believe we don't have to extend this to support per SoC value, because it
> should be always safe to take the value of SoC that requires the longest
> locking period. The differences are small enough to be insignificant, so there
> should be no practical performance penalty.

It's not _that_ small for something like APLL which can be changing
constantly in DVFS.

24MHz input clock, right?  ...and I see some P values of up to 6.

That means with 270 lock time is 67.5 us, right?
...and with 200 lock time is 50 us, right?

...so that's a 17.5 us difference by using the correct multiplier.
Overall DVFS switch time was measured recently at ~350us, so that
would give us a 5% speedup on DVFS switching.

We've had debates in-house in the past about how critical DVFS
switching time is.  In the past there have been some who have
advocated that it's very important, since it affects responsiveness
(how fast can you spin up when you suddenly have something to do).


Anyway, when it's something as simple as passing in a parameter to get
it right, it seems worth doing.

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




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux