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 X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F314C3F2D1 for ; Thu, 5 Mar 2020 22:18:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EAF3420801 for ; Thu, 5 Mar 2020 22:18:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="cO7lKma5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726204AbgCEWSU (ORCPT ); Thu, 5 Mar 2020 17:18:20 -0500 Received: from mail-vs1-f67.google.com ([209.85.217.67]:41870 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbgCEWSU (ORCPT ); Thu, 5 Mar 2020 17:18:20 -0500 Received: by mail-vs1-f67.google.com with SMTP id k188so261595vsc.8 for ; Thu, 05 Mar 2020 14:18:19 -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:content-transfer-encoding; bh=KaysUP+3Av+N3rptK3NvGlj/ejFA3gDwE+RY9/HC1SE=; b=cO7lKma5P41BEzS5Zq4IgnFZZnd95U39OACyYzmddDkWoykXKe+Dc1zrW6TCjWts4a /MNL7estdbZEtjBHceq0tR2XThzeTxj0qJNzHFevlJ4Clj2em5EaYjSfsuSdCk1X+h5r 8bdYd942qRJya+3QBptQJQH7B8bFN5XRqf0x8= 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:content-transfer-encoding; bh=KaysUP+3Av+N3rptK3NvGlj/ejFA3gDwE+RY9/HC1SE=; b=HOFmdGcmwLpxxNGdaSNwllUWfmQdfQ8cfV/JKynTVWBmrVqK+TQruWAy/UdBf4r/hm aWnQznWihKL8IV2H/UZuQVyj+DqzRRnQYw8jNonmbE97V77gQ0SV8pmH+nGn5iRje2jq fkbu3jtjf0FEMLRhvTegEPiUMYM0s9T841J/XhRGt5TifZ8vwR0HweqUK0Wh8cPtg57f TQqnLv3Er3Pv3vb5fL10rRmXfAzxf1xRJVy7nfU2tqde8WAdcaJwdfpcvwUzMXKeC8oO 1XtdQpVedlrakRIZclu5QOfEqV3hB5MCb/+IWqtsgA7dBdzEyDvWWzo486kDPapX9ZGx KNig== X-Gm-Message-State: ANhLgQ3lZjlTbi9okHUBeRgLAOTMZgwDW3GOLzELltBrZsww2zDJhfKW 3w0wCYWGSoGz+svi4YoyfnpnVU0gzWg= X-Google-Smtp-Source: ADFU+vtDMG2SgcMaetaKF/Wn8Y9ILebRqVRESIiN2m5M6yYJqGCFfgOSZi0aa5HlP6VIQE221ktugw== X-Received: by 2002:a67:d106:: with SMTP id u6mr378913vsi.61.1583446699046; Thu, 05 Mar 2020 14:18:19 -0800 (PST) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com. [209.85.221.176]) by smtp.gmail.com with ESMTPSA id e66sm2412160vke.35.2020.03.05.14.18.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Mar 2020 14:18:17 -0800 (PST) Received: by mail-vk1-f176.google.com with SMTP id a76so55264vki.13 for ; Thu, 05 Mar 2020 14:18:17 -0800 (PST) X-Received: by 2002:a1f:97c8:: with SMTP id z191mr983268vkd.0.1583446696985; Thu, 05 Mar 2020 14:18:16 -0800 (PST) MIME-Version: 1.0 References: <1582889903-12890-1-git-send-email-mkshah@codeaurora.org> <1582889903-12890-4-git-send-email-mkshah@codeaurora.org> <7704638e-b473-d0cf-73ab-2bdb67b636ba@codeaurora.org> In-Reply-To: From: Doug Anderson Date: Thu, 5 Mar 2020 14:18:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v9 3/3] soc: qcom: rpmh: Invoke rpmh_flush() for dirty caches 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" Content-Transfer-Encoding: quoted-printable Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, On Thu, Mar 5, 2020 at 1:41 AM Maulik Shah wrote: >> There are other cases like below which also gets impacted if driver > >> don't cache anything... > >> > >> for example, when we don=E2=80=99t have dedicated ACTIVE TCS ( if we h= ave below > >> config with ACTIVE TCS count 0) > >> qcom,tcs-config =3D , > >> , > >> , > >> > >> Now to send active data, driver may re-use/ re-purpose few of the slee= p > >> or wake TCS, to be used as ACTIVE TCS and once work is done, > >> it will be re-allocated in SLEEP/ WAKE TCS pool accordingly. If driver > >> don=E2=80=99t cache, all the SLEEP and WAKE data is lost when one > >> of TCS is repurposed to use as ACTIVE TCS. > > Ah, interesting. I'll read the code more, but are you expecting this > > type of situation to work today, or is it theoretical for the future? > yes, we have targets which needs to work with this type of situation. My brain is still slowly absorbing all the code, but something tells me that targets with no ACTIVE TCS will not work properly with non-OSI mode unless you change your patches more. Specifically to make the zero ACTIVE TCS case work I think you need a rpmh_flush() call after _ALL_ calls to rpmh_write() and rpmh_write_batch() (even those modifying ACTIVE state). rpmh_write_async() will be yet more interesting because you'd have to flush in rpmh_tx_done() I guess? ...and also somehow you need to inhibit entering sleep mode if an async write was in progress? Maybe easier to just detect the "non-OSI-mode + 0 ACTIVE TCS" case at probe time and fail to probe? -Doug