[U-Boot] [PATCH v2 2/3] Tegra114: fdt: Update DT files with I2C info for T114/Dalmore

Tom Warren twarren.nvidia at gmail.com
Thu Feb 7 17:14:24 CET 2013


Stephen,

On Wed, Feb 6, 2013 at 5:00 PM, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 02/06/2013 04:26 PM, Tom Warren wrote:
>> Note that T114 does not have a separate/different DVC (power I2C)
>> controller like T20 - all 5 I2C controllers are identical, but
>> I2C5 is used to designate the controller intended for power
>> control (PWR_I2C in the schematics).
>
>> diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
>
>> +     tegra_car: clock at 60006000 {
>> +             compatible = "nvidia,tegra114-car, nvidia,tegra30-car";
>
> Only the Tegra114 value should be listed here; the presence of the
> Tegra30 value in the upstream kernel is a mistake that will be fixed as
> part of the Tegra114 clock driver patches.

OK. But this is why I think hewing to the Linux DT files, while
laudable, is a time sink. Though since T114 is so new & still settling
in, I guess some churn is expected.

>
>> +     i2c at 7000c000 {
>> +             compatible = "nvidia,tegra114-i2c", "nvidia,tegra20-i2c";
>
> Same here; only include the Tegra114 value since the HW isn't 100%
> compatible with the Tegra20 HW.

What does the 'compatible' designater mean, exactly? Does it require
100% identical HW? Compatible, in a SW/HW sense, to me means that
newer SW will work with older/similar (but not exactly the same) HW,
etc.

Tegra U-Boot uses the "tegra20-i2c" name to find and load the I2C
driver. I could add a new entry in the compat-names table for
tegra114-i2c, but I still don't think there's enough difference
between T20/T30 and T114 I2C to justify a whole new I2C driver - so
far, it's just one register with a new clk divider that has to be
taken in consideration when programming the clock source divider.

I could do as the driver does for T20, where there is a separate DVC
controller, plus 3 normal I2C controllers. I could 'find_aliases' for
the tegrat114-i2c controller first,  process its nodes, and return. If
no tegrat114-i2c exists, the driver would continue on to look for
tegra20-i2c/tegra20-dvc controller info as it does now.  It'd still be
one tegra_i2c.c driver, with a flag in the i2c_bus struct telling me
if I found T114 I2C HW (i2c_bus->single_clk, etc.) and I could then do
the new clock divider dance based on that flag. How does that sound?
>
>> diff --git a/board/nvidia/dts/tegra114-dalmore.dts b/board/nvidia/dts/tegra114-dalmore.dts
>
>> +     i2c at 7000d000 {
>> +             status = "okay";
>> +             clock-frequency = <100000>;
>> +     };
>
> According to our downstream Linux kernel, that I2C controller can run up
> to 400KHz on this board.
>
But it also runs @ 100KHz just fine, too. Do we need to run at the
fastest clock? That's the DVC (PWR_I2C) controller, which U-Boot does
little to nothing with right now.

I can set it to 400KHz, but what are the advantages/justifications? Is
anything wrong with leaving it at 100KHz?

Tom


More information about the U-Boot mailing list