[PATCH v1 0/3] rtc: mt6359: Cleanup and support start-year property

[PATCH v1 0/3] rtc: mt6359: Cleanup and support start-year property

[AngeloGioacchino Del Regno]

This series adds support for the start-year property and removes the
custom handling of the RTC_MIN_YEAR_OFFSET (which is, effectively, doing
the exact same).

The start_secs timestamp was set to match the previous one from the
custom behavior so that there is no time drift on any device after
applying this.

While at it, a cleanup to use the Day-of-Week HW register instead of
manually calculating tm_wday was also performed.

For the bindings commit, this series goes on top of the MT6397 schema
conversion from Macpaul Lin [1].

This series was tested on a MT8195 Cherry Tomato Chromebook.

[1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/

AngeloGioacchino Del Regno (3):
  dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC
  rtc: mt6359: Add RTC hardware range and add support for start-year
  rtc: mt6359: Use RTC_TC_DOW hardware register for wday

 .../bindings/mfd/mediatek,mt6397.yaml         |  2 ++
 drivers/rtc/rtc-mt6397.c                      | 29 +++++++------------
 2 files changed, 12 insertions(+), 19 deletions(-)

-- 
2.46.0

[PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[AngeloGioacchino Del Regno]

Enable evaluating the start-year property to allow shifting the
RTC's HW range.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 953358bc997a..a83cc35f51f1 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -71,6 +71,8 @@ properties:
                   - mediatek,mt6366-rtc
               - const: mediatek,mt6358-rtc
 
+      start-year: true
+
     required:
       - compatible
 
-- 
2.46.0

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 309 bytes --]

On Mon, Sep 23, 2024 at 12:00:08PM +0200, AngeloGioacchino Del Regno wrote:
> Enable evaluating the start-year property to allow shifting the
> RTC's HW range.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Lee Jones]

On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:

> Enable evaluating the start-year property to allow shifting the
> RTC's HW range.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>  Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++

No such file.

>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 953358bc997a..a83cc35f51f1 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -71,6 +71,8 @@ properties:
>                    - mediatek,mt6366-rtc
>                - const: mediatek,mt6358-rtc
>  
> +      start-year: true
> +
>      required:
>        - compatible
>  
> -- 
> 2.46.0
> 

-- 
Lee Jones [李琼斯]

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[AngeloGioacchino Del Regno]

Il 09/10/24 12:15, Lee Jones ha scritto:
> On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:
> 
>> Enable evaluating the start-year property to allow shifting the
>> RTC's HW range.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
> 
> No such file.
> 

In the cover letter, I wrote:


For the bindings commit, this series goes on top of the MT6397 schema
conversion from Macpaul Lin [1].

This series was tested on a MT8195 Cherry Tomato Chromebook.

[1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/


So, that's why. :-)

Cheers,
Angelo

>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
>> index 953358bc997a..a83cc35f51f1 100644
>> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
>> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
>> @@ -71,6 +71,8 @@ properties:
>>                     - mediatek,mt6366-rtc
>>                 - const: mediatek,mt6358-rtc
>>   
>> +      start-year: true
>> +
>>       required:
>>         - compatible
>>   
>> -- 
>> 2.46.0
>>
> 

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Lee Jones]

On Wed, 09 Oct 2024, AngeloGioacchino Del Regno wrote:

> Il 09/10/24 12:15, Lee Jones ha scritto:
> > On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:
> > 
> > > Enable evaluating the start-year property to allow shifting the
> > > RTC's HW range.
> > > 
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > >   Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
> > 
> > No such file.
> > 
> 
> In the cover letter, I wrote:
> 
> 
> For the bindings commit, this series goes on top of the MT6397 schema
> conversion from Macpaul Lin [1].
> 
> This series was tested on a MT8195 Cherry Tomato Chromebook.
> 
> [1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/
> 
> 
> So, that's why. :-)

Nope, try again. :)

-- 
Lee Jones [李琼斯]

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Lee Jones]

On Wed, 09 Oct 2024, Lee Jones wrote:

> On Wed, 09 Oct 2024, AngeloGioacchino Del Regno wrote:
> 
> > Il 09/10/24 12:15, Lee Jones ha scritto:
> > > On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:
> > > 
> > > > Enable evaluating the start-year property to allow shifting the
> > > > RTC's HW range.
> > > > 
> > > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > > ---
> > > >   Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
> > > 
> > > No such file.
> > > 
> > 
> > In the cover letter, I wrote:
> > 
> > 
> > For the bindings commit, this series goes on top of the MT6397 schema
> > conversion from Macpaul Lin [1].
> > 
> > This series was tested on a MT8195 Cherry Tomato Chromebook.
> > 
> > [1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/
> > 
> > 
> > So, that's why. :-)
> 
> Nope, try again. :)

I guess you actually mean:

  https://lore.kernel.org/all/20240918064955.6518-2-macpaul.lin@mediatek.com/

It's on my list.  I'll place yours behind it and see how we go.

-- 
Lee Jones [李琼斯]

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Macpaul Lin]

On 10/9/24 18:37, Lee Jones wrote:
> 	
> 
> External email : Please do not click links or open attachments until you 
> have verified the sender or the content.
> 
> On Wed, 09 Oct 2024, Lee Jones wrote:
> 
>> On Wed, 09 Oct 2024, AngeloGioacchino Del Regno wrote:
>> 
>> > Il 09/10/24 12:15, Lee Jones ha scritto:
>> > > On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:
>> > > 
>> > > > Enable evaluating the start-year property to allow shifting the
>> > > > RTC's HW range.
>> > > > 
>> > > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> > > > ---
>> > > >   Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
>> > > 
>> > > No such file.
>> > > 
>> > 
>> > In the cover letter, I wrote:
>> > 
>> > 
>> > For the bindings commit, this series goes on top of the MT6397 schema
>> > conversion from Macpaul Lin [1].
>> > 
>> > This series was tested on a MT8195 Cherry Tomato Chromebook.
>> > 
>> > [1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/
>> > 
>> > 
>> > So, that's why. :-)
>> 
>> Nope, try again. :)
> 
> I guess you actually mean:
> 
>    https://lore.kernel.org/all/20240918064955.6518-2-macpaul.lin@mediatek.com/
> 
> It's on my list.  I'll place yours behind it and see how we go.

Just a reminder.
The last reviewed patch set should be 'v8' because of the update for

'Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml'

[1/3] 
https://lore.kernel.org/all/20241001104145.24054-1-macpaul.lin@mediatek.com/

The [2/3] and [3/3] patches are dependent.

> 
> -- 
> Lee Jones [李琼斯]
> 

Thanks
Macpaul Lin

Re: [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[AngeloGioacchino Del Regno]

Il 09/10/24 12:37, Lee Jones ha scritto:
> On Wed, 09 Oct 2024, Lee Jones wrote:
> 
>> On Wed, 09 Oct 2024, AngeloGioacchino Del Regno wrote:
>>
>>> Il 09/10/24 12:15, Lee Jones ha scritto:
>>>> On Mon, 23 Sep 2024, AngeloGioacchino Del Regno wrote:
>>>>
>>>>> Enable evaluating the start-year property to allow shifting the
>>>>> RTC's HW range.
>>>>>
>>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml | 2 ++
>>>>
>>>> No such file.
>>>>
>>>
>>> In the cover letter, I wrote:
>>>
>>>
>>> For the bindings commit, this series goes on top of the MT6397 schema
>>> conversion from Macpaul Lin [1].
>>>
>>> This series was tested on a MT8195 Cherry Tomato Chromebook.
>>>
>>> [1]: https://lore.kernel.org/all/20240918064955.6518-1-macpaul.lin@mediatek.com/
>>>
>>>
>>> So, that's why. :-)
>>
>> Nope, try again. :)
> 
> I guess you actually mean:
> 
>    https://lore.kernel.org/all/20240918064955.6518-2-macpaul.lin@mediatek.com/
> 
> It's on my list.  I'll place yours behind it and see how we go.
> 

Yes I actually mean that one.

That's because I use to paste links to the cover letter of a series, and that
one did actually miss it, so that's what happened there I guess.

Anyway, I'm happy that you figured it out - this reminds me that I actually want
to keep asking to add cover letters when I review series..... :-)

Btw, many thanks!
Angelo

Re: (subset) [PATCH v1 1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC

[Lee Jones]

On Mon, 23 Sep 2024 12:00:08 +0200, AngeloGioacchino Del Regno wrote:
> Enable evaluating the start-year property to allow shifting the
> RTC's HW range.
> 
> 

Applied, thanks!

[1/3] dt-bindings: mfd: mediatek: mt6397: Add start-year property to RTC
      commit: 0a98b711db1345687df995495ee1d097bba5a958

--
Lee Jones [李琼斯]

[PATCH v1 2/3] rtc: mt6359: Add RTC hardware range and add support for start-year

[AngeloGioacchino Del Regno]

Add the RTC hardware range parameters to enable the possibility
of using the `start-year` devicetree property which, if present,
will set the start_secs parameter by overriding the defaults
that this driver is setting;

To keep compatibility with (hence have the same date/time reading
as) the old behavior, set:
 - range_min to 1900-01-01 00:00:00
 - range_max to 2027-12-31 23:59:59 (HW year max range is 0-127)
 - start_secs defaulting to 1968-01-02 00:00:00

Please note that the oddness of starting from January 2nd is not
a hardware quirk and it's done only to get the same date/time
reading as an RTC which time was set before this commit.

Also remove the RTC_MIN_YEAR_OFFSET addition and subtraction in
callbacks set_time() and read_time() respectively, as now this
is already done by the API.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/rtc/rtc-mt6397.c | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 1617063669cc..4785af123a7f 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -96,12 +96,6 @@ static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
 			goto exit;
 	} while (sec < tm->tm_sec);
 
-	/* HW register use 7 bits to store year data, minus
-	 * RTC_MIN_YEAR_OFFSET before write year data to register, and plus
-	 * RTC_MIN_YEAR_OFFSET back after read year from register
-	 */
-	tm->tm_year += RTC_MIN_YEAR_OFFSET;
-
 	/* HW register start mon from one, but tm_mon start from zero. */
 	tm->tm_mon--;
 	time = rtc_tm_to_time64(tm);
@@ -122,7 +116,6 @@ static int mtk_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	int ret;
 	u16 data[RTC_OFFSET_COUNT];
 
-	tm->tm_year -= RTC_MIN_YEAR_OFFSET;
 	tm->tm_mon++;
 
 	data[RTC_OFFSET_SEC] = tm->tm_sec;
@@ -178,7 +171,6 @@ static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_AL_MTH_MASK;
 	tm->tm_year = data[RTC_OFFSET_YEAR] & RTC_AL_YEA_MASK;
 
-	tm->tm_year += RTC_MIN_YEAR_OFFSET;
 	tm->tm_mon--;
 
 	return 0;
@@ -194,7 +186,6 @@ static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
 	int ret;
 	u16 data[RTC_OFFSET_COUNT];
 
-	tm->tm_year -= RTC_MIN_YEAR_OFFSET;
 	tm->tm_mon++;
 
 	mutex_lock(&rtc->lock);
@@ -302,6 +293,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
 	device_init_wakeup(&pdev->dev, 1);
 
 	rtc->rtc_dev->ops = &mtk_rtc_ops;
+	rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
+	rtc->rtc_dev->range_max = mktime64(2027, 12, 31, 23, 59, 59);
+	rtc->rtc_dev->start_secs = mktime64(1968, 1, 2, 0, 0, 0);
+	rtc->rtc_dev->set_start_time = true;
 
 	return devm_rtc_register_device(rtc->rtc_dev);
 }
-- 
2.46.0

Re: [PATCH v1 2/3] rtc: mt6359: Add RTC hardware range and add support for start-year

[Macpaul Lin]

On 9/23/24 18:00, AngeloGioacchino Del Regno wrote:
> Add the RTC hardware range parameters to enable the possibility
> of using the `start-year` devicetree property which, if present,
> will set the start_secs parameter by overriding the defaults
> that this driver is setting;
> 
> To keep compatibility with (hence have the same date/time reading
> as) the old behavior, set:
>   - range_min to 1900-01-01 00:00:00
>   - range_max to 2027-12-31 23:59:59 (HW year max range is 0-127)
>   - start_secs defaulting to 1968-01-02 00:00:00
> 
> Please note that the oddness of starting from January 2nd is not
> a hardware quirk and it's done only to get the same date/time
> reading as an RTC which time was set before this commit.
> 
> Also remove the RTC_MIN_YEAR_OFFSET addition and subtraction in
> callbacks set_time() and read_time() respectively, as now this
> is already done by the API.
> 
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
>   drivers/rtc/rtc-mt6397.c | 13 ++++---------
>   1 file changed, 4 insertions(+), 9 deletions(-)

[snip]

Thanks for helping add new patch fix for RTC.

> @@ -302,6 +293,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
>   	device_init_wakeup(&pdev->dev, 1);
>   
>   	rtc->rtc_dev->ops = &mtk_rtc_ops;
> +	rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
> +	rtc->rtc_dev->range_max = mktime64(2027, 12, 31, 23, 59, 59);
> +	rtc->rtc_dev->start_secs = mktime64(1968, 1, 2, 0, 0, 0);
> +	rtc->rtc_dev->set_start_time = true;
>   
>   	return devm_rtc_register_device(rtc->rtc_dev);
>   }

Dear @Zhanhan, Please help to leave comment if you think there is 
something need to be clarify. For example, I've found some relate origin 
defines
in "include/linux/mfd/mt6397/rtc.h"
#define RTC_MIN_YEAR	1968
#define RTC_BASE_YEAR	1900
#define RTC_NUM_YEAR	128
#define RTC_MIN_YEAR_OFFSET	(RTC_MIN_YEAR - RTC_BASE_YEAR)

Should MediaTek remove RTC_MIN_YEAR and RTC_BASE_YEAR in next patch?
And since there may not exist any smartphone/tablet/TV using mt6397
RTC earlier than 2010? Is it possible to change
RTC_TIMESTAMP_BEGIN_1900 to RTC_TIMESTAMP_BEGIN_2000 without breaking
compatibility for these devices?

Thanks
Macpaul Lin

Re: [PATCH v1 2/3] rtc: mt6359: Add RTC hardware range and add support for start-year

[Macpaul Lin]

On 9/24/24 12:08, Macpaul Lin wrote:
> 
> On 9/23/24 18:00, AngeloGioacchino Del Regno wrote:
>> Add the RTC hardware range parameters to enable the possibility
>> of using the `start-year` devicetree property which, if present,
>> will set the start_secs parameter by overriding the defaults
>> that this driver is setting;
>>
>> To keep compatibility with (hence have the same date/time reading
>> as) the old behavior, set:
>>   - range_min to 1900-01-01 00:00:00
>>   - range_max to 2027-12-31 23:59:59 (HW year max range is 0-127)
>>   - start_secs defaulting to 1968-01-02 00:00:00
>>
>> Please note that the oddness of starting from January 2nd is not
>> a hardware quirk and it's done only to get the same date/time
>> reading as an RTC which time was set before this commit.
>>
>> Also remove the RTC_MIN_YEAR_OFFSET addition and subtraction in
>> callbacks set_time() and read_time() respectively, as now this
>> is already done by the API.
>>
>> Signed-off-by: AngeloGioacchino Del Regno 
>> <angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/rtc/rtc-mt6397.c | 13 ++++---------
>>   1 file changed, 4 insertions(+), 9 deletions(-)
> 
> [snip]
> 
> Thanks for helping add new patch fix for RTC.
> 
>> @@ -302,6 +293,10 @@ static int mtk_rtc_probe(struct platform_device 
>> *pdev)
>>       device_init_wakeup(&pdev->dev, 1);
>>       rtc->rtc_dev->ops = &mtk_rtc_ops;
>> +    rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
>> +    rtc->rtc_dev->range_max = mktime64(2027, 12, 31, 23, 59, 59);
>> +    rtc->rtc_dev->start_secs = mktime64(1968, 1, 2, 0, 0, 0);
>> +    rtc->rtc_dev->set_start_time = true;
>>       return devm_rtc_register_device(rtc->rtc_dev);
>>   }
> 
> Dear @Zhanhan, Please help to leave comment if you think there is 
> something need to be clarify. For example, I've found some relate origin 
> defines
> in "include/linux/mfd/mt6397/rtc.h"
> #define RTC_MIN_YEAR    1968
> #define RTC_BASE_YEAR    1900
> #define RTC_NUM_YEAR    128
> #define RTC_MIN_YEAR_OFFSET    (RTC_MIN_YEAR - RTC_BASE_YEAR)
> 
> Should MediaTek remove RTC_MIN_YEAR and RTC_BASE_YEAR in next patch?
> And since there may not exist any smartphone/tablet/TV using mt6397
> RTC earlier than 2010? Is it possible to change
> RTC_TIMESTAMP_BEGIN_1900 to RTC_TIMESTAMP_BEGIN_2000 without breaking
> compatibility for these devices?
> 
> Thanks
> Macpaul Lin
> 

After discussing these change with ZhanZhan, MediaTek think use 
RTC_TIMESTAMP_BEGIN_1900 and the other changes are okay.

Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Reviewed-by: ZhanZhan Ge <zhanzhan.ge@mediatek.com>

Thanks!
Macpaul Lin

Re: [PATCH v1 2/3] rtc: mt6359: Add RTC hardware range and add support for start-year

[AngeloGioacchino Del Regno]

Il 24/09/24 09:05, Macpaul Lin ha scritto:
> 
> On 9/24/24 12:08, Macpaul Lin wrote:
>>
>> On 9/23/24 18:00, AngeloGioacchino Del Regno wrote:
>>> Add the RTC hardware range parameters to enable the possibility
>>> of using the `start-year` devicetree property which, if present,
>>> will set the start_secs parameter by overriding the defaults
>>> that this driver is setting;
>>>
>>> To keep compatibility with (hence have the same date/time reading
>>> as) the old behavior, set:
>>>   - range_min to 1900-01-01 00:00:00
>>>   - range_max to 2027-12-31 23:59:59 (HW year max range is 0-127)
>>>   - start_secs defaulting to 1968-01-02 00:00:00
>>>
>>> Please note that the oddness of starting from January 2nd is not
>>> a hardware quirk and it's done only to get the same date/time
>>> reading as an RTC which time was set before this commit.
>>>
>>> Also remove the RTC_MIN_YEAR_OFFSET addition and subtraction in
>>> callbacks set_time() and read_time() respectively, as now this
>>> is already done by the API.
>>>
>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>>> ---
>>>   drivers/rtc/rtc-mt6397.c | 13 ++++---------
>>>   1 file changed, 4 insertions(+), 9 deletions(-)
>>
>> [snip]
>>
>> Thanks for helping add new patch fix for RTC.
>>
>>> @@ -302,6 +293,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
>>>       device_init_wakeup(&pdev->dev, 1);
>>>       rtc->rtc_dev->ops = &mtk_rtc_ops;
>>> +    rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
>>> +    rtc->rtc_dev->range_max = mktime64(2027, 12, 31, 23, 59, 59);
>>> +    rtc->rtc_dev->start_secs = mktime64(1968, 1, 2, 0, 0, 0);
>>> +    rtc->rtc_dev->set_start_time = true;
>>>       return devm_rtc_register_device(rtc->rtc_dev);
>>>   }
>>
>> Dear @Zhanhan, Please help to leave comment if you think there is something need 
>> to be clarify. For example, I've found some relate origin defines
>> in "include/linux/mfd/mt6397/rtc.h"
>> #define RTC_MIN_YEAR    1968
>> #define RTC_BASE_YEAR    1900
>> #define RTC_NUM_YEAR    128
>> #define RTC_MIN_YEAR_OFFSET    (RTC_MIN_YEAR - RTC_BASE_YEAR)
>>
>> Should MediaTek remove RTC_MIN_YEAR and RTC_BASE_YEAR in next patch?
>> And since there may not exist any smartphone/tablet/TV using mt6397
>> RTC earlier than 2010? Is it possible to change
>> RTC_TIMESTAMP_BEGIN_1900 to RTC_TIMESTAMP_BEGIN_2000 without breaking
>> compatibility for these devices?
>>
>> Thanks
>> Macpaul Lin
>>
> 
> After discussing these change with ZhanZhan, MediaTek think use 
> RTC_TIMESTAMP_BEGIN_1900 and the other changes are okay.
> 
> Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
> Reviewed-by: ZhanZhan Ge <zhanzhan.ge@mediatek.com>
> 

Thank you Macpaul, ZhanZhan :-)

Cheers,
Angelo

Re: [PATCH v1 2/3] rtc: mt6359: Add RTC hardware range and add support for start-year

[AngeloGioacchino Del Regno]

Il 24/09/24 06:08, Macpaul Lin ha scritto:
> 
> On 9/23/24 18:00, AngeloGioacchino Del Regno wrote:
>> Add the RTC hardware range parameters to enable the possibility
>> of using the `start-year` devicetree property which, if present,
>> will set the start_secs parameter by overriding the defaults
>> that this driver is setting;
>>
>> To keep compatibility with (hence have the same date/time reading
>> as) the old behavior, set:
>>   - range_min to 1900-01-01 00:00:00
>>   - range_max to 2027-12-31 23:59:59 (HW year max range is 0-127)
>>   - start_secs defaulting to 1968-01-02 00:00:00
>>
>> Please note that the oddness of starting from January 2nd is not
>> a hardware quirk and it's done only to get the same date/time
>> reading as an RTC which time was set before this commit.
>>
>> Also remove the RTC_MIN_YEAR_OFFSET addition and subtraction in
>> callbacks set_time() and read_time() respectively, as now this
>> is already done by the API.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/rtc/rtc-mt6397.c | 13 ++++---------
>>   1 file changed, 4 insertions(+), 9 deletions(-)
> 
> [snip]
> 
> Thanks for helping add new patch fix for RTC.
> 
>> @@ -302,6 +293,10 @@ static int mtk_rtc_probe(struct platform_device *pdev)
>>       device_init_wakeup(&pdev->dev, 1);
>>       rtc->rtc_dev->ops = &mtk_rtc_ops;
>> +    rtc->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_1900;
>> +    rtc->rtc_dev->range_max = mktime64(2027, 12, 31, 23, 59, 59);
>> +    rtc->rtc_dev->start_secs = mktime64(1968, 1, 2, 0, 0, 0);
>> +    rtc->rtc_dev->set_start_time = true;
>>       return devm_rtc_register_device(rtc->rtc_dev);
>>   }
> 
> Dear @Zhanhan, Please help to leave comment if you think there is something need to 
> be clarify. For example, I've found some relate origin defines
> in "include/linux/mfd/mt6397/rtc.h"
> #define RTC_MIN_YEAR    1968
> #define RTC_BASE_YEAR    1900
> #define RTC_NUM_YEAR    128
> #define RTC_MIN_YEAR_OFFSET    (RTC_MIN_YEAR - RTC_BASE_YEAR)
> 
> Should MediaTek remove RTC_MIN_YEAR and RTC_BASE_YEAR in next patch?
> And since there may not exist any smartphone/tablet/TV using mt6397
> RTC earlier than 2010? Is it possible to change
> RTC_TIMESTAMP_BEGIN_1900 to RTC_TIMESTAMP_BEGIN_2000 without breaking
> compatibility for these devices?

Adding some context:

Being clear, the RTC timestamp starting at year 1900 doesn't mean that the
last achievable date is 2027, as the time is anyway shifted by 68 years in
this case - so, by default, the year range goes from 1968 to 2095 (unless
overridden by the start-year property, of course).

This means that setting the RTC to start at a different year doesn't really
give any measurable improvement, as that would avoid just one addition and
one subtraction operation at read and write respectively, which is something
that happens "rarely in a boot life" (RTC usually gets read once at kernel
boot, and written every time you change the date/time, which normally happens
once per day, if not even less...!).

Cheers,
Angelo

[PATCH v1 3/3] rtc: mt6359: Use RTC_TC_DOW hardware register for wday

[AngeloGioacchino Del Regno]

Instead of calculating the number of full days since Sunday with
(days + 4) % 7, read (and write) that to the RTC Day-of-week Time
Counter register (RTC_TC_DOW).

Some transformation (addition and subtraction for set/get) is
still done, as this register's range is [1..7], while the tm_wday
in struct tm's range is [0..6].

Please note that this was added only to set_time() and read_time()
callbacks because set_alarm() and read_alarm() are setting a bit
in RTC_AL_MASK to ignore DOW for RTC HW alarms for unknown reasons.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/rtc/rtc-mt6397.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 4785af123a7f..152699219a2b 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -75,6 +75,7 @@ static int __mtk_rtc_read_time(struct mt6397_rtc *rtc,
 	tm->tm_min = data[RTC_OFFSET_MIN];
 	tm->tm_hour = data[RTC_OFFSET_HOUR];
 	tm->tm_mday = data[RTC_OFFSET_DOM];
+	tm->tm_wday = data[RTC_OFFSET_DOW];
 	tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_TC_MTH_MASK;
 	tm->tm_year = data[RTC_OFFSET_YEAR];
 
@@ -86,9 +87,8 @@ static int __mtk_rtc_read_time(struct mt6397_rtc *rtc,
 
 static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
-	time64_t time;
 	struct mt6397_rtc *rtc = dev_get_drvdata(dev);
-	int days, sec, ret;
+	int sec, ret;
 
 	do {
 		ret = __mtk_rtc_read_time(rtc, tm, &sec);
@@ -96,15 +96,9 @@ static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
 			goto exit;
 	} while (sec < tm->tm_sec);
 
-	/* HW register start mon from one, but tm_mon start from zero. */
+	/* HW register start mon/wday from one, but tm_mon/tm_wday start from zero. */
 	tm->tm_mon--;
-	time = rtc_tm_to_time64(tm);
-
-	/* rtc_tm_to_time64 covert Gregorian date to seconds since
-	 * 01-01-1970 00:00:00, and this date is Thursday.
-	 */
-	days = div_s64(time, 86400);
-	tm->tm_wday = (days + 4) % 7;
+	tm->tm_wday--;
 
 exit:
 	return ret;
@@ -117,11 +111,13 @@ static int mtk_rtc_set_time(struct device *dev, struct rtc_time *tm)
 	u16 data[RTC_OFFSET_COUNT];
 
 	tm->tm_mon++;
+	tm->tm_wday++;
 
 	data[RTC_OFFSET_SEC] = tm->tm_sec;
 	data[RTC_OFFSET_MIN] = tm->tm_min;
 	data[RTC_OFFSET_HOUR] = tm->tm_hour;
 	data[RTC_OFFSET_DOM] = tm->tm_mday;
+	data[RTC_OFFSET_DOW] = tm->tm_wday;
 	data[RTC_OFFSET_MTH] = tm->tm_mon;
 	data[RTC_OFFSET_YEAR] = tm->tm_year;
 
-- 
2.46.0

Re: (subset) [PATCH v1 0/3] rtc: mt6359: Cleanup and support start-year property

[Alexandre Belloni]

On Mon, 23 Sep 2024 12:00:07 +0200, AngeloGioacchino Del Regno wrote:
> This series adds support for the start-year property and removes the
> custom handling of the RTC_MIN_YEAR_OFFSET (which is, effectively, doing
> the exact same).
> 
> The start_secs timestamp was set to match the previous one from the
> custom behavior so that there is no time drift on any device after
> applying this.
> 
> [...]

Applied, thanks!

[2/3] rtc: mt6359: Add RTC hardware range and add support for start-year
      https://git.kernel.org/abelloni/c/34bbdc12d04e
[3/3] rtc: mt6359: Use RTC_TC_DOW hardware register for wday
      https://git.kernel.org/abelloni/c/d6f471a74790

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com