[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4uxrknyfpxds73gnzql34a4ksph2b5plpxqkcddgyrcflxtgp@5dkvmdptvqbx>
Date: Sun, 25 Jun 2023 21:44:21 +0200
From: Marijn Suijten <marijn.suijten@...ainline.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rob Clark <robdclark@...il.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Krishna Manikandan <quic_mkrishn@...cinc.com>,
~postmarketos/upstreaming@...ts.sr.ht,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Martin Botka <martin.botka@...ainline.org>,
Jami Kettunen <jami.kettunen@...ainline.org>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org,
Krzysztof Kozlowski <krzk@...nel.org>,
linux-clk@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, Lux Aliaga <they@...t.lgbt>
Subject: Re: [PATCH 02/15] dt-bindings: clock: qcom,dispcc-sm6125: Remove
unused GCC_DISP_AHB_CLK
On 2023-06-24 11:08:30, Krzysztof Kozlowski wrote:
> On 24/06/2023 02:41, Marijn Suijten wrote:
> > The downsteam driver for dispcc only ever gets and puts this clock
> > without ever using it in the clocktree; this unnecessary workaround was
> > never ported to mainline, hence the driver doesn't consume this clock
> > and shouldn't be required by the bindings.
> >
> > Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock bindings")
> > Signed-off-by: Marijn Suijten <marijn.suijten@...ainline.org>
> > ---
>
> In perfect would we would like to know whether hardware needs this clock
> enabled/controlled, not whether some driver needs it. I understand
> though that with lack of proper docs we rely on drivers, so:
It might only use this to figure out if those clocks have already probed
or are available. The logic goes as follows:
clk = devm_clk_get(&pdev->dev, "cfg_ahb_clk");
if (IS_ERR(clk)) {
if (PTR_ERR(clk) != -EPROBE_DEFER)
dev_err(&pdev->dev, "Unable to get ahb clock handle\n");
return PTR_ERR(clk);
}
devm_clk_put(&pdev->dev, clk);
Nothing else uses/parents cfg_ahb_clk. Maybe with clk_ignore_unused or
similar, it gets turned on but never off again?
Indeed, a lack of documentation and comment from the manufacturer makes
it impossible to know, and ignoring it (as the driver already does)
works just fine.
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Thanks!
- Marijn
>
> Best regards,
> Krzysztof
>
Powered by blists - more mailing lists