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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E134BC11D30 for ; Mon, 24 Feb 2020 15:13:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7F3920836 for ; Mon, 24 Feb 2020 15:13:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DlXk+F01" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727877AbgBXPM6 (ORCPT ); Mon, 24 Feb 2020 10:12:58 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:38028 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727299AbgBXPM6 (ORCPT ); Mon, 24 Feb 2020 10:12:58 -0500 Received: by mail-lf1-f68.google.com with SMTP id r14so7043226lfm.5; Mon, 24 Feb 2020 07:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NqBC/JTdN8Jhgh77Z/JOfc6onLMRt8x9FgCKxFMToSA=; b=DlXk+F01D5V+hjxzKQ+R4TXFvFhnIHeH8JPudsn9Hc5uGSSnb6hL1oOwSF/UQI8/5J LXgke8razdDXQKYoi13jw/YPN92bqblOlA6Y51aXxJPatFlpBnhusaYfudq1IN2rO8z/ N/0rwF14JLfuEjEWDdWsx6Tgq+5ZfAswCl/t3G0enpLELlMWG2rXv3Gn0wYI88eGFUDW II2Pvqv05AVF2dhOocRWn2OoyrISiVGduHWJ5+WFIVWuHxxnd9mktzdNhVxRP9ZJ5yEC qRcrww1aDPyEeKhtFOMb8clpAZs/VbswkCfV44DrcV9DL0a01MW4WAk/DDbrDh4Am5at XGqA== 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=NqBC/JTdN8Jhgh77Z/JOfc6onLMRt8x9FgCKxFMToSA=; b=B4H0gCch1Zlvx922RNcWjmm/VNwsYGC+XPE+TWizWGymFDHX8F17c5FYH7MqLpSkht i54ucI+i/VnrKfwAX8PhrxEX5yWZe7LCba6q19fCRF8F429zwRIwVYGNk67AwDeZGZw3 7KKj9cdoLmKCygJmabFIpDw0ykgKeiC1zCAWLko4y7qTGnzI5VH2BuTyYs3nk7h0Uke8 5gmFuM102jlQ9nEqgLahkW44PlGB1NnGrStEtivtUWBaCm5a+AJXAd24d17UnIYhyimw mW59SLcXfUXTTd7jTIN1y67uH81UqpgmwNbmrGmlVGO9vhnHn/rGuPuOyVqIz5SHBhil WB4A== X-Gm-Message-State: APjAAAVwtQ51s83HOA+BOTYO/FcEZglQR8mS7IW5VMCzlhrjYEJta777 b5dUt6fSGggIA/9BrXvW8nFLTDeb X-Google-Smtp-Source: APXvYqzNiy/vS3fXWyrrePfi6+dUliAV53R0cVwJ2gTrHQw97/0yz1u9lSVF6dvqPO04KR50qsFTlg== X-Received: by 2002:a19:488c:: with SMTP id v134mr3302748lfa.66.1582557175316; Mon, 24 Feb 2020 07:12:55 -0800 (PST) Received: from [192.168.2.145] (79-139-233-37.dynamic.spd-mgts.ru. [79.139.233.37]) by smtp.googlemail.com with ESMTPSA id 23sm6428466ljw.31.2020.02.24.07.12.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Feb 2020 07:12:54 -0800 (PST) Subject: Re: [PATCH v9 09/17] arm: tegra20: cpuidle: Handle case where secondary CPU hangs on entering LP2 To: Daniel Lezcano Cc: Thierry Reding , Jonathan Hunter , Peter De Schrijver , "Rafael J. Wysocki" , =?UTF-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Jasper Korten , David Heidelberg , Peter Geis , linux-pm@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200212235134.12638-1-digetx@gmail.com> <20200212235134.12638-10-digetx@gmail.com> <20200221154318.GO10516@linaro.org> <239a2b66-8da8-2e6c-d19d-9ed207ad0a64@gmail.com> <20200221173649.GU10516@linaro.org> <50a8fb7c-f497-2234-c0b0-560aec1c5691@gmail.com> <21e3cc35-cc6b-5452-da93-bdaac43716c5@linaro.org> From: Dmitry Osipenko Message-ID: Date: Mon, 24 Feb 2020 18:12:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 22.02.2020 00:11, Daniel Lezcano пишет: > On 21/02/2020 21:54, Dmitry Osipenko wrote: >> 21.02.2020 23:48, Daniel Lezcano пишет: >>> On 21/02/2020 21:21, Dmitry Osipenko wrote: >>>> 21.02.2020 23:02, Daniel Lezcano пишет: >>> >>> [ ... ] >>> >>>>>>>>>> + >>>>>>>>>> + /* >>>>>>>>>> + * The primary CPU0 core shall wait for the secondaries >>>>>>>>>> + * shutdown in order to power-off CPU's cluster safely. >>>>>>>>>> + * The timeout value depends on the current CPU frequency, >>>>>>>>>> + * it takes about 40-150us in average and over 1000us in >>>>>>>>>> + * a worst case scenario. >>>>>>>>>> + */ >>>>>>>>>> + do { >>>>>>>>>> + if (tegra_cpu_rail_off_ready()) >>>>>>>>>> + return 0; >>>>>>>>>> + >>>>>>>>>> + } while (ktime_before(ktime_get(), timeout)); >>>>>>>>> >>>>>>>>> So this loop will aggresively call tegra_cpu_rail_off_ready() and retry 3 >>>>>>>>> times. The tegra_cpu_rail_off_ready() function can be called thoushand of times >>>>>>>>> here but the function will hang 1.5s :/ >>>>>>>>> >>>>>>>>> I suggest something like: >>>>>>>>> >>>>>>>>> while (retries--i && !tegra_cpu_rail_off_ready()) >>>>>>>>> udelay(100); >>>>>>>>> >>>>>>>>> So calls to tegra_cpu_rail_off_ready() and 100us x maximum >>>>>>>>> impact. >>>>>>>> But udelay() also results into CPU spinning in a busy-loop, and thus, >>>>>>>> what's the difference? >>>>>>> >>>>>>> busy looping instead of register reads with all the hardware things involved behind. >>>>>> >>>>>> Please notice that this code runs only on an older Cortex-A9/A15, which >>>>>> doesn't support WFE for the delaying, and thus, CPU always busy-loops >>>>>> inside udelay(). >>>>>> >>>>>> What about if I'll add cpu_relax() to the loop? Do you think it it could >>>>>> have any positive effect? >>>>> >>>>> I think udelay() has a call to cpu_relax(). >>>> >>>> Yes, my point is that udelay() doesn't bring much benefit for us here >>>> because: >>>> >>>> 1. we want to enter into power-gated state as quick as possible and >>>> udelay() just adds an unnecessary delay >>>> >>>> 2. udelay() spins in a busy-loop until delay is expired, just like we're >>>> doing it in this function already >>> >>> In this case why not remove ktime_get() and increase the number of retries? >> >> Because the busy-loop performance depends on CPU's frequency, so we >> can't rely on a bare number of the retries. > > Why not if computed in the worst case scenario? There are always at least a few dozens of microseconds to wait, so something like udelay(10) should be a bit better variant anyways. > Anyway, I'll let you give a try. Turned out that udelay(10) is noticeably better when system is running on a lower freqs in comparison to ktime_get(). I'll switch to udelay in v10, thank you very much for the suggestion!