From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Fri, 24 Jan 2014 10:26:07 -0700
Subject: [U-Boot] [PATCH V2] ARM: tegra: don't exceed AVP limits when
 configuring PLLP
In-Reply-To: <20140124141353.GF25720@ulmo.nvidia.com>
References: <1390503493-32180-1-git-send-email-swarren@wwwdotorg.org>
	<20140124141353.GF25720@ulmo.nvidia.com>
Message-ID: <52E2A22F.4040408@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 01/24/2014 07:13 AM, Thierry Reding wrote:
> On Thu, Jan 23, 2014 at 11:58:13AM -0700, Stephen Warren wrote:
> [...]
>> diff --git a/arch/arm/cpu/tegra-common/clock.c b/arch/arm/cpu/tegra-common/clock.c
> [...]
>> @@ -575,3 +575,91 @@ void clock_init(void)
>>  	/* Do any special system timer/TSC setup */
>>  	arch_timer_init();
>>  }
>> +
>> +static void set_avp_clock_to(u32 src)
> 
> Perhaps a better name would be "set_avp_clock_source()"? _to had me
> confused at first because I assumed it would be setting a frequency.

Yes, that name is better.

>> +void tegra30_or_later_adjust_pllp(void)
> 
> I would've called this simply tegra30_adjust_pllp(), where it's implied
> that when you call tegra30_*() from code targetted at later generations
> these would be compatible with Tegra30.
> 
> But if you'd rather make it implicit that's fine too.

I wondered about that, and thought it'd be odd for e.g. Tegra114 clock
code to be calling Tegra30 functions. That said, if we start encoding
into function names a complete description of which chips they support,
we'll have very long function names, so I guess renaming it makes sense.
I'll post V3.