On Tue, 9 Jul 2024 at 13:53, Satya Priya Kakitapalli (Temp)
<quic_skakitap@xxxxxxxxxxx> wrote:
On 7/3/2024 3:50 PM, Dmitry Baryshkov wrote:Yes, I'm asking why it's kept up enabled from probe rather than via
On Tue, Jul 02, 2024 at 09:20:43PM GMT, Satya Priya Kakitapalli wrote:These are not required for camcc sm8150 hence not modelled.
Add support for the camera clock controller for camera clientsThe patch mostly LGTM, several quesitons:
to be able to request for camcc clocks on SM8150 platform.
Reviewed-by: Bryan O'Donoghue<bryan.odonoghue@xxxxxxxxxx>
Signed-off-by: Satya Priya Kakitapalli<quic_skakitap@xxxxxxxxxxx>
---
drivers/clk/qcom/Kconfig | 9 +
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/camcc-sm8150.c | 2159 +++++++++++++++++++++++++++++++++++++++
3 files changed, 2169 insertions(+)
- There are no cam_cc_sleep_clk and no cam_cc_xo_clk_src. Why?
- Why is cam_cc_gdsc_clk not modelled in the clock framework?This clock is kept enabled from probe, hence not required to be modelled
explicitly.
clock framework?
Does it apply to SM8150? For example, on SM8250 RCG2s are not parked.- I see that most if not all RCG clocks use rcg2_shared ops instead ofAs per the HW design recommendation, RCG needs to be parked at a safe
using simple rcg2 ops, could you please clarify that?
clock source(XO) in the disable path, shared_ops is used to achieve the
same.
- RETAIN_FF_ENABLE has been used for GDSCs for sc7280, sc8280xp, sm8550,I have rechecked this in downstream and seems it is not really needed
sm8650 and x1e8 platforms. Should it really be set for sm8150? If so,
should it also be added to other camcc drivers (if so, for which
platforms)?
for sm8150, I'll drop in next post.