Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1281605rwb; Thu, 1 Dec 2022 15:11:48 -0800 (PST) X-Google-Smtp-Source: AA0mqf6dalNsfzG/WNhztLefpuTBs6LUPycMGdPd/IKM+vdBcGXBWVRl58qHUYbHZvK4kQQBN+jM X-Received: by 2002:aa7:cd91:0:b0:469:2f36:fd with SMTP id x17-20020aa7cd91000000b004692f3600fdmr48425065edv.385.1669936307936; Thu, 01 Dec 2022 15:11:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669936307; cv=none; d=google.com; s=arc-20160816; b=Twdb4Degp3G4iN3wrV1BSmvQ1T8HNRDLMIAGXiCTkVlr4qSRl0cfJz+G9vrErUrdCj Kl/A8dM14azidtthr7Fp1D8WXA9jEVI3Y2EfuIGFv9TnHA/q9Jcs1DOTK/CBXxp03yIl CJ30BpX/YFVzk1gfH2LAPDNlqZhHuQntUyOUjv4PHF3uE1KOezjuvSe84L4usoi1bolg Q4ZYcZQyjZD8LPvn63vtCIy/zVcRmyn6+5ii810Loq6jRTxS43lYIask3umEJpRL//x1 WtoaHVSc3OrpJqDJBjLJq04b/gqXcHWsfOIm76T7s+HDZ/+lD1NgWZAYGk6fInG9jHgz S/zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=fCPxH2q1KQ1JbqqWkb97/NMJ6dMBGekChqIhAvpWTQA=; b=wKLV1kmlM7HYpn5X3IF0wuIi6tNihUjG9+rkTx8xCdjaRVmh4nrK8c8zC1TPTyZJHl 4IzJBZGSNA3kvnj4kOTwPsBpkK7d83Fuh8rIBr+ux4xLk1L1z41XVocvVz4ra0Zfpd8y +1A9ZvGEsBmrbKlzINyKGgPQGk8E4VDsPiP9kONS2BtZXmNEmpNg3NKJvSGrjzuhL2sc d0BMyhOifAFukX5kjUsb6KbtQMzCClWoqdpAdwhOhyC/DNuBVZfbW8LAD2SMSMNUhI4f b4IBXbSx8TZMP0pCokTFKVMX5OMW2mrW5+dCSbloIYNj7kwwW7GAI1aMLnr4G6SeIgY1 aMvg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Dhi9a4n1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sd36-20020a1709076e2400b007ae814af6aasi5231729ejc.87.2022.12.01.15.11.28; Thu, 01 Dec 2022 15:11:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Dhi9a4n1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231572AbiLAW5Q (ORCPT + 81 others); Thu, 1 Dec 2022 17:57:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50296 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230284AbiLAW5M (ORCPT ); Thu, 1 Dec 2022 17:57:12 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51973BE4E6; Thu, 1 Dec 2022 14:57:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0649CB82059; Thu, 1 Dec 2022 22:57:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 158DCC433C1; Thu, 1 Dec 2022 22:57:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669935428; bh=Iece4Ggdjnc0zgVTxLn8Qf6TaPc+ROmQXehO4YnTyUk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Dhi9a4n1MDkugPm6zzlyfa1b463Z4vsP2TF/EUCWg0UeTI/wZXo9HV75Wrqt9ktiN 0VE/7gjmbALvarkSaaTK2vduEPR3b0vHlQ8YRjQW8VWmt3r+0KG1ZSer25P2FwUi4j cIPN0/vWkJ8U0tyCI294h+QP/yExXFxgYvLJKem9oRgF7bqTyzY4Cwk8MzOUMgialh XqMJ+4y7T+NuC9fDSOQlLlGdDWFmKH7jGWrxKiw6TPwsijz0ec+D7b7uT0a9dTAuWG W4sAIyUbit8zbldtmN0SLaKsxMhCJgIrQev/i8YLwVihXjXRSQEWEKeAiL1dqsFWj6 m/m92RAlKTIxA== Date: Thu, 1 Dec 2022 16:57:05 -0600 From: Bjorn Andersson To: Akhil P Oommen , Ulf Hansson Cc: freedreno , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Rob Clark , Stephen Boyd , Dmitry Baryshkov , Philipp Zabel , Douglas Anderson , krzysztof.kozlowski@linaro.org, Abhinav Kumar , Andy Gross , Daniel Vetter , David Airlie , Konrad Dybcio , Krzysztof Kozlowski , Michael Turquette , Rob Herring , Sean Paul , Stephen Boyd , devicetree@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 0/6] clk/qcom: Support gdsc collapse polling using 'reset' interface Message-ID: <20221201225705.46r2m35ketvzipox@builder.lan> References: <1664960824-20951-1-git-send-email-quic_akhilpo@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1664960824-20951-1-git-send-email-quic_akhilpo@quicinc.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 05, 2022 at 02:36:58PM +0530, Akhil P Oommen wrote: > @Ulf, Akhil has a power-domain for a piece of hardware which may be voted active by multiple different subsystems (co-processors/execution contexts) in the system. As such, during the powering down sequence we don't wait for the power-domain to turn off. But in the event of an error, the recovery mechanism relies on waiting for the hardware to settle in a powered off state. The proposal here is to use the reset framework to wait for this state to be reached, before continuing with the recovery mechanism in the client driver. Given our other discussions on quirky behavior, do you have any input/suggestions on this? > Some clients like adreno gpu driver would like to ensure that its gdsc > is collapsed at hardware during a gpu reset sequence. This is because it > has a votable gdsc which could be ON due to a vote from another subsystem > like tz, hyp etc or due to an internal hardware signal. To allow > this, gpucc driver can expose an interface to the client driver using > reset framework. Using this the client driver can trigger a polling within > the gdsc driver. @Akhil, this description is fairly generic. As we've reached the state where the hardware has settled and we return to the client, what prevents it from being powered up again? Or is it simply a question of it hitting the powered-off state, not necessarily staying there? Regards, Bjorn > > This series is rebased on top of qcom/linux:for-next branch. > > Related discussion: https://patchwork.freedesktop.org/patch/493144/ > > Changes in v7: > - Update commit message (Bjorn) > - Rebased on top of qcom/linux:for-next branch. > > Changes in v6: > - No code changes in this version. Just captured the Acked-by tags > > Changes in v5: > - Nit: Remove a duplicate blank line (Krzysztof) > > Changes in v4: > - Update gpu dt-binding schema > - Typo fix in commit text > > Changes in v3: > - Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof) > > Changes in v2: > - Return error when a particular custom reset op is not implemented. (Dmitry) > > Akhil P Oommen (6): > dt-bindings: clk: qcom: Support gpu cx gdsc reset > clk: qcom: Allow custom reset ops > clk: qcom: gdsc: Add a reset op to poll gdsc collapse > clk: qcom: gpucc-sc7280: Add cx collapse reset support > dt-bindings: drm/msm/gpu: Add optional resets > arm64: dts: qcom: sc7280: Add Reset support for gpu > > .../devicetree/bindings/display/msm/gpu.yaml | 6 +++++ > arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +++ > drivers/clk/qcom/gdsc.c | 23 ++++++++++++++---- > drivers/clk/qcom/gdsc.h | 7 ++++++ > drivers/clk/qcom/gpucc-sc7280.c | 10 ++++++++ > drivers/clk/qcom/reset.c | 27 +++++++++++++++++++++- > drivers/clk/qcom/reset.h | 8 +++++++ > include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ > 8 files changed, 82 insertions(+), 5 deletions(-) > > -- > 2.7.4 >