| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <772ad12e-2865-4c14-d6b8-80c99a30d802@quicinc.com>
Date: Wed, 24 May 2023 19:36:26 +0530
From: Jagadeesh Kona <quic_jkona@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Taniya Das <quic_tdas@...cinc.com>
CC: Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Andy Gross <agross@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
"Bjorn Andersson" <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
<linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<quic_skakitap@...cinc.com>, <quic_imrashai@...cinc.com>,
<quic_ajipan@...cinc.com>
Subject: Re: [PATCH V4 2/3] clk: qcom: videocc-sm8450: Add video clock
controller driver for SM8450
Hi Dmitry,
Thanks for your review!
On 5/19/2023 6:19 PM, Dmitry Baryshkov wrote:
> On Fri, 19 May 2023 at 13:53, Taniya Das <quic_tdas@...cinc.com> wrote:
>>
>> Hello Dmitry,
>>
>> Thank you for your review.
>>
>> On 5/10/2023 2:03 AM, Dmitry Baryshkov wrote:
>>> On Tue, 9 May 2023 at 20:22, Taniya Das <quic_tdas@...cinc.com> wrote:
>>>>
>>>> Add support for the video clock controller driver for peripheral clock
>>>> clients to be able to request for video cc clocks.
>>>>
>>>> Signed-off-by: Taniya Das <quic_tdas@...cinc.com>
>>>> ---
>>>> Changes since V3:
>>>> - Use lower case hex.
>>>> - Check the return value here and bail out early on failure in probe.
>>>>
>>>> Changes since V2:
>>>> - Update the header file name to match the latest upstream header
>>>> files.
>>>>
>>>> Changes since V1:
>>>> - Use DT indices instead of fw_name.
>>>> - Replace pm_runtime_enable with devm_pm_runtime_enable.
>>>> - Change license to GPL from GPL V2.
>>>>
>>>> drivers/clk/qcom/Kconfig | 9 +
>>>> drivers/clk/qcom/Makefile | 1 +
>>>> drivers/clk/qcom/videocc-sm8450.c | 461 ++++++++++++++++++++++++++++++
>>>> 3 files changed, 471 insertions(+)
>>>> create mode 100644 drivers/clk/qcom/videocc-sm8450.c
>>>
>>> [skipped]
>>>
>>>
>>>> +static const struct qcom_reset_map video_cc_sm8450_resets[] = {
>>>> + [CVP_VIDEO_CC_INTERFACE_BCR] = { 0x80e0 },
>>>> + [CVP_VIDEO_CC_MVS0_BCR] = { 0x8098 },
>>>> + [CVP_VIDEO_CC_MVS0C_BCR] = { 0x8048 },
>>>> + [CVP_VIDEO_CC_MVS1_BCR] = { 0x80bc },
>>>> + [CVP_VIDEO_CC_MVS1C_BCR] = { 0x8070 },
>>>
>>> Can we have a common VIDEO_CC prefix here please?
>>
>> The BCR names are coming from hardware plan and software interface, thus
>> we would like to keep them intact.
>
> We have had a similar discussion on the sm8350-videocc driver. While
> keeping the hardware names is nice, name uniformity also should not be
> neglected. It is much easier to follow and verify the patches if all
> videocc resets start with VIDEO_CC name.
>
As mentioned earlier, the BCR names are coming from hardware plan.
Client drivers also use hardware plan to refer to these names. Hence we
would like to keep these names aligned as per the hardware plan.
>>
>>
>>>
>>>> + [VIDEO_CC_MVS0C_CLK_ARES] = { 0x8064, 2 },
>>>> + [VIDEO_CC_MVS1C_CLK_ARES] = { 0x808c, 2 },
>>>> +};
>>>> +
>>
>> The ARES resets are coming from VideoCC clocks(CBCR), hence the name
>> starts with VIDEO_CC.
>>
>>>> +static const struct regmap_config video_cc_sm8450_regmap_config = {
>>>> + .reg_bits = 32,
>>>> + .reg_stride = 4,
>>>> + .val_bits = 32,
>>>> + .max_register = 0x9f4c,
>>>> + .fast_io = true,
>>>> +};
>>>> +
>>>> +static struct qcom_cc_desc video_cc_sm8450_desc = {
>>>> + .config = &video_cc_sm8450_regmap_config,
>>>> + .clks = video_cc_sm8450_clocks,
>>>> + .num_clks = ARRAY_SIZE(video_cc_sm8450_clocks),
>>>> + .resets = video_cc_sm8450_resets,
>>>> + .num_resets = ARRAY_SIZE(video_cc_sm8450_resets),
>>>> + .gdscs = video_cc_sm8450_gdscs,
>>>> + .num_gdscs = ARRAY_SIZE(video_cc_sm8450_gdscs),
>>>> +};
>>>> +
>>>> +static const struct of_device_id video_cc_sm8450_match_table[] = {
>>>> + { .compatible = "qcom,sm8450-videocc" },
>>>> + { }
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, video_cc_sm8450_match_table);
>>>> +
>>>> +static int video_cc_sm8450_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct regmap *regmap;
>>>> + int ret;
>>>> +
>>>> + ret = devm_pm_runtime_enable(&pdev->dev);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + ret = pm_runtime_resume_and_get(&pdev->dev);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + regmap = qcom_cc_map(pdev, &video_cc_sm8450_desc);
>>>> + if (IS_ERR(regmap)) {
>>>> + pm_runtime_put(&pdev->dev);
>>>> + return PTR_ERR(regmap);
>>>> + }
>>>> +
>>>> + clk_lucid_evo_pll_configure(&video_cc_pll0, regmap, &video_cc_pll0_config);
>>>> + clk_lucid_evo_pll_configure(&video_cc_pll1, regmap, &video_cc_pll1_config);
>>>> +
>>>> + /*
>>>> + * Keep clocks always enabled:
>>>> + * video_cc_ahb_clk
>>>> + * video_cc_sleep_clk
>>>> + * video_cc_xo_clk
>>>> + */
>>>> + regmap_update_bits(regmap, 0x80e4, BIT(0), BIT(0));
>>>> + regmap_update_bits(regmap, 0x8130, BIT(0), BIT(0));
>>>> + regmap_update_bits(regmap, 0x8114, BIT(0), BIT(0));
>>>> +
>>>> + ret = qcom_cc_really_probe(pdev, &video_cc_sm8450_desc, regmap);
>>>> +
>>>> + pm_runtime_put(&pdev->dev);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static struct platform_driver video_cc_sm8450_driver = {
>>>> + .probe = video_cc_sm8450_probe,
>>>> + .driver = {
>>>> + .name = "video_cc-sm8450",
>>>> + .of_match_table = video_cc_sm8450_match_table,
>>>> + },
>>>> +};
>>>> +
>>>> +static int __init video_cc_sm8450_init(void)
>>>> +{
>>>> + return platform_driver_register(&video_cc_sm8450_driver);
>>>> +}
>>>> +subsys_initcall(video_cc_sm8450_init);
>>>> +
>>>> +static void __exit video_cc_sm8450_exit(void)
>>>> +{
>>>> + platform_driver_unregister(&video_cc_sm8450_driver);
>>>> +}
>>>> +module_exit(video_cc_sm8450_exit);
>>>
>>> module_platform_driver() ?
>>>
>>
>> We would like to keep the clock drivers all probed at subsys_initcall.
>> We could revisit and update as cleanup if we want to move them to module
>> init.
>
> Any particular reason?
>
We need to evaluate and validate if module_initcall works for us in all
the scenarios. We will revisit and post a cleanup patch once we conclude
module_initcall works for us in all scenarios.
Thanks & Regards,
Jagadeesh
Powered by blists - more mailing lists