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 9DD83C7618F for ; Fri, 19 Jul 2019 18:22:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 771B22187F for ; Fri, 19 Jul 2019 18:22:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="oEoDF/B5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729537AbfGSSWv (ORCPT ); Fri, 19 Jul 2019 14:22:51 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:46383 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729267AbfGSSWu (ORCPT ); Fri, 19 Jul 2019 14:22:50 -0400 Received: by mail-pg1-f194.google.com with SMTP id i8so14797010pgm.13 for ; Fri, 19 Jul 2019 11:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:subject:to:cc:from:user-agent:date; bh=Re7bGdDSOibN8TyYx8ctmhIgW7ORnAd3d48dCZJCs8Q=; b=oEoDF/B5t2C4jMyi0S3gpDDDEAULRf8xC6rFSgoeZdTzvCnFkmp2+heSBg+MUNkDIK 79pg5Yxh7fPZnpa/k7fQwwMAqUxRN8E9EliidC4XXf5Ub3aqt9uKBijJG11AFMkmnDa8 VEjbN6CNTvnTRyBw2vzdxu6dkh15XZOgB/88Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:subject:to:cc:from :user-agent:date; bh=Re7bGdDSOibN8TyYx8ctmhIgW7ORnAd3d48dCZJCs8Q=; b=QU+25ZYxjP6HcooADVKRPLKNlGmMSZaccSiH+1JScJU9EyUVZkiE41Tc03DlHr9zA6 fNneG9DYMKDDe2jQ0r8bjGX/zDHmTI1vCE7JKZQevJOR4Tm2GyVcKfboe3GbJ4Yp/rfU vQqSGNQuczFnLA7yZvd/FyLlIauw6qOexqZYht4ofanrGpxkkBvIZ2+71X9wBjA0P5pm WkXlsSWCo790c0nM7VzO9qCb/ptlBS9x+93ce4pmk2J+x0R+ZVpZ3+Hm+oLt/QUXK3oJ rHbLz7c3ZgSXShmkqLCfKpjWScJZvPEAtdndR6gYUYFyeWMgko2Hp1fxZ4A+Srs1+yG5 2hkw== X-Gm-Message-State: APjAAAVfXLEAdBxKrwlz4OqfCs0+17lRWdobQzO2yaWgaHDxct0sZJsb 7ywLBJjrWu33dQl+WG7n6J7MpQ== X-Google-Smtp-Source: APXvYqxLDMfkGd7dZydioh7pVtp9VngkVUtndNJ46UNpuFKD1wUMhzFnwP3J+Hp0NedhZzJZxsIESg== X-Received: by 2002:a17:90a:8a15:: with SMTP id w21mr59661059pjn.134.1563560570145; Fri, 19 Jul 2019 11:22:50 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id 81sm52293060pfx.111.2019.07.19.11.22.49 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Fri, 19 Jul 2019 11:22:49 -0700 (PDT) Message-ID: <5d320a79.1c69fb81.17c57.b9ba@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190701152907.16407-2-ilina@codeaurora.org> References: <20190701152907.16407-1-ilina@codeaurora.org> <20190701152907.16407-2-ilina@codeaurora.org> Subject: Re: [PATCH 2/2] drivers: qcom: rpmh-rsc: fix read back of trigger register To: Lina Iyer , andy.gross@linaro.org, bjorn.andersson@linaro.org Cc: 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, Lina Iyer From: Stephen Boyd User-Agent: alot/0.8.1 Date: Fri, 19 Jul 2019 11:22:48 -0700 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Quoting Lina Iyer (2019-07-01 08:29:07) > When triggering a TCS to send its contents, reading back the trigger > value may return an incorrect value. That is because, writing the > trigger may raise an interrupt which could be handled immediately and > the trigger value could be reset in the interrupt handler. By doing a > read back we may end up spinning waiting for the value we wrote. Doesn't this need to be squashed into the patch that gets rid of the irqs disabled state of this code? It sounds an awful lot like this problem only happens now because the previous patch removed the irqsave/irqrestore code around this function.