[PATCH 1/4] power: regulator: Trigger probe of regulators which are always-on or boot-on

[Marek Vasut]

On 9/10/24 11:05 AM, Svyatoslav Ryhel wrote:
> пн, 9 вер. 2024 р. о 19:13 Marek Vasut <marex at denx.de> пише:
>>
>> On 8/20/24 9:08 AM, Svyatoslav Ryhel wrote:
>>> пн, 19 серп. 2024 р. о 20:27 Marek Vasut <marex at 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?