* Matthijs van Duin <matthijsvanduin@xxxxxxxxx> [150519 00:27]: > On 18 May 2015 at 17:21, Tony Lindgren <tony@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
