[U-Boot] [PATCH v2 1/7] Tegra30: Add arch-tegra30 include files

[Tom Warren]

Stephen,

On Mon, Dec 3, 2012 at 5:22 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 12/03/2012 04:45 PM, Tom Warren wrote:
>> Common Tegra files are in arch-tegra, shared between T20 and T30.
>> Tegra30-specific headers are in arch-tegra30. Note that some of
>> these will be filled in as more T30 support is added (drivers,
>> WB/LP0 support, etc.). A couple of Tegra20 files were changed
>> to support common headers in arch-tegra, also.
>
>> diff --git a/arch/arm/include/asm/arch-tegra/tegra.h b/arch/arm/include/asm/arch-tegra/tegra.h
>
>> +/*
>> + * These are used to distinguish SOC types for setting up clocks. Mostly
>> + * we can tell the clocking required by looking at the SOC sku_id, but
>> + * for T30 it is a user option as to whether to run PLLP in fast or slow
>> + * mode, so we have two options there.
>> + */
>>  enum {
>>       TEGRA_SOC_T20,
>>       TEGRA_SOC_T25,
>> +     TEGRA_SOC_T30,
>> +     TEGRA_SOC_T30_408MHZ,   /* A T30 with faster PLLP */
>> +     TEGRA_SOC2_SLOW,        /* T2x needs to run at slow clock initially */
>>
>> -     TEGRA_SOC_COUNT,
>> +     TEGRA_SOC_CNT,
>>       TEGRA_SOC_UNKNOWN       = -1,
>>  };
>
> Can you remind me why TEGRA_SOC_T30_408MHZ exists; isn't it a SW thing
> whereas this enum is meant to be identifying the HW?

It exists in our internal repo, and I don't want to remove it until
I've brought our upstream version fully up-to-speed @ 408MHz. This
initial patchset runs T30 PLLP @ 216MHz, with an option to upgrade to
408MHz at runtime.  Once this baseline T30 support is in, I'll look
into making PLLP 408MHz from the get-go.

>
>> diff --git a/arch/arm/include/asm/arch-tegra30/funcmux.h b/arch/arm/include/asm/arch-tegra30/funcmux.h
>
>> +/* Configs supported by the func mux */
>> +enum {
>> +     FUNCMUX_DEFAULT = 0,    /* default config */
>> +
>> +     /* UART configs */
>> +     FUNCMUX_UART1_ULPI = 0,
>
> funcmux isn't going to be remotely useful for Tegra30. There are
> something like 460 possible ways of muxing out (IIRC) just a 4-pin UART
> A on Tegra30. That's why when I was defining the proposed ODMDATA2
> representation of UART pinmux for the Tegra30 BCT, I didn't have a
> single enum covering the entire UART configuration, but rather a 4-bit
> field per signal (RXD, TXD, RTS, CTS) that indicated which of the
> possible pins to route it to.
>
> Still, I guess having the initial port use funcmux is fine since we only
> need to support 1 option for now. We'll hopefully just convert it to use
> the BCT ODMDATA2 format rather quickly.

Yeah, I wanted to get this in, then let your ODMDATA2 change migrate
in, and then convert over to using that for UART init for T30 too.

>
> A similar comment will probably apply to any other peripheral on Tegra30.