On Sun, Jun 19, 2016 at 11:12:55AM -0700, Andrey Smirnov wrote: > On Sun, Jun 19, 2016 at 7:29 AM, Rob Herring <robh@xxxxxxxxxx> wrote: > > On Tue, Jun 14, 2016 at 10:59:29PM -0700, Andrey Smirnov wrote: > >> Add DS1341 specific power-saving options that allow to disable certain > >> functional aspects of the chip in order to minimize its power > >> consumption. > > > > This description doesn't match that you are adding a new binding. It is > > preferred that bindings are a separate patch. > > OK, will split this patch into two in v2. > > > > >> > >> Signed-off-by: Andrey Smirnov <andrew.smirnov@xxxxxxxxx> > >> --- > >> .../devicetree/bindings/rtc/dallas,ds1341.txt | 23 ++++++++++++++++++ > >> drivers/rtc/rtc-ds1307.c | 28 ++++++++++++++++++++++ > >> 2 files changed, 51 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/rtc/dallas,ds1341.txt > >> > >> diff --git a/Documentation/devicetree/bindings/rtc/dallas,ds1341.txt b/Documentation/devicetree/bindings/rtc/dallas,ds1341.txt > >> new file mode 100644 > >> index 0000000..b8be7a4 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/rtc/dallas,ds1341.txt > >> @@ -0,0 +1,23 @@ > >> +* Dallas DS1341 I2C Serial Real-Time Clock > >> + > >> +Required properties: > >> + > >> +- compatible: Should contain "dallas,ds1341". > >> + > >> +- reg: I2C address for chip > >> + > >> +Optional properties: > >> + > >> +- disable-oscillator-stop-flag : Configure chip to disable oscillator > >> + fault detection circuitry > >> + > >> +- enable-glitch-filter : Configure chip to enable crystal oscillator > >> + output glitch filtering > > > > What determines setting these properties or not? > > Setting those properties allows drastically reduce RTC's power > consumption at the expense of reliability and quality of service. In > my use case, DS1341 is powered by a supercap and enabling those two > setting allows to increase holdup from less than a day do 2+ weeks. 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... > > They should have vendor prefix and be explicit that they are boolean. > > I was trying to be consistent with ds1339 and ds1390 bindings which do > not have vendor prefixes. Will fix in v2. Okay, then they are fine if you are using existing properties. Perhaps these should all be in a common binding doc though. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
