[U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Heiko Schocher <hs@denx.de>]

Hello Stephen,

Am 29.07.2013 18:12, schrieb Stephen Warren:
> On 05/04/2013 06:01 AM, Heiko Schocher wrote:
>> From: Simon Glass<sjg@chromium.org>
>>
>> This enables CONFIG_SYS_I2C on Tegra, updating existing boards and the Tegra
>> i2c driver to support this.
>
> Heiko, the latest U-Boot tree hangs during boot on Tegra, and "git

:-(

Could you enable debug printf?

> bisect" points at this patch. Olof reported the issue to me.

Thanks!

> Can you take a look at the code and see what might be wrong? Thanks.

Yep.

> I suspect some kind of initialization ordering issue, since the boot
> messages are:
>
> -----
> U-Boot SPL 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37)
> U-Boot 2013.07-rc3-00038-g880540d (Jul 29 2013 - 10:04:37)
>
> TEGRA30
> Board: NVIDIA Beaver
> I2C:   Caller requested bad clock: periph=-49, parent=2
> -----
>
> ... and that "bad clock" message implies to me that the I2C driver is
> initializing before it has parsed the correct clock ID out of device tree.

Hmm... looking in the patch ... I can see nothing which changes
some initializing order ...

@Simon: Do you have an idea?

just found some wrong settings for tegra30:

In include/configs/tegra30-common.h:
/* Total I2C ports on Tegra30 */
#define TEGRA_I2C_NUM_CONTROLLERS       5

README says:
                - drivers/i2c/tegra_i2c.c:
                 - activate this driver with CONFIG_SYS_I2C_TEGRA
                 - This driver adds 4 i2c buses with a fix speed from
                   100000 and the slave addr 0!

end yes, in the i2c driver are only 4 ports activated ... this
should be changed ... but I think, this has nothing to do with
your problem ... but try to add in the i2c driver one more i2c adapter
for the case TEGRA_I2C_NUM_CONTROLLERS > 4

> Some later commit causes the hang to happen right after printing "I2C:",
> without printing the "bad clock" message. I didn't investigate that,
> since I'm assuming the root-cause is the same. Most likely some later
> commit causes the uninitialized data to be a valid clock, yet not the
> actual I2C clock, so the I2C clock still isn't turned on, and touching
> HW (i.e. reading/writing the I2C registers) without a running clock on
> Tegra caused hard hangs.

digging deeper, the above "bad clock" message

is a result from calling this function from the i2c driver:
./drivers/i2c/tegra_i2c.c:
static void i2c_init_controller(struct i2c_bus *i2c_bus)
{
         /*
          * Use PLLP - DP-04508-001_v06 datasheet indicates a divisor of 8
          * here, in section 23.3.1, but in fact we seem to need a factor of
          * 16 to get the right frequency.
          */
         clock_start_periph_pll(i2c_bus->periph_id, CLOCK_ID_PERIPH,
                 i2c_bus->speed * 2 * 8);

Please enable debug printfs and look from where i2c_init_controller()
is called. You should see the following debug printf if it go the right
way (Just reading code, I have no HW ...)

process_nodes():
                 debug("%s: controller bus %d at %p, periph_id %d, speed %d: ",
                       is_dvc ? "dvc" : "i2c", i, i2c_bus->regs,
                       i2c_bus->periph_id, i2c_bus->speed);

called from i2c_init_board in this driver.

This should be called from drivers/i2c/i2c_core.c i2c_init_all()
called from arch/arm/lib/board.c init_func_i2c()

I think i2c_bus->periph_id ("periph=-49") is not setup right ... do
you have the correct dt?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany