Hi Tom,
On Wed, 11 Sept 2024 at 10:25, Tom Rini trini@konsulko.com wrote:
On Wed, Sep 11, 2024 at 02:12:12PM +0300, Svyatoslav Ryhel wrote:
ср, 11 вер. 2024 р. о 14:01 Marek Vasut marex@denx.de пише:
On 9/11/24 7:57 AM, Svyatoslav Ryhel wrote:
[...]
> You did mention something regarding I2C/PMIC driver probe timing, but it > seems the I2C driver and PMIC drivers probe roughly around the same time > in both pass and fail cases ?
Yes, here I agree that they both probe and probe passes, but I assume timing of i2c call is critical and there may be some dependency which is not ready.
My guess would be pinmux or clock, maybe the i2c controller is marked as bootph-* in DT and its pinmux/clock is not? Maybe the i2c on tegra works by sheer coincidence right now? Can you have a look?
Power i2c line (one that hosts PMIC) is configured extremely early in SPL since it is needed for cpu and core voltage setup so even if, as you say, tegra works by sheer coincidence, specifically this i2c line should work non the less, since it has all its pre-requisites (clock and pinmux) configured on early stage.
Is it possible that this configuration is somehow reset or reconfigured from DT early on in U-Boot proper ?
No
Do you have serial console output in board_f.c time in U-Boot proper , possibly using DEUBG_UART , to check if there might be some prior failing I2C transfer at that board_f.c time ?
Haven't spotted anything weird there.
As I have told, I was not able to determine exact reason why this happens, it should not and yet it does. This is why I have abandoned my attempt to implement same changes you are currently proposing.
If tegra has a problem, it should be fixed on tegra side and not block core plumbing. I am not seeing the problem on stm32 or imx systems, so I am banking toward tegra-specific issue.
And yet you are pushing tegra breaking stuff. I will insist on reverting this is it passes.
Are you able to debug this ?
No, I am not able find exact cuse of this behavior.
How do you propose we resolve this then, Svyatoslav? I threw this patch at some TI platforms as well and they're all fine. Are you unable to get some early debuging information out like Marek was asking? Thanks.
At this point I would like to have an optional Kconfig to enable the always-on regulators in the init sequence, perhaps as part of initf_dm(). It should not be in DM core, sorry.
-- Tom