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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4DA30C77B76 for ; Thu, 20 Apr 2023 15:40:08 +0000 (UTC) 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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cwtuV8tFci85qdzmp3KGs/FZDs5O4cMpUQY9wYg/YAs=; b=NkKhf2LHijIPHi Xclb8i62sAJTwzUKsH4+p6dHibSgQvVITGriKlccpTJ2Rt3OAfMRbCfV4uDr54+4mtKpGRhD2pJNn lw0B3QKi4AF286sYovY0n+pcuO1XVhw1XHkEGDexTPf7xonKAxcIYELRn96VR6PtRxEtWcd71czCc XMbtYnQXO69CqFPZDDe1lmLD9bYZejEW26zlf6ONteryRnXk0tYEX4xS9wHmbdKjNkY7rwwkqyGhY xMcOUdImHsLvlzq8sbugv3qKUt2Skyv6k8icPHg/qiuA6zJAAtIga6GbznzpYfEulcvl81KpEGeRX MLZzzO7n6CyEeAS+KSfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ppWNN-008QmE-0j; Thu, 20 Apr 2023 15:39:13 +0000 Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ppWNK-008QlM-0A for linux-arm-kernel@lists.infradead.org; Thu, 20 Apr 2023 15:39:11 +0000 Received: by mail-ej1-x62e.google.com with SMTP id dx24so7253387ejb.11 for ; Thu, 20 Apr 2023 08:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1682005147; x=1684597147; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=hFqx6feXpGTHB3FL7fExLBgKD0kA93DiWIz8p5ciQ1A=; b=e2wmO4PTrmgFS4PMHpvi7Uj2qDn5QqG9HlLghB79R6YOPGTZ6qhkj2Glk9s3yigX+h 0zHtj+2P+RmuxnpyutdUDvcRDGpHplCQwn9A1Zw4y0VgiDAfZRrUHTArnKo4bk6WSf3O jeUHhEzB/UjpUeEXjj9ADmhwQkevITFchUz5sHELnMoubT+sdEczKYUg6aXjUhKfjJ5v A2f4lAtEbHp6DD6axgdR2PsZ0rEj9komqu8T+ylRoQBZiGL7qmtlMDtQAa/5lrMPC75H +Tu8brNS4XNq++xgszlxexRdv1YQVyk3+Zle8EqZ0D7RkSWady/nF5SH0o/tPj4LfKU+ p1Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682005147; x=1684597147; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hFqx6feXpGTHB3FL7fExLBgKD0kA93DiWIz8p5ciQ1A=; b=F1OMQ31uSZ8UMXJcRx9uTuomX1DkvD0Bz4qjFznocztD/iuWpjupmge6tyHPn6SLxE tjcUhLIKof2NCpSlmtRnpTgBbKvxSOJI/cySAQTRIU+ND2BPwU/r7l4At1ruA8xTrNuA hQOpVVcZCZeX2MXGlcW+8nB/6dvyVl9Z/ghqvQH03U3Ha9hK4Z129YodDfY6Co7m6ceb Rzm9B5msIczdfc9qlhh6/WxRuxci7L50xLT4RS9jvPc068iAyZpaYtckbt1LvZQz1GUQ s5bjwxl/DW7YnNyEthlbfdS2hAQmxbJDLiIcZD0vzRvfDf8sK1pVRQJg3L9H6gffVUIu l5Xg== X-Gm-Message-State: AAQBX9fyz+Un1Am+jUw1hm2VK17dzlkC8QKEHXGWmyisradQ4CvJLeaU fQARylvG4o2Iu3Pa0rN6s/clDA== X-Google-Smtp-Source: AKy350aN3xhBBxE+VdGqTHz+YbdaIGULhJZIvketzGosMh5NRoGqDsJdEqOwuEDtEcFey41H+14F5A== X-Received: by 2002:a17:906:2243:b0:889:5686:486a with SMTP id 3-20020a170906224300b008895686486amr1808894ejr.30.1682005147659; Thu, 20 Apr 2023 08:39:07 -0700 (PDT) Received: from ?IPV6:2a02:810d:15c0:828:bcb8:77e6:8f45:4771? ([2a02:810d:15c0:828:bcb8:77e6:8f45:4771]) by smtp.gmail.com with ESMTPSA id qt18-20020a170906ecf200b0094f2a03486esm851028ejb.224.2023.04.20.08.39.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 20 Apr 2023 08:39:07 -0700 (PDT) Message-ID: <01d22e48-40f0-b1dd-aa00-cf484c4364ee@linaro.org> Date: Thu, 20 Apr 2023 17:39:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v2 2/4] spi: s3c64xx: add cpu_relax in polling loop Content-Language: en-US To: Jaewon Kim , Mark Brown , Andi Shyti , Alim Akhtar Cc: linux-spi@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Chanho Park References: <20230419060639.38853-1-jaewon02.kim@samsung.com> <20230419060639.38853-3-jaewon02.kim@samsung.com> <36f37a18-0022-0368-bf7c-ebdd724b1558@linaro.org> From: Krzysztof Kozlowski In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230420_083910_092958_0E062FC5 X-CRM114-Status: GOOD ( 20.82 ) 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 19/04/2023 13:13, Jaewon Kim wrote: > > On 23. 4. 19. 17:14, Krzysztof Kozlowski wrote: >> On 19/04/2023 08:06, Jaewon Kim wrote: >>> Adds cpu_relax() to prevent long busy-wait. >> How cpu_relax prevents long waiting? > > As I know, cpu_relax() can be converted to yield. This can prevent > excessive use of the CPU in busy-loop. That's ok, you just wrote that it will prevent long waiting, so I assume it will shorten the wait time. > > I'll replace poor sentence like below in v3. > > ("Adds cpu_relax() to allow CPU relaxation in busy-loop") > >>> There is busy-wait loop to check data transfer completion in polling mode. >>> >>> Signed-off-by: Jaewon Kim >>> --- >>> drivers/spi/spi-s3c64xx.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c >>> index 273aa02322d9..886722fb40ea 100644 >>> --- a/drivers/spi/spi-s3c64xx.c >>> +++ b/drivers/spi/spi-s3c64xx.c >>> @@ -568,6 +568,7 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd, >>> >>> val = msecs_to_loops(ms); >>> do { >>> + cpu_relax(); >> Shouldn't this be just readl_poll_timeout()? Or the syntax would be too >> complicated? > > I think we can replace this while() loop to readl_poll_timeout(). > > However, we should use 0 value as 'delay_us' parameter. Because delay > can affect throughput. > > > My purpose is add relax to this busy-loop. > > we cannot give relax if we change to readl_poll_timeout(). readl_poll_timeout() will know to do the best. You do not need to add cpu_relax there. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel