Il 11/02/22 04:51, Dawei Chien ha scritto:
On Thu, 2022-02-03 at 16:04 +0100, AngeloGioacchino Del Regno wrote:
Il 12/08/21 10:58, Dawei Chien ha scritto:
From: Henry Chen <henryc.chen@xxxxxxxxxxxx>
Add dvfsrc driver for MT6873/MT8183/MT8192
Signed-off-by: Henry Chen <henryc.chen@xxxxxxxxxxxx>
Signed-off-by: Dawei Chien <dawei.chien@xxxxxxxxxxxx>
---
drivers/soc/mediatek/Kconfig | 11 +
drivers/soc/mediatek/Makefile | 1 +
drivers/soc/mediatek/mtk-dvfsrc.c | 421
++++++++++++++++++++++++++++++++
include/linux/soc/mediatek/mtk_dvfsrc.h | 35 +++
4 files changed, 468 insertions(+)
create mode 100644 drivers/soc/mediatek/mtk-dvfsrc.c
create mode 100644 include/linux/soc/mediatek/mtk_dvfsrc.h
..snip..
diff --git a/drivers/soc/mediatek/mtk-dvfsrc.c
b/drivers/soc/mediatek/mtk-dvfsrc.c
new file mode 100644
index 000000000000..6ef167cf55bd
--- /dev/null
+++ b/drivers/soc/mediatek/mtk-dvfsrc.c
..snip..
+static int mtk_dvfsrc_probe(struct platform_device *pdev)
+{
+ struct arm_smccc_res ares;
+ struct resource *res;
+ struct mtk_dvfsrc *dvfsrc;
+ int ret;
+
+ dvfsrc = devm_kzalloc(&pdev->dev, sizeof(*dvfsrc), GFP_KERNEL);
+ if (!dvfsrc)
+ return -ENOMEM;
+
+ dvfsrc->dvd = of_device_get_match_data(&pdev->dev);
+ dvfsrc->dev = &pdev->dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ dvfsrc->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dvfsrc->regs))
+ return PTR_ERR(dvfsrc->regs);
+
+ spin_lock_init(&dvfsrc->req_lock);
+ mutex_init(&dvfsrc->pstate_lock);
+
+ arm_smccc_smc(MTK_SIP_VCOREFS_CONTROL, MTK_SIP_DVFSRC_INIT, 0,
0, 0,
+ 0, 0, 0, &ares);
+
+ if (!ares.a0) {
+ dvfsrc->dram_type = ares.a1;
+ dev_info(dvfsrc->dev, "dram_type: %d\n", dvfsrc-
dram_type);
+ } else {
+ dev_err(dvfsrc->dev, "init fails: %lu\n", ares.a0);
+ return ares.a0;
+ }
+
+ dvfsrc->curr_opps = &dvfsrc->dvd->opps_desc[dvfsrc->dram_type];
+ platform_set_drvdata(pdev, dvfsrc);
+
+ dvfsrc->regulator = platform_device_register_data(dvfsrc->dev,
+ "mtk-dvfsrc-regulator", -1, NULL, 0);
Why are you registering platform devices like this?
Please use device-tree instead.
Thank you for advisement. Let me just describe history.
Actually, we did use device-tree to probe interconnect/regulator driver
in v4, and reviewer had some advisement
https://patchwork.kernel.org/project/linux-mediatek/patch/1584092066-24425-12-git-send-email-henryc.chen@xxxxxxxxxxxx/#23243049
https://patchwork.kernel.org/project/linux-mediatek/patch/1584092066-24425-9-git-send-email-henryc.chen@xxxxxxxxxxxx/#23236945
so we refer to this driver to use platform_device_register_data after
v5.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/soc/qcom/smd-rpm.c?h=next-20220209#n213
Would you kindly give your advisement, thank you.
Hello Dawei,
I was under the impression that the regulator and EMI were different hardware,
while effectively they are inside of the DVFS Resource Collector IP, and the
registers look like being a bit mixed up, so it's impossible to actually
specify a relative iospace for the regulator, or for the EMI.
In this case, from what I understand right now, the emi and regulator are not
different hardware, but "features of" the DVFS Resource Collector.
I've done some research around the kernel and, effectively, the only way that
makes sense, is to register the feature-drivers (emi/vreg) with
platform_device_register_data(), as per your current approach, even though I
have a hunch that it will look a bit confusing in device-tree, as you'd be using
the same node for both regulator and interconnects...
I would exclude doing it as a MFD driver, as I don't see any very clean way to
actually implement that.
At this point, let's just keep it as it is, or this would probably get a lot
overcomplicated for no good reasons.
So, please ignore the device-tree suggestion and go on with the other suggested
fixes for this driver.
Looking forward to see your v4!
Kind regards,
Angelo
