From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58885367285 for ; Wed, 12 Aug 2026 11:49:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786535367; cv=none; b=JwPotkvS2wd4ax4tNbtwy9s+w6mkdsDUitaHalgDl6ghTOXWbuCJd2v4ckJ3eAOUeRWYSD8TBhDyTc2jUSLmI2zl4uty8Vjk5NHd4kz8jx+bQfCtuajQmGd0IcchymubbgavKoBLLBSmuKOdbba/qNUe622pfQhsV74c9sqWmeE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786535367; c=relaxed/simple; bh=nxvL0AK6niVXMz1Fn/ec2Ck1XXsRkMZvaVNGXb65JMY=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=rfIXGgIvx9HgeMc/gY2wrWdkgzwqA4qeA/ewUfBSeU450wLYyz9HgTccKU4SMGXKxXJmRzCb5+DqvsG1ju/IKvxeY04HPXyctWdrWG18du6FDsdeeX6M22x46gVSJb/AN/GhcTzYZviRH8rjhhh2kjggohvSllfokKEUfTaiUJ4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=iqtLTZSy; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=aZf5Ili/; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="iqtLTZSy"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="aZf5Ili/" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67CB4pGR3963810 for ; Wed, 12 Aug 2026 11:49:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= H3hQKhgDiWny7vxdESXleC4boEjiTAY24LazqRntx8A=; b=iqtLTZSyV0QTcKzC DMRJumJbXlMmY8D1MKoc7V+HgfsXCYzwlr3rdUd4THZPaSKbaDPuO+FXDqo8FsZu 0vmVn7zyCeDh6lSOe6QSp/1QEJ1wi9bUlxBGLz0hGuXb155PEWfv0wy5yVWaIses EXi/frQWfLoHPYWTjcKbKJkmFMqyyNYxVz13cfCrvPuZ08rZGtzKH367fN/Jx0bg xiu/zACbURqbHENZhB+5Axh0+rGaLI6fXu1Fjqw2wTVZYt9MDdVkpN6c/hiJFIQZ ZMBroXUhbZ6XJka5C4mbwSlIsoym4zoHmFymZzliXh1wFW1qCFlUlWR8CpVUlMJ4 xw5Dhw== Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4g0nucgkkh-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 12 Aug 2026 11:49:25 +0000 (GMT) Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-51c12e43b98so10312591cf.1 for ; Wed, 12 Aug 2026 04:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1786535364; x=1787140164; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=H3hQKhgDiWny7vxdESXleC4boEjiTAY24LazqRntx8A=; b=aZf5Ili/kva3hFxxj6UjWZKCTcis9gdyuqWWNy1/kAIG0KJXwWc0ZDLVs08QGL4u7s TKKHo6K3WEDS3O89/3dXOPaJ5jk5+/5RojSWkCzWTsKS3aFNyRcHDjGJaL3pbmLC2t3C bgAn5AM266xJBKF+dRY6vdElJF3Gzc+Fhi4lUoS15J3j1ImeevE82YVFxqcnypn8YlT6 a9AVP503UoN9HSJlgkU57GeiBKvOF2OUtp6eHmhGq1GHEpKAjC9m13zROj8lGpRO4i0S ZcpmvKuumSbIguMjfNYiBiItFx0EEpgrM/gbrpiENqqcBAiLbjdCU0wIhUZsZlmcTyI2 EFhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786535364; x=1787140164; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=H3hQKhgDiWny7vxdESXleC4boEjiTAY24LazqRntx8A=; b=ZTw6l4QcP3WDeMXnrP/EHLChRkAXk0OuHvR7/zNvR39pSpfgV7gcb4vzsAznucg5J5 zenhJKucUJZ9TTcBYJ81Cq8+3IoDRD5jcg0pnQ0jp4KGP0LOqST68AUNkGfjy3PekqTh zshHyIZkaXJFm4ymJqp0m92pp0wFGMZzsgLeYzZqEesfCwSnKpFtPl6PdQkgmxJT3uJd Vc2yVt0kWZxUVxb/d2TY3N50N2RhoW8h05GdxE7fp54Ik3T6H1Cm/f1VVAKmcwWo7ur+ jk4UZ6v8yUOkx9yoYhdMA85mJIWXLWKMAphL7BzfcVFhejo+k1lGQuZ2Irp7jfjfc+Jo qhWQ== X-Forwarded-Encrypted: i=1; AHgh+RqwzkPogycj5rNVjDk0Fe85Tx45+jLVtNd6ealLY8/OTOSASLeGFdp7sUL+eDT2vm0UsGiQeriXydr4j2s=@vger.kernel.org X-Gm-Message-State: AOJu0YzBRW5tAgsBF/VEYmFxZ/+NMNT8ffG7ncTLK8/XOXn7k1uKcjTH SHBRFHGe7gV9oqjhDemkX0iky5Z0O0q3CmOOVYo6SiTHuHKZSGyP+5EnqracxUV6phOl5gC27K1 2JdgTvoSvmZEtw402lHq4go9jOhzC+VQvSpfQAXC1B4p36Q4vH8g5acWhTEBv386wHVs= X-Gm-Gg: AR+sD11bCeh/QqisCRIPk+0tgZRKI2c0C2vce/SJYi94/2feSH09UGO+7x5NPfCYHH+ qwm+4h3vtz9c75znn1TJN4+/Uwuv7cg4bZ+dneAj+VgPyd0EFoqAtlseJBkhSDuflZapDKJPMhF wjr7J9NVvUcbyaTYblUx+gpGQEFiZpQNpPqbeEU8fT2famQUKeCu5A8ZAn/MTcsuyNoHo3QGpqP kYxzo+QgaS7NvwjOiOqfVgbuNxEDFbkVJGBrXYtybO33SKOXWZAlAYQQyAvjJDv9AEoJGzacOgs SkAjd/q3R2yKm5HSjKnvWp010Tjdhb0LTiTuTC5y7GKq38oJ6UvOAFt3FZ8r89f5Iqzox5Ritqx xMF4MCc9jC5h2ur6tZD5puj4FlfUdECeEk++/79O9IaLMmxYLZAs5PCef8CBn24Q= X-Received: by 2002:a05:622a:350:b0:51c:84f0:d903 with SMTP id d75a77b69052e-52d6473a1b8mr32496931cf.17.1786535364357; Wed, 12 Aug 2026 04:49:24 -0700 (PDT) X-Received: by 2002:a05:622a:350:b0:51c:84f0:d903 with SMTP id d75a77b69052e-52d6473a1b8mr32496521cf.17.1786535363881; Wed, 12 Aug 2026 04:49:23 -0700 (PDT) Received: from ?IPV6:2a05:6e02:1041:c10:d71e:6d83:9df1:6316? ([2a05:6e02:1041:c10:d71e:6d83:9df1:6316]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4997aaa5d04sm64004465e9.2.2026.08.12.04.49.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Aug 2026 04:49:21 -0700 (PDT) Message-ID: <9fb18d37-0406-46e6-8552-fb925dc14fad@oss.qualcomm.com> Date: Wed, 12 Aug 2026 13:49:18 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] clocksource/drivers/sun4i: Wait for pending reload before CTRL write To: =?UTF-8?Q?Ond=C5=99ej_Jirman?= , linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org, Daniel Lezcano , Thomas Gleixner , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , Maxime Ripard , "moderated list:ARM/Allwinner sunXi SoC support" References: <20260725113341.2250687-1-megi@xff.cz> <9e9003b7-0331-4b37-9b06-5e9de887199e@oss.qualcomm.com> Content-Language: en-US From: Daniel Lezcano In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-GUID: zeqXaVNUog756fa6LRM-LM5EE7bGWtRf X-Proofpoint-ORIG-GUID: zeqXaVNUog756fa6LRM-LM5EE7bGWtRf X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEyMDA5NSBTYWx0ZWRfX2CcsBQc7PK4a xMKauIriLNOLwuV2RgXKLhwMpVokoIKRrcmHMZxcWOh5w2TvBi7eq2U2WM5u/HLj1PvZNb9f6z/ le88ggitLMJcvUQBQyanvwSABRoceU2YXcBZDrKPHOiNiYGoWzPoxUnCoFKpE7rZtvnrALPhhRb HbEDk65I0ODE4T6Q3HdbI8c8bj0IwWnbkDkgjQ6qpS0R3lnItIRWHzyndOKU2X8yU2vAd28l2m6 ehuBYuGGEY9nyCTGZom8a6KoJB0FC+m8Gz/tykurMz3+jOQsk84v4/wj858W+EhpoUChkYqRhjK bFAC4kNKS76VQCCJaa0n+r61s+VvEMHMhnuTEHhppOCyS4haCtmVPsQaygND4IYsdkFatytCM3D aVPmumFpSBXAYaR+0dDdWy44Oi/4eCDLjrn6pZPtzdKGWfpOAbJBO1HoezqlgSRakV5eueIompK Vb0oZwf7tKA3qLvZA9g== X-Authority-Analysis: v=2.4 cv=VcjH+lp9 c=1 sm=1 tr=0 ts=6a7c5dc5 cx=c_pps a=EVbN6Ke/fEF3bsl7X48z0g==:117 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=SbrujaV1hovVMzGLTeQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=a_PwQJl-kcHnX1M80qC6:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwODEyMDA5NSBTYWx0ZWRfX7gQbt3jB3hGD 0DBw8dF8GzzCH/4a+m3EU48UYIWFHasu3FBxd5cBkmnS48Ki1/G4L7OQc215GHnETJ3GzGvzUPW 5n15mkX0jtN/eUILYhceUiZ3EDHds3M= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-12_03,2026-08-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 adultscore=0 priorityscore=1501 phishscore=0 suspectscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608120095 On 8/12/26 13:09, Ondřej Jirman wrote: > Hello Daniel, > > On Wed, Aug 12, 2026 at 11:56:03AM +0200, Daniel Lezcano wrote: >> On 7/25/26 13:33, Ondřej Jirman wrote: >>> From: Ondrej Jirman >>> >>> The A13 manual says of TMR0_RELOAD: "After the bit is set, it can not be >>> written again before it's cleared automatically." Both time_stop() and >>> time_start() read-modify-write the control register, so a reload still in >>> flight gets rewritten and the write can be dropped, leaving the timer >>> unarmed. In oneshot mode this happens on every tick, and the tick >>> eventually stops for good. >>> >>> Wait for the reload to clear first. All control register updates go >>> through sun4i_clkevt_time_stop(). >>> >>> Without this my Allwinner A13 based Pocketbook Touch Lux 3 stops >>> scheduling processes during boot or within a few seconds of executing >>> userspace. Only sysrq+t over serial port works at this stage, which is >>> how I discovered the root cause. >>> >>> Fixes: 7e14183469d8 ("clocksource: sun4i: Fix bug when switching from periodic to oneshot modes") >>> Signed-off-by: Ondrej Jirman >>> --- >>> BTW, similar issue will likely be also in timer-sun5i.c but I don't have any >>> device that would exercise it. And it's possible that this triggers more easily >>> with CONFIG_HZ=1000 which I use. >>> >>> drivers/clocksource/timer-sun4i.c | 26 +++++++++++++++++++++++++- >>> 1 file changed, 25 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/clocksource/timer-sun4i.c b/drivers/clocksource/timer-sun4i.c >>> index 7bdcc60ad43c..2e7457f671c4 100644 >>> --- a/drivers/clocksource/timer-sun4i.c >>> +++ b/drivers/clocksource/timer-sun4i.c >>> @@ -39,6 +39,9 @@ >>> #define TIMER_SYNC_TICKS 3 >>> +/* The reload bit clears a couple of source clock cycles after it is set. */ >>> +#define TIMER_RELOAD_MAX_POLL 100 >>> + >>> /* >>> * When we disable a timer, we need to wait at least for 2 cycles of >>> * the timer source clock. We will use for that the clocksource timer >>> @@ -53,9 +56,30 @@ static void sun4i_clkevt_sync(void __iomem *base) >>> cpu_relax(); >>> } >>> +/* >>> + * The control register must not be written while a reload is still in >>> + * flight, or the write can be dropped. >>> + */ >>> +static int sun4i_clkevt_wait_reload(void __iomem *base, u8 timer) >>> +{ >>> + int i; >>> + >>> + for (i = 0; i < TIMER_RELOAD_MAX_POLL; i++) { >>> + if (!(readl(base + TIMER_CTL_REG(timer)) & TIMER_CTL_RELOAD)) >>> + return 0; >>> + cpu_relax(); >>> + } >> >> The loop looks correct but I'm wondering why not use the helper: >> >> ret = readl_poll_timeout_atomic(base + TIMER_CTL_REG(timer), val, >> !(val & TIMER_CTL_RELOAD), 0, timeout); >> > > I can. The only difference would be that this would loop up to 1000 * timeout > times, instead of 100 times in case reload bit never returns to 0. But that > never happens anyway. Sorry I don't get the 1000 * timeout Does the documentation says anything about the duration before the register is cleared ? >>> + return -ETIME; >>> +} >>> + >>> static void sun4i_clkevt_time_stop(void __iomem *base, u8 timer) >>> { >>> - u32 val = readl(base + TIMER_CTL_REG(timer)); >>> + u32 val; >>> + >>> + sun4i_clkevt_wait_reload(base, timer); >> >> If it fails ? > > There's not much to do, since sun4i_clkevt_time_stop() does not return anything > anyway and it's used across the file quite extensively. Well, the file is small, > but sun4i_clkevt_time_stop is called in every function exported via timer_of > struct... :) > > I can rewrite all these functions to report all errors to timer core, but in > practice reload always resets very quickly, and a condition where the loop even > loops happens once every few seconds or so. I doubt anything but return 0 > would ever happen anyway. I'd certainly notice, because it would again cause > instant lockup of my e-reader. Maybe I can just return void from > sun4i_clkevt_wait_reload() and not pretend there are errors to report, > instead? IMO, returning void is fine along with a message, may be a WARN as it is really, AFAIU, not supposed to happen. It will be easy for anyone to find out where the issue is coming from