[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d44b972-9337-472a-9010-71ebaa0d45cf@linaro.org>
Date: Thu, 26 Oct 2023 12:34:27 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
andersson@...nel.org, agross@...nel.org, mturquette@...libre.com,
sboyd@...nel.org, dmitry.baryshkov@...aro.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
jonathan@...ek.ca, quic_tdas@...cinc.com,
vladimir.zapolskiy@...aro.org
Cc: linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v4 3/4] clk: qcom: camcc-sc8280xp: Add sc8280xp
CAMCC
On 26/10/2023 12:21, Konrad Dybcio wrote:
>> + .flags = HW_CTRL | RETAIN_FF_ENABLE,
> This should really be HW_CTRL_TRIGGER from [1]
>
> and then downstream uses cam_bps_transfer_gdsc_control and
> cam_bps_get_gdsc_control to control hw (fast) or sw (normal) mode
>
> similarly in drivers/cam_icp/icp_hw/ipe_hw/ipe_soc.c for IPE
I'm happy to do such a conversion if said patch hits -next, qcom-next or
clk-next before this patch, otherwise I'd rather not gate this driver on
stuff that's not queued anywhere.
There's alot of CAMSS stuff driver/compat/dtsi that is gated on having
the CAMCC upstream, effectively all of the CAMSS stuff for sc8280xp.
Fair ?
---
bod
Powered by blists - more mailing lists