From patchwork Tue Jun 18 15:26:29 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Biju Das X-Patchwork-Id: 13702518 Received: from relmlie6.idc.renesas.com (relmlor2.renesas.com [210.160.252.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5FC7C1E895; Tue, 18 Jun 2024 15:26:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.160.252.172 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718724411; cv=none; b=EXj+8zapcdxkHPfXfX5BjuLSmkJ8e657IlpAayTNWrfoh9gUKmfn2Mq43SWnKuvOIbzpbwr8uxeNDIxBFeB04CIdM5Y36lmkg0d3hLhbJkOiG+1690eC3aZK72lWvrRBoZCFsJWeGW12Zz/LpTUzls46AyqHUZUwSjmtu5QTsug= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718724411; c=relaxed/simple; bh=nQhEqavArIQ/hs+sfgW4QyFhU59OZMb6rIk6RRvZsQI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=oxKmLfWv45fZzPChZk2YvmOu1mR734PxJXD/eyHIOs42AuHVGIzzhaIRtKhKvKxyjTuEa4ONbNYP2fvve+/Odaq0jsNAxXS2EeK8HOpAc7QhPzpBXnMtM0K+Tf1gO0xqTC2qImphFY75IV7sqVqaWOzX1FTa4t3SbonpMCQ0AgI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bp.renesas.com; spf=pass smtp.mailfrom=bp.renesas.com; arc=none smtp.client-ip=210.160.252.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bp.renesas.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bp.renesas.com X-IronPort-AV: E=Sophos;i="6.08,247,1712588400"; d="scan'208";a="212384983" Received: from unknown (HELO relmlir6.idc.renesas.com) ([10.200.68.152]) by relmlie6.idc.renesas.com with ESMTP; 19 Jun 2024 00:26:40 +0900 Received: from localhost.localdomain (unknown [10.226.93.44]) by relmlir6.idc.renesas.com (Postfix) with ESMTP id 2CDE14006A90; Wed, 19 Jun 2024 00:26:37 +0900 (JST) From: Biju Das To: Alexandre Belloni Cc: Biju Das , linux-rtc@vger.kernel.org, Geert Uytterhoeven , Prabhakar Mahadev Lad , Biju Das , linux-renesas-soc@vger.kernel.org Subject: [PATCH 0/2] Update correct procedure for clearing alarm Date: Tue, 18 Jun 2024 16:26:29 +0100 Message-ID: <20240618152635.48956-1-biju.das.jz@bp.renesas.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-renesas-soc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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. Apart from this, there is an internal delay(~250 microsec) from setting ALME = 0 to disabling the alarm function, so the user must add a short delay of greater than 250µs between setting ALME = 0 and clearing ALM. Currently setting of ALME = 0 is done after clearing the ALM, so just reverse the operation and add a delay of 275 microsec. Also add a 250msec delay before clearing the ALM. [1]https://www.renesas.com/us/en/document/dst/raa215300-datasheet?r=1506351 Biju Das (2): rtc: isl1208: Add a delay for clearing alarm rtc: isl1208: Add correct procedure for clearing alarm drivers/rtc/rtc-isl1208.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-)