Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6155148ybf; Thu, 5 Mar 2020 14:21:33 -0800 (PST) X-Google-Smtp-Source: ADFU+vtTfZhdFMMk/lOli3YU9xNfXlfcXOg7Eijyfb4ScU8JbTTxwFU2rQar+ogJK0Ty/BNGqGUZ X-Received: by 2002:a05:6830:57d:: with SMTP id f29mr94024otc.164.1583446893397; Thu, 05 Mar 2020 14:21:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583446893; cv=none; d=google.com; s=arc-20160816; b=Di6Q609dUUc6AV2bvr4Ga18zFusa9UCs8PSI6bJf64cBv0XTgHgOHeuuuwz+1IBAeB Q2d31oimkKNc1cvlbsINKb0vvhITSpoTh15Mr+r50VV32moxSWlcLLXRLyRvvpl9616q ZND4YTH3nRLck1unc7BYE6Xjgv+Vlho/a2J1LjLiiQ4fUtdMTLtlDFGmJHv5kfq8vJ9G kupz3QkaNVBQHUbznIHWmphJ2AUskeSAzUBqx+YQ8/uMOsNd7HkD7Wap/SMQrszPTNV7 xJ4qFNNGJxGX0/QaY8NsO6jguRpV6gOD9kFpgrt8ee3tJHr5waVomgGw/mpY+M/7JXJf erwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LrmCjw7xyG8fg4C1dKjDiV0Q8S1LhYkzPOfDEOi+i6c=; b=XI6IMuBZBqp/HcnCFyFCm3gSwe0CSR/sZB/TtsWi70raLQ4/gt96itsMqCVwjxBaq7 J8Tg/t+MnAEM0eAZnlEgKV6LP3AgXLllWo/Oh2y5IMd2weDLs2msLbH9AgvAqbBEhzYy 63X2PWlP5I8rOydvEpCIyJGV8NU2g7QjeW5C5ueG6D7Xa3qIC0CNxIMyxqK4gBGVzRT2 POAFin3G5hH3pBgkxO6F+ZoVGlSjaP8xGX28RbSYubPJiWoWobpDDgUUqV2CEFbOeGYe kseKjK+aNENIPPr1GJBAPv83dVtgjKvFkfriBf9YyAn5mbuOD1vHO+5v8rvIg0cBSTA3 7fJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=JhxBDlNu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o20si161339ota.17.2020.03.05.14.21.21; Thu, 05 Mar 2020 14:21:33 -0800 (PST) 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=@chromium.org header.s=google header.b=JhxBDlNu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726413AbgCEWUw (ORCPT + 99 others); Thu, 5 Mar 2020 17:20:52 -0500 Received: from mail-vs1-f66.google.com ([209.85.217.66]:40995 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbgCEWUw (ORCPT ); Thu, 5 Mar 2020 17:20:52 -0500 Received: by mail-vs1-f66.google.com with SMTP id k188so266185vsc.8 for ; Thu, 05 Mar 2020 14:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LrmCjw7xyG8fg4C1dKjDiV0Q8S1LhYkzPOfDEOi+i6c=; b=JhxBDlNuZ+wqBBfKTq7jRiznrdUS2hRiPAoff37XUBYnwD4QbFPjdEWWg8BXQeu3HA sP5144hQmSd5qudCwUvdsz2OpsStzWufw3hsrRFRRi55g6skgNorWbKv7cJP1B6ltpMy Bze/Tte7ajsI4RYzI2m66PsE3nztR+E+istJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LrmCjw7xyG8fg4C1dKjDiV0Q8S1LhYkzPOfDEOi+i6c=; b=VcgatQYe531GR6QQMXUmb6/JsoB9yYpXLlhzBinDjFFsZHuyf5L9p8KNqWVbsfJ2Fx 3YrYTHeW4sH5KvxHeYcy4oHAVCooT8jfGMeCJBxxOu9qwIkW7oiWD3LQijGtoT7n/Fs/ 95SspbRE82uHYOunjiSBhQ3FAfeHoZ9oQgwXRqAbUuOnJqcL23Ev/HYCOtgIzyZaEn2b QHgR+XU1HnrtbcwLvmuVRKd9DU9LLhV0EftTDMr2/EtXDywvKoIbBA1ZKXBkKq9T5g/7 GzhhFCxqqV6GlBmn+ynKw5oappvJgnm/+4X6+pe+7linnaNcNYSgmNXRHZWHagMVYL6g gPMQ== X-Gm-Message-State: ANhLgQ1oog4uXvRK0Q1RT5++KoCeM3l0lZ1k3eKOMIpSee3eGATodYve VbwD93ZHdkei6KRZ3teWZQO6Y8ON3ps= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr355004vsr.189.1583446851215; Thu, 05 Mar 2020 14:20:51 -0800 (PST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com. [209.85.217.50]) by smtp.gmail.com with ESMTPSA id b19sm8784767vka.48.2020.03.05.14.20.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2020 14:20:50 -0800 (PST) Received: by mail-vs1-f50.google.com with SMTP id n27so300568vsa.0 for ; Thu, 05 Mar 2020 14:20:50 -0800 (PST) X-Received: by 2002:a05:6102:101d:: with SMTP id q29mr385638vsp.73.1583446849518; Thu, 05 Mar 2020 14:20:49 -0800 (PST) MIME-Version: 1.0 References: <1583428023-19559-1-git-send-email-mkshah@codeaurora.org> <1583428023-19559-5-git-send-email-mkshah@codeaurora.org> In-Reply-To: <1583428023-19559-5-git-send-email-mkshah@codeaurora.org> From: Doug Anderson Date: Thu, 5 Mar 2020 14:20:38 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 4/4] soc: qcom: rpmh: Invalidate SLEEP and WAKE TCSes before flushing new data To: Maulik Shah Cc: Stephen Boyd , Matthias Kaehlcke , Evan Green , Bjorn Andersson , LKML , linux-arm-msm , Andy Gross , Rajendra Nayak , Lina Iyer , lsrao@codeaurora.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Mar 5, 2020 at 9:07 AM Maulik Shah wrote: > > TCSes have previously programmed data when rpmh_flush is called. > This can cause old data to trigger along with newly flushed. > > Fix this by cleaning SLEEP and WAKE TCSes before new data is flushed. > > Fixes: 600513dfeef3 ("drivers: qcom: rpmh: cache sleep/wake state requests") > Signed-off-by: Maulik Shah > --- > drivers/soc/qcom/rpmh.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/soc/qcom/rpmh.c b/drivers/soc/qcom/rpmh.c > index 1951f6a..63364ce 100644 > --- a/drivers/soc/qcom/rpmh.c > +++ b/drivers/soc/qcom/rpmh.c > @@ -472,6 +472,11 @@ int rpmh_flush(struct rpmh_ctrlr *ctrlr) > return 0; > } > > + /* Invalidate the TCSes first to avoid stale data */ > + do { > + ret = rpmh_rsc_invalidate(ctrlr_to_drv(ctrlr)); > + } while (ret == -EAGAIN); > + > /* First flush the cached batch requests */ > ret = flush_batch(ctrlr); > if (ret) I think you should make this patch 3/4 instead of 4/4, and then: 1. In this patch remove the call to rpmh_rsc_invalidate() in rpmh_invalidate(). You've already marked things "dirty" in invalidate_batch() so no need to actually program the hardware--it'll happen in the flush. 2. In patch 4/4 (the flushing patch) add a call to rpmh_flush() to rpmh_invalidate() if you're in non-OSI mode. Presumably you'll need a spinlock around the rpmh_flush() call? The end result of that will be that rpmh_invalidate() will properly leave the non-batch sleep/wake sets programmed. -Doug