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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB9F2C76196 for ; Fri, 7 Apr 2023 07:02:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229531AbjDGHCn (ORCPT ); Fri, 7 Apr 2023 03:02:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231814AbjDGHCm (ORCPT ); Fri, 7 Apr 2023 03:02:42 -0400 Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77A607EF1 for ; Fri, 7 Apr 2023 00:02:40 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id s13so23569061wmr.4 for ; Fri, 07 Apr 2023 00:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680850959; x=1683442959; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yDRZJb+gw9WKl+q/YP3+9vfEWrdxXYb08xE3KjrncwY=; b=TlUNuHXhE7dkX3ma2znO7zdAacJiO27ghArmpkXlH8c3ATv+KBTc8LUhyVrkypI+mP 0zQlggzvEemyf2P17MWTNYZVT5pEmY7G8l0KpU4b0QsyPvMfMJZshCs5c4HdBgpV6MQP XN2grzseW68CfcpULpwxh3ynO/USV/6im6FxHW40/svQL+ApI5uK1eCRpcAHn1PqPRYE iwww25egOIvVPfxbt4pMX674CTKLbiVEO/0Ip1e+6ahSlHwFQkQF7naCFmxlgJCIHPZU 6QypBjxTNvF8oRGQexdGN9PM2UNsP9cuq6GQxZBhFfnm80WY+czp/4FjLGOZC9ZJW9dw 8zbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680850959; x=1683442959; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yDRZJb+gw9WKl+q/YP3+9vfEWrdxXYb08xE3KjrncwY=; b=y+a3f8dNx+oLSfzu/LuKxhy8cjeuhu/mSfxkiF8O8m4eFHa/hAx32n/uZxyODvd39p wEFxXmkQ/OvMNdy1iYvmLetrjYjceFhbVSWNUi5fCR2F+lbHv18o8VoA7rxQdzpqXB0e LXOi6cjxpCMsZZhE3vxwjlYsm2uPeUvhfmDJsljZr81lvjA7OvdgrE3t9rkLAITGhuyb FwnM40bHsyqD7hD6ieKWUua32AiPWsiwUlyEB5s54AtfYqHxRJC7u38Zi9OmEHQEj46g a33LhSUUWcbUkzXqohqRAjH2ckEJgNhoyk8TkmfYZF8FXr/1gEwVBzgKO5EZKWAMzGzb ZTbg== X-Gm-Message-State: AAQBX9eetndJ5wIqp/PRawxYDNlQGwq0MjunASj+QOL6J/8zUsdXHc1l 6oJC6dRMUr8dmJeH3WQmexXmNg== X-Google-Smtp-Source: AKy350Yf7cZzWZgOSGchAXM9/7IoYqhc4Z0zpcrhQUgBsDYEyMpw3OS/oAAO8/EgLIduuLczRZdj6g== X-Received: by 2002:a05:600c:2202:b0:3ee:289a:3c3a with SMTP id z2-20020a05600c220200b003ee289a3c3amr566623wml.30.1680850958894; Fri, 07 Apr 2023 00:02:38 -0700 (PDT) Received: from linaro.org ([94.52.112.99]) by smtp.gmail.com with ESMTPSA id i42-20020a05600c4b2a00b003f0321c22basm7224793wmp.12.2023.04.07.00.02.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Apr 2023 00:02:38 -0700 (PDT) Date: Fri, 7 Apr 2023 10:02:36 +0300 From: Abel Vesa To: Eric Biggers Cc: Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Konrad Dybcio , Manivannan Sadhasivam , Alim Akhtar , Avri Altman , Bart Van Assche , Adrian Hunter , "James E . J . Bottomley" , "Martin K . Petersen" , Herbert Xu , "David S . Miller" , linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, Linux Kernel Mailing List , linux-arm-msm@vger.kernel.org, linux-crypto@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: [PATCH v5 4/6] scsi: ufs: ufs-qcom: Switch to the new ICE API Message-ID: References: <20230403200530.2103099-1-abel.vesa@linaro.org> <20230403200530.2103099-5-abel.vesa@linaro.org> <20230406201634.GA20288@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230406201634.GA20288@sol.localdomain> Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 23-04-06 13:16:34, Eric Biggers wrote: > Hi Abel, > > On Mon, Apr 03, 2023 at 11:05:28PM +0300, Abel Vesa wrote: > > Now that there is a new dedicated ICE driver, drop the ufs-qcom-ice and > > use the new ICE api provided by the Qualcomm soc driver ice. The platforms > > that already have ICE support will use the API as library since there will > > not be a devicetree node, but instead they have reg range. In this case, > > the of_qcom_ice_get will return an ICE instance created for the consumer's > > device. But if there are platforms that do not have ice reg in the > > consumer devicetree node and instead provide a dedicated ICE devicetree > > node, the of_qcom_ice_get will look up the device based on qcom,ice > > property and will get the ICE instance registered by the probe function > > of the ice driver. > > > > Signed-off-by: Abel Vesa > > This is still silent about how the ICE clock behavior is being changed. Right, I'll add the some more info into the commit message about the clock being handled by the ICE driver. > > I'm still trying to understand all this myself, so please bear with me, but my > understanding is that the UFS clocks can be disabled even while the host > controller is runtime-resumed. This is called "clock gating" in the code. The ICE clock is now being controlled by the new driver. > > Before, the ICE clock was just listed as one of the UFS clocks. So, it was just > managed like the other UFS clocks. > > Now, it appears that the ICE clock is always enabled while the host controller > is runtime-resumed. So, this patch removes support for gating of the ICE clock. I just tested this and it works as expected, which is: ICE clock gets enable on qcom_ice_create (via *clk_get*_enabled) and then, on the runtime suspend of the UFS, the qcom_ice_suspend is called which will disable the clock. Then, every time UFS runtime resumes/suspends the clock gets enabled/disabled. Hope that makes sense. Let me know if you think I'm missing something here. > > Is that intended? > > - Eric