[rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[Michael Lange]

For RTC chips with no IRQ directly connected to the SoC, the RTC chip
can be forced as a wakeup source by stating that explicitly in
the device's .dts file using the "wakeup-source" boolean property.
This will guarantee the 'wakealarm' sysfs entry is available on the
device, if supported by the RTC.

With these changes to the driver rtc-ds1307 and the necessary entries
in the .dts file, I get an working ds1337 RTC on the Witty Pi extension
board by UUGear for the Raspberry Pi.

An example for the entry in the .dts file:

	rtc: ds1337@68 {
		compatible = "dallas,ds1337";
		reg = <0x68>;
		wakeup-source;

If the "wakeup-source" property is set, do not request an IRQ.
Set also UIE mode to unsupported, to get a working 'hwclock' binary.

Signed-off-by: Michael Lange <linuxstuff@milaw.biz>
---
 drivers/rtc/rtc-ds1307.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index aa705bb..7500b5c 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -860,6 +860,7 @@ static int ds1307_probe(struct i2c_client *client,
 	struct chip_desc	*chip = &chips[id->driver_data];
 	struct i2c_adapter	*adapter = to_i2c_adapter(client->dev.parent);
 	bool			want_irq = false;
+	bool			ds1307_can_wakeup_device = false;
 	unsigned char		*buf;
 	struct ds1307_platform_data *pdata = dev_get_platdata(&client->dev);
 	irq_handler_t	irq_handler = ds1307_irq;
@@ -907,6 +908,20 @@ static int ds1307_probe(struct i2c_client *client,
 		ds1307->write_block_data = ds1307_write_block_data;
 	}
 
+#ifdef CONFIG_OF
+/*
+ * For devices with no IRQ directly connected to the SoC, the RTC chip
+ * can be forced as a wakeup source by stating that explicitly in
+ * the device's .dts file using the "wakeup-source" boolean property.
+ * If the "wakeup-source" property is set, don't request an IRQ.
+ * This will guarantee the 'wakealarm' sysfs entry is available on the device,
+ * if supported by the RTC.
+ */
+	if (of_property_read_bool(client->dev.of_node, "wakeup-source")) {
+		ds1307_can_wakeup_device = true;
+	}
+#endif
+
 	switch (ds1307->type) {
 	case ds_1337:
 	case ds_1339:
@@ -925,11 +940,13 @@ static int ds1307_probe(struct i2c_client *client,
 			ds1307->regs[0] &= ~DS1337_BIT_nEOSC;
 
 		/*
-		 * Using IRQ?  Disable the square wave and both alarms.
+		 * Using IRQ or defined as wakeup-source?
+		 * Disable the square wave and both alarms.
 		 * For some variants, be sure alarms can trigger when we're
 		 * running on Vbackup (BBSQI/BBSQW)
 		 */
-		if (ds1307->client->irq > 0 && chip->alarm) {
+		if (chip->alarm && (ds1307->client->irq > 0 ||
+						ds1307_can_wakeup_device)) {
 			ds1307->regs[0] |= DS1337_BIT_INTCN
 					| bbsqi_bitpos[ds1307->type];
 			ds1307->regs[0] &= ~(DS1337_BIT_A2IE | DS1337_BIT_A1IE);
@@ -1144,6 +1161,14 @@ read_rtc:
 		return PTR_ERR(ds1307->rtc);
 	}
 
+	if (ds1307_can_wakeup_device) {
+		/* Disable request for an IRQ */
+		want_irq = false;
+		dev_info(&client->dev, "'wakeup-source' is set, request for an IRQ is disabled!\n");
+		/* We cannot support UIE mode if we do not have an IRQ line */
+		ds1307->rtc->uie_unsupported = 1;
+	}
+
 	if (want_irq) {
 		err = devm_request_threaded_irq(&client->dev,
 						client->irq, NULL, irq_handler,
-- 
2.4.10

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[Alexandre Belloni]

Hi,

On 21/01/2016 at 18:10:16 +0100, Michael Lange wrote :
> For RTC chips with no IRQ directly connected to the SoC, the RTC chip
> can be forced as a wakeup source by stating that explicitly in
> the device's .dts file using the "wakeup-source" boolean property.
> This will guarantee the 'wakealarm' sysfs entry is available on the
> device, if supported by the RTC.
> 
> With these changes to the driver rtc-ds1307 and the necessary entries
> in the .dts file, I get an working ds1337 RTC on the Witty Pi extension
> board by UUGear for the Raspberry Pi.
> 
> An example for the entry in the .dts file:
> 
> 	rtc: ds1337@68 {
> 		compatible = "dallas,ds1337";
> 		reg = <0x68>;
> 		wakeup-source;
> 
> If the "wakeup-source" property is set, do not request an IRQ.
> Set also UIE mode to unsupported, to get a working 'hwclock' binary.
> 

I don't think setting uie_unsupported is necessary because the alarm
functions will fail anyway. What kind of issue did you have?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[Michael Lange]

Hi,

> Hi,
>
> I don't think setting uie_unsupported is necessary because the alarm
> functions will fail anyway. What kind of issue did you have?
>

Tested today in the morning, before I had to go to work, the wakealarm
and the 'hwclock' binary with and without to set uie_unsupported in 
rtc-ds1307.


With uie_unsupported = 1:

The wakealarm is working, as expected:
   root@rbpi2 michael # echo +60 > /sys/class/rtc/rtc0/wakealarm
   root@rbpi2 michael # shutdown -h now
... wait, and the Raspberry comes up.

The hwclock binary is also working:
root@rbpi2 michael # LC_ALL=C hwclock -D -s
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1453438995 seconds after 1969
Last calibration done at 1453438995 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time 
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2016/01/22 05:05:29
Hw clock time : 2016/01/22 05:05:29 = 1453439129 seconds since 1969
Time since last adjustment is 134 seconds
Calculated Hardware Clock drift is 0.000000 seconds
Calling settimeofday:
     tv.tv_sec = 1453439129, tv.tv_usec = 0
     tz.tz_minuteswest = -60

root@rbpi2 michael # LC_ALL=C hwclock -D -w
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1453438995 seconds after 1969
Last calibration done at 1453438995 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time 
from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2016/01/22 05:05:48
Hw clock time : 2016/01/22 05:05:48 = 1453439148 seconds since 1969
Time since last adjustment is 153 seconds
Calculated Hardware Clock drift is 0.000000 seconds
missed it - 1453439148.507319 is too far past 1453439148.500000 
(0.007319 > 0.001000)
1453439149.500000 is close enough to 1453439149.500000 (0.000000 < 
0.002000)
Set RTC to 1453439149 (1453439148 + 1; refsystime = 1453439148.000000)
Setting Hardware Clock to 05:05:49 = 1453439149 seconds since 1969
ioctl(RTC_SET_TIME) was successful.
Not adjusting drift factor because the --update-drift option was not used.



After that, the kernel was compiled without setting ui_unsupported in
rtc-ds1307.c, and I got the following:

root@rbpi2 michael # LC_ALL=C hwclock -D -s
hwclock from util-linux 2.27.1
Using the /dev interface to the clock.
Last drift adjustment done at 1453439148 seconds after 1969
Last calibration done at 1453439148 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
select() to /dev/rtc to wait for clock tick timed out...synchronization 
failed

The wakealarm is still working fine.



The ds1337 on the Witty Pi extension board is connected to the i2c pins on
the Raspberry and the alarm pin is probably connected to a mosfet (F7319)
on this board, that powers up the Raspberry through the 5V-Pin on the
40pin-header.

But I'm not sure at all with the mosfet ... I'm not a electronics 
technician ...



An other example for a RTC and no IRQ to the CPU/Soc is in the rtc-isl12057
http://lxr.free-electrons.com/source/drivers/rtc/rtc-isl12057.c#L460
http://lxr.free-electrons.com/source/drivers/rtc/rtc-isl12057.c#L604

Without this patch the ds1337 got no wakealarm sysfs entry.



Regards
MichaeL

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[Alexandre Belloni]

Hi,

On 22/01/2016 at 16:35:39 +0100, Michael Lange wrote :
> >I don't think setting uie_unsupported is necessary because the alarm
> >functions will fail anyway. What kind of issue did you have?
> >
> 
> Tested today in the morning, before I had to go to work, the wakealarm
> and the 'hwclock' binary with and without to set uie_unsupported in
> rtc-ds1307.
> 
> 
> With uie_unsupported = 1:
> 
> The wakealarm is working, as expected:
>   root@rbpi2 michael # echo +60 > /sys/class/rtc/rtc0/wakealarm
>   root@rbpi2 michael # shutdown -h now
> ... wait, and the Raspberry comes up.
> 
> The hwclock binary is also working:
> root@rbpi2 michael # LC_ALL=C hwclock -D -s
> hwclock from util-linux 2.27.1
> Using the /dev interface to the clock.
> Last drift adjustment done at 1453438995 seconds after 1969
> Last calibration done at 1453438995 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> /dev/rtc does not have interrupt functions. Waiting in loop for time from
> /dev/rtc to change
> ...got clock tick
> Time read from Hardware Clock: 2016/01/22 05:05:29
> Hw clock time : 2016/01/22 05:05:29 = 1453439129 seconds since 1969
> Time since last adjustment is 134 seconds
> Calculated Hardware Clock drift is 0.000000 seconds
> Calling settimeofday:
>     tv.tv_sec = 1453439129, tv.tv_usec = 0
>     tz.tz_minuteswest = -60
> 
> root@rbpi2 michael # LC_ALL=C hwclock -D -w
> hwclock from util-linux 2.27.1
> Using the /dev interface to the clock.
> Last drift adjustment done at 1453438995 seconds after 1969
> Last calibration done at 1453438995 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> /dev/rtc does not have interrupt functions. Waiting in loop for time from
> /dev/rtc to change
> ...got clock tick
> Time read from Hardware Clock: 2016/01/22 05:05:48
> Hw clock time : 2016/01/22 05:05:48 = 1453439148 seconds since 1969
> Time since last adjustment is 153 seconds
> Calculated Hardware Clock drift is 0.000000 seconds
> missed it - 1453439148.507319 is too far past 1453439148.500000 (0.007319 >
> 0.001000)
> 1453439149.500000 is close enough to 1453439149.500000 (0.000000 < 0.002000)
> Set RTC to 1453439149 (1453439148 + 1; refsystime = 1453439148.000000)
> Setting Hardware Clock to 05:05:49 = 1453439149 seconds since 1969
> ioctl(RTC_SET_TIME) was successful.
> Not adjusting drift factor because the --update-drift option was not used.
> 
> 
> 
> After that, the kernel was compiled without setting ui_unsupported in
> rtc-ds1307.c, and I got the following:
> 
> root@rbpi2 michael # LC_ALL=C hwclock -D -s
> hwclock from util-linux 2.27.1
> Using the /dev interface to the clock.
> Last drift adjustment done at 1453439148 seconds after 1969
> Last calibration done at 1453439148 seconds after 1969
> Hardware clock is on UTC time
> Assuming hardware clock is kept in UTC time.
> Waiting for clock tick...
> select() to /dev/rtc to wait for clock tick timed out...synchronization
> failed
> 
> The wakealarm is still working fine.
> 

Ok, thanks, I'll try to reproduce on one of my boards but this shouldn't
happen. My current understanding is that uie_unsupported should only be
set when the alarm function is supported but the resolution is higher
than a second (usually a minute).

> 
> The ds1337 on the Witty Pi extension board is connected to the i2c pins on
> the Raspberry and the alarm pin is probably connected to a mosfet (F7319)
> on this board, that powers up the Raspberry through the 5V-Pin on the
> 40pin-header.
> 
> But I'm not sure at all with the mosfet ... I'm not a electronics technician
> ...
> 

I don't think it actually matter :)

> 
> 
> An other example for a RTC and no IRQ to the CPU/Soc is in the rtc-isl12057
> http://lxr.free-electrons.com/source/drivers/rtc/rtc-isl12057.c#L460
> http://lxr.free-electrons.com/source/drivers/rtc/rtc-isl12057.c#L604
> 
> Without this patch the ds1337 got no wakealarm sysfs entry.
> 

Sure, I understand the rationale behind the patch. I'll take it as is
and I'll investigate the uie_unsupported oddity.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [rtc-linux] [PATCH] rtc: ds1307.c: add support for the DT property 'wakeup-source'

[Alexandre Belloni]

On 21/01/2016 at 18:10:16 +0100, Michael Lange wrote :
> For RTC chips with no IRQ directly connected to the SoC, the RTC chip
> can be forced as a wakeup source by stating that explicitly in
> the device's .dts file using the "wakeup-source" boolean property.
> This will guarantee the 'wakealarm' sysfs entry is available on the
> device, if supported by the RTC.
> 
> With these changes to the driver rtc-ds1307 and the necessary entries
> in the .dts file, I get an working ds1337 RTC on the Witty Pi extension
> board by UUGear for the Raspberry Pi.
> 
> An example for the entry in the .dts file:
> 
> 	rtc: ds1337@68 {
> 		compatible = "dallas,ds1337";
> 		reg = <0x68>;
> 		wakeup-source;
> 
> If the "wakeup-source" property is set, do not request an IRQ.
> Set also UIE mode to unsupported, to get a working 'hwclock' binary.
> 
> Signed-off-by: Michael Lange <linuxstuff@milaw.biz>
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.