Hello Stephen,
Am 29.07.2013 18:12, schrieb Stephen Warren:
On 05/04/2013 06:01 AM, Heiko Schocher wrote:
From: Simon Glasssjg@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