From: "Heiko Stübner" <heiko@sntech.de>
To: Ulf Hansson <ulf.hansson@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Frank Wang <frank.wang@rock-chips.com>,
Shresth Prasad <shresthprasad7@gmail.com>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Detlev Casanova <detlev.casanova@collabora.com>,
Jonas Karlman <jonas@kwiboo.se>, Yao Zi <ziyao@disroot.org>
Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, Yao Zi <ziyao@disroot.org>
Subject: Re: [PATCH 6/8] clk: rockchip: rk3528: Add SD/SDIO tuning clocks in GRF region
Date: Wed, 05 Mar 2025 11:21:48 +0100 [thread overview]
Message-ID: <2583035.OBFZWjSADL@diego> (raw)
In-Reply-To: <20250301104724.36399-1-ziyao@disroot.org>
Hi,
Am Samstag, 1. März 2025, 11:47:24 MEZ schrieb Yao Zi:
> These clocks locate in VO and VPU GRF, serving for SD/SDIO controller
> tuning purpose. Add their definitions and register them in driver if
> corresponding GRF is available.
(no critique, just an observation :-) )
this puts a completely new meaning on the "general register files"
as dumping ground ;-) .
Whoever got the idea of making sdmm/sdio tuning controls part
of GRFs that are supposed display and/or video encoder parts :-D
> GRFs are looked up by compatible to simplify devicetree binding.
>
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> static int __init clk_rk3528_probe(struct platform_device *pdev)
> {
> + unsigned long nr_vpu_branches = ARRAY_SIZE(rk3528_vpu_clk_branches);
> + unsigned long nr_vo_branches = ARRAY_SIZE(rk3528_vo_clk_branches);
> + unsigned long nr_branches = ARRAY_SIZE(rk3528_clk_branches);
> struct rockchip_clk_provider *ctx;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - unsigned long nr_branches = ARRAY_SIZE(rk3528_clk_branches);
> - unsigned long nr_clks;
> + struct regmap *vo_grf, *vpu_grf;
> void __iomem *reg_base;
> -
> - nr_clks = rockchip_clk_find_max_clk_id(rk3528_clk_branches,
> - nr_branches) + 1;
> + unsigned long nr_clks;
>
> reg_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(reg_base))
> return dev_err_probe(dev, PTR_ERR(reg_base),
> "could not map cru region");
>
> + nr_clks = rockchip_clk_find_max_clk_id(rk3528_clk_branches,
> + nr_branches) + 1;
> +
> + vo_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3528-vo-grf");
> + if (!IS_ERR(vo_grf))
for readability, please make this into something like
if (!IS_ERR(vo_grf)) {
nr_vo_clks = rockchip_clk_find_max_clk_id(rk3528_vo_clk_branches,
nr_vo_branches) + 1;
nr_clks = max(nr_vo_clks, nr_clks);
}
> + else if (PTR_ERR(vo_grf) != ENODEV)
> + return dev_err_probe(dev, PTR_ERR(vo_grf),
> + "failed to look up VO GRF\n");
> +
> + vpu_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3528-vpu-grf");
> + if (!IS_ERR(vpu_grf))
> + nr_clks = MAX(rockchip_clk_find_max_clk_id(rk3528_vpu_clk_branches,
> + nr_vpu_branches) + 1,
> + nr_clks);
same here please
> + else if (PTR_ERR(vpu_grf) != ENODEV)
> + return dev_err_probe(dev, PTR_ERR(vpu_grf),
> + "failed to look up VPU GRF\n");
> +
> ctx = rockchip_clk_init(np, reg_base, nr_clks);
> if (IS_ERR(ctx))
> return dev_err_probe(dev, PTR_ERR(ctx),
Thanks
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Ulf Hansson <ulf.hansson@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Frank Wang <frank.wang@rock-chips.com>,
Shresth Prasad <shresthprasad7@gmail.com>,
Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Detlev Casanova <detlev.casanova@collabora.com>,
Jonas Karlman <jonas@kwiboo.se>, Yao Zi <ziyao@disroot.org>
Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, Yao Zi <ziyao@disroot.org>
Subject: Re: [PATCH 6/8] clk: rockchip: rk3528: Add SD/SDIO tuning clocks in GRF region
Date: Wed, 05 Mar 2025 11:21:48 +0100 [thread overview]
Message-ID: <2583035.OBFZWjSADL@diego> (raw)
In-Reply-To: <20250301104724.36399-1-ziyao@disroot.org>
Hi,
Am Samstag, 1. März 2025, 11:47:24 MEZ schrieb Yao Zi:
> These clocks locate in VO and VPU GRF, serving for SD/SDIO controller
> tuning purpose. Add their definitions and register them in driver if
> corresponding GRF is available.
(no critique, just an observation :-) )
this puts a completely new meaning on the "general register files"
as dumping ground ;-) .
Whoever got the idea of making sdmm/sdio tuning controls part
of GRFs that are supposed display and/or video encoder parts :-D
> GRFs are looked up by compatible to simplify devicetree binding.
>
> Signed-off-by: Yao Zi <ziyao@disroot.org>
> ---
> static int __init clk_rk3528_probe(struct platform_device *pdev)
> {
> + unsigned long nr_vpu_branches = ARRAY_SIZE(rk3528_vpu_clk_branches);
> + unsigned long nr_vo_branches = ARRAY_SIZE(rk3528_vo_clk_branches);
> + unsigned long nr_branches = ARRAY_SIZE(rk3528_clk_branches);
> struct rockchip_clk_provider *ctx;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - unsigned long nr_branches = ARRAY_SIZE(rk3528_clk_branches);
> - unsigned long nr_clks;
> + struct regmap *vo_grf, *vpu_grf;
> void __iomem *reg_base;
> -
> - nr_clks = rockchip_clk_find_max_clk_id(rk3528_clk_branches,
> - nr_branches) + 1;
> + unsigned long nr_clks;
>
> reg_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(reg_base))
> return dev_err_probe(dev, PTR_ERR(reg_base),
> "could not map cru region");
>
> + nr_clks = rockchip_clk_find_max_clk_id(rk3528_clk_branches,
> + nr_branches) + 1;
> +
> + vo_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3528-vo-grf");
> + if (!IS_ERR(vo_grf))
for readability, please make this into something like
if (!IS_ERR(vo_grf)) {
nr_vo_clks = rockchip_clk_find_max_clk_id(rk3528_vo_clk_branches,
nr_vo_branches) + 1;
nr_clks = max(nr_vo_clks, nr_clks);
}
> + else if (PTR_ERR(vo_grf) != ENODEV)
> + return dev_err_probe(dev, PTR_ERR(vo_grf),
> + "failed to look up VO GRF\n");
> +
> + vpu_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3528-vpu-grf");
> + if (!IS_ERR(vpu_grf))
> + nr_clks = MAX(rockchip_clk_find_max_clk_id(rk3528_vpu_clk_branches,
> + nr_vpu_branches) + 1,
> + nr_clks);
same here please
> + else if (PTR_ERR(vpu_grf) != ENODEV)
> + return dev_err_probe(dev, PTR_ERR(vpu_grf),
> + "failed to look up VPU GRF\n");
> +
> ctx = rockchip_clk_init(np, reg_base, nr_clks);
> if (IS_ERR(ctx))
> return dev_err_probe(dev, PTR_ERR(ctx),
Thanks
Heiko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-03-05 10:53 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-01 10:42 [PATCH 0/8] Support SD/SDIO controllers on RK3528 Yao Zi
2025-03-01 10:42 ` Yao Zi
2025-03-01 10:42 ` [PATCH 1/8] dt-bindings: soc: rockchip: Add RK3528 VO GRF syscon Yao Zi
2025-03-01 10:42 ` Yao Zi
2025-03-03 15:07 ` Rob Herring (Arm)
2025-03-03 15:07 ` Rob Herring (Arm)
2025-03-01 10:42 ` [PATCH 2/8] dt-bindings: soc: rockchip: Add RK3528 VPU " Yao Zi
2025-03-01 10:42 ` Yao Zi
2025-03-03 15:08 ` Rob Herring (Arm)
2025-03-03 15:08 ` Rob Herring (Arm)
2025-03-01 10:42 ` [PATCH 3/8] dt-bindings: mmc: rockchip-dw-mshc: Add compatible string for RK3528 Yao Zi
2025-03-01 10:42 ` Yao Zi
2025-03-03 15:08 ` Rob Herring (Arm)
2025-03-03 15:08 ` Rob Herring (Arm)
2025-03-01 10:42 ` [PATCH 4/8] dt-bindings: clock: Add GRF clock definition " Yao Zi
2025-03-01 10:42 ` Yao Zi
2025-03-01 10:46 ` [PATCH 5/8] clk: rockchip: Support MMC clocks in GRF region Yao Zi
2025-03-01 10:46 ` Yao Zi
2025-03-01 10:47 ` [PATCH 6/8] clk: rockchip: rk3528: Add SD/SDIO tuning " Yao Zi
2025-03-01 10:47 ` Yao Zi
2025-03-05 10:00 ` Chukun Pan
2025-03-05 10:00 ` Chukun Pan
2025-03-05 10:21 ` Heiko Stübner [this message]
2025-03-05 10:21 ` Heiko Stübner
2025-03-05 10:49 ` Yao Zi
2025-03-05 10:49 ` Yao Zi
2025-03-01 10:47 ` [PATCH 7/8] arm64: dts: rockchip: Add SDMMC/SDIO controllers for RK3528 Yao Zi
2025-03-01 10:47 ` Yao Zi
2025-03-01 12:47 ` Jonas Karlman
2025-03-01 12:47 ` Jonas Karlman
2025-03-01 12:55 ` Heiko Stübner
2025-03-01 12:55 ` Heiko Stübner
2025-03-02 11:01 ` Jonas Karlman
2025-03-02 11:01 ` Jonas Karlman
2025-03-01 13:33 ` Yao Zi
2025-03-01 13:33 ` Yao Zi
2025-03-02 11:33 ` Jonas Karlman
2025-03-02 11:33 ` Jonas Karlman
2025-03-01 10:48 ` [PATCH 8/8] arm64: dts: rockchip: Enable SD-card interface on Radxa E20C Yao Zi
2025-03-01 10:48 ` Yao Zi
2025-03-01 13:01 ` Jonas Karlman
2025-03-01 13:01 ` Jonas Karlman
2025-03-01 15:15 ` Yao Zi
2025-03-01 15:15 ` Yao Zi
2025-03-02 11:56 ` Jonas Karlman
2025-03-02 11:56 ` Jonas Karlman
2025-03-02 16:16 ` Yao Zi
2025-03-02 16:16 ` Yao Zi
2025-03-04 12:10 ` Chukun Pan
2025-03-04 12:10 ` Chukun Pan
2025-03-04 19:49 ` Yao Zi
2025-03-04 19:49 ` Yao Zi
2025-03-04 19:55 ` Jonas Karlman
2025-03-04 19:55 ` Jonas Karlman
2025-03-04 20:02 ` Yao Zi
2025-03-04 20:02 ` Yao Zi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2583035.OBFZWjSADL@diego \
--to=heiko@sntech.de \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=frank.wang@rock-chips.com \
--cc=jonas@kwiboo.se \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=shresthprasad7@gmail.com \
--cc=ulf.hansson@linaro.org \
--cc=ziyao@disroot.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.