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=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 BC1BCC10F25 for ; Mon, 9 Mar 2020 21:10:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9ACD82465A for ; Mon, 9 Mar 2020 21:10:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583788258; bh=yU68s5HuqYhNTYUkzjC1U86mJUMTG72xWa99BdXa1bY=; h=In-Reply-To:References:Subject:From:Cc:To:Date:List-ID:From; b=AeEMKGDNoANlCQTl8TqbPktM+TQnls7fJtlxvQGWX1XFQpOOMob+/h0V3qT2vuQjP dxIfl1vgPTJl4E8Ahx4u/9npKJ7SjwvHaYYOem5KRlTQYzTIXnat2Ux445oHmgiZGt K3ZQLDmmqhm+B68+gOLzQTUJs8sr1ItYb+vHi7eU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726439AbgCIVKz (ORCPT ); Mon, 9 Mar 2020 17:10:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:33978 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726157AbgCIVKz (ORCPT ); Mon, 9 Mar 2020 17:10:55 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D84DF2146E; Mon, 9 Mar 2020 21:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583788255; bh=yU68s5HuqYhNTYUkzjC1U86mJUMTG72xWa99BdXa1bY=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=ZiHtmQcjssp3eqcwno/Z5O1qOGfIC18fPg9z1OUcICEZI42NWDZ6K1K5BWNv+P1uM USxqOOwfqAdf8EDqwM8vqAoxXEWc6UQFXWyXUQsDR8/im7LeR09i+cT5LHc9fwoy4S EkSQNZCoVaFh0602XoLwEmox69k44dEIyZshMPNk= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20200215021232.1149-1-mdtipton@codeaurora.org> References: <20200215021232.1149-1-mdtipton@codeaurora.org> Subject: Re: [PATCH] clk: qcom: clk-rpmh: Wait for completion when enabling clocks From: Stephen Boyd Cc: bjorn.andersson@linaro.org, mturquette@baylibre.com, agross@kernel.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Tipton To: Mike Tipton , tdas@codeaurora.org Date: Mon, 09 Mar 2020 14:10:54 -0700 Message-ID: <158378825407.66766.14135857856613969751@swboyd.mtv.corp.google.com> User-Agent: alot/0.9 Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Quoting Mike Tipton (2020-02-14 18:12:32) > The current implementation always uses rpmh_write_async, which doesn't > wait for completion. That's fine for disable requests since there's no > immediate need for the clocks and they can be disabled in the > background. However, for enable requests we need to ensure the clocks > are actually enabled before returning to the client. Otherwise, clients > can end up accessing their HW before the necessary clocks are enabled, > which can lead to bus errors. >=20 > Use the synchronous version of this API (rpmh_write) for enable requests > in the active set to ensure completion. >=20 > Completion isn't required for sleep/wake sets, since they don't take > effect until after we enter sleep. All rpmh requests are automatically > flushed prior to entering sleep. >=20 > Fixes: 9c7e47025a6b ("clk: qcom: clk-rpmh: Add QCOM RPMh clock driver") > Signed-off-by: Mike Tipton > --- Applied to clk-next but I squashed in some changes to make it easier for me to read.