Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp9664651ybi; Wed, 24 Jul 2019 07:57:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqwimW/3y/RvFn9oXaVe+VmryC+npa+aHPOj0TNKUBisDqZPAdbdCTBhRRFLEfczL0r87NTw X-Received: by 2002:a63:cc14:: with SMTP id x20mr35418942pgf.142.1563980231451; Wed, 24 Jul 2019 07:57:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563980231; cv=none; d=google.com; s=arc-20160816; b=yBSz1KMhzckVRpMjglYzSItP3MLEMKSMB1O5/fCph4ji/6BMXtZ0rUbYubUEeVxeHl kTQxuet4YKn0EalEtKYtMi2/vS7DypNdmy7CjmrVv+HxnxXEZourlnd64HtR6GVofI3h oGn4LNfMo6Y5cCy/QQjPJk315rNL/59Kx8dY+MJJ4mzXXY0ZjtY0Uz4JhHeCrtyWSG9C fa2RChfF8SsTahRKOsMAFtIzm9d/C6fX+IAcSUdSQJAWc4iDwJ6ucEp4gVkROVbl9aQK 531smkfowDh/s2x4BUG9XdB5FHeSVlHix7DKqv3/Cd7xatvrRT6Q2+ceXUKMFWJCrch/ Lt4w== 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=ekVMmunhjXB0Aani8gogW+lX9OlpIgh8Fk9fwTNvsOI=; b=Pv8DPWfbZydV41QEHpFOvzse07Kz1NTGcDbmGDpMOmIVPzceOICsHj72phhbcm9JWl OuTqCAlnmkJrAg47JvAgA+aNTtwoNVgBMAUWCeTt+CWDxtno/P2eyhE0ah5qpoaZ6pRz PY5WxZGq7U0h/xDdW/Dc2bf8Afc6E9VHSO5sDcnhwY4NFtABDIuBQoe8jsw7e2lH1FBJ UbnCMdSP1fBkoZIAnTEs3ARbBhtjquUJUg3pNt6D0V6yauSfHGZc3CgZwCBvVWNUD06S giFz8paPE/opbX4XvxwHVYISTUzymO6FgG3RrcUFNV/qJrC2tZicnk0Px0D063j46QEE poZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=Pua54TwA; dkim=pass header.i=@codeaurora.org header.s=default header.b=DtQ+dy6w; 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 x62si14551428pgd.48.2019.07.24.07.56.56; Wed, 24 Jul 2019 07:57:11 -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=Pua54TwA; dkim=pass header.i=@codeaurora.org header.s=default header.b=DtQ+dy6w; 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 S1728223AbfGXOy4 (ORCPT + 99 others); Wed, 24 Jul 2019 10:54:56 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58300 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726422AbfGXOyz (ORCPT ); Wed, 24 Jul 2019 10:54:55 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 45D0960274; Wed, 24 Jul 2019 14:54:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563980094; bh=yWgNZ+6j27JK6qHT8Wru4w9mCaugWru6Fkq+nAqkWAw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Pua54TwApd+WIRPxsD62yTuahZGP8CGJFMO1meGOq+qsGoOvSOmuD8rZoi2PbOdIr N5PhuA9sZWIncNmhnMPY7faMPWHUiBV7+njNo8sKeXA0WCCJBKgZ6dMnB4xZHAlau4 wdMqmgHyOt+bgbgMRTWBfED2BqS54Pe7jY0G2ssw= 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 02DBD60256; Wed, 24 Jul 2019 14:54:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1563980093; bh=yWgNZ+6j27JK6qHT8Wru4w9mCaugWru6Fkq+nAqkWAw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DtQ+dy6wZ/clfrH9yDnsfRlopdptwRgUupbLa7Gr/pfpGJeUNO8GKnVx9VEsC6d+y Y3v7JFxJsA/veONur0M94ZxBaugCuQjhsLrzVO+b9lZD0ZN6bppvoAkRNzDPPAdvTR 9TiU9A5DiOirFuxxqLVMqODHyM4jWGK5+CCvsSfg= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 02DBD60256 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:54:52 -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: <20190724145452.GC18620@codeaurora.org> References: <20190722215340.3071-1-ilina@codeaurora.org> <5d375054.1c69fb81.7ce3f.3591@mx.google.com> <20190723192159.GA18620@codeaurora.org> <5d376bb3.1c69fb81.2bb4e.7771@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <5d376bb3.1c69fb81.2bb4e.7771@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:19 -0600, Stephen Boyd wrote: >Quoting Lina Iyer (2019-07-23 12:21:59) >> 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. > >Yes drv->lock wasn't an irqsave/restore variant because it was a >spinlock inside of an obviously already irqsaved region of code because >the tcs->lock was outside the drv->lock and that was saving the irq >flags. > Oh, right. >> >> >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. > >It needs to be changed to maintain the irqsaving/restoring of the code. > May be I should club this with the following patch. Instead of adding irqsave and restore to drv->lock and then remvoing them again in the following patch. >> >> @@ -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 ?? >> > >Yes, it should have irq save/restore still. >