From: Stephen Boyd <sboyd@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>, Daniel Palmer <daniel@0x0f.com>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Romain Perier <romain.perier@gmail.com>,
linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH v2 2/9] clk: mstar: msc313 cpupll clk driver
Date: Fri, 07 Jan 2022 17:25:14 -0800 [thread overview]
Message-ID: <20220108012515.D1213C36AEB@smtp.kernel.org> (raw)
In-Reply-To: <20220102165730.50190-3-romain.perier@gmail.com>
Quoting Romain Perier (2022-01-02 08:57:23)
> diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
> index de37e1bce2d2..a44ca2b180ff 100644
> --- a/drivers/clk/mstar/Kconfig
> +++ b/drivers/clk/mstar/Kconfig
> @@ -7,3 +7,10 @@ config MSTAR_MSC313_MPLL
> help
> Support for the MPLL PLL and dividers block present on
> MStar/Sigmastar SoCs.
> +
> +config MSTAR_MSC313_CPUPLL
Can this file be sorted on Kconfig name?
> + bool "MStar CPUPLL driver"
> + depends on ARCH_MSTARV7 || COMPILE_TEST
> + default ARCH_MSTARV7
> + help
> + Support for the CPU PLL present on MStar/Sigmastar SoCs.
> diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
> index f8dcd25ede1d..9f05b73a0619 100644
> --- a/drivers/clk/mstar/Makefile
> +++ b/drivers/clk/mstar/Makefile
> @@ -4,3 +4,4 @@
> #
>
> obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
> +obj-$(CONFIG_MSTAR_MSC313_CPUPLL) += clk-msc313-cpupll.o
> diff --git a/drivers/clk/mstar/clk-msc313-cpupll.c b/drivers/clk/mstar/clk-msc313-cpupll.c
> new file mode 100644
> index 000000000000..2229b16475eb
> --- /dev/null
> +++ b/drivers/clk/mstar/clk-msc313-cpupll.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Daniel Palmer <daniel@thingy.jp>
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
Is this include used? Please drop unused includes.
> +#include <linux/of_address.h>
> +#include <linux/module.h>
It isn't a module though.
> +#include <linux/kernel.h>
Preferably sort includes alphabetically too.
> +
> +/*
> + * This IP is not documented outside of the messy vendor driver.
> + * Below is what we think the registers look like based on looking at
> + * the vendor code and poking at the hardware:
> + *
> + * 0x140 -- LPF low. Seems to store one half of the clock transition
> + * 0x144 /
> + * 0x148 -- LPF high. Seems to store one half of the clock transition
> + * 0x14c /
> + * 0x150 -- vendor code says "toggle lpf enable"
> + * 0x154 -- mu?
> + * 0x15c -- lpf_update_count?
> + * 0x160 -- vendor code says "switch to LPF". Clock source config? Register bank?
> + * 0x164 -- vendor code says "from low to high" which seems to mean transition from LPF low to
> + * LPF high.
> + * 0x174 -- Seems to be the PLL lock status bit
> + * 0x180 -- Seems to be the current frequency, this might need to be populated by software?
> + * 0x184 / The vendor driver uses these to set the initial value of LPF low
> + *
> + * Frequency seems to be calculated like this:
> + * (parent clock (432mhz) / register_magic_value) * 16 * 524288
> + * Only the lower 24 bits of the resulting value will be used. In addition, the
> + * PLL doesn't seem to be able to lock on frequencies lower than 220 MHz, as
> + * divisor 0xfb586f (220 MHz) works but 0xfb7fff locks up.
> + *
> + * Vendor values:
> + * frequency - register value
> + *
> + * 400000000 - 0x0067AE14
> + * 600000000 - 0x00451EB8,
> + * 800000000 - 0x0033D70A,
> + * 1000000000 - 0x002978d4,
> + */
> +
> +#define REG_LPF_LOW_L 0x140
> +#define REG_LPF_LOW_H 0x144
> +#define REG_LPF_HIGH_BOTTOM 0x148
> +#define REG_LPF_HIGH_TOP 0x14c
> +#define REG_LPF_TOGGLE 0x150
> +#define REG_LPF_MYSTERYTWO 0x154
> +#define REG_LPF_UPDATE_COUNT 0x15c
> +#define REG_LPF_MYSTERYONE 0x160
> +#define REG_LPF_TRANSITIONCTRL 0x164
> +#define REG_LPF_LOCK 0x174
> +#define REG_CURRENT 0x180
> +
> +#define MULTIPLIER_1 16
> +#define MULTIPLIER_2 524288
> +#define MULTIPLIER (MULTIPLIER_1 * MULTIPLIER_2)
> +
> +struct msc313_cpupll {
> + void __iomem *base;
> + struct clk_hw clk_hw;
> +};
> +
> +#define to_cpupll(_hw) container_of(_hw, struct msc313_cpupll, clk_hw)
> +
> +static u32 msc313_cpupll_reg_read32(struct msc313_cpupll *cpupll, unsigned int reg)
> +{
> + u32 value;
> +
> + value = ioread16(cpupll->base + reg + 4) << 16;
> + value |= ioread16(cpupll->base + reg);
> +
> + return value;
> +}
> +
> +static void msc313_cpupll_reg_write32(struct msc313_cpupll *cpupll, unsigned int reg, u32 value)
> +{
> + u16 l = value & 0xffff, h = (value >> 16) & 0xffff;
> +
> + iowrite16(l, cpupll->base + reg);
We don't usually see 16-bit accesses but if that's what the hardware
wants then OK.
> + iowrite16(h, cpupll->base + reg + 4);
> +}
> +
> +static void msc313_cpupll_setfreq(struct msc313_cpupll *cpupll, u32 regvalue)
> +{
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_HIGH_BOTTOM, regvalue);
> +
> + iowrite16(0x1, cpupll->base + REG_LPF_MYSTERYONE);
> + iowrite16(0x6, cpupll->base + REG_LPF_MYSTERYTWO);
> + iowrite16(0x8, cpupll->base + REG_LPF_UPDATE_COUNT);
> + iowrite16(BIT(12), cpupll->base + REG_LPF_TRANSITIONCTRL);
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> + iowrite16(1, cpupll->base + REG_LPF_TOGGLE);
> +
> + while (!(ioread16(cpupll->base + REG_LPF_LOCK)))
> + cpu_relax();
Any timeout? Can this use the io read timeout APIs?
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> +
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L, regvalue);
> +}
> +
> +static unsigned long msc313_cpupll_frequencyforreg(u32 reg, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> +
> + if (prescaled == 0 || reg == 0)
> + return 0;
> + scaled = DIV_ROUND_DOWN_ULL(prescaled, reg);
> +
> + return scaled;
Just
return DIV_ROUND_DOWN_ULL(...);
> +}
> +
> +static u32 msc313_cpupll_regforfrequecy(unsigned long rate, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> + u32 reg;
> +
> + if (prescaled == 0 || rate == 0)
> + return 0;
> +
> + scaled = DIV_ROUND_UP_ULL(prescaled, rate);
> + reg = scaled;
> +
> + return reg;
Just
return DIV_ROUND_UP_ULL(...);
> +}
> +
> +static unsigned long msc313_cpupll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> +
> + return msc313_cpupll_frequencyforreg(msc313_cpupll_reg_read32(cpupll, REG_LPF_LOW_L),
> + parent_rate);
> +}
> +
> +static long msc313_cpupll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + u32 reg = msc313_cpupll_regforfrequecy(rate, *parent_rate);
> + long rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + /*
> + * This is my poor attempt at making sure the resulting
> + * rate doesn't overshoot the requested rate.
If you want better bounds you can use determine_rate and then look at
the min/max constraints to make sure you don't overshoot. But otherwise
round_rate implementation is up to the provider to figure out what
should happen, i.e. overshooting could be OK if the provider intends for
it.
> + */
> + for (; rounded >= rate && reg > 0; reg--)
> + rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + return rounded;
> +}
> +
> +static int msc313_cpupll_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> + u32 reg = msc313_cpupll_regforfrequecy(rate, parent_rate);
> +
> + msc313_cpupll_setfreq(cpupll, reg);
> +
> + return 0;
> +}
> +
> +static const struct clk_ops msc313_cpupll_ops = {
> + .recalc_rate = msc313_cpupll_recalc_rate,
> + .round_rate = msc313_cpupll_round_rate,
> + .set_rate = msc313_cpupll_set_rate,
> +};
> +
> +static const struct of_device_id msc313_cpupll_of_match[] = {
> + {
> + .compatible = "mstar,msc313-cpupll",
> + },
> + {}
This can and should be less lines
{ .compatible = "mstar,msc313-cpupll", },
{}
> +};
> +
> +static const struct clk_parent_data cpupll_parent = {
> + .index = 0,
> +};
> +
> +static int msc313_cpupll_probe(struct platform_device *pdev)
> +{
> + struct clk_init_data clk_init = {};
> + struct device *dev = &pdev->dev;
> + struct msc313_cpupll *cpupll;
> + int ret;
> +
> + cpupll = devm_kzalloc(&pdev->dev, sizeof(*cpupll), GFP_KERNEL);
> + if (!cpupll)
> + return -ENOMEM;
> +
> + cpupll->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(cpupll->base))
> + return PTR_ERR(cpupll->base);
> +
> + /* LPF might not contain the current frequency so fix that up */
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L,
> + msc313_cpupll_reg_read32(cpupll, REG_CURRENT));
> +
> + clk_init.name = dev_name(dev);
> + clk_init.ops = &msc313_cpupll_ops;
> + clk_init.flags = CLK_IS_CRITICAL;
Why is it critical? Can we have a comment? The clk ops don't have enable
or disable so it seems like the flag won't do anything.
> + clk_init.parent_data = &cpupll_parent;
> + clk_init.num_parents = 1;
> + cpupll->clk_hw.init = &clk_init;
> +
> + ret = devm_clk_hw_register(dev, &cpupll->clk_hw);
> + if (ret)
> + return ret;
> +
> + return of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_simple_get, &cpupll->clk_hw);
> +}
> +
> +static struct platform_driver msc313_cpupll_driver = {
> + .driver = {
> + .name = "mstar-msc313-cpupll",
> + .of_match_table = msc313_cpupll_of_match,
> + },
> + .probe = msc313_cpupll_probe,
> +};
> +builtin_platform_driver(msc313_cpupll_driver);
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>, Daniel Palmer <daniel@0x0f.com>,
Michael Turquette <mturquette@baylibre.com>,
Rob Herring <robh+dt@kernel.org>,
Romain Perier <romain.perier@gmail.com>,
linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Willy Tarreau <w@1wt.eu>
Subject: Re: [PATCH v2 2/9] clk: mstar: msc313 cpupll clk driver
Date: Fri, 07 Jan 2022 17:25:14 -0800 [thread overview]
Message-ID: <20220108012515.D1213C36AEB@smtp.kernel.org> (raw)
In-Reply-To: <20220102165730.50190-3-romain.perier@gmail.com>
Quoting Romain Perier (2022-01-02 08:57:23)
> diff --git a/drivers/clk/mstar/Kconfig b/drivers/clk/mstar/Kconfig
> index de37e1bce2d2..a44ca2b180ff 100644
> --- a/drivers/clk/mstar/Kconfig
> +++ b/drivers/clk/mstar/Kconfig
> @@ -7,3 +7,10 @@ config MSTAR_MSC313_MPLL
> help
> Support for the MPLL PLL and dividers block present on
> MStar/Sigmastar SoCs.
> +
> +config MSTAR_MSC313_CPUPLL
Can this file be sorted on Kconfig name?
> + bool "MStar CPUPLL driver"
> + depends on ARCH_MSTARV7 || COMPILE_TEST
> + default ARCH_MSTARV7
> + help
> + Support for the CPU PLL present on MStar/Sigmastar SoCs.
> diff --git a/drivers/clk/mstar/Makefile b/drivers/clk/mstar/Makefile
> index f8dcd25ede1d..9f05b73a0619 100644
> --- a/drivers/clk/mstar/Makefile
> +++ b/drivers/clk/mstar/Makefile
> @@ -4,3 +4,4 @@
> #
>
> obj-$(CONFIG_MSTAR_MSC313_MPLL) += clk-msc313-mpll.o
> +obj-$(CONFIG_MSTAR_MSC313_CPUPLL) += clk-msc313-cpupll.o
> diff --git a/drivers/clk/mstar/clk-msc313-cpupll.c b/drivers/clk/mstar/clk-msc313-cpupll.c
> new file mode 100644
> index 000000000000..2229b16475eb
> --- /dev/null
> +++ b/drivers/clk/mstar/clk-msc313-cpupll.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Daniel Palmer <daniel@thingy.jp>
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
Is this include used? Please drop unused includes.
> +#include <linux/of_address.h>
> +#include <linux/module.h>
It isn't a module though.
> +#include <linux/kernel.h>
Preferably sort includes alphabetically too.
> +
> +/*
> + * This IP is not documented outside of the messy vendor driver.
> + * Below is what we think the registers look like based on looking at
> + * the vendor code and poking at the hardware:
> + *
> + * 0x140 -- LPF low. Seems to store one half of the clock transition
> + * 0x144 /
> + * 0x148 -- LPF high. Seems to store one half of the clock transition
> + * 0x14c /
> + * 0x150 -- vendor code says "toggle lpf enable"
> + * 0x154 -- mu?
> + * 0x15c -- lpf_update_count?
> + * 0x160 -- vendor code says "switch to LPF". Clock source config? Register bank?
> + * 0x164 -- vendor code says "from low to high" which seems to mean transition from LPF low to
> + * LPF high.
> + * 0x174 -- Seems to be the PLL lock status bit
> + * 0x180 -- Seems to be the current frequency, this might need to be populated by software?
> + * 0x184 / The vendor driver uses these to set the initial value of LPF low
> + *
> + * Frequency seems to be calculated like this:
> + * (parent clock (432mhz) / register_magic_value) * 16 * 524288
> + * Only the lower 24 bits of the resulting value will be used. In addition, the
> + * PLL doesn't seem to be able to lock on frequencies lower than 220 MHz, as
> + * divisor 0xfb586f (220 MHz) works but 0xfb7fff locks up.
> + *
> + * Vendor values:
> + * frequency - register value
> + *
> + * 400000000 - 0x0067AE14
> + * 600000000 - 0x00451EB8,
> + * 800000000 - 0x0033D70A,
> + * 1000000000 - 0x002978d4,
> + */
> +
> +#define REG_LPF_LOW_L 0x140
> +#define REG_LPF_LOW_H 0x144
> +#define REG_LPF_HIGH_BOTTOM 0x148
> +#define REG_LPF_HIGH_TOP 0x14c
> +#define REG_LPF_TOGGLE 0x150
> +#define REG_LPF_MYSTERYTWO 0x154
> +#define REG_LPF_UPDATE_COUNT 0x15c
> +#define REG_LPF_MYSTERYONE 0x160
> +#define REG_LPF_TRANSITIONCTRL 0x164
> +#define REG_LPF_LOCK 0x174
> +#define REG_CURRENT 0x180
> +
> +#define MULTIPLIER_1 16
> +#define MULTIPLIER_2 524288
> +#define MULTIPLIER (MULTIPLIER_1 * MULTIPLIER_2)
> +
> +struct msc313_cpupll {
> + void __iomem *base;
> + struct clk_hw clk_hw;
> +};
> +
> +#define to_cpupll(_hw) container_of(_hw, struct msc313_cpupll, clk_hw)
> +
> +static u32 msc313_cpupll_reg_read32(struct msc313_cpupll *cpupll, unsigned int reg)
> +{
> + u32 value;
> +
> + value = ioread16(cpupll->base + reg + 4) << 16;
> + value |= ioread16(cpupll->base + reg);
> +
> + return value;
> +}
> +
> +static void msc313_cpupll_reg_write32(struct msc313_cpupll *cpupll, unsigned int reg, u32 value)
> +{
> + u16 l = value & 0xffff, h = (value >> 16) & 0xffff;
> +
> + iowrite16(l, cpupll->base + reg);
We don't usually see 16-bit accesses but if that's what the hardware
wants then OK.
> + iowrite16(h, cpupll->base + reg + 4);
> +}
> +
> +static void msc313_cpupll_setfreq(struct msc313_cpupll *cpupll, u32 regvalue)
> +{
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_HIGH_BOTTOM, regvalue);
> +
> + iowrite16(0x1, cpupll->base + REG_LPF_MYSTERYONE);
> + iowrite16(0x6, cpupll->base + REG_LPF_MYSTERYTWO);
> + iowrite16(0x8, cpupll->base + REG_LPF_UPDATE_COUNT);
> + iowrite16(BIT(12), cpupll->base + REG_LPF_TRANSITIONCTRL);
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> + iowrite16(1, cpupll->base + REG_LPF_TOGGLE);
> +
> + while (!(ioread16(cpupll->base + REG_LPF_LOCK)))
> + cpu_relax();
Any timeout? Can this use the io read timeout APIs?
> +
> + iowrite16(0, cpupll->base + REG_LPF_TOGGLE);
> +
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L, regvalue);
> +}
> +
> +static unsigned long msc313_cpupll_frequencyforreg(u32 reg, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> +
> + if (prescaled == 0 || reg == 0)
> + return 0;
> + scaled = DIV_ROUND_DOWN_ULL(prescaled, reg);
> +
> + return scaled;
Just
return DIV_ROUND_DOWN_ULL(...);
> +}
> +
> +static u32 msc313_cpupll_regforfrequecy(unsigned long rate, unsigned long parent_rate)
> +{
> + unsigned long long prescaled = ((unsigned long long)parent_rate) * MULTIPLIER;
> + unsigned long long scaled;
> + u32 reg;
> +
> + if (prescaled == 0 || rate == 0)
> + return 0;
> +
> + scaled = DIV_ROUND_UP_ULL(prescaled, rate);
> + reg = scaled;
> +
> + return reg;
Just
return DIV_ROUND_UP_ULL(...);
> +}
> +
> +static unsigned long msc313_cpupll_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> +
> + return msc313_cpupll_frequencyforreg(msc313_cpupll_reg_read32(cpupll, REG_LPF_LOW_L),
> + parent_rate);
> +}
> +
> +static long msc313_cpupll_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + u32 reg = msc313_cpupll_regforfrequecy(rate, *parent_rate);
> + long rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + /*
> + * This is my poor attempt at making sure the resulting
> + * rate doesn't overshoot the requested rate.
If you want better bounds you can use determine_rate and then look at
the min/max constraints to make sure you don't overshoot. But otherwise
round_rate implementation is up to the provider to figure out what
should happen, i.e. overshooting could be OK if the provider intends for
it.
> + */
> + for (; rounded >= rate && reg > 0; reg--)
> + rounded = msc313_cpupll_frequencyforreg(reg, *parent_rate);
> +
> + return rounded;
> +}
> +
> +static int msc313_cpupll_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
> +{
> + struct msc313_cpupll *cpupll = to_cpupll(hw);
> + u32 reg = msc313_cpupll_regforfrequecy(rate, parent_rate);
> +
> + msc313_cpupll_setfreq(cpupll, reg);
> +
> + return 0;
> +}
> +
> +static const struct clk_ops msc313_cpupll_ops = {
> + .recalc_rate = msc313_cpupll_recalc_rate,
> + .round_rate = msc313_cpupll_round_rate,
> + .set_rate = msc313_cpupll_set_rate,
> +};
> +
> +static const struct of_device_id msc313_cpupll_of_match[] = {
> + {
> + .compatible = "mstar,msc313-cpupll",
> + },
> + {}
This can and should be less lines
{ .compatible = "mstar,msc313-cpupll", },
{}
> +};
> +
> +static const struct clk_parent_data cpupll_parent = {
> + .index = 0,
> +};
> +
> +static int msc313_cpupll_probe(struct platform_device *pdev)
> +{
> + struct clk_init_data clk_init = {};
> + struct device *dev = &pdev->dev;
> + struct msc313_cpupll *cpupll;
> + int ret;
> +
> + cpupll = devm_kzalloc(&pdev->dev, sizeof(*cpupll), GFP_KERNEL);
> + if (!cpupll)
> + return -ENOMEM;
> +
> + cpupll->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(cpupll->base))
> + return PTR_ERR(cpupll->base);
> +
> + /* LPF might not contain the current frequency so fix that up */
> + msc313_cpupll_reg_write32(cpupll, REG_LPF_LOW_L,
> + msc313_cpupll_reg_read32(cpupll, REG_CURRENT));
> +
> + clk_init.name = dev_name(dev);
> + clk_init.ops = &msc313_cpupll_ops;
> + clk_init.flags = CLK_IS_CRITICAL;
Why is it critical? Can we have a comment? The clk ops don't have enable
or disable so it seems like the flag won't do anything.
> + clk_init.parent_data = &cpupll_parent;
> + clk_init.num_parents = 1;
> + cpupll->clk_hw.init = &clk_init;
> +
> + ret = devm_clk_hw_register(dev, &cpupll->clk_hw);
> + if (ret)
> + return ret;
> +
> + return of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_simple_get, &cpupll->clk_hw);
> +}
> +
> +static struct platform_driver msc313_cpupll_driver = {
> + .driver = {
> + .name = "mstar-msc313-cpupll",
> + .of_match_table = msc313_cpupll_of_match,
> + },
> + .probe = msc313_cpupll_probe,
> +};
> +builtin_platform_driver(msc313_cpupll_driver);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-08 1:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-02 16:57 [PATCH v2 0/9] ARM: mstar: cpupll Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 1/9] dt-bindings: clk: mstar msc313 cpupll binding description Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-10 22:11 ` Rob Herring
2022-01-10 22:11 ` Rob Herring
2022-01-02 16:57 ` [PATCH v2 2/9] clk: mstar: msc313 cpupll clk driver Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-08 1:25 ` Stephen Boyd [this message]
2022-01-08 1:25 ` Stephen Boyd
2022-01-08 11:49 ` Daniel Palmer
2022-01-08 11:49 ` Daniel Palmer
2022-01-02 16:57 ` [PATCH v2 3/9] ARM: mstar: Add cpupll to base dtsi Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 4/9] ARM: mstar: Link cpupll to cpu Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 5/9] ARM: mstar: Link cpupll to second core Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 6/9] ARM: mstar: Add OPP table for infinity Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 7/9] ARM: mstar: Add OPP table for infinity3 Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 8/9] ARM: mstar: Add OPP table for mercury5 Romain Perier
2022-01-02 16:57 ` Romain Perier
2022-01-02 16:57 ` [PATCH v2 9/9] ARM: mstar: Extend opp_table for infinity2m Romain Perier
2022-01-02 16:57 ` Romain Perier
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=20220108012515.D1213C36AEB@smtp.kernel.org \
--to=sboyd@kernel.org \
--cc=arnd@arndb.de \
--cc=daniel@0x0f.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=robh+dt@kernel.org \
--cc=romain.perier@gmail.com \
--cc=w@1wt.eu \
/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.