From: tony@atomide•com (Tony Lindgren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller
Date: Tue, 19 May 2015 07:55:26 -0700 [thread overview]
Message-ID: <20150519145526.GO10274@atomide.com> (raw)
In-Reply-To: <CAALWOA-OwUuAbc7Wd_SV-14mVbOCVWvKwKgb3eOjVGEery28og@mail.gmail.com>
* Matthijs van Duin <matthijsvanduin@gmail•com> [150519 00:27]:
> On 18 May 2015 at 17:21, Tony Lindgren <tony@atomide•com> wrote:
> > If some of these depend on the SoC revision and cannot be detected
> > based on the RTC driver revision register, that information should
> > be be passed to the RTC driver in platform data.
>
> The SoC revision is easy enough to check via the control module as
> usual, but is not really the biggest issue. Even on SoC rev 1.0
> RTC-only sleep still has some functionality (the RTC freezes if PMIC
> enters sleep-state, but that may still be preferred compared to
> complete loss of date and time), so I'm not even sure I'd bother with
> this check.
OK
> The serious problems however depend on the PCB: Entering RTC-only
> sleep is only properly supported on some early prototype series
> (pre-A6) of the BeagleBone Black. Since rev A6A (which includes all
> production versions) it is not supported at all.
>
> On rev A6 of the Black, as well as (afaik) all versions of the White
> (if anyone cares, since they normally have SoC rev 1.0), the impact of
> entering RTC-only sleep is heavily dependent on external connections
> and hardware, most of which not really detectable. It is possible to
> go from "hmm, annoying standby current" to a recipe for stir-fried I/O
> pin simply by connecting a console cable while the device is in sleep.
> This is not something the kernel can foresee or prevent.
>
> I'm pretty sure the sane thing to do here is disable RTC-only sleep by
> default. People who care about it can still enable it after they
> verified the particular combination of pcb revision, external
> hardware, and usage scenario is safe (or patched the hardware to make
> it safe, or decided they're willing to take the risk.)
Makes sense to me. Robert, care to update your patch to summarize
some of the "why" parts?
> It may be useful to leave some references for those who seek guidance:
>
> 1. The issues with AM335x rev 1.0 SoCs are documented in the errata.
>
> 2. Unfortunately I still have no idea why TI altered the connection
> diagram w.r.t. "VDDS" (and as a consequence officially defeatured
> RTC-only sleep) when the TPS65217C/D PMIC for AM335x + DDR3/3L memory
> is used. Maybe I'll still get an answer from TI on E2E, but I'm also
> planning to do more thorough testing this week especially w.r.t.
> current consumption patterns during boot and shutdown.
>
> 3. The BeagleBone regulator problem is particularly notorious among
> people who (try to) use the PMIC's battery power support, since the
> problem then also surfaces during full shutdown. It has a long
> discussion thread here:
> https://groups.google.com/d/topic/beagleboard/7sxPePT7wkM/discussion
> which includes two posts by me with fairly detailed analysis along
> with scope pics:
> https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/3vFMPydR20IJ
> https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/V1Ft-xxh0agJ
OK thanks for the good summary.
Regards,
Tony
prev parent reply other threads:[~2015-05-19 14:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 13:50 [PATCH] ARM: dts: am335x-bone* enable pmic-shutdown-controller Robert Nelson
2015-05-13 14:16 ` Johan Hovold
2015-05-13 14:48 ` Johan Hovold
2015-05-16 2:48 ` Matthijs van Duin
2015-05-18 15:21 ` Tony Lindgren
2015-05-18 16:13 ` Robert Nelson
2015-05-18 16:29 ` Tony Lindgren
2015-05-18 16:49 ` Robert Nelson
2015-05-18 17:03 ` Tony Lindgren
2015-05-18 18:01 ` Pantelis Antoniou
2015-05-18 18:14 ` Tony Lindgren
2015-05-18 18:18 ` Pantelis Antoniou
2015-05-18 20:37 ` Tony Lindgren
2015-05-19 7:25 ` Matthijs van Duin
2015-05-19 14:55 ` Tony Lindgren [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150519145526.GO10274@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox