Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1441543
| From | Andrey Smirnov <andrew.smirnov@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options |
| Date | 2016-07-12 18:30 +0200 |
| Message-ID | <rU8Jl-7nR-35@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <rLM3f-3BK-5@gated-at.bofh.it> <rLPu9-5V2-7@gated-at.bofh.it> <rMB5L-2DJ-9@gated-at.bofh.it> <rMB5L-2DJ-7@gated-at.bofh.it> <rMGf8-5Rv-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Jun 21, 2016 at 7:34 PM, Andrey Smirnov <andrew.smirnov@gmail.com> wrote: > On Tue, Jun 21, 2016 at 2:07 PM, Alexandre Belloni > <alexandre.belloni@free-electrons.com> wrote: >> On 21/06/2016 at 15:49:04 -0500, Rob Herring wrote : >>> So wouldn't you want to set one mode while running and the lower power >>> mode while suspended? I'm trying to understand the frequency of changing >>> this. If it is always one setting for a board, then yes it belongs in >>> DT. If it is a user decision, then it probably shouldn't be in DT. >>> >>> Seeing as these are reused, I've probably already had this discussion... >>> >> >> I would agree with Rob here. It may be better to provide a sysfs >> interface to configure that particular behavior. > > I don't see any value in doing that, could you give me a realistic > example of a scenario in which a user would want to spend some of > uptime with RTC oscillator fault detection/glitch filtering disabled > and then enable it? > >> This is usually ok because the use case is: >> - the RTC is not configured, time has never been set >> - time is set for the first time >> - the user can set the oscillator mode/detection/... > > Unfortunately exposing that feature using sysfs gives you a leaky > abstraction and your userspace instead of using a generic RTC starts > using DS1341 RTC. So to accommodate for that a user would have to: > > a) Write + integrate a userspace tool to set the mode (which IMHO is > decided upon once and doesn't change) > b) If a board design is new and there's a chance of moving this chip > to a different I2C bus, the code above would have to account for that > and not hardcore sysfs path > c) If board's BSP is intended to be used in multiple generations of a > product, not all of which would use DS1341, it would be necessary to > accommodate for that by either more code in the tool or an additional > BSP build configuration variant > >> - on subsequent reboots, the mode is kept alongside the time and date >> > > This assumes that your bootloader leaves those mode bits alone. > >> I would advise against trying to set a mode automatically in the driver >> because you may have unexpected power cuts and it may then let the RTC >> consume more power than what you really want. >> > > I fell like I am not understanding you correctly. Why would moving > configuration decision logic into userspace improve the situation in > case of unexpected power loss? > > Andrey Alexandre, what's the status of this discussion/patchset? Would it be more acceptable if I dropped all of the refactoring and just kept the code adding new feature + DT binding for it? I am more than happy to drop all but essential parts of the patches if that would allow us to make progress. Thank you, Andrey
Back to linux.kernel | Previous | Next | Find similar | Unroll thread
Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options Andrey Smirnov <andrew.smirnov@gmail.com> - 2016-07-12 18:30 +0200
csiph-web