Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp3651454pxf; Mon, 22 Mar 2021 11:27:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiSViDGzBhWVTYzZ+pEnqQ3nr1iPoSH9vf9ijHmnbN6BbK9rQYXiKlzvJdzwWLym9YFWaF X-Received: by 2002:a17:906:58c9:: with SMTP id e9mr1128506ejs.26.1616437658626; Mon, 22 Mar 2021 11:27:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616437658; cv=none; d=google.com; s=arc-20160816; b=bsm9qxpCXjxzwvKvYM2uQL3KYmEiJewWgl8nWCVXHiG9T5gwcGPtSiV8VBO+zTRmkW HZEpZoT0l/3uB3X8falcYtAO0H0Fl+V2eA9zebc6+B7fAuY34vfbB7JDscCyYGNZ8uYt HfE4x50a2mOfZ1TW37B6BZs0+1JyXvbO8JOcSVi0ifHq/e1YqYkOa8fCoQ+ZIY5qioG6 9Ahw1byA6FSoRvny561/f0W+c19hIHcO0shCQk7FrqelWXQUGw1VmgK6Oif2D/j2mFJx Ym3HWDnHYhvhT1wRePNkdnmUxTVpS+uOgdBfT+E47p6VgZdKZW0EsZehiOivG8Zwg3Z6 +dwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=ySJvyA1Vk+WlWIAVpdaEw/cb8TtbtV3XIc6h1+nRJT4=; b=uc4vDOmIP+yLpcIn76cOC8SggWw5pXG27AS5ljaKS9UPToDMdn1Kmn/QqCm6wk74Jz hlm72Mfs6fw2RIji90opXUhZ1Bz7Wrz67Fzers8HTee8gOdsSXoltruZ2g6ijqy2Y94c Iv7lo9M0VxQYIaJQ6eKrOSEc7GCvjQ2Rf0vskwsgSy1A6IYp+ZC8x55w6own73oIZC7f mZcDZf4/l4tfcmnQ6Ar25gsWGrJfABch4HIqzN2Ee25HMzPtRAHVtm+Rz1jZoezRrB7D oe23JROWSeDFUfsKE2rWNl0fmz/qBvgokg781vMM3MRhs4ZLJNNI3JkEu645CyAZKSW1 y2uA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EYEwtse8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ss21si11929887ejb.338.2021.03.22.11.27.16; Mon, 22 Mar 2021 11:27:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EYEwtse8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231249AbhCVSYF (ORCPT + 99 others); Mon, 22 Mar 2021 14:24:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231694AbhCVSXk (ORCPT ); Mon, 22 Mar 2021 14:23:40 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 595A6C061574 for ; Mon, 22 Mar 2021 11:23:39 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id n11-20020a05600c4f8bb029010e5cf86347so11409697wmq.1 for ; Mon, 22 Mar 2021 11:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ySJvyA1Vk+WlWIAVpdaEw/cb8TtbtV3XIc6h1+nRJT4=; b=EYEwtse8Tfbhei4D4G24ggUMmPdbnWhNGAn/uaCsHWSGN1xHWkp8XNQsZBlU0rmqPP OF5bevWmwR8En6oyPXRetZsPWZS2pqtMWpVZU0rN7Z4CfBTvhLuQBoLRN1KI1SIfpNcu i79FSRJldWPSD8A5W8PK9kTpgwuvDKYmEb7SV8ptL+u2AXXZV4TkSCE04HukddGcgQNo kF0G3Pu5VkORcwFIlTNVoT9NDMmQp4iip/TgsIeMS8Xe8WXyC4IRrr6pLUTnNWkEBCum GZlsN8VzA/eTXih8JSucA3+ld59QNXphmZL2KPaPOwywrrBFjFlgAZYZIVd6KkfzpcNy 04pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ySJvyA1Vk+WlWIAVpdaEw/cb8TtbtV3XIc6h1+nRJT4=; b=ZKKvWPU2ORjQrY8Ljnq1odMrIz6qFiZ+CT3Fpi26XfJWTDep3/cBI287lC6gL3bvqD HvaTLyzL+caTXaO9MUd3v+gZXoOu2M6xu2FBQUt8gFNp4evCJNvslM0CSSMZAKjvdd9r lEg6fxyuuMDcna70Q/KZ3fk2r6rleEpuMtBO5qXeCAi68QhTt/0YP6TWaSYI+bbVnJm3 0ZaMJbBp7r1wdW3thuXMJpebmA6vazm4IVzMnO+bCvPqBhNPebzFNkztV/gfL7fB8MKu Pywaaz5UCrw94EMiLyeJJ2Lhg0xu0D3ARlqGVEUuGgdbGv4sAJJvbMdLpybScIjxJYbt S6Bg== X-Gm-Message-State: AOAM533gueDER/2WPKon0+daUk2ndQYr8aZK8xOdSioK0VKj3Ew+ZGE/ rWLDW0ucsrxe50xLGt332TheGQ== X-Received: by 2002:a1c:771a:: with SMTP id t26mr317022wmi.60.1616437417956; Mon, 22 Mar 2021 11:23:37 -0700 (PDT) Received: from ?IPv6:2a01:e34:ed2f:f020:2091:71d6:3ab2:37f2? ([2a01:e34:ed2f:f020:2091:71d6:3ab2:37f2]) by smtp.googlemail.com with ESMTPSA id v18sm21863898wrf.41.2021.03.22.11.23.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Mar 2021 11:23:37 -0700 (PDT) Subject: Re: [PATCH 1/2] clocksource/drivers/timer-ti-dm: Prepare to handle dra7 timer wrap issue To: Tony Lindgren Cc: Thomas Gleixner , Keerthy , linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Tero Kristo References: <20210304073737.15810-1-tony@atomide.com> <20210304073737.15810-2-tony@atomide.com> <556d55af-0b30-8751-6aef-2e1bb9db1a76@linaro.org> From: Daniel Lezcano Message-ID: <5c3c2447-3f8c-160c-8761-e43c1b4ebbf9@linaro.org> Date: Mon, 22 Mar 2021 19:23:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/03/2021 17:33, Tony Lindgren wrote: > Hi, > > * Daniel Lezcano [210322 15:56]: >> On 04/03/2021 08:37, Tony Lindgren wrote: >>> There is a timer wrap issue on dra7 for the ARM architected timer. >>> In a typical clock configuration the timer fails to wrap after 388 days. >>> >>> To work around the issue, we need to use timer-ti-dm timers instead. >>> >>> Let's prepare for adding support for percpu timers by adding a common >>> dmtimer_clkevt_init_common() and call it from dmtimer_clockevent_init(). >>> This patch makes no intentional functional changes. >>> >>> Signed-off-by: Tony Lindgren >>> --- >> >> [ ... ] >> >>> @@ -575,33 +574,60 @@ static int __init dmtimer_clockevent_init(struct device_node *np) >>> */ >>> writel_relaxed(OMAP_TIMER_CTRL_POSTED, t->base + t->ifctrl); >>> >>> + if (dev->cpumask == cpu_possible_mask) >>> + irqflags = IRQF_TIMER; >>> + else >>> + irqflags = IRQF_TIMER | IRQF_NOBALANCING; >> >> Can you explain the reasoning behind the test above ? > > In the per cpu case we assign one dmtimer per cpu, and we want the > interrupt handling on the assigned CPU. In the per cpu case we have > the cpu specified with dev->cpumask unlike for the normal clockevent > case. > > In the per cpu dmtimer case the interrupt line is not wired per cpu > though, so I don't think we want to add IRQF_PERCPU here. If it is per cpu, then the parameter will be cpumask_of(cpu). If there is one cpu, no balancing can happen and then the IRQF_NOBALANCING is not needed, neither this test and the irqflags, right? -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog