diff mbox

[RFC,1/3] dt-bindings: rtc: Add Realtek RTD1295

Message ID 20170820013632.18375-2-afaerber@suse.de (mailing list archive)
State New, archived
Headers show

Commit Message

Andreas Färber Aug. 20, 2017, 1:36 a.m. UTC
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

Comments

Rob Herring (Arm) Aug. 23, 2017, 12:29 a.m. UTC | #1
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>
Andreas Färber Aug. 27, 2017, 10:41 a.m. UTC | #2
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
Andrew Lunn Aug. 27, 2017, 1:47 p.m. UTC | #3
> 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
Andreas Färber Aug. 27, 2017, 5:26 p.m. UTC | #4
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
Alexandre Belloni Aug. 27, 2017, 7:07 p.m. UTC | #5
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.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
new file mode 100644
index 000000000000..bbf1ccb5df31
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/realtek,rtd119x.txt
@@ -0,0 +1,16 @@ 
+Realtek RTD129x Real-Time Clock
+===============================
+
+Required properties:
+- compatible :  Should be "realtek,rtd1295-rtc"
+- reg        :  Specifies the physical base address and size
+- clocks     :  Specifies the clock gate
+
+
+Example:
+
+	rtc@9801b600 {
+		compatible = "realtek,rtd1295-clk";
+		reg = <0x9801b600 0x100>;
+		clocks = <&clkc RTD1295_CLK_EN_MISC_RTC>;
+	};