public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@denx.de>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: cip-dev@lists.cip-project.org,
	Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>,
	Pavel Machek <pavel@denx.de>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 5.10.y-cip 12/13] rtc: isl1208: Add a delay for clearing alarm
Date: Tue, 30 Jul 2024 14:30:38 +0200	[thread overview]
Message-ID: <Zqjc7hY7eEXVDTfX@duo.ucw.cz> (raw)
In-Reply-To: <20240729153504.510443-13-biju.das.jz@bp.renesas.com>

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

Hi!

> commit 0dbd610c426ed695eef5d26584259d96b6250c76 upstream.
> 
> As per the latest HW manual[1], the INT# output is pulled low after the
> alarm is triggered. After the INT# output is pulled low, it is low for at
> least 250ms, even if the correct action is taken to clear it. It is
> impossible to clear ALM if it is still active. The host must wait for the
> RTC to progress past the alarm time plus the 250ms delay before clearing
> ALM.

> [1]https://www.renesas.com/us/en/document/dst/raa215300-datasheet?r=1506351

Ok, so this is kind of interesting. Yes, Renesas hw manual documents
250ms delay, but is that true for other chips? This seems to be
generic driver.

> +++ b/drivers/rtc/rtc-isl1208.c
> @@ -7,6 +7,7 @@
>  
>  #include <linux/bcd.h>
>  #include <linux/clk.h>
> +#include <linux/delay.h>
>  #include <linux/i2c.h>
>  #include <linux/module.h>
>  #include <linux/of_device.h>
> @@ -628,6 +629,18 @@ isl1208_rtc_interrupt(int irq, void *data)
>  	struct isl1208_state *isl1208 = i2c_get_clientdata(client);
>  	int handled = 0, sr, err;
>  
> +	if (!isl1208->config->has_tamper) {
> +		/*
> +		 * The INT# output is pulled low 250ms after the alarm is
> +		 * triggered. After the INT# output is pulled low, it is low for
> +		 * at least 250ms, even if the correct action is taken to clear
> +		 * it. It is impossible to clear ALM if it is still active. The
> +		 * host must wait for the RTC to progress past the alarm time
> +		 * plus the 250ms delay before clearing ALM.
> +		 */
> +		msleep(250);
> +	}

Plus 250 msec in interrupt handler is strange. I guess this is i2c so
you can sleep, but... Plus I'd expect it to be conditional on we
having the alarm interrupt?

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

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

  reply	other threads:[~2024-07-30 12:30 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-29 15:34 [PATCH 5.10.y-cip 00/13] RZ/G2L enhancements Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 01/13] reset: rzg2l-usbphy-ctrl: Move reset controller registration Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 02/13] regulator: core: Add helper for allow HW access to enable/disable regulator Biju Das
2024-07-30 12:28   ` Pavel Machek
2024-07-30 12:32     ` Biju Das
2024-07-31 10:06       ` Pavel Machek
2024-07-31 13:08         ` Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 03/13] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document USB VBUS regulator Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 04/13] reset: renesas: Add USB VBUS regulator device as child Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 05/13] regulator: Add Renesas RZ/G2L USB VBUS regulator driver Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 06/13] regulator: renesas-usb-vbus-regulator: Update the default Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 07/13] regulator: Further restrict RZG2L USB VBCTRL regulator dependencies Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 08/13] phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCs Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 09/13] arm64: dts: renesas: rz-smarc: Replace fixed regulator for USB VBUS Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 10/13] dmaengine: sh: rz-dmac: Fix lockdep assert warning Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 11/13] dt-bindings: watchdog: dlg,da9062-watchdog: Drop blank space Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 12/13] rtc: isl1208: Add a delay for clearing alarm Biju Das
2024-07-30 12:30   ` Pavel Machek [this message]
2024-07-30 12:34     ` Biju Das
2024-07-29 15:34 ` [PATCH 5.10.y-cip 13/13] rtc: isl1208: Update correct procedure " Biju Das
2024-07-30 12:25 ` [PATCH 5.10.y-cip 00/13] RZ/G2L enhancements Pavel Machek
2024-07-31 10:07 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zqjc7hY7eEXVDTfX@duo.ucw.cz \
    --to=pavel@denx.de \
    --cc=biju.das.jz@bp.renesas.com \
    --cc=cip-dev@lists.cip-project.org \
    --cc=nobuhiro1.iwamatsu@toshiba.co.jp \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox