| Message ID | 20170820013632.18375-1-afaerber@suse.de |
|---|---|
| Headers | show |
| Series | arm64: Realtek RTD1295 RTC | expand |
On Sun, Aug 20, 2017 at 03:36:29AM +0200, Andreas Färber wrote: > Add a binding for the RTC on the Realtek RTD119x/RTD129x SoC families. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > .../devicetree/bindings/rtc/realtek,rtd119x.txt | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt Acked-by: Rob Herring <robh@kernel.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rob, Am 23.08.2017 um 02:29 schrieb Rob Herring: > On Sun, Aug 20, 2017 at 03:36:29AM +0200, Andreas Färber wrote: >> Add a binding for the RTC on the Realtek RTD119x/RTD129x SoC families. >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> .../devicetree/bindings/rtc/realtek,rtd119x.txt | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt > > Acked-by: Rob Herring <robh@kernel.org> Thanks. Did you read the RFC question in the cover letter as well and have any comments? Downstream has an rtc-base-year = <2014>; property that I had left out in this RFC and due to your ack not included in v2. Should we default to 2014 in the driver and add an optional base-year property once we encounter a diverging device, or should we make it required from the beginning? I did not spot any other rtc binding with such a property and would appreciate a clarification. Thanks in advance, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Thanks. Did you read the RFC question in the cover letter as well and > have any comments? Downstream has an rtc-base-year = <2014>; property > that I had left out in this RFC and due to your ack not included in v2. > > Should we default to 2014 in the driver and add an optional base-year > property once we encounter a diverging device, or should we make it > required from the beginning? I did not spot any other rtc binding with > such a property and would appreciate a clarification. Hi Andreas From the perspective of the hardware, does it care what the base is? A device using a different base will initially return the wrong time. But once the correct time has been written back, it will be O.K. This only becomes an issue if a device is used with different OSs, which have different bases. Swapping back and forth between OSs then becomes an issue. KISS suggests not having a base in DT until it is actually required. Since it is an additional property, it does not break backwards compatibility when added. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew, Am 27.08.2017 um 15:47 schrieb Andrew Lunn: >> Thanks. Did you read the RFC question in the cover letter as well and >> have any comments? Downstream has an rtc-base-year = <2014>; property >> that I had left out in this RFC and due to your ack not included in v2. >> >> Should we default to 2014 in the driver and add an optional base-year >> property once we encounter a diverging device, or should we make it >> required from the beginning? I did not spot any other rtc binding with >> such a property and would appreciate a clarification. > > From the perspective of the hardware, does it care what the base is? The hardware stores a 15-bit number of days since Jan 1st of that base year. It does not store the base year. The datasheet does not name such a base year. No manual is available. The driver needs to get it from somewhere for calculating day/month/year in read_time and days in set_time. The read_offset/set_offset API appeared to be something different. > A device using a different base will initially return the wrong > time. But once the correct time has been written back, it will be O.K. > > This only becomes an issue if a device is used with different OSs, > which have different bases. Swapping back and forth between OSs then > becomes an issue. These are TV boxes, so yes, I'm dual-booting into Android with a vendor 4.1 kernel and would like to keep date compatibility. https://en.opensuse.org/HCL:Zidoo_X9S https://en.opensuse.org/HCL:ProBox2_Ava https://en.opensuse.org/HCL:Lake1 As stated in the v2 rtc commit message, 2014 is the base year encountered on all three devices that I've had access to. @Jiang, if you're using a different base year, please speak up! > KISS suggests not having a base in DT until it is actually > required. Since it is an additional property, it does not break > backwards compatibility when added. That's what I've attempted here - but for RDA8810PL serial Rob said he did not want future changes to my binding, therefore I am asking for his confirmation here. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27/08/2017 at 19:26:11 +0200, Andreas Färber wrote: > Hi Andrew, > > Am 27.08.2017 um 15:47 schrieb Andrew Lunn: > >> Thanks. Did you read the RFC question in the cover letter as well and > >> have any comments? Downstream has an rtc-base-year = <2014>; property > >> that I had left out in this RFC and due to your ack not included in v2. > >> > >> Should we default to 2014 in the driver and add an optional base-year > >> property once we encounter a diverging device, or should we make it > >> required from the beginning? I did not spot any other rtc binding with > >> such a property and would appreciate a clarification. > > > > From the perspective of the hardware, does it care what the base is? > > The hardware stores a 15-bit number of days since Jan 1st of that base > year. It does not store the base year. > > The datasheet does not name such a base year. No manual is available. > > The driver needs to get it from somewhere for calculating day/month/year > in read_time and days in set_time. > > The read_offset/set_offset API appeared to be something different. > There is no api to change the epoch of an RTC because it is difficult to do in a race free way. This has to be worked on. Anyway, you don't really care for now as it goes up to 2093 and hopefully, you will never have a product with a different epoch. > > A device using a different base will initially return the wrong > > time. But once the correct time has been written back, it will be O.K. > > The other issue being that you don't have any way to know whether the base is correct or not until the date is set. > > This only becomes an issue if a device is used with different OSs, > > which have different bases. Swapping back and forth between OSs then > > becomes an issue. > > These are TV boxes, so yes, I'm dual-booting into Android with a vendor > 4.1 kernel and would like to keep date compatibility. > > https://en.opensuse.org/HCL:Zidoo_X9S > https://en.opensuse.org/HCL:ProBox2_Ava > https://en.opensuse.org/HCL:Lake1 > > As stated in the v2 rtc commit message, 2014 is the base year > encountered on all three devices that I've had access to. > @Jiang, if you're using a different base year, please speak up! > > > KISS suggests not having a base in DT until it is actually > > required. Since it is an additional property, it does not break > > backwards compatibility when added. > > That's what I've attempted here - but for RDA8810PL serial Rob said he > did not want future changes to my binding, therefore I am asking for his > confirmation here. It would be a change that is easy enough to do in a backward compatible way so that is probably fine. -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html