Re: [PATCH v1] ARM: tegra: Fix sd4 regulator in Jetson TK1 device tree

[Stephen Warren <swarren@wwwdotorg.org>]

On 10/01/2014 11:13 AM, Vidya Sagar wrote:
>
>
>> -----Original Message-----
>> From: Stephen Warren [mailto:swarren@wwwdotorg.org]
>> Sent: Monday, September 29, 2014 9:15 PM
>> To: Vidya Sagar
>> Cc: thierry.reding@gmail.com; Laxman Dewangan; Krishna Thota; linux-
>> tegra@vger.kernel.org; linux@arm.linux.org.uk; linux-
>> kernel@vger.kernel.org
>> Subject: Re: [PATCH v1] ARM: tegra: Fix sd4 regulator in Jetson TK1 device
>> tree
>>
>> On 09/29/2014 04:25 AM, Vidya Sagar wrote:
>>>
>>>> -----Original Message-----
>>>> From: Stephen Warren [mailto:swarren@wwwdotorg.org]
>>>> Sent: Tuesday, September 23, 2014 12:36 AM
>>>> To: Vidya Sagar
>>>> Cc: thierry.reding@gmail.com; Laxman Dewangan; Krishna Thota; linux-
>>>> tegra@vger.kernel.org; linux@arm.linux.org.uk; linux-
>>>> kernel@vger.kernel.org
>>>> Subject: Re: [PATCH v1] ARM: tegra: Fix sd4 regulator in Jetson TK1
>>>> device tree
>>>>
>>>> On 09/22/2014 11:57 AM, Vidya Sagar wrote:
>>>>> sd4 is an always on regulator which is turned on at boot time.
>>>>> It is externally controller through gpio. This change reflects the
>>>>> same in Jetson TK1 device tree
>>>>
>>>> In the schematics, the "Power Sequencing" timing diagram says "S/W
>>>> controlled" for SD4/+1.05V_RUN. I also don't see an "ENABLE1" pin on
>>>> the AS3722, which would be required for ...
>>
>> Can you please comment on this aspect of the issue?
>>
>>>>> +					ams,ext-control = <1>;
>>>>
>>>> ... to be valid.
>>>>
>>>> What's the source of information behind this change?
>>>>
>>>> What symptoms does this patch correct?
>>>
>>> I'm seeing one issue when I add support for PCIe suspend/resume
>> functionality.
>>> The issue is that, when regulator_bulk_diable() is called, disabling one of
>> the power rails (which is deriving its voltage from SD4) of PCIe is failing.
>>> The reason being, I2C controller is getting power gated
>>
>> Why is the fix being applied to SD4 if the issue is with a power rail derived
>> from SD4? Shouldn't any fix be applied directly to the problematic rail rather
>> than some parent rail?
>>
>> Since the I2C controller is part of the SoC and we don't have power domain
>> support yet, the only way the I2C controller can get power gated is when the
>> SoC as a whole is turned off.
>>
>>   > before power rail disable is called.
>>
>> ... so without making SD4 dependant on ext-control, since no SW can be
>> running at this point, the only way SD4 could get turned off is that the PMIC
>> turns it off itself at the appropriate point in the system power sequence
>> based on its OTP programming, or the board HW is already set up to turn off
>> SD4 at the appropriate time somehow. Is that not happening?
>> That would imply incorrect PMIC programming wouldn't it?
>>
>
> After some debugging, found that the I2C driver's suspend is getting called before the suspend
> of PCIe is called (BTW, PCie has suspend_noirq..!) Hence, when PCIe driver wants to disable regulators
> it fails because of I2C write failure, which is expected given I2C is already suspended.

Ah. It sounds like the PCIe driver should have a regular suspend 
function not a suspend_noirq function then. It's certainly expected that 
resources behind an I2C bus (i.e. most regulators) can't be manipulated 
in a suspend_noirq function.

> Hence, SD4 is made dependent on ENABLE1 input which is the sleep signal from Tegra.
>
>>> Hence SD4 is made dependent on ENABLE1, which is nothing but the deep
>>> sleep signal coming from Tegra, So eventually, SD4 will be powered off
>> when system enters into deep-sleep state.
>>
>> This sounds like a workaround that happens to make the system do what you
>> want rather than a root-cause fix.
>>
>>> Source of information is from downstream kernel
>>
>> We need to use HW schematics and other primary data to determine the
>> correct approach.