From: Xingyu Wu <xingyu.wu@starfivetech.com> To: Stephen Boyd <sboyd@kernel.org>, Emil Renner Berthing <kernel@esmil.dk>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Philipp Zabel <p.zabel@pengutronix.de>, <devicetree@vger.kernel.org>, <linux-riscv@lists.infradead.org> Cc: Rob Herring <robh+dt@kernel.org>, Conor Dooley <conor@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Hal Feng <hal.feng@starfivetech.com>, <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org> Subject: Re: [PATCH v1 03/11] clk: starfive: Add StarFive JH7110 System-Top-Group clock driver Date: Mon, 30 Jan 2023 16:02:28 +0800 [thread overview] Message-ID: <0e77bf23-b359-9884-6a8c-368e31d718a4@starfivetech.com> (raw) In-Reply-To: <5bb5263d26b157548d7ba39f80989c69.sboyd@kernel.org> On 2023/1/26 10:33, Stephen Boyd wrote: > Quoting Xingyu Wu (2023-01-19 18:44:37) >> diff --git a/drivers/clk/starfive/clk-starfive-jh7110-stg.c b/drivers/clk/starfive/clk-starfive-jh7110-stg.c >> new file mode 100644 >> index 000000000000..c2740f44e796 >> --- /dev/null >> +++ b/drivers/clk/starfive/clk-starfive-jh7110-stg.c >> @@ -0,0 +1,180 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * StarFive JH7110 System-Top-Group Clock Driver >> + * >> + * Copyright (C) 2022 StarFive Technology Co., Ltd. >> + */ >> + >> +#include <linux/clk.h> > > Is this include used? If not, please remove. Will drop in next patch. > >> +#include <linux/clk-provider.h> >> +#include <linux/io.h> >> +#include <linux/of.h> >> +#include <linux/platform_device.h> >> + >> +#include <dt-bindings/clock/starfive,jh7110-crg.h> >> + >> +#include "clk-starfive-jh71x0.h" >> + > [...] >> +static int jh7110_stgcrg_probe(struct platform_device *pdev) >> +{ >> + struct jh71x0_clk_priv *priv; >> + unsigned int idx; >> + int ret; >> + >> + priv = devm_kzalloc(&pdev->dev, >> + struct_size(priv, reg, JH7110_STGCLK_END), >> + GFP_KERNEL); >> + if (!priv) >> + return -ENOMEM; >> + >> + spin_lock_init(&priv->rmw_lock); >> + priv->dev = &pdev->dev; >> + priv->base = devm_platform_ioremap_resource(pdev, 0); >> + if (IS_ERR(priv->base)) >> + return PTR_ERR(priv->base); >> + >> + dev_set_drvdata(priv->dev, priv->base); >> + >> + for (idx = 0; idx < JH7110_STGCLK_END; idx++) { >> + u32 max = jh7110_stgclk_data[idx].max; >> + struct clk_parent_data parents[4] = {}; >> + struct clk_init_data init = { >> + .name = jh7110_stgclk_data[idx].name, >> + .ops = starfive_jh71x0_clk_ops(max), >> + .parent_data = parents, >> + .num_parents = >> + ((max & JH71X0_CLK_MUX_MASK) >> JH71X0_CLK_MUX_SHIFT) + 1, >> + .flags = jh7110_stgclk_data[idx].flags, >> + }; >> + struct jh71x0_clk *clk = &priv->reg[idx]; >> + unsigned int i; >> + >> + for (i = 0; i < init.num_parents; i++) { >> + unsigned int pidx = jh7110_stgclk_data[idx].parents[i]; >> + >> + if (pidx < JH7110_STGCLK_END) >> + parents[i].hw = &priv->reg[pidx].hw; >> + else if (pidx == JH7110_STGCLK_OSC) >> + parents[i].fw_name = "osc"; >> + else if (pidx == JH7110_STGCLK_HIFI4_CORE) >> + parents[i].fw_name = "hifi4_core"; >> + else if (pidx == JH7110_STGCLK_STG_AXIAHB) >> + parents[i].fw_name = "stg_axiahb"; >> + else if (pidx == JH7110_STGCLK_USB_125M) >> + parents[i].fw_name = "usb_125m"; >> + else if (pidx == JH7110_STGCLK_CPU_BUS) >> + parents[i].fw_name = "cpu_bus"; >> + else if (pidx == JH7110_STGCLK_HIFI4_AXI) >> + parents[i].fw_name = "hifi4_axi"; >> + else if (pidx == JH7110_STGCLK_NOCSTG_BUS) >> + parents[i].fw_name = "nocstg_bus"; >> + else if (pidx == JH7110_STGCLK_APB_BUS) >> + parents[i].fw_name = "apb_bus"; > > Can this be an array lookup instead of a pile of conditions? > > if (pidx < JH7110_STGCLK_END) > ... > else > parents[i].fw_name = fw_table[pidx - JH7110_STGCLK_END]; > > Or even better, don't use strings at all and just make the 'pidx' number > (possibly minus the end constant) be the 'clocks' property index that > you want. It seen to be a good way that there uses an array. Based on the another way, can I use the 'pidx' number to get the 'clock-names' property to be the parent clock name? > >> + } >> + >> + clk->hw.init = &init; >> + clk->idx = idx; >> + clk->max_div = max & JH71X0_CLK_DIV_MASK; >> + >> + ret = devm_clk_hw_register(&pdev->dev, &clk->hw); >> + if (ret) >> + return ret; >> + } >> + >> + ret = devm_of_clk_add_hw_provider(&pdev->dev, jh7110_stgclk_get, priv); >> + if (ret) >> + return ret; >> + >> + return jh7110_reset_controller_register(priv, "reset-stg", 2); > > Is this also devm-ified? No, it need to be freed actively. I will advise Hal Feng this. Best regards, Xingyu Wu
WARNING: multiple messages have this Message-ID (diff)
From: Xingyu Wu <xingyu.wu@starfivetech.com> To: Stephen Boyd <sboyd@kernel.org>, Emil Renner Berthing <kernel@esmil.dk>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Michael Turquette <mturquette@baylibre.com>, Philipp Zabel <p.zabel@pengutronix.de>, <devicetree@vger.kernel.org>, <linux-riscv@lists.infradead.org> Cc: Rob Herring <robh+dt@kernel.org>, Conor Dooley <conor@kernel.org>, "Paul Walmsley" <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Hal Feng <hal.feng@starfivetech.com>, <linux-kernel@vger.kernel.org>, <linux-clk@vger.kernel.org> Subject: Re: [PATCH v1 03/11] clk: starfive: Add StarFive JH7110 System-Top-Group clock driver Date: Mon, 30 Jan 2023 16:02:28 +0800 [thread overview] Message-ID: <0e77bf23-b359-9884-6a8c-368e31d718a4@starfivetech.com> (raw) In-Reply-To: <5bb5263d26b157548d7ba39f80989c69.sboyd@kernel.org> On 2023/1/26 10:33, Stephen Boyd wrote: > Quoting Xingyu Wu (2023-01-19 18:44:37) >> diff --git a/drivers/clk/starfive/clk-starfive-jh7110-stg.c b/drivers/clk/starfive/clk-starfive-jh7110-stg.c >> new file mode 100644 >> index 000000000000..c2740f44e796 >> --- /dev/null >> +++ b/drivers/clk/starfive/clk-starfive-jh7110-stg.c >> @@ -0,0 +1,180 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * StarFive JH7110 System-Top-Group Clock Driver >> + * >> + * Copyright (C) 2022 StarFive Technology Co., Ltd. >> + */ >> + >> +#include <linux/clk.h> > > Is this include used? If not, please remove. Will drop in next patch. > >> +#include <linux/clk-provider.h> >> +#include <linux/io.h> >> +#include <linux/of.h> >> +#include <linux/platform_device.h> >> + >> +#include <dt-bindings/clock/starfive,jh7110-crg.h> >> + >> +#include "clk-starfive-jh71x0.h" >> + > [...] >> +static int jh7110_stgcrg_probe(struct platform_device *pdev) >> +{ >> + struct jh71x0_clk_priv *priv; >> + unsigned int idx; >> + int ret; >> + >> + priv = devm_kzalloc(&pdev->dev, >> + struct_size(priv, reg, JH7110_STGCLK_END), >> + GFP_KERNEL); >> + if (!priv) >> + return -ENOMEM; >> + >> + spin_lock_init(&priv->rmw_lock); >> + priv->dev = &pdev->dev; >> + priv->base = devm_platform_ioremap_resource(pdev, 0); >> + if (IS_ERR(priv->base)) >> + return PTR_ERR(priv->base); >> + >> + dev_set_drvdata(priv->dev, priv->base); >> + >> + for (idx = 0; idx < JH7110_STGCLK_END; idx++) { >> + u32 max = jh7110_stgclk_data[idx].max; >> + struct clk_parent_data parents[4] = {}; >> + struct clk_init_data init = { >> + .name = jh7110_stgclk_data[idx].name, >> + .ops = starfive_jh71x0_clk_ops(max), >> + .parent_data = parents, >> + .num_parents = >> + ((max & JH71X0_CLK_MUX_MASK) >> JH71X0_CLK_MUX_SHIFT) + 1, >> + .flags = jh7110_stgclk_data[idx].flags, >> + }; >> + struct jh71x0_clk *clk = &priv->reg[idx]; >> + unsigned int i; >> + >> + for (i = 0; i < init.num_parents; i++) { >> + unsigned int pidx = jh7110_stgclk_data[idx].parents[i]; >> + >> + if (pidx < JH7110_STGCLK_END) >> + parents[i].hw = &priv->reg[pidx].hw; >> + else if (pidx == JH7110_STGCLK_OSC) >> + parents[i].fw_name = "osc"; >> + else if (pidx == JH7110_STGCLK_HIFI4_CORE) >> + parents[i].fw_name = "hifi4_core"; >> + else if (pidx == JH7110_STGCLK_STG_AXIAHB) >> + parents[i].fw_name = "stg_axiahb"; >> + else if (pidx == JH7110_STGCLK_USB_125M) >> + parents[i].fw_name = "usb_125m"; >> + else if (pidx == JH7110_STGCLK_CPU_BUS) >> + parents[i].fw_name = "cpu_bus"; >> + else if (pidx == JH7110_STGCLK_HIFI4_AXI) >> + parents[i].fw_name = "hifi4_axi"; >> + else if (pidx == JH7110_STGCLK_NOCSTG_BUS) >> + parents[i].fw_name = "nocstg_bus"; >> + else if (pidx == JH7110_STGCLK_APB_BUS) >> + parents[i].fw_name = "apb_bus"; > > Can this be an array lookup instead of a pile of conditions? > > if (pidx < JH7110_STGCLK_END) > ... > else > parents[i].fw_name = fw_table[pidx - JH7110_STGCLK_END]; > > Or even better, don't use strings at all and just make the 'pidx' number > (possibly minus the end constant) be the 'clocks' property index that > you want. It seen to be a good way that there uses an array. Based on the another way, can I use the 'pidx' number to get the 'clock-names' property to be the parent clock name? > >> + } >> + >> + clk->hw.init = &init; >> + clk->idx = idx; >> + clk->max_div = max & JH71X0_CLK_DIV_MASK; >> + >> + ret = devm_clk_hw_register(&pdev->dev, &clk->hw); >> + if (ret) >> + return ret; >> + } >> + >> + ret = devm_of_clk_add_hw_provider(&pdev->dev, jh7110_stgclk_get, priv); >> + if (ret) >> + return ret; >> + >> + return jh7110_reset_controller_register(priv, "reset-stg", 2); > > Is this also devm-ified? No, it need to be freed actively. I will advise Hal Feng this. Best regards, Xingyu Wu _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-01-30 8:06 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-20 2:44 [PATCH v1 00/11] Add new partial clock and reset drivers for StarFive JH7110 Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 01/11] dt-bindings: clock: Add StarFive JH7110 System-Top-Group clock and reset generator Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 8:11 ` Krzysztof Kozlowski 2023-01-20 8:11 ` Krzysztof Kozlowski 2023-01-30 6:17 ` Xingyu Wu 2023-01-30 6:17 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 02/11] reset: starfive: jh7110: Add StarFive System-Top-Group reset support Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 03/11] clk: starfive: Add StarFive JH7110 System-Top-Group clock driver Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-26 2:33 ` Stephen Boyd 2023-01-26 2:33 ` Stephen Boyd 2023-01-30 8:02 ` Xingyu Wu [this message] 2023-01-30 8:02 ` Xingyu Wu 2023-01-31 0:35 ` Stephen Boyd 2023-01-31 0:35 ` Stephen Boyd 2023-01-31 6:51 ` Xingyu Wu 2023-01-31 6:51 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 04/11] dt-bindings: clock: Add StarFive JH7110 Image-Signal-Process clock and reset generator Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 8:12 ` Krzysztof Kozlowski 2023-01-20 8:12 ` Krzysztof Kozlowski 2023-01-30 8:03 ` Xingyu Wu 2023-01-30 8:03 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 05/11] reset: starfive: jh7110: Add StarFive Image-Signal-Process reset support Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 06/11] clk: starfive: Add StarFive JH7110 Image-Signal-Process clock driver Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-26 2:35 ` Stephen Boyd 2023-01-26 2:35 ` Stephen Boyd 2023-01-30 8:09 ` Xingyu Wu 2023-01-30 8:09 ` Xingyu Wu 2023-01-31 0:38 ` Stephen Boyd 2023-01-31 0:38 ` Stephen Boyd 2023-01-31 6:52 ` Xingyu Wu 2023-01-31 6:52 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 07/11] dt-bindings: clock: Add StarFive JH7110 Video-Output clock and reset generator Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 8:13 ` Krzysztof Kozlowski 2023-01-20 8:13 ` Krzysztof Kozlowski 2023-01-30 8:10 ` Xingyu Wu 2023-01-30 8:10 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 08/11] reset: starfive: jh7110: Add StarFive Video-Output reset support Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 09/11] clk: starfive: Add StarFive JH7110 Video-Output clock driver Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 10/11] riscv: dts: starfive: jh7110: Add DVP and HDMI TX pixel external clocks Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu 2023-01-20 2:44 ` [PATCH v1 11/11] riscv: dts: starfive: jh7110: Add STGCRG/ISPCRG/VOUTCRG nodes Xingyu Wu 2023-01-20 2:44 ` Xingyu Wu
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=0e77bf23-b359-9884-6a8c-368e31d718a4@starfivetech.com \ --to=xingyu.wu@starfivetech.com \ --cc=aou@eecs.berkeley.edu \ --cc=conor@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=hal.feng@starfivetech.com \ --cc=kernel@esmil.dk \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=mturquette@baylibre.com \ --cc=p.zabel@pengutronix.de \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.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: linkBe 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.