| 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
| ||
|
Date: Wed, 24 May 2023 19:50:14 +0530
From: Jagadeesh Kona <quic_jkona@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Conor Dooley <conor+dt@...nel.org>,
"Bjorn Andersson" <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Taniya Das <quic_tdas@...cinc.com>,
<linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] clk: qcom: videocc-sm8550: Add video clock controller
driver for SM8550
Hi Dmitry,
Thanks for your review!
On 5/9/2023 10:45 PM, Dmitry Baryshkov wrote:
> On Tue, 9 May 2023 at 19:14, Jagadeesh Kona <quic_jkona@...cinc.com> wrote:
>>
>> Add support for the video clock controller for video clients to be able
>> to request for videocc clocks on SM8550 platform.
>>
>> Signed-off-by: Jagadeesh Kona <quic_jkona@...cinc.com>
>> Signed-off-by: Taniya Das <quic_tdas@...cinc.com>
>> ---
>> drivers/clk/qcom/Kconfig | 10 +
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/videocc-sm8550.c | 468 ++++++++++++++++++++++++++++++
>> 3 files changed, 479 insertions(+)
>> create mode 100644 drivers/clk/qcom/videocc-sm8550.c
>>
>> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
>> index 12be3e2371b3..6bb9b4aff047 100644
>> --- a/drivers/clk/qcom/Kconfig
>> +++ b/drivers/clk/qcom/Kconfig
>> @@ -925,6 +925,16 @@ config SM_VIDEOCC_8250
>> Say Y if you want to support video devices and functionality such as
>> video encode and decode.
>>
>> +config SM_VIDEOCC_8550
>> + tristate "SM8550 Video Clock Controller"
>> + select SM_GCC_8550
>> + select QCOM_GDSC
>> + help
>> + Support for the video clock controller on Qualcomm Technologies, Inc.
>> + SM8550 devices.
>> + Say Y if you want to support video devices and functionality such as
>> + video encode/decode.
>> +
>> config SPMI_PMIC_CLKDIV
>> tristate "SPMI PMIC clkdiv Support"
>> depends on SPMI || COMPILE_TEST
>> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
>> index 9ff4c373ad95..f0b95fc217aa 100644
>> --- a/drivers/clk/qcom/Makefile
>> +++ b/drivers/clk/qcom/Makefile
>> @@ -127,6 +127,7 @@ obj-$(CONFIG_SM_GPUCC_8350) += gpucc-sm8350.o
>> obj-$(CONFIG_SM_TCSRCC_8550) += tcsrcc-sm8550.o
>> obj-$(CONFIG_SM_VIDEOCC_8150) += videocc-sm8150.o
>> obj-$(CONFIG_SM_VIDEOCC_8250) += videocc-sm8250.o
>> +obj-$(CONFIG_SM_VIDEOCC_8550) += videocc-sm8550.o
>> obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
>> obj-$(CONFIG_KPSS_XCC) += kpss-xcc.o
>> obj-$(CONFIG_QCOM_HFPLL) += hfpll.o
>> diff --git a/drivers/clk/qcom/videocc-sm8550.c b/drivers/clk/qcom/videocc-sm8550.c
>> new file mode 100644
>> index 000000000000..10e4b2725ddf
>> --- /dev/null
>> +++ b/drivers/clk/qcom/videocc-sm8550.c
>> @@ -0,0 +1,468 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2023, Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/pm_runtime.h>
>> +#include <linux/regmap.h>
>> +
>> +#include <dt-bindings/clock/qcom,sm8550-videocc.h>
>> +
>> +#include "clk-alpha-pll.h"
>> +#include "clk-branch.h"
>> +#include "clk-rcg.h"
>> +#include "clk-regmap.h"
>> +#include "clk-regmap-divider.h"
>> +#include "common.h"
>> +#include "gdsc.h"
>> +#include "reset.h"
>> +
>> +enum {
>> + DT_BI_TCXO,
>
> Any additional handling for gcc_video_ahb clk? It doesn't seem to be
> used as a parent. Probably you intended to use it as a pm_clk?
> Yes it is a pm_clk, but no additional handling is required from driver side.
>> +};
>> +
>> +enum {
>> + P_BI_TCXO,
>> + P_VIDEO_CC_PLL0_OUT_MAIN,
>> + P_VIDEO_CC_PLL1_OUT_MAIN,
>> +};
[skipped]
>> +static struct clk_regmap *video_cc_sm8550_clocks[] = {
>> + [VIDEO_CC_MVS0_CLK] = &video_cc_mvs0_clk.clkr,
>> + [VIDEO_CC_MVS0_CLK_SRC] = &video_cc_mvs0_clk_src.clkr,
>> + [VIDEO_CC_MVS0_DIV_CLK_SRC] = &video_cc_mvs0_div_clk_src.clkr,
>> + [VIDEO_CC_MVS0C_CLK] = &video_cc_mvs0c_clk.clkr,
>> + [VIDEO_CC_MVS0C_DIV2_DIV_CLK_SRC] = &video_cc_mvs0c_div2_div_clk_src.clkr,
>> + [VIDEO_CC_MVS1_CLK] = &video_cc_mvs1_clk.clkr,
>> + [VIDEO_CC_MVS1_CLK_SRC] = &video_cc_mvs1_clk_src.clkr,
>> + [VIDEO_CC_MVS1_DIV_CLK_SRC] = &video_cc_mvs1_div_clk_src.clkr,
>> + [VIDEO_CC_MVS1C_CLK] = &video_cc_mvs1c_clk.clkr,
>> + [VIDEO_CC_MVS1C_DIV2_DIV_CLK_SRC] = &video_cc_mvs1c_div2_div_clk_src.clkr,
>> + [VIDEO_CC_PLL0] = &video_cc_pll0.clkr,
>> + [VIDEO_CC_PLL1] = &video_cc_pll1.clkr,
>> +};
>> +
>> +static struct gdsc *video_cc_sm8550_gdscs[] = {
>> + [VIDEO_CC_MVS0C_GDSC] = &video_cc_mvs0c_gdsc,
>> + [VIDEO_CC_MVS0_GDSC] = &video_cc_mvs0_gdsc,
>> + [VIDEO_CC_MVS1C_GDSC] = &video_cc_mvs1c_gdsc,
>> + [VIDEO_CC_MVS1_GDSC] = &video_cc_mvs1_gdsc,
>> +};
>> +
>> +static const struct qcom_reset_map video_cc_sm8550_resets[] = {
>> + [CVP_VIDEO_CC_INTERFACE_BCR] = { 0x80f0 },
>> + [CVP_VIDEO_CC_MVS0_BCR] = { 0x80a0 },
>> + [CVP_VIDEO_CC_MVS0C_BCR] = { 0x8048 },
>> + [CVP_VIDEO_CC_MVS1_BCR] = { 0x80c8 },
>> + [CVP_VIDEO_CC_MVS1C_BCR] = { 0x8074 },
>
> Please rename them to start with the VIDEO_CC prefix.
>
These names are coming from hardware plan and clients will
refer to hardware plan for these names. So we would like to
keep the names intact same as from hardware plan.
>> + [VIDEO_CC_MVS0C_CLK_ARES] = { 0x8064, 2 },
>> + [VIDEO_CC_MVS1C_CLK_ARES] = { 0x8090, 2 },
>> +};
>> +
>> +static const struct regmap_config video_cc_sm8550_regmap_config = {
>> + .reg_bits = 32,
>> + .reg_stride = 4,
>> + .val_bits = 32,
>> + .max_register = 0x9f4c,
>> + .fast_io = true,
>> +};
>> +
>> +static struct qcom_cc_desc video_cc_sm8550_desc = {
>> + .config = &video_cc_sm8550_regmap_config,
>> + .clks = video_cc_sm8550_clocks,
>> + .num_clks = ARRAY_SIZE(video_cc_sm8550_clocks),
>> + .resets = video_cc_sm8550_resets,
>> + .num_resets = ARRAY_SIZE(video_cc_sm8550_resets),
>> + .gdscs = video_cc_sm8550_gdscs,
>> + .num_gdscs = ARRAY_SIZE(video_cc_sm8550_gdscs),
>> +};
>> +
>> +static const struct of_device_id video_cc_sm8550_match_table[] = {
>> + { .compatible = "qcom,sm8550-videocc" },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, video_cc_sm8550_match_table);
>> +
>> +static int video_cc_sm8550_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_sm8550_desc);
>> + if (IS_ERR(regmap)) {
>> + pm_runtime_put(&pdev->dev);
>> + return PTR_ERR(regmap);
>> + }
>> +
>> + clk_lucid_ole_pll_configure(&video_cc_pll0, regmap, &video_cc_pll0_config);
>> + clk_lucid_ole_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, 0x80f4, BIT(0), BIT(0));
>> + regmap_update_bits(regmap, 0x8140, BIT(0), BIT(0));
>> + regmap_update_bits(regmap, 0x8124, BIT(0), BIT(0));
>> +
>> + ret = qcom_cc_really_probe(pdev, &video_cc_sm8550_desc, regmap);
>> +
>> + pm_runtime_put(&pdev->dev);
>> +
>> + return ret;
>> +}
>> +
>> +static struct platform_driver video_cc_sm8550_driver = {
>> + .probe = video_cc_sm8550_probe,
>> + .driver = {
>> + .name = "video_cc-sm8550",
>> + .of_match_table = video_cc_sm8550_match_table,
>> + },
>> +};
>> +
>> +static int __init video_cc_sm8550_init(void)
>> +{
>> + return platform_driver_register(&video_cc_sm8550_driver);
>> +}
>> +subsys_initcall(video_cc_sm8550_init);
>
> module_platform_driver() instead? There is no need to register videocc
> at the subsys level.
>
We need to evaluate and validate if module_platform_driver works for us
in all scenarios. We will post a cleanup patch once we conclude
module_platform_driver works for us in all cases.
Thanks & Regards,
Jagadeesh
Powered by blists - more mailing lists