From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E215C433EF for ; Wed, 3 Nov 2021 10:06:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4DB13610E8 for ; Wed, 3 Nov 2021 10:06:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4DB13610E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XMxNVVdzrQZTL4x7H8x66PQ1CAoePWCuB/LAwDkg+uw=; b=yuRWryZGQ47TQ3 rkH79YLJqPt94p7PSdTbFckfhPy/gkvC012eGpW7XPOTQm6rPb0Pj/zFV/33u1BpFP+FVe5Ev/Mi/ BOfpPgiAwAIPRFNTZeQlbVzkdRYwAnbrseBmd2axNwdo3EIulk0ttxNis3TOd/4fdbyMUpDhvLlMP 4e32Mi3+DTet8InQ55L1Hrep5FUe3X51ZpWITHAIvn6gtOeZMyoG2T47MX75236JKOiXtiEw4tFt3 RNbIaeNznFRaCBVGDGGl6+8ni53DBFGFpHiIcWZGPkP73A4p+KDYdvamHF46y207F/Mz4WMlyDO+Q Kt2OU0EJ/ojmQPWZVtuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1miD8H-004o0Y-0D; Wed, 03 Nov 2021 10:04:37 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1miD8B-004nyk-TI for linux-arm-kernel@lists.infradead.org; Wed, 03 Nov 2021 10:04:33 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C331D6E; Wed, 3 Nov 2021 03:04:30 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.75.102]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B8073F719; Wed, 3 Nov 2021 03:04:27 -0700 (PDT) Date: Wed, 3 Nov 2021 10:04:18 +0000 From: Mark Rutland To: Youngmin Nam Cc: Krzysztof Kozlowski , will@kernel.org, daniel.lezcano@linaro.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, pullip.cho@samsung.com, hoony.yu@samsung.com, hajun.sung@samsung.com, myung-su.cha@samsung.com, kgene@kernel.org Subject: Re: [PATCH v2 1/2] clocksource/drivers/exynos_mct_v2: introduce Exynos MCT version 2 driver for next Exynos SoC Message-ID: <20211103100407.GA35817@C02TD0UTHF1T.local> References: <20211102001122.27516-1-youngmin.nam@samsung.com> <20211102001122.27516-2-youngmin.nam@samsung.com> <20211102102802.GA16545@C02TD0UTHF1T.local> <20211103000945.GA48132@perf> <83f6574b-bbab-f0c3-7198-f773c3dcfc63@canonical.com> <20211103092444.GA7013@perf> <20211103095727.GA19093@perf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211103095727.GA19093@perf> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211103_030432_090778_43DC1C6D X-CRM114-Status: GOOD ( 34.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 03, 2021 at 06:57:28PM +0900, Youngmin Nam wrote: > On Wed, Nov 03, 2021 at 10:04:36AM +0100, Krzysztof Kozlowski wrote: > > On 03/11/2021 10:24, Youngmin Nam wrote: > > > On Wed, Nov 03, 2021 at 09:18:07AM +0100, Krzysztof Kozlowski wrote: > > >> On 03/11/2021 01:09, Youngmin Nam wrote: > > >>> On Tue, Nov 02, 2021 at 10:28:10AM +0000, Mark Rutland wrote: > > >>>> On Tue, Nov 02, 2021 at 09:11:21AM +0900, Youngmin Nam wrote: > > >>>>> + evt->rating = 500; /* use value higher than ARM arch timer */ > > >>>> > > >>>> Previously Will asked you to try CLOCK_EVT_FEAT_PERCPU here, and to set > > >>>> the C3STOP flag on the arch timer via the DT when necessary, rather than > > >>>> trying to override the arch timer like this: > > >>>> > > >>>> https://protect2.fireeye.com/v1/url?k=72526080-2dc9598b-7253ebcf-002590f5b904-ca603717c6462908&q=1&e=be56aa83-dbac-4639-913d-d388620fe3fc&u=https%3A%2F%2Flore.kernel.org%2Fr%2F20211027073458.GA22231%40willie-the-truck > > >>> Hi Mark. > > >>> It looks like you missed my previous mail. > > >>> https://protect2.fireeye.com/v1/url?k=ab15817a-cbf71c27-ab140a35-000babd9f1ba-123b7f313b1b1ccc&q=1&e=34c8716e-6d2e-4d8e-82fe-04777ebc5eb3&u=https%3A%2F%2Flore.kernel.org%2Fall%2F20211029035422.GA30523%40perf%2F%23t > > >>> > > >>> Yes, I believe Will's suggestion definitely will work. Then please do so. > > >>> But that is for performance not functionality. No; it's about *consistency*, and avoiding unnecssary special cases. The whole point is that marking the generic timer as C3STOP *accurately* describes how the timer behaves on your platform, and marking the MCTv2 as a percpu timer which *can* act as a back-up also aligns with that. That approach leaves the policy in the kernel, and we can play about with that later without functional breakage. > > >>> As a driver for new H/W IP I would like to confirm functionality first. > > >>> We need more time to test this feature with our exynos core power down feature. > > >>> And we need to do a various regression test whether there is another corner case or not. > > >>> So, how about we apply Will's suggetion later after the current patchset is merged first? > > >>> After doing our regression test with our exynos core power down feature, we can confirm this. > > >> > > >> Not really, because once it is merged there is no incentive to fix it or > > >> simply changing it can be forgotten. Also similarly to commit > > >> 6282edb72bed ("clocksource/drivers/exynos_mct: Increase priority over > > >> ARM arch timer"), there should be a valid and serious reason to > > >> prioritize Exynos MCT. It's also worth nothing that the case described for 6282edb72bed is really a system design erratum, since the counter is supposed to be in an always-on power domain and should be counting well before a regular OS kernel boots. The arm64 kernel requires the architected counter to be running before it is entered, or there will be subtle breakage. > > > No, it's not. I also want to decrease MCTv2 timer rating so that we want to use arm arch timer as a default. > > > But this feature has to be confirmed with core power down feature enabled. > > > Without core power down feature, we can't comfirm this. > > > Ater that we need to check whether there is regression or not related power, stability, and so on. > > > I'm not saying I will not apply Will's suggestion but I just want to apply later after some hard test. > > > > You repeat the same argument, the same words. Nothing new. Repeating the > > same won't change it, use the lower priority. This is a patch for new > > kernel, so there is a plenty of time to test it and it won't affect your > > production environment. > > > So, how about we control timer rating value with DT ? > Of course the default rating value should be lower than arm arch timer's. > Do you agree with this? No; placing a rating value in the DT is a hack. That should *not* live in the DT because it's linux-internal detail and not a description of the HW. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel