пн, 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. > 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. > It seems the tegra3 DTs have most of the PMIC regulators marked as > boot-on and always-on , so enabling the regulators early is the right > thing to do. Only essentials are added, thus they are marked this way. > > [...] > > > 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 > > pkt header 1 sent (0x10010) > > pkt header 2 sent (0x0) > > pkt header 3 sent (0xb0) > > pkt data sent (0x0) > > i2c_xfer: 2 messages > > i2c_xfer: chip=0x58, len=0x1 > > i2c_write_data: chip=0x58, len=0x1 > > write_data: 0xfb > This seems to be access to register 0xfb , i.e. something else ?
