[Letux-kernel] Idle-osc-off questions

[H. Nikolaus Schaller]

> Am 27.02.2018 um 13:05 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> On Tue, 27 Feb 2018 09:01:41 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 26.02.2018 um 23:22 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> Hi,
>>> 
>>> I am stumbling across another thing I do not understand:
>>> 
>>> What does this idle-osc-thing really?
>>> 
>>> If I understand the code correctly,
>>>               .compatible = "ti,twl4030-power-idle-osc-off",
>> 
>> Well as usual documentation is a little unspecific:
>> 
>> https://patchwork.kernel.org/patch/4250851/
>> 
>> "does not work on all boards depending on how the external oscillator is wired"
>> instead of telling how it should be wired to make it work...
>> 
>>> 
>>> enables this part of the sleep script (in twl4030-power.c)
>>>       TWL_REMAP_OFF(RES_CLKEN, DEV_GRP_P1 | DEV_GRP_P3, 3, 2),
>>> 
>>> 
>>> which should control the CLKEN pin to power off (tps65950 TRM p. 238)
>>> the oscillator.
>> 
>> Yes, this is my understanding that it should turn off the oscillator.
>> 
>>> But CLKEN is not connected.
>>> 
>>> Then there is the comment in the source
>>> /* Disable 32 KiHz oscillator during idle */
>>> 
>>> which does not make sense. Disabling a 32khz osc?
>>> Especially since rtc wakeup works.
>>> 
>>> Looking at the changes in the schematic, I see that the enable
>>> pin of that 26Mhz osc is connected to vpll1. According to this line,
>>> TWL_REMAP_OFF(RES_VPLL1, DEV_GRP_P1, 3, 1),
>>> 
>>> It seems to be switched off in suspend. Switching a 26Mhz osc off when
>>> it is not
>>> needed seems to be sane.
>>> But that rises even more questions.
>>> 
>>> VPLL1 out is just connected to a capacitor and the oscillator enable
>>> pin. But how is that capacitor discharged? Across leakages in the
>>> oscillator and the internal regulator feedback loop probably. Well,
>>> if we have discharges around 1uA, then it will go down after some time.
>> 
>> AFAIR this setup was inspired/recommended by the Neo900 schematics.
>> 
>> So probably we have a board where idle-osc-off does not work as expected?
>> 
> probably it is not needed for powering of the oscillator.
> I will probably try it out on the letux3704 (no modem!)
> Lets have a look what happens.
> 
>>> 
>>> But the idle-osc-off thing has influences.
>>> - some mA lower suspend currents
>>> - strange behaviour on idle currents
>>> -> sometimes even 6mA below the currents in the same state
>>>    as without idle-osc-off, sometimes up to 20mA higher,
>>>    generally not worse when everything is loaded than without
>>>    that osc-off thing.
>>> - strange behaviour when suspending while charging
>>>  -> immediate wakeup with strange errors.
>>> 
>>> The behaviour feels like floating pins
>> 
>> Well, does it also gate the HFCLK out clock from the twl4030 to the omap3?
>> Then some subsystems (even the audio part inside the twl4030) may be turned
>> completely off.
>> 
> I think HFCLK out is a separate issue. Not influenced by idle,osc-off.
> Interesting is what happens when there is no clock in and HFCLK out
> still enabled. If the input is floating maybe we have some random
> oscillations.
> 
>> And there may be floating pins. If I remember correctly, Neil did suspect
>> the ULPI connection for the modem not being pulled down during suspend.
>> 
> I will check, there are patches around to remap that to gpio
> on suspend.
> 
> 
>> 
>> 
>> So I read this that the canonical way would be to use CLKEN (idle-off-code)
>> but using VPLL1 is equally good. And VPLL1 has an internal power consumer
>> which quickly discharges the capacitor.
>> 
>> Hope this gives some enlightenment.
> 
> I guess the wiring of VPLL1 seems not to be a problem.
> 
> But there are now a lot of questins. I think I will even check some
> macro definitions, maybe there is something mixed up. I simply do not
> understand why CLKEN state should influence anything.
> 
> Ok, I am swimming in an ocean of open questions...

Maybe Tony Lindgren can trow a life ring.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180227/48bd9405/attachment.asc>