Hi Heiko,
On Mon, Jul 29, 2013 at 10:28 PM, Heiko Schocher <h...@denx.de> wrote:
> Hello Stephen,
>
> Am 29.07.2013 18:12, schrieb Stephen Warren:
>
> On 05/04/2013 06:01 AM, Heiko Schocher wrote:
>>
>>> From: Simon Glass<s...@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?
I am not sure what is wrong here - Stephen if you have a board and can
debug please do, otherwise I might be able to dig one out.
49 looks to be PERIPH_ID_TVO.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
