ср, 11 вер. 2024 р. о 14:01 Marek Vasut <[email protected]> пише: > > 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.
