On 9/10/24 11:05 AM, Svyatoslav Ryhel wrote:
пн, 9 вер. 2024 р. о 19:13 Marek Vasut <ma...@denx.de> пише:
On 8/20/24 9:08 AM, Svyatoslav Ryhel wrote:
пн, 19 серп. 2024 р. о 20:27 Marek Vasut <ma...@denx.de> пише:
On 8/1/24 2:28 AM, Marek Vasut wrote:
On 7/29/24 1:55 PM, Svyatoslav Ryhel wrote:
[...]
What is the problem you observe on tegra 3 ?
i2c line fails since it probes in spl with your patch, but it does not
relocate and then probes once more after relocation. Probe fails along
with all devices on same line.
Could it be that you either have to:
- Add DM_I2C to tegra 3 SPL
- Remove bootph-* from DT to remove the regulator node from SPL
- /delete-property/ regulator-always-on; and /delete-property/
regulator-boot-on; in -u-boot.dtsi to prevent the regulator from being
enabled in SPL ?
Obviously NO, you propose nonsense. Same dts is used for both stages.
DT source yes, DT blob likely no.
And I have to add hack-ish stuff just because you wanna introduce code
which causes known regressions.
I am trying to understand what problem there is on tegra 3, but it is
still not clear to me.
Is the problem somehow related to PMICs (?) being probed in SPL (?)
because they have regulators (?) which are marked as regulator-always-on
? If so, then this is correct behavior, and if this is not desired in
SPL, then you can remove this property from SPL DT in -u-boot.dtsi using
/delete-property/ .
[...]
"We must not probe things as we go. There might be other
dependencies not yet bound. It may also take some time. This is not
following driver model design, sorry.
So please think of a way to do this properly."
What is this quote about ? Where is this from ?
What is the problem with Tegra 3 and this patchset ?
Can you please explain that so this patchset can move forward ?
with your changes
U-Boot 2024.07-00696-ge217e2769db9-dirty (Aug 20 2024 - 09:55:29 +0300)
SoC: tegra114
Model: NVIDIA Tegra Note 7
Board: NVIDIA TegraTab
DRAM: 1 GiB
tegra_i2c_probe: called
i2c: controller bus 0 at 7000d000, speed 0: tegra_i2c_probe: exit
i2c_init_controller: speed=400000
i2c_init_controller: CLK_DIV_STD_FAST_MODE setting = 25
i2c_xfer: 2 messages
i2c_xfer: chip=0x58, len=0x1
i2c_write_data: chip=0x58, len=0x1
write_data: 0x37
pkt header 1 sent (0x10010)
pkt header 2 sent (0x0)
pkt header 3 sent (0x100b0)
pkt data sent (0x37)
tegra_i2c_write_data: Error (-1) !!!
i2c_write_data(): rc=-1
i2c_write: error sending
read error from device: bd26f8e0 register: 0x37!
This seems like the PMIC driver (palmas?) is trying to read register
0x37 PGOOD and the I2C transfer fails . Why does the I2C transfer fail ?
You are asking me? Because your patches break some important setup sequence.
PMIC model does not matter, all behave same way.
These regulator patches do not modify anything related to I2C and I
don't observe this kind of behavior on iMX8M or STM32 platforms, so I
suspect this is something specific to tegra.
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?
