Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9662731ybi; Wed, 24 Jul 2019 07:55:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqwBCN59wH7TR5+aR1i2yii7NhoAAtytQnVmXYbKriIuUMO+hBBobcx3rF0J9bOoIKNq9TBO X-Received: by 2002:a63:fd50:: with SMTP id m16mr80621647pgj.192.1563980105814; Wed, 24 Jul 2019 07:55:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563980105; cv=none; d=google.com; s=arc-20160816; b=cMMSyF4L1PTFiTq/EiKCjrXgoHIjAMWgCNMQem4sf+KBpS310xUh9p+6pDGpocBAOF 79ySS3XqvsO4nr7p7Pc0Ku4f60pB9SkU45AiKpt4a8B6FWnNZlvMqRme4nrSCtjgB1Am ZQDv+fE6w9noHo6gV16QjqDEMKTOCSCsR1tj84izs2pDsJw2o2hkSMNdobnywi2+h0iE jvDFW0+Xwa0OMJ91gKX11WdBPlDSbdameYd2zfVjtir9fNLy5eWV2hdHwTCSOkvp19r+ Bwy2AvT94JJ4J55gUS7A7NO4CkJkSx+reqVFIAtpGf6UcthEf8HiTpSIdtXBljP1F72H DsPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:dkim-signature:dkim-signature; bh=/HpLgyoDGtFCvyZApeCdPFvjPTReImPEcELYgWz0O7c=; b=v1Mjp+RH+b2tLYPfz60iFKswEn5piniFJjFSgruPNc1W2dfChQsAviYb6sl1Vt6FmY SYFVvYrUl4XmTabqXxRH0uEfyc3FXAcakveh2rDkr0C1Kp1hF2LF0wy1A3tZVow4yuDX QL/IR49T5gaVGw0xZerXcvo0vrKMvzobDPn9NxX6CiDXXxNDQd1VqCAwjIIQXbp8gukW QizKpah68EgYkgw0ioUs0qErFTtOadhjjgOyL1YjOPCH0IbpW/j+2Bq8Yo2pnpC6fxGo hVNQLY1y4XP+L8sPx6U+vIlZ/CrJaR6Iypgqnbcdzh7oSJJ0MPGQIWxzsEeOVW14m6b+ c19w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=TdQ7z7+0; dkim=pass header.i=@codeaurora.org header.s=default header.b=QND30vBz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a88si13582313pje.6.2019.07.24.07.54.51; Wed, 24 Jul 2019 07:55:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=TdQ7z7+0; dkim=pass header.i=@codeaurora.org header.s=default header.b=QND30vBz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387559AbfGXOw4 (ORCPT + 99 others); Wed, 24 Jul 2019 10:52:56 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57016 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbfGXOwz (ORCPT ); Wed, 24 Jul 2019 10:52:55 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id BEC4260256; Wed, 24 Jul 2019 14:52:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563979973; bh=GLF+INpUZtE9vDJdCTqRAtCJy5OjjE16gdlqI1ORlT4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TdQ7z7+0lgIwRufSCZJ94H9BM6jN6fQ9sh+dDMMS+x8HG0IMGNd15ozl7BCaLj6hB +KH9Uj1Fyzee8aIfT0vh3Qb+C8nyVSXMe0c0ffFCPSy1P9dewg4J0RyfcaQ6LGH0B0 Xqq/UrtOGxhXCOLdi/Pc3U8vY89Kgb5H3hVIvDrc= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED,SPF_NONE autolearn=no autolearn_force=no version=3.4.0 Received: from localhost (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: ilina@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 840C160256; Wed, 24 Jul 2019 14:52:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563979972; bh=GLF+INpUZtE9vDJdCTqRAtCJy5OjjE16gdlqI1ORlT4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QND30vBzpIkaYYFjjvb2CT2OH40UymiL3J86jcesMc7H0XSMHVTiFYVSWQs2rev0K yBpfVDzLjBwijs3EiVMX/Qpoy9IfZGOuNUw4JQ4QKelTd3SyskBCaWca/Z2/iEwFSX D0YV6YBWte/uye5F+POPV0UZ/pxUV/7ROT8mnjYw= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 840C160256 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=ilina@codeaurora.org Date: Wed, 24 Jul 2019 08:52:51 -0600 From: Lina Iyer To: Stephen Boyd Cc: agross@kernel.org, bjorn.andersson@linaro.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, rnayak@codeaurora.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, dianders@chromium.org, mkshah@codeaurora.org Subject: Re: [PATCH V2 2/4] drivers: qcom: rpmh-rsc: avoid locking in the interrupt handler Message-ID: <20190724145251.GB18620@codeaurora.org> References: <20190722215340.3071-1-ilina@codeaurora.org> <20190722215340.3071-2-ilina@codeaurora.org> <5d3769df.1c69fb81.55d03.aa33@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5d3769df.1c69fb81.55d03.aa33@mx.google.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 23 2019 at 14:11 -0600, Stephen Boyd wrote: >Quoting Lina Iyer (2019-07-22 14:53:38) >> Avoid locking in the interrupt context to improve latency. Since we >> don't lock in the interrupt context, it is possible that we now could >> race with the DRV_CONTROL register that writes the enable register and >> cleared by the interrupt handler. For fire-n-forget requests, the >> interrupt may be raised as soon as the TCS is triggered and the IRQ >> handler may clear the enable bit before the DRV_CONTROL is read back. >> >> Use the non-sync variant when enabling the TCS register to avoid reading >> back a value that may been cleared because the interrupt handler ran >> immediately after triggering the TCS. >> >> Signed-off-by: Lina Iyer >> --- > >I have to read this patch carefully. The commit text isn't convincing me >that it is actually safe to make this change. It mostly talks about the >performance improvements and how we need to fix __tcs_trigger(), which >is good, but I was hoping to be convinced that not grabbing the lock >here is safe. > >How do we ensure that drv->tcs_in_use is cleared before we call >tcs_write() and try to look for a free bit? Isn't it possible that we'll >get into a situation where the bitmap is all used up but the hardware >has just received an interrupt and is going to clear out a bit and then >an rpmh write fails with -EBUSY? > If we have a situation where there are no available free bits, we retry and that is part of the function. Since we have only 2 TCSes avaialble to write to the hardware and there could be multiple requests coming in, it is a very common situation. We try and acquire the drv->lock and if there are free TCS available and if available mark them busy and send our requests. If there are none available, we keep retrying. >> drivers/soc/qcom/rpmh-rsc.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c >> index 5ede8d6de3ad..694ba881624e 100644 >> --- a/drivers/soc/qcom/rpmh-rsc.c >> +++ b/drivers/soc/qcom/rpmh-rsc.c >> @@ -242,9 +242,7 @@ static irqreturn_t tcs_tx_done(int irq, void *p) >> write_tcs_reg(drv, RSC_DRV_CMD_ENABLE, i, 0); >> write_tcs_reg(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, i, 0); >> write_tcs_reg(drv, RSC_DRV_IRQ_CLEAR, 0, BIT(i)); >> - spin_lock(&drv->lock); >> clear_bit(i, drv->tcs_in_use); >> - spin_unlock(&drv->lock); >> if (req) >> rpmh_tx_done(req, err); >> } >> @@ -304,7 +302,7 @@ static void __tcs_trigger(struct rsc_drv *drv, int tcs_id) >> enable = TCS_AMC_MODE_ENABLE; >> write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable); >> enable |= TCS_AMC_MODE_TRIGGER; >> - write_tcs_reg_sync(drv, RSC_DRV_CONTROL, tcs_id, enable); >> + write_tcs_reg(drv, RSC_DRV_CONTROL, tcs_id, enable); >> } >> >> static int check_for_req_inflight(struct rsc_drv *drv, struct tcs_group *tcs,