[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230406201634.GA20288@sol.localdomain>
Date: Thu, 6 Apr 2023 13:16:34 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Abel Vesa <abel.vesa@...aro.org>
Cc: Ulf Hansson <ulf.hansson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Manivannan Sadhasivam <mani@...nel.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Avri Altman <avri.altman@....com>,
Bart Van Assche <bvanassche@....org>,
Adrian Hunter <adrian.hunter@...el.com>,
"James E . J . Bottomley" <jejb@...ux.ibm.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S . Miller" <davem@...emloft.net>,
linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm-msm@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-scsi@...r.kernel.org
Subject: Re: [PATCH v5 4/6] scsi: ufs: ufs-qcom: Switch to the new ICE API
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 <abel.vesa@...aro.org>
This is still silent about how the ICE clock behavior is being changed.
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.
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.
Is that intended?
- Eric
Powered by blists - more mailing lists