From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 30 Jul 2013 06:28:45 +0200 Subject: [U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework In-Reply-To: <51F6946F.8010500@wwwdotorg.org> References: <1367668903-29653-1-git-send-email-hs@denx.de> <1367668903-29653-9-git-send-email-hs@denx.de> <51F6946F.8010500@wwwdotorg.org> Message-ID: <51F740FD.4080505@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.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 >> >> 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