Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8984059ybi; Tue, 23 Jul 2019 19:27:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqwWCQyYuEIn4Z0xTZYa7v1Xrt/mMgh/x+DNFlVpvN5/xC1CQ8ZCXsrlJT0vDxVVqaAP8xYu X-Received: by 2002:a17:90b:28f:: with SMTP id az15mr84087774pjb.18.1563935274800; Tue, 23 Jul 2019 19:27:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563935274; cv=none; d=google.com; s=arc-20160816; b=F9G7RdWnkfMgvhNnV2QA6J7c6eUczD3NlD1mt2HXXxvoH8MTSDXU97ZeNCqbzo0GoK obkw4xeuKcu8CGc/auLLviilVXKc/TCuuvD4ZtLCAJTmJRSKXLPxxWclip2uFjyaQw/B ssBaXaQ3ThjsC5paypWFSa8MLAvZoE20BYwhePuvmhmRobJVvtv6DGK+Wue4U7KT0rz1 htDWLtDmtVbZuLHFQPSauFSlswBfHCaUk8WsH965A+qrTQSZcJLP/O0BvChyr+HQ/guT eFTw/PpL3PQemgS6+3mEdpo+7Yyx8LncEyvZSB+1ARnXDKp446HInUOY8oICNIsDLxsp jVbA== 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=LbCpEQLpA/BbEUo1lkwBZuTL7xD9RTgdnKKiuzoUjXk=; b=u/+d5TRbY2PTX6rTBLdUE73YcRWDs9thaf6EcRlasl8FjHIAMT+WtgImYUL1LCg5B+ a0p6aloLpX/9TB1wC5nVMDoOoFuGaSpWPa0EyfITGr0Su8xFdffgbQWpuyG6wgRD72ol 0OyNQk2OScntaxA6bp+fkqnO0iGBCxgvys+d2gR4M2qBbJVl9ADgISoY0RoWV+SNs3pk 5mTHrv82rDsaGkuHdXYzVuhcuw1NPQW/JscU1yge661vJua6qWjYCioEyWToCgu2kdcW v+CAROoeCU8Z7BkLhzUhdQP2qyNl3YVkr/w8htQN/IruHVF7otgSvYiquGLRyGKeYRPz /eNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=oJY3y4jJ; dkim=pass header.i=@codeaurora.org header.s=default header.b=mHbrgoKW; 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 61si12758994ple.275.2019.07.23.19.27.39; Tue, 23 Jul 2019 19:27:54 -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=oJY3y4jJ; dkim=pass header.i=@codeaurora.org header.s=default header.b=mHbrgoKW; 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 S2391636AbfGWTWE (ORCPT + 99 others); Tue, 23 Jul 2019 15:22:04 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:48260 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388860AbfGWTWE (ORCPT ); Tue, 23 Jul 2019 15:22:04 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 0AA1360FEA; Tue, 23 Jul 2019 19:22:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563909723; bh=bfET2k5xpnZDhEFDAJZolFfmIsNzlqNPLX0+nG24TTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oJY3y4jJSJfOXehEeN11f5G5Q74+niajD7c81rIWMX2dfKdROLpyaLfbRKONGKjnh W6ayyZRSolnrpqXPJuFk3Mw+Gf0YUXqEJY8vF6mHMIGhWRUCgstLMM6haLCGMwDzWf nkCrFpU/Lbbm8ZIfanCEYFlbYfXJscb9n6B7FFRw= 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 C2CF0618DC; Tue, 23 Jul 2019 19:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563909720; bh=bfET2k5xpnZDhEFDAJZolFfmIsNzlqNPLX0+nG24TTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mHbrgoKWIZ4I5DlJ2XtJTN6hAqWkfj1OgCvpe7u1bG2bTmW6RJN6jsrXfZDOcQXh0 B/vAvQtArVZqbfwcbX1yloGPXzmnDuaKWVhPUn9JRT6g8WB+nN5mGGyeVHA0lKIMCO BTk5XmSRF9J0lWwoniPbJkqVTGm2tMhGpG6EZ020= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org C2CF0618DC 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: Tue, 23 Jul 2019 13:21:59 -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, "Raju P.L.S.S.S.N" Subject: Re: [PATCH V2 1/4] drivers: qcom: rpmh-rsc: simplify TCS locking Message-ID: <20190723192159.GA18620@codeaurora.org> References: <20190722215340.3071-1-ilina@codeaurora.org> <5d375054.1c69fb81.7ce3f.3591@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5d375054.1c69fb81.7ce3f.3591@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 12:22 -0600, Stephen Boyd wrote: >Quoting Lina Iyer (2019-07-22 14:53:37) >> From: "Raju P.L.S.S.S.N" >> >> The tcs->lock was introduced to serialize access with in TCS group. But, >> drv->lock is still needed to synchronize core aspects of the >> communication. This puts the drv->lock in the critical and high latency >> path of sending a request. drv->lock provides the all necessary >> synchronization. So remove locking around TCS group and simply use the >> drv->lock instead. > >This doesn't talk about removing the irq saving and restoring though. You mean for drv->lock? It was not an _irqsave/_irqrestore anyways and we were only removing the tcs->lock. >Can you keep irq saving and restoring in this patch and then remove that >in the next patch with reasoning? It probably isn't safe if the lock is >taken in interrupt context anyway. > Yes, the drv->lock should have been irqsave/irqrestore, but it hasn't been changed by this patch. >> >> Signed-off-by: Raju P.L.S.S.S.N >> [ilina: split patch into multiple files, update commit text] >> Signed-off-by: Lina Iyer > >> diff --git a/drivers/soc/qcom/rpmh-internal.h b/drivers/soc/qcom/rpmh-internal.h >> index a7bbbb67991c..969d5030860e 100644 >> --- a/drivers/soc/qcom/rpmh-internal.h >> +++ b/drivers/soc/qcom/rpmh-internal.h >> diff --git a/drivers/soc/qcom/rpmh-rsc.c b/drivers/soc/qcom/rpmh-rsc.c >> index e278fc11fe5c..5ede8d6de3ad 100644 >> --- a/drivers/soc/qcom/rpmh-rsc.c >> +++ b/drivers/soc/qcom/rpmh-rsc.c >> @@ -106,26 +106,26 @@ static int tcs_invalidate(struct rsc_drv *drv, int type) >> { >> int m; >> struct tcs_group *tcs; >> + int ret = 0; >> >> tcs = get_tcs_of_type(drv, type); >> >> - spin_lock(&tcs->lock); >> - if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) { >> - spin_unlock(&tcs->lock); >> - return 0; >> - } >> + spin_lock(&drv->lock); >> + if (bitmap_empty(tcs->slots, MAX_TCS_SLOTS)) >> + goto done_invalidate; >> >> for (m = tcs->offset; m < tcs->offset + tcs->num_tcs; m++) { >> if (!tcs_is_free(drv, m)) { >> - spin_unlock(&tcs->lock); >> - return -EAGAIN; >> + ret = -EAGAIN; >> + goto done_invalidate; >> } >> write_tcs_reg_sync(drv, RSC_DRV_CMD_ENABLE, m, 0); >> write_tcs_reg_sync(drv, RSC_DRV_CMD_WAIT_FOR_CMPL, m, 0); >> } >> bitmap_zero(tcs->slots, MAX_TCS_SLOTS); >> - spin_unlock(&tcs->lock); >> >> +done_invalidate: >> + spin_unlock(&drv->lock); >> return 0; > >return ret now? > Yes, will do. >> } >> >> @@ -349,41 +349,35 @@ static int tcs_write(struct rsc_drv *drv, const struct tcs_request *msg) >> { >> struct tcs_group *tcs; >> int tcs_id; >> - unsigned long flags; >> int ret; >> >> tcs = get_tcs_for_msg(drv, msg); >> if (IS_ERR(tcs)) >> return PTR_ERR(tcs); >> >> - spin_lock_irqsave(&tcs->lock, flags); >> spin_lock(&drv->lock); >> /* >> * The h/w does not like if we send a request to the same address, >> * when one is already in-flight or being processed. >> */ >> ret = check_for_req_inflight(drv, tcs, msg); >> - if (ret) { >> - spin_unlock(&drv->lock); >> + if (ret) >> goto done_write; >> - } >> >> tcs_id = find_free_tcs(tcs); >> if (tcs_id < 0) { >> ret = tcs_id; >> - spin_unlock(&drv->lock); >> goto done_write; >> } >> >> tcs->req[tcs_id - tcs->offset] = msg; >> set_bit(tcs_id, drv->tcs_in_use); >> - spin_unlock(&drv->lock); >> >> __tcs_buffer_write(drv, tcs_id, 0, msg); >> __tcs_trigger(drv, tcs_id); >> >> done_write: >> - spin_unlock_irqrestore(&tcs->lock, flags); >> + spin_unlock(&drv->lock); >> return ret; >> } >> >> @@ -481,19 +475,18 @@ static int tcs_ctrl_write(struct rsc_drv *drv, const struct tcs_request *msg) >> { >> struct tcs_group *tcs; >> int tcs_id = 0, cmd_id = 0; >> - unsigned long flags; >> int ret; >> >> tcs = get_tcs_for_msg(drv, msg); >> if (IS_ERR(tcs)) >> return PTR_ERR(tcs); >> >> - spin_lock_irqsave(&tcs->lock, flags); >> + spin_lock(&drv->lock); >> /* find the TCS id and the command in the TCS to write to */ >> ret = find_slots(tcs, msg, &tcs_id, &cmd_id); >> if (!ret) >> __tcs_buffer_write(drv, tcs_id, cmd_id, msg); >> - spin_unlock_irqrestore(&tcs->lock, flags); >> + spin_unlock(&drv->lock); >> > >These ones, just leave them doing the irq save restore for now? > drv->lock ?? --Lina