[bug report] Droid 4 cpcap rtc

[bug report] Droid 4 cpcap rtc

[Dev Null]

Hi Sebastian

Im a droid 4 user / maemo leste dev. I would like to bring these things to your attention:

1. writing to the rtc via rtc-cpcap with hwclock appears to not work at all.
	- see https://github.com/maemo-leste/bugtracker/issues/399
	- hwclock: ioctl(RTC_SET_TIME) to /dev/rtc0 to set the time failed: Numerical result out of range
2. do you by any chance know how the RGB -> RGWRBW pentile color conversion happens on the droid 4? is this handled in hardware or in software or in firmware somewere?

-- 
Dev Null <devnull@uvos.xyz>

[PATCH] rtc: cpcap: fix range

[Sebastian Reichel]

Unbreak CPCAP driver, which has one more bit in the day counter
increasing the max. range from 2014 to 2058. The original commit
introducing the range limit was obviously wrong, since the driver
has only been written in 2017 (3 years after 14 bits would have
run out).

Reported-by: Sicelo A. Mhlongo <absicsz@gmail.com>
Reported-by: Dev Null <devnull@uvos.xyz>
Fixes: d2377f8cc5a7 ("rtc: cpcap: set range")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 drivers/rtc/rtc-cpcap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
index a603f1f21125..800667d73a6f 100644
--- a/drivers/rtc/rtc-cpcap.c
+++ b/drivers/rtc/rtc-cpcap.c
@@ -261,7 +261,7 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
 		return PTR_ERR(rtc->rtc_dev);
 
 	rtc->rtc_dev->ops = &cpcap_rtc_ops;
-	rtc->rtc_dev->range_max = (1 << 14) * SECS_PER_DAY - 1;
+	rtc->rtc_dev->range_max = (timeu64_t) (DAY_MASK + 1) * SECS_PER_DAY - 1;
 
 	err = cpcap_get_vendor(dev, rtc->regmap, &rtc->vendor);
 	if (err)
-- 
2.27.0

Re: [PATCH] rtc: cpcap: fix range

[Tony Lindgren]

* Sebastian Reichel <sebastian.reichel@collabora.com> [200629 11:42]:
> Unbreak CPCAP driver, which has one more bit in the day counter
> increasing the max. range from 2014 to 2058. The original commit
> introducing the range limit was obviously wrong, since the driver
> has only been written in 2017 (3 years after 14 bits would have
> run out).

So I guess with 14 bits vs 15 bits we have these date ranges:

1970 + (0x3fff / 365) = 2014
1970 + (0x7fff / 365) = 2059

Meaning we can't do the whole year for 2059 and it's only 2058
compatible like you say above :)

Acked-by: Tony Lindgren <tony@atomide.com>

Re: [PATCH] rtc: cpcap: fix range

[Merlijn Wajer]

Hi,

On 29/06/2020 13:41, Sebastian Reichel wrote:
> Unbreak CPCAP driver, which has one more bit in the day counter
> increasing the max. range from 2014 to 2058. The original commit
> introducing the range limit was obviously wrong, since the driver
> has only been written in 2017 (3 years after 14 bits would have
> run out).

This seems to work for me, thanks.

Please add as you deem appropriate:

Tested-by: Merlijn Wajer <merlijn@wizzup.org>
Acked-by: Merlijn Wajer <merlijn@wizzup.org>

Cheers,
Merlijn

Re: [PATCH] rtc: cpcap: fix range

[Alexandre Belloni]

On Mon, 29 Jun 2020 13:41:23 +0200, Sebastian Reichel wrote:
> Unbreak CPCAP driver, which has one more bit in the day counter
> increasing the max. range from 2014 to 2058. The original commit
> introducing the range limit was obviously wrong, since the driver
> has only been written in 2017 (3 years after 14 bits would have
> run out).

Applied, thanks!

What happen is that I can't count bits and so I though PCAP had 13 bits and
CPCAP 14 bits while it is indeed 14 and 15. I did the correct thing in the PCAP
driver though.

Thanks for the fix!

[1/1] rtc: cpcap: fix range
      commit: d6ac11f677ded28180fc9e59b01db79036c3ec31

Best regards,
-- 
Alexandre Belloni <alexandre.belloni@bootlin.com>

Re: [bug report] Droid 4 cpcap rtc

[Sebastian Reichel]

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

Hi,

On Mon, Jun 29, 2020 at 12:29:17AM +0200, Dev Null wrote:
> 1. writing to the rtc via rtc-cpcap with hwclock appears to not work at all.
> 	- see https://github.com/maemo-leste/bugtracker/issues/399
> 	- hwclock: ioctl(RTC_SET_TIME) to /dev/rtc0 to set the time failed: Numerical result out of range

Looks like a regression introduced by "rtc: cpcap: set range",
which landed in v5.7.

> 2. do you by any chance know how the RGB -> RGWRBW pentile color
> conversion happens on the droid 4? is this handled in hardware or
> in software or in firmware somewere?

The omapdrm RGB framebuffer is send to the DSI panel, which has its
own local framebuffer to support panel self refresh. The panel
controller does the format change transparently and does not offer
any configuration options as far as I know.

-- Sebastian

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