* Re: [PATCH 0/3] RK356x/Quartz64 Model A SPI
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: Nicolas Frattaroli, Rob Herring, Heiko Stuebner
Cc: linux-kernel, devicetree, linux-rockchip, linux-arm-kernel
In-Reply-To: <20211126154344.724316-1-frattaroli.nicolas@gmail.com>
On Fri, 26 Nov 2021 16:43:41 +0100, Nicolas Frattaroli wrote:
> The first patch of this series adds a compatible for rk3568-spi
> to the DT bindings.
>
> The second adds the SPI nodes for RK3566 and RK3568 SoCs. The nodes
> were lifted from the downstream vendor kernel's devicetree, and were
> double-checked for correctness.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-linus
Thanks!
[1/3] dt-bindings: spi: spi-rockchip: Add rk3568-spi compatible
commit: bdac3bbd0dc63873a9c606b8e4f814e6d61d288d
[2/3] arm64: dts: rockchip: Add spi nodes on rk356x
(no commit info)
[3/3] arm64: dts: rockchip: Add spi1 pins on Quartz64 A
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: regulators: Add missing regulator names
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: Alexander Stein, Liam Girdwood, Rob Herring, Robin Gong; +Cc: devicetree
In-Reply-To: <20220119103747.58305-1-alexander.stein@ew.tq-group.com>
On Wed, 19 Jan 2022 11:37:47 +0100, Alexander Stein wrote:
> The valid regulator names for the subnodes does not match the ones
> mentioned in the description.
> PFUZE3000 & PFUZE3001 uses 'v33', 'vccsd' and 'vldo[1-4]' as well, so
> add them to the allowed node names.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] dt-bindings: regulators: Add missing regulator names
commit: 8e9977e48c7c2a49e09859456dcba12a8d804a51
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH net-next v1 4/9] dt-bindings: net: mtk-star-emac: add support for MT8365
From: Bartosz Golaszewski @ 2022-01-25 10:23 UTC (permalink / raw)
To: Biao Huang
Cc: David Miller, Rob Herring, Fabien Parent, Jakub Kicinski,
Felix Fietkau, John Crispin, Sean Wang, Mark Lee,
Matthias Brugger, netdev, devicetree, Linux Kernel Mailing List,
Linux ARM, moderated list:ARM/Mediatek SoC..., Yinghua Pan,
srv_heupstream, Macpaul Lin
In-Reply-To: <20220120070226.1492-5-biao.huang@mediatek.com>
On Thu, Jan 20, 2022 at 8:02 AM Biao Huang <biao.huang@mediatek.com> wrote:
>
> Add binding document for Ethernet on MT8365.
>
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> ---
> Documentation/devicetree/bindings/net/mediatek,star-emac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
> index e6a5ff208253..87a8b25b03a6 100644
> --- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
> +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml
> @@ -23,6 +23,7 @@ properties:
> - mediatek,mt8516-eth
> - mediatek,mt8518-eth
> - mediatek,mt8175-eth
> + - mediatek,mt8365-eth
>
> reg:
> maxItems: 1
> --
> 2.25.1
>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
^ permalink raw reply
* Re: [PATCH net-next v1 2/9] net: ethernet: mtk-star-emac: modify IRQ trigger flags
From: Bartosz Golaszewski @ 2022-01-25 10:22 UTC (permalink / raw)
To: Biao Huang
Cc: David Miller, Rob Herring, Fabien Parent, Jakub Kicinski,
Felix Fietkau, John Crispin, Sean Wang, Mark Lee,
Matthias Brugger, netdev, devicetree, Linux Kernel Mailing List,
Linux ARM, moderated list:ARM/Mediatek SoC..., Yinghua Pan,
srv_heupstream, Macpaul Lin
In-Reply-To: <20220120070226.1492-3-biao.huang@mediatek.com>
On Thu, Jan 20, 2022 at 8:02 AM Biao Huang <biao.huang@mediatek.com> wrote:
>
> If the flags in request_irq() is IRQF_TRIGGER_NONE, the trigger method
> is determined by "interrupt" property in dts.
> So, modify the flag from IRQF_TRIGGER_FALLING to IRQF_TRIGGER_NONE.
>
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> Signed-off-by: Yinghua Pan <ot_yinghua.pan@mediatek.com>
> ---
> drivers/net/ethernet/mediatek/mtk_star_emac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> index 26f5020f2e9c..7c2af775d601 100644
> --- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> @@ -959,7 +959,7 @@ static int mtk_star_enable(struct net_device *ndev)
>
> /* Request the interrupt */
> ret = request_irq(ndev->irq, mtk_star_handle_irq,
> - IRQF_TRIGGER_FALLING, ndev->name, ndev);
> + IRQF_TRIGGER_NONE, ndev->name, ndev);
> if (ret)
> goto err_free_skbs;
>
> --
> 2.25.1
>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
^ permalink raw reply
* Re: [PATCH v3 0/6] ASoC: Xilinx fixes
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: alsa-devel, Robert Hancock
Cc: tiwai, lgirdwood, kuninori.morimoto.gx, devicetree, perex,
robh+dt, michal.simek, maruthi.srinivas.bayyavarapu
In-Reply-To: <20220120195832.1742271-1-robert.hancock@calian.com>
On Thu, 20 Jan 2022 13:58:26 -0600, Robert Hancock wrote:
> There are drivers in mainline for the Xilinx Audio Formatter and Xilinx
> I2S IP cores. However, because of a few issues, these were only really
> usable with Xilinx's xlnx_pl_snd_card top-level driver, which is not in
> mainline (and not suitable for mainline).
>
> The fixes in this patchset, for the simple-card layer as well as the
> Xilinx drivers, now allow these drivers to be properly used with
> simple-card without any out-of-tree support code.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/6] ASoC: xilinx: xlnx_formatter_pcm: Handle sysclk setting
commit: 1c5091fbe7e0d0804158200b7feac5123f7b4fbd
[2/6] ASoC: xilinx: xlnx_i2s: create drvdata structure
commit: 5e46c63ca22278fe363dfd9f5360c2e2ad082087
[3/6] ASoC: xilinx: xlnx_i2s: Handle sysclk setting
commit: c47aef899c1bb0cbda48808356e7c040d95ca612
[4/6] ASoC: simple-card-utils: Set sysclk on all components
commit: ce2f7b8d4290c22e462e465d1da38a1c113ae66a
[5/6] ASoC: dt-bindings: simple-card: document new system-clock-fixed flag
commit: e9fed03aebacb8873dee8e2edfbce96f27f6c730
[6/6] ASoC: simple-card-utils: Add new system-clock-fixed flag
commit: 5ca2ab4598179a2690a38420f3fde9f2ad79d55c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 0/2] ASoC: add support for TAS5805M digital amplifier
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: alsa-devel, Daniel Beer, devicetree
Cc: Liam Girdwood, Rob Herring, Derek Simkowiak, Andy Liu,
linux-kernel
In-Reply-To: <cover.1642298336.git.daniel.beer@igorinstitute.com>
On Sun, 16 Jan 2022 14:58:56 +1300, Daniel Beer wrote:
> This pair of patches implements support for the TAS5805M class D audio
> amplifier. This driver, and the example configuration in the device-tree
> file, were originally based on a 4.19 series kernel and have been
> modified slightly from the tested version.
>
> This resubmission differs from v2 as follows:
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: add support for TAS5805M digital amplifier
commit: 2e5a74c68d601b11a496f91f76fa7bb236d10bd0
[2/2] ASoC: dt-bindings: add bindings for TI TAS5805M.
commit: b8aec7a4a01b75973c22f004377a48593a3fef03
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 0/5] fsl-asoc-card: Add optional dt property for setting mclk-id
From: Mark Brown @ 2022-01-25 10:20 UTC (permalink / raw)
To: Ariel D'Alessandro, alsa-devel, devicetree, linux-omap,
linux-kernel, linuxppc-dev
Cc: tiwai, michael, tony, lgirdwood, kuninori.morimoto.gx,
nicoleotsuka, bcousson, Xiubo.Lee, shengjiu.wang, festevam, perex,
robh+dt
In-Reply-To: <20220117132109.283365-1-ariel.dalessandro@collabora.com>
On Mon, 17 Jan 2022 10:21:04 -0300, Ariel D'Alessandro wrote:
> This is a follow up of patchset:
>
> [RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
>
> Sound cards may allow using different main clock inputs. In the generic
> fsl-asoc-card driver, these values are hardcoded for each specific card
> configuration.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/5] dt-bindings: sound: Rename tlv320aic31xx-micbias as tlv320aic31xx
commit: 85f856f790b5fd427cb31b3f62755713174da0aa
[2/5] dt-bindings: tlv320aic31xx: Define PLL clock inputs
commit: 6045ffd366283236f0de79c8a0e98ae766e9a8f9
[3/5] ASoC: bindings: fsl-asoc-card: Add mclk-id optional property
commit: 55915f20ad9ae92015bf7b2c4ac854e5b720d63f
[4/5] ASoC: fsl-asoc-card: Add optional dt property for setting mclk-id
commit: e6ec5a3936ee0c01f46e1d09dc758bb762e06dd9
[5/5] ASoC: fsl-asoc-card: Remove BCLK default value for tlv320aic31xx card
commit: d4c4e2861560ab1cbf540bbda5bcdf4c92b17110
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 3/3] nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios property
From: Miquel Raynal @ 2022-01-25 10:11 UTC (permalink / raw)
To: Christophe Kerello
Cc: richard, vigneshr, robh+dt, srinivas.kandagatla, linux-mtd,
linux-kernel, linux-stm32, devicetree, chenshumin86
In-Reply-To: <20220105135734.271313-4-christophe.kerello@foss.st.com>
Hi Christophe,
christophe.kerello@foss.st.com wrote on Wed, 5 Jan 2022 14:57:34 +0100:
Sorry for the time it took me to review this patchset.
> Wp-gpios property can be used on NVMEN nodes and the same property can
> be also used on MTD NAND nodes. In case of the wp-gpios property is
> defined at NAND level node, the GPIO management is done at NAND driver
> level. Write protect is disabled when the driver is probed or resumed
> and is enabled when the driver is released or suspended.
>
> When no partitions are defined in the NAND DT node, then the NAND DT node
> will be passed to NVMEM framework. If wp-gpios property is defined in
> this node, the GPIO resource is taken twice and the NAND controller
> driver fails to probe.
>
> It would be possible to set config->wp_gpio at MTD level before calling
> nvmem_register function but NVMEM framework will toggled this GPIO on
toggle
> each write when this GPIO should only be controlled at NAND level driver
> to ensure that the Write Protect has not been enabled.
>
> As MTD framework is only using NVMEN framework in read only, a way to fix
NVMEM
> this conflict is to get the GPIO resource at NVMEM level only if reg_write
> API is defined. This GPIO is only toggled if reg_write ops is defined.
The solution looks a bit hackish to me.
The nvmem_config structure already contains a field named wp_gpio which
seem to imply that callers can provide a wp_gpio handle there if they
want. But yet the nvmem core ignores if no gpio was provided and will
try to get one anyway. Shouldn't this behavior be changed?
There are already a big number of callers for nvmem_register() so I
understand it might be a bit tedious to just drop the else part of
that condition, but maybe we can provide a dummy cookie into the
wp_gpio field which would be interpreted as: "don't mess with it". Or
perhaps an additional flag somewhere else just to clearly skip the
wp_gpio thing entirely?
> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
> ---
> drivers/nvmem/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index e765d3d0542e..e11c74db64f9 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -769,7 +769,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>
> if (config->wp_gpio)
> nvmem->wp_gpio = config->wp_gpio;
> - else
> + else if (config->reg_write)
> nvmem->wp_gpio = gpiod_get_optional(config->dev, "wp",
> GPIOD_OUT_HIGH);
> if (IS_ERR(nvmem->wp_gpio)) {
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH net-next v1 1/9] net: ethernet: mtk-star-emac: store bit_clk_div in compat structure
From: Bartosz Golaszewski @ 2022-01-25 9:50 UTC (permalink / raw)
To: Biao Huang
Cc: David Miller, Rob Herring, Fabien Parent, Jakub Kicinski,
Felix Fietkau, John Crispin, Sean Wang, Mark Lee,
Matthias Brugger, netdev, devicetree, Linux Kernel Mailing List,
Linux ARM, moderated list:ARM/Mediatek SoC..., Yinghua Pan,
srv_heupstream, Macpaul Lin
In-Reply-To: <20220120070226.1492-2-biao.huang@mediatek.com>
On Thu, Jan 20, 2022 at 8:02 AM Biao Huang <biao.huang@mediatek.com> wrote:
>
> From: Fabien Parent <fparent@baylibre.com>
>
> Not all the SoC are using the same clock divider. Move the divider into
> a compat structure specific to the SoCs.
>
> Signed-off-by: Biao Huang <biao.huang@mediatek.com>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
> ---
> drivers/net/ethernet/mediatek/mtk_star_emac.c | 23 +++++++++++++++----
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> index 1d5dd2015453..26f5020f2e9c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> @@ -17,6 +17,7 @@
> #include <linux/module.h>
> #include <linux/netdevice.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/of_mdio.h>
> #include <linux/of_net.h>
> #include <linux/platform_device.h>
> @@ -232,6 +233,10 @@ struct mtk_star_ring {
> unsigned int tail;
> };
>
> +struct mtk_star_compat {
> + unsigned char bit_clk_div;
> +};
> +
> struct mtk_star_priv {
> struct net_device *ndev;
>
> @@ -257,6 +262,8 @@ struct mtk_star_priv {
> int duplex;
> int pause;
>
> + const struct mtk_star_compat *compat_data;
> +
> /* Protects against concurrent descriptor access. */
> spinlock_t lock;
>
> @@ -899,7 +906,7 @@ static void mtk_star_init_config(struct mtk_star_priv *priv)
> regmap_write(priv->regs, MTK_STAR_REG_SYS_CONF, val);
> regmap_update_bits(priv->regs, MTK_STAR_REG_MAC_CLK_CONF,
> MTK_STAR_MSK_MAC_CLK_CONF,
> - MTK_STAR_BIT_CLK_DIV_10);
> + priv->compat_data->bit_clk_div);
> }
>
> static void mtk_star_set_mode_rmii(struct mtk_star_priv *priv)
> @@ -1461,6 +1468,7 @@ static int mtk_star_probe(struct platform_device *pdev)
>
> priv = netdev_priv(ndev);
> priv->ndev = ndev;
> + priv->compat_data = of_device_get_match_data(&pdev->dev);
> SET_NETDEV_DEV(ndev, dev);
> platform_set_drvdata(pdev, ndev);
>
> @@ -1556,10 +1564,17 @@ static int mtk_star_probe(struct platform_device *pdev)
> return devm_register_netdev(dev, ndev);
> }
>
> +static struct mtk_star_compat mtk_star_mt8516_compat = {
static const ... ?
> + .bit_clk_div = MTK_STAR_BIT_CLK_DIV_10,
> +};
> +
> static const struct of_device_id mtk_star_of_match[] = {
> - { .compatible = "mediatek,mt8516-eth", },
> - { .compatible = "mediatek,mt8518-eth", },
> - { .compatible = "mediatek,mt8175-eth", },
> + { .compatible = "mediatek,mt8516-eth",
> + .data = &mtk_star_mt8516_compat },
> + { .compatible = "mediatek,mt8518-eth",
> + .data = &mtk_star_mt8516_compat },
> + { .compatible = "mediatek,mt8175-eth",
> + .data = &mtk_star_mt8516_compat },
> { }
> };
> MODULE_DEVICE_TABLE(of, mtk_star_of_match);
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: zynqmp: add AMS driver to device tree
From: Michal Simek @ 2022-01-25 9:42 UTC (permalink / raw)
To: Robert Hancock, linux-iio
Cc: robh+dt, michal.simek, anand.ashok.dumbre, jic23, lars,
manish.narani, linux-arm-kernel, devicetree
In-Reply-To: <20220120010246.3794962-2-robert.hancock@calian.com>
On 1/20/22 02:02, Robert Hancock wrote:
> Add an entry to the ZynqMP device tree to support the AMS device which
> now has a driver in mainline.
>
> Signed-off-by: Robert Hancock <robert.hancock@calian.com>
> ---
> .../arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi | 4 +++
> arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 26 +++++++++++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> index 1e0b1bca7c94..108592104a1b 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-clk-ccf.dtsi
> @@ -239,6 +239,10 @@ &lpd_watchdog {
> clocks = <&zynqmp_clk LPD_WDT>;
> };
>
> +&xilinx_ams {
> + clocks = <&zynqmp_clk AMS_REF>;
> +};
Please send this patch out of the series. It should go via soc tree not via iio
tree.
And unfortunately clock is not listed in DT binding document and needs to be
added there.
Can you please send that patch too? dtbs_check reports it as issue.
> +
> &zynqmp_dpdma {
> clocks = <&zynqmp_clk DPDMA_REF>;
> };
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index 74e66443e4ce..d1fe1e5b46c1 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -878,6 +878,32 @@ lpd_watchdog: watchdog@ff150000 {
> timeout-sec = <10>;
> };
>
> + xilinx_ams: ams@ffa50000 {
> + compatible = "xlnx,zynqmp-ams";
> + status = "disabled";
> + interrupt-parent = <&gic>;
> + interrupts = <0 56 4>;
> + reg = <0x0 0xffa50000 0x0 0x800>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #io-channel-cells = <1>;
> + ranges = <0 0 0xffa50800 0x800>;
> +
> + ams_ps: ams_ps@0 {
> + compatible = "xlnx,zynqmp-ams-ps";
> + status = "disabled";
> + reg = <0x0 0x400>;
> + };
> +
> + ams_pl: ams_pl@400 {
> + compatible = "xlnx,zynqmp-ams-pl";
> + status = "disabled";
> + reg = <0x400 0x400>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> +
> zynqmp_dpdma: dma-controller@fd4c0000 {
> compatible = "xlnx,zynqmp-dpdma";
> status = "disabled";
And this second piece is completely aligned with dt binding that's why it is fine.
Thanks,
Michal
^ permalink raw reply
* [PATCH RESEND v4 8/9] clk: cs2000-cp: freeze config during register fiddling
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
Make sure to freeze the configuration of the chip during the programming
of 32-bit registers. This avoids the processing of invalid intermediate
states.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/clk/clk-cs2000-cp.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index 9f99e39b41f2..1baf0595ba59 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -52,6 +52,7 @@
#define FRACNSRC_DYNAMIC (1 << 0)
/* GLOBAL_CFG */
+#define FREEZE (1 << 7)
#define ENDEV2 (0x1)
/* FUNC_CFG1 */
@@ -335,6 +336,10 @@ static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
{
int ret;
+ ret = cs2000_bset(priv, GLOBAL_CFG, FREEZE, FREEZE);
+ if (ret < 0)
+ return ret;
+
ret = cs2000_select_ratio_mode(priv, rate, parent_rate);
if (ret < 0)
return ret;
@@ -347,6 +352,10 @@ static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
if (ret < 0)
return ret;
+ ret = cs2000_bset(priv, GLOBAL_CFG, FREEZE, 0);
+ if (ret < 0)
+ return ret;
+
priv->saved_rate = rate;
priv->saved_parent_rate = parent_rate;
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 1/9] dt-bindings: clock: convert cs2000-cp bindings to yaml
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
The original author of the file was added as maintainer.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../bindings/clock/cirrus,cs2000-cp.yaml | 63 +++++++++++++++++++
.../devicetree/bindings/clock/cs2000-cp.txt | 22 -------
2 files changed, 63 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
new file mode 100644
index 000000000000..379a8bab49ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/cirrus,cs2000-cp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binding CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+
+maintainers:
+ - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
+
+description: |
+ The CS2000-CP is an extremely versatile system clocking device that
+ utilizes a programmable phase lock loop.
+
+ Link: https://www.cirrus.com/products/cs2000/
+
+properties:
+ compatible:
+ enum:
+ - cirrus,cs2000-cp
+
+ clocks:
+ description:
+ Common clock binding for CLK_IN, XTI/REF_CLK
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: clk_in
+ - const: ref_clk
+
+ '#clock-cells':
+ const: 0
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c@0 {
+ reg = <0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ clock-controller@4f {
+ #clock-cells = <0>;
+ compatible = "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&rcar_sound 0>, <&x12_clk>;
+ clock-names = "clk_in", "ref_clk";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
deleted file mode 100644
index 54e6df0bee8a..000000000000
--- a/Documentation/devicetree/bindings/clock/cs2000-cp.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
-
-Required properties:
-
-- compatible: "cirrus,cs2000-cp"
-- reg: The chip select number on the I2C bus
-- clocks: common clock binding for CLK_IN, XTI/REF_CLK
-- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk
-- #clock-cells: must be <0>
-
-Example:
-
-&i2c2 {
- ...
- cs2000: clk_multiplier@4f {
- #clock-cells = <0>;
- compatible = "cirrus,cs2000-cp";
- reg = <0x4f>;
- clocks = <&rcar_sound 0>, <&x12_clk>;
- clock-names = "clk_in", "ref_clk";
- };
-};
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 0/9] clk: cs2000-cp: add dynamic mode and more features
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
Mike, Stephen,
This patch series adds support for dynamic mode, configurable clock
skip settings and a tranisition to regmap.
As Kuninori Morimoto is not responding, would you kindly do me the
favor and take this series directly? I don't know what else to do
than resending the set over and over again.
The patches still apply cleanly to 5.17-rc1, and we're using them
in production since a while.
All DT patches are Acked-by already by Rob; what left is a review of
the implementation bits.
Thanks,
Daniel
Daniel Mack (9):
dt-bindings: clock: convert cs2000-cp bindings to yaml
dt-bindings: clock: cs2000-cp: document aux-output-source
dt-bindings: clock: cs2000-cp: document cirrus,clock-skip flag
dt-bindings: clock: cs2000-cp: document cirrus,dynamic-mode
clk: cs2000-cp: Make aux output function controllable
clk: cs2000-cp: add support for dynamic mode
clk: cs2000-cp: make clock skip setting configurable
clk: cs2000-cp: freeze config during register fiddling
clk: cs2000-cp: convert driver to regmap
.../bindings/clock/cirrus,cs2000-cp.yaml | 91 +++++++
.../devicetree/bindings/clock/cs2000-cp.txt | 22 --
drivers/clk/Kconfig | 1 +
drivers/clk/clk-cs2000-cp.c | 243 ++++++++++++------
include/dt-bindings/clock/cirrus,cs2000-cp.h | 14 +
5 files changed, 264 insertions(+), 107 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
create mode 100644 include/dt-bindings/clock/cirrus,cs2000-cp.h
--
2.31.1
^ permalink raw reply
* [PATCH RESEND v4 6/9] clk: cs2000-cp: add support for dynamic mode
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
The CS2000 chip features two input clocks, REF_CLK and CLK_IN.
In static mode, the output clock (CLK_OUT) is directly derived from
REF_CLK, and CLK_IN is ignored. In dynamic mode, CLK_IN is used by the
digital PLL.
In dynamic mode, a low-frequency ratio configuration that uses a higher
multiplier factor.
Until now, only the static mode and high-frequency divider rations of
the hardware was supported by the driver. This patch adds support for
dynamic mode and both ratios:
* Parse a new OF property 'cirrus,dynamic-mode' to determine the mode
* In dynamic mode, present CLK_IN as parent clock, else use REF_CLK
* The low-frequency ratio mode is automatically selected, depending
on the mode of operation and the given input and output rates
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/clk/clk-cs2000-cp.c | 111 ++++++++++++++++++++++++------------
1 file changed, 74 insertions(+), 37 deletions(-)
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index db7290621cef..bd030e156d65 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -49,7 +49,7 @@
#define LOCKCLK_MASK LOCKCLK(0x3)
#define FRACNSRC_MASK (1 << 0)
#define FRACNSRC_STATIC (0 << 0)
-#define FRACNSRC_DYNAMIC (1 << 1)
+#define FRACNSRC_DYNAMIC (1 << 0)
/* GLOBAL_CFG */
#define ENDEV2 (0x1)
@@ -79,6 +79,9 @@ struct cs2000_priv {
struct clk *clk_in;
struct clk *ref_clk;
+ bool dynamic_mode;
+ bool lf_ratio;
+
/* suspend/resume */
unsigned long saved_rate;
unsigned long saved_parent_rate;
@@ -134,17 +137,11 @@ static int cs2000_enable_dev_config(struct cs2000_priv *priv, bool enable)
if (ret < 0)
return ret;
- /* FIXME: for Static ratio mode */
- ret = cs2000_bset(priv, FUNC_CFG2, LFRATIO_MASK,
- LFRATIO_12_20);
- if (ret < 0)
- return ret;
-
return 0;
}
-static int cs2000_clk_in_bound_rate(struct cs2000_priv *priv,
- u32 rate_in)
+static int cs2000_ref_clk_bound_rate(struct cs2000_priv *priv,
+ u32 rate_in)
{
u32 val;
@@ -191,35 +188,37 @@ static int cs2000_clk_out_enable(struct cs2000_priv *priv, bool enable)
(AUXOUTDIS | CLKOUTDIS));
}
-static u32 cs2000_rate_to_ratio(u32 rate_in, u32 rate_out)
+static u32 cs2000_rate_to_ratio(u32 rate_in, u32 rate_out, bool lf_ratio)
{
u64 ratio;
+ u32 multiplier = lf_ratio ? 12 : 20;
/*
- * ratio = rate_out / rate_in * 2^20
+ * ratio = rate_out / rate_in * 2^multiplier
*
* To avoid over flow, rate_out is u64.
* The result should be u32.
*/
- ratio = (u64)rate_out << 20;
+ ratio = (u64)rate_out << multiplier;
do_div(ratio, rate_in);
return ratio;
}
-static unsigned long cs2000_ratio_to_rate(u32 ratio, u32 rate_in)
+static unsigned long cs2000_ratio_to_rate(u32 ratio, u32 rate_in, bool lf_ratio)
{
u64 rate_out;
+ u32 multiplier = lf_ratio ? 12 : 20;
/*
- * ratio = rate_out / rate_in * 2^20
+ * ratio = rate_out / rate_in * 2^multiplier
*
* To avoid over flow, rate_out is u64.
* The result should be u32 or unsigned long.
*/
rate_out = (u64)ratio * rate_in;
- return rate_out >> 20;
+ return rate_out >> multiplier;
}
static int cs2000_ratio_set(struct cs2000_priv *priv,
@@ -232,7 +231,7 @@ static int cs2000_ratio_set(struct cs2000_priv *priv,
if (CH_SIZE_ERR(ch))
return -EINVAL;
- val = cs2000_rate_to_ratio(rate_in, rate_out);
+ val = cs2000_rate_to_ratio(rate_in, rate_out, priv->lf_ratio);
for (i = 0; i < RATIO_REG_SIZE; i++) {
ret = cs2000_write(priv,
Ratio_Add(ch, i),
@@ -265,22 +264,20 @@ static u32 cs2000_ratio_get(struct cs2000_priv *priv, int ch)
static int cs2000_ratio_select(struct cs2000_priv *priv, int ch)
{
int ret;
+ u8 fracnsrc;
if (CH_SIZE_ERR(ch))
return -EINVAL;
- /*
- * FIXME
- *
- * this driver supports static ratio mode only at this point.
- */
ret = cs2000_bset(priv, DEVICE_CFG1, RSEL_MASK, RSEL(ch));
if (ret < 0)
return ret;
+ fracnsrc = priv->dynamic_mode ? FRACNSRC_DYNAMIC : FRACNSRC_STATIC;
+
ret = cs2000_bset(priv, DEVICE_CFG2,
- (AUTORMOD | LOCKCLK_MASK | FRACNSRC_MASK),
- (LOCKCLK(ch) | FRACNSRC_STATIC));
+ AUTORMOD | LOCKCLK_MASK | FRACNSRC_MASK,
+ LOCKCLK(ch) | fracnsrc);
if (ret < 0)
return ret;
@@ -296,17 +293,39 @@ static unsigned long cs2000_recalc_rate(struct clk_hw *hw,
ratio = cs2000_ratio_get(priv, ch);
- return cs2000_ratio_to_rate(ratio, parent_rate);
+ return cs2000_ratio_to_rate(ratio, parent_rate, priv->lf_ratio);
}
static long cs2000_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)
{
+ struct cs2000_priv *priv = hw_to_priv(hw);
u32 ratio;
- ratio = cs2000_rate_to_ratio(*parent_rate, rate);
+ ratio = cs2000_rate_to_ratio(*parent_rate, rate, priv->lf_ratio);
+
+ return cs2000_ratio_to_rate(ratio, *parent_rate, priv->lf_ratio);
+}
+
+static int cs2000_select_ratio_mode(struct cs2000_priv *priv,
+ unsigned long rate,
+ unsigned long parent_rate)
+{
+ /*
+ * From the datasheet:
+ *
+ * | It is recommended that the 12.20 High-Resolution format be
+ * | utilized whenever the desired ratio is less than 4096 since
+ * | the output frequency accuracy of the PLL is directly proportional
+ * | to the accuracy of the timing reference clock and the resolution
+ * | of the R_UD.
+ *
+ * This mode is only available in dynamic mode.
+ */
+ priv->lf_ratio = priv->dynamic_mode && ((rate / parent_rate) > 4096);
- return cs2000_ratio_to_rate(ratio, *parent_rate);
+ return cs2000_bset(priv, FUNC_CFG2, LFRATIO_MASK,
+ priv->lf_ratio ? LFRATIO_20_12 : LFRATIO_12_20);
}
static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
@@ -315,7 +334,7 @@ static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
{
int ret;
- ret = cs2000_clk_in_bound_rate(priv, parent_rate);
+ ret = cs2000_select_ratio_mode(priv, rate, parent_rate);
if (ret < 0)
return ret;
@@ -382,8 +401,13 @@ static void cs2000_disable(struct clk_hw *hw)
static u8 cs2000_get_parent(struct clk_hw *hw)
{
- /* always return REF_CLK */
- return REF_CLK;
+ struct cs2000_priv *priv = hw_to_priv(hw);
+
+ /*
+ * In dynamic mode, output rates are derived from CLK_IN.
+ * In static mode, CLK_IN is ignored, so we return REF_CLK instead.
+ */
+ return priv->dynamic_mode ? CLK_IN : REF_CLK;
}
static const struct clk_ops cs2000_ops = {
@@ -424,28 +448,41 @@ static int cs2000_clk_register(struct cs2000_priv *priv)
const char *name = np->name;
static const char *parent_names[CLK_MAX];
u32 aux_out = 0;
+ int ref_clk_rate;
int ch = 0; /* it uses ch0 only at this point */
- int rate;
int ret;
of_property_read_string(np, "clock-output-names", &name);
+ priv->dynamic_mode = of_property_read_bool(np, "cirrus,dynamic-mode");
+ dev_info(dev, "operating in %s mode\n",
+ priv->dynamic_mode ? "dynamic" : "static");
+
of_property_read_u32(np, "cirrus,aux-output-source", &aux_out);
ret = cs2000_bset(priv, DEVICE_CFG1,
AUXOUTSRC_MASK, AUXOUTSRC(aux_out));
if (ret < 0)
return ret;
- /*
- * set default rate as 1/1.
- * otherwise .set_rate which setup ratio
- * is never called if user requests 1/1 rate
- */
- rate = clk_get_rate(priv->ref_clk);
- ret = __cs2000_set_rate(priv, ch, rate, rate);
+ ref_clk_rate = clk_get_rate(priv->ref_clk);
+ ret = cs2000_ref_clk_bound_rate(priv, ref_clk_rate);
if (ret < 0)
return ret;
+ if (priv->dynamic_mode) {
+ /* Default to low-frequency mode to allow for large ratios */
+ priv->lf_ratio = true;
+ } else {
+ /*
+ * set default rate as 1/1.
+ * otherwise .set_rate which setup ratio
+ * is never called if user requests 1/1 rate
+ */
+ ret = __cs2000_set_rate(priv, ch, ref_clk_rate, ref_clk_rate);
+ if (ret < 0)
+ return ret;
+ }
+
parent_names[CLK_IN] = __clk_get_name(priv->clk_in);
parent_names[REF_CLK] = __clk_get_name(priv->ref_clk);
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 5/9] clk: cs2000-cp: Make aux output function controllable
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
The aux output pin can be configured to output either of the two clock
inputs, the generated clock or the pll lock status. Allow access to
this feature through a new optional device-tree property.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/clk/clk-cs2000-cp.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index 92bc4aca0f95..db7290621cef 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -39,6 +39,8 @@
/* DEVICE_CFG1 */
#define RSEL(x) (((x) & 0x3) << 3)
#define RSEL_MASK RSEL(0x3)
+#define AUXOUTSRC(x) (((x) & 0x3) << 1)
+#define AUXOUTSRC_MASK AUXOUTSRC(0x3)
#define ENDEV1 (0x1)
/* DEVICE_CFG2 */
@@ -421,12 +423,19 @@ static int cs2000_clk_register(struct cs2000_priv *priv)
struct clk_init_data init;
const char *name = np->name;
static const char *parent_names[CLK_MAX];
+ u32 aux_out = 0;
int ch = 0; /* it uses ch0 only at this point */
int rate;
int ret;
of_property_read_string(np, "clock-output-names", &name);
+ of_property_read_u32(np, "cirrus,aux-output-source", &aux_out);
+ ret = cs2000_bset(priv, DEVICE_CFG1,
+ AUXOUTSRC_MASK, AUXOUTSRC(aux_out));
+ if (ret < 0)
+ return ret;
+
/*
* set default rate as 1/1.
* otherwise .set_rate which setup ratio
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 3/9] dt-bindings: clock: cs2000-cp: document cirrus,clock-skip flag
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
This mode allows the PLL to maintain lock even when CLK_IN has
missing pulses for up to 20 ms.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index 79b90500f6ac..9047d8a24a08 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -48,6 +48,12 @@ properties:
- 3 # CS2000CP_AUX_OUTPUT_PLL_LOCK: pll lock status
default: 0
+ cirrus,clock-skip:
+ description:
+ This mode allows the PLL to maintain lock even when CLK_IN
+ has missing pulses for up to 20 ms.
+ $ref: /schemas/types.yaml#/definitions/flag
+
required:
- compatible
- reg
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 2/9] dt-bindings: clock: cs2000-cp: document aux-output-source
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
This new optional property can be used to control the function of the
auxiliary output pin. Introduce a new dt-bindings include file that
contains the numerical values.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/clock/cirrus,cs2000-cp.yaml | 14 ++++++++++++++
include/dt-bindings/clock/cirrus,cs2000-cp.h | 14 ++++++++++++++
2 files changed, 28 insertions(+)
create mode 100644 include/dt-bindings/clock/cirrus,cs2000-cp.h
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index 379a8bab49ca..79b90500f6ac 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -37,6 +37,17 @@ properties:
reg:
maxItems: 1
+ cirrus,aux-output-source:
+ description:
+ Specifies the function of the auxiliary clock output pin
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum:
+ - 0 # CS2000CP_AUX_OUTPUT_REF_CLK: ref_clk input
+ - 1 # CS2000CP_AUX_OUTPUT_CLK_IN: clk_in input
+ - 2 # CS2000CP_AUX_OUTPUT_CLK_OUT: clk_out output
+ - 3 # CS2000CP_AUX_OUTPUT_PLL_LOCK: pll lock status
+ default: 0
+
required:
- compatible
- reg
@@ -48,6 +59,8 @@ additionalProperties: false
examples:
- |
+ #include <dt-bindings/clock/cirrus,cs2000-cp.h>
+
i2c@0 {
reg = <0x0 0x100>;
#address-cells = <1>;
@@ -59,5 +72,6 @@ examples:
reg = <0x4f>;
clocks = <&rcar_sound 0>, <&x12_clk>;
clock-names = "clk_in", "ref_clk";
+ cirrus,aux-output-source = <CS2000CP_AUX_OUTPUT_CLK_OUT>;
};
};
diff --git a/include/dt-bindings/clock/cirrus,cs2000-cp.h b/include/dt-bindings/clock/cirrus,cs2000-cp.h
new file mode 100644
index 000000000000..fe3ac71750a8
--- /dev/null
+++ b/include/dt-bindings/clock/cirrus,cs2000-cp.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2021 Daniel Mack
+ */
+
+#ifndef __DT_BINDINGS_CS2000CP_CLK_H
+#define __DT_BINDINGS_CS2000CP_CLK_H
+
+#define CS2000CP_AUX_OUTPUT_REF_CLK 0
+#define CS2000CP_AUX_OUTPUT_CLK_IN 1
+#define CS2000CP_AUX_OUTPUT_CLK_OUT 2
+#define CS2000CP_AUX_OUTPUT_PLL_LOCK 3
+
+#endif /* __DT_BINDINGS_CS2000CP_CLK_H */
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 9/9] clk: cs2000-cp: convert driver to regmap
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
Regmap gives us caching, debugging infrastructure and other things for
free and does away with open-coded bit-fiddling implementations.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/clk/Kconfig | 1 +
drivers/clk/clk-cs2000-cp.c | 124 ++++++++++++++++++++----------------
2 files changed, 69 insertions(+), 56 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 70df25b2cd8b..237a3a76118c 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -195,6 +195,7 @@ config COMMON_CLK_CDCE925
config COMMON_CLK_CS2000_CP
tristate "Clock driver for CS2000 Fractional-N Clock Synthesizer & Clock Multiplier"
depends on I2C
+ select REGMAP_I2C
help
If you say yes here you get support for the CS2000 clock multiplier.
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index 1baf0595ba59..dc5040a84dcc 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -11,6 +11,7 @@
#include <linux/i2c.h>
#include <linux/of_device.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#define CH_MAX 4
#define RATIO_REG_SIZE 4
@@ -74,11 +75,36 @@
#define REF_CLK 1
#define CLK_MAX 2
+static bool cs2000_readable_reg(struct device *dev, unsigned int reg)
+{
+ return reg > 0;
+}
+
+static bool cs2000_writeable_reg(struct device *dev, unsigned int reg)
+{
+ return reg != DEVICE_ID;
+}
+
+static bool cs2000_volatile_reg(struct device *dev, unsigned int reg)
+{
+ return reg == DEVICE_CTRL;
+}
+
+static const struct regmap_config cs2000_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = FUNC_CFG2,
+ .readable_reg = cs2000_readable_reg,
+ .writeable_reg = cs2000_writeable_reg,
+ .volatile_reg = cs2000_volatile_reg,
+};
+
struct cs2000_priv {
struct clk_hw hw;
struct i2c_client *client;
struct clk *clk_in;
struct clk *ref_clk;
+ struct regmap *regmap;
bool dynamic_mode;
bool lf_ratio;
@@ -101,41 +127,22 @@ static const struct i2c_device_id cs2000_id[] = {
};
MODULE_DEVICE_TABLE(i2c, cs2000_id);
-#define cs2000_read(priv, addr) \
- i2c_smbus_read_byte_data(priv_to_client(priv), addr)
-#define cs2000_write(priv, addr, val) \
- i2c_smbus_write_byte_data(priv_to_client(priv), addr, val)
-
-static int cs2000_bset(struct cs2000_priv *priv, u8 addr, u8 mask, u8 val)
-{
- s32 data;
-
- data = cs2000_read(priv, addr);
- if (data < 0)
- return data;
-
- data &= ~mask;
- data |= (val & mask);
-
- return cs2000_write(priv, addr, data);
-}
-
static int cs2000_enable_dev_config(struct cs2000_priv *priv, bool enable)
{
int ret;
- ret = cs2000_bset(priv, DEVICE_CFG1, ENDEV1,
- enable ? ENDEV1 : 0);
+ ret = regmap_update_bits(priv->regmap, DEVICE_CFG1, ENDEV1,
+ enable ? ENDEV1 : 0);
if (ret < 0)
return ret;
- ret = cs2000_bset(priv, GLOBAL_CFG, ENDEV2,
- enable ? ENDEV2 : 0);
+ ret = regmap_update_bits(priv->regmap, GLOBAL_CFG, ENDEV2,
+ enable ? ENDEV2 : 0);
if (ret < 0)
return ret;
- ret = cs2000_bset(priv, FUNC_CFG1, CLKSKIPEN,
- (enable && priv->clk_skip) ? CLKSKIPEN : 0);
+ ret = regmap_update_bits(priv->regmap, FUNC_CFG1, CLKSKIPEN,
+ (enable && priv->clk_skip) ? CLKSKIPEN : 0);
if (ret < 0)
return ret;
@@ -156,21 +163,21 @@ static int cs2000_ref_clk_bound_rate(struct cs2000_priv *priv,
else
return -EINVAL;
- return cs2000_bset(priv, FUNC_CFG1,
- REFCLKDIV_MASK,
- REFCLKDIV(val));
+ return regmap_update_bits(priv->regmap, FUNC_CFG1,
+ REFCLKDIV_MASK,
+ REFCLKDIV(val));
}
static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
{
struct device *dev = priv_to_dev(priv);
- s32 val;
- unsigned int i;
+ unsigned int i, val;
+ int ret;
for (i = 0; i < 256; i++) {
- val = cs2000_read(priv, DEVICE_CTRL);
- if (val < 0)
- return val;
+ ret = regmap_read(priv->regmap, DEVICE_CTRL, &val);
+ if (ret < 0)
+ return ret;
if (!(val & PLL_UNLOCK))
return 0;
udelay(1);
@@ -184,10 +191,10 @@ static int cs2000_wait_pll_lock(struct cs2000_priv *priv)
static int cs2000_clk_out_enable(struct cs2000_priv *priv, bool enable)
{
/* enable both AUX_OUT, CLK_OUT */
- return cs2000_bset(priv, DEVICE_CTRL,
- (AUXOUTDIS | CLKOUTDIS),
- enable ? 0 :
- (AUXOUTDIS | CLKOUTDIS));
+ return regmap_update_bits(priv->regmap, DEVICE_CTRL,
+ (AUXOUTDIS | CLKOUTDIS),
+ enable ? 0 :
+ (AUXOUTDIS | CLKOUTDIS));
}
static u32 cs2000_rate_to_ratio(u32 rate_in, u32 rate_out, bool lf_ratio)
@@ -235,7 +242,7 @@ static int cs2000_ratio_set(struct cs2000_priv *priv,
val = cs2000_rate_to_ratio(rate_in, rate_out, priv->lf_ratio);
for (i = 0; i < RATIO_REG_SIZE; i++) {
- ret = cs2000_write(priv,
+ ret = regmap_write(priv->regmap,
Ratio_Add(ch, i),
Ratio_Val(val, i));
if (ret < 0)
@@ -247,14 +254,14 @@ static int cs2000_ratio_set(struct cs2000_priv *priv,
static u32 cs2000_ratio_get(struct cs2000_priv *priv, int ch)
{
- s32 tmp;
+ unsigned int tmp, i;
u32 val;
- unsigned int i;
+ int ret;
val = 0;
for (i = 0; i < RATIO_REG_SIZE; i++) {
- tmp = cs2000_read(priv, Ratio_Add(ch, i));
- if (tmp < 0)
+ ret = regmap_read(priv->regmap, Ratio_Add(ch, i), &tmp);
+ if (ret < 0)
return 0;
val |= Val_Ratio(tmp, i);
@@ -271,15 +278,15 @@ static int cs2000_ratio_select(struct cs2000_priv *priv, int ch)
if (CH_SIZE_ERR(ch))
return -EINVAL;
- ret = cs2000_bset(priv, DEVICE_CFG1, RSEL_MASK, RSEL(ch));
+ ret = regmap_update_bits(priv->regmap, DEVICE_CFG1, RSEL_MASK, RSEL(ch));
if (ret < 0)
return ret;
fracnsrc = priv->dynamic_mode ? FRACNSRC_DYNAMIC : FRACNSRC_STATIC;
- ret = cs2000_bset(priv, DEVICE_CFG2,
- AUTORMOD | LOCKCLK_MASK | FRACNSRC_MASK,
- LOCKCLK(ch) | fracnsrc);
+ ret = regmap_update_bits(priv->regmap, DEVICE_CFG2,
+ AUTORMOD | LOCKCLK_MASK | FRACNSRC_MASK,
+ LOCKCLK(ch) | fracnsrc);
if (ret < 0)
return ret;
@@ -326,8 +333,8 @@ static int cs2000_select_ratio_mode(struct cs2000_priv *priv,
*/
priv->lf_ratio = priv->dynamic_mode && ((rate / parent_rate) > 4096);
- return cs2000_bset(priv, FUNC_CFG2, LFRATIO_MASK,
- priv->lf_ratio ? LFRATIO_20_12 : LFRATIO_12_20);
+ return regmap_update_bits(priv->regmap, FUNC_CFG2, LFRATIO_MASK,
+ priv->lf_ratio ? LFRATIO_20_12 : LFRATIO_12_20);
}
static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
@@ -336,7 +343,7 @@ static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
{
int ret;
- ret = cs2000_bset(priv, GLOBAL_CFG, FREEZE, FREEZE);
+ ret = regmap_update_bits(priv->regmap, GLOBAL_CFG, FREEZE, FREEZE);
if (ret < 0)
return ret;
@@ -352,7 +359,7 @@ static int __cs2000_set_rate(struct cs2000_priv *priv, int ch,
if (ret < 0)
return ret;
- ret = cs2000_bset(priv, GLOBAL_CFG, FREEZE, 0);
+ ret = regmap_update_bits(priv->regmap, GLOBAL_CFG, FREEZE, 0);
if (ret < 0)
return ret;
@@ -469,8 +476,8 @@ static int cs2000_clk_register(struct cs2000_priv *priv)
priv->dynamic_mode ? "dynamic" : "static");
of_property_read_u32(np, "cirrus,aux-output-source", &aux_out);
- ret = cs2000_bset(priv, DEVICE_CFG1,
- AUXOUTSRC_MASK, AUXOUTSRC(aux_out));
+ ret = regmap_update_bits(priv->regmap, DEVICE_CFG1,
+ AUXOUTSRC_MASK, AUXOUTSRC(aux_out));
if (ret < 0)
return ret;
@@ -522,12 +529,13 @@ static int cs2000_clk_register(struct cs2000_priv *priv)
static int cs2000_version_print(struct cs2000_priv *priv)
{
struct device *dev = priv_to_dev(priv);
- s32 val;
const char *revision;
+ unsigned int val;
+ int ret;
- val = cs2000_read(priv, DEVICE_ID);
- if (val < 0)
- return val;
+ ret = regmap_read(priv->regmap, DEVICE_ID, &val);
+ if (ret < 0)
+ return ret;
/* CS2000 should be 0x0 */
if (val >> 3)
@@ -576,6 +584,10 @@ static int cs2000_probe(struct i2c_client *client,
priv->client = client;
i2c_set_clientdata(client, priv);
+ priv->regmap = devm_regmap_init_i2c(client, &cs2000_regmap_config);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+
ret = cs2000_clk_get(priv);
if (ret < 0)
return ret;
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 4/9] dt-bindings: clock: cs2000-cp: document cirrus,dynamic-mode
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
This new flag exists to enable the dynamic mode of the hardware.
When not given, the static mode is used.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index 9047d8a24a08..0abd6ba82dfd 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -54,6 +54,14 @@ properties:
has missing pulses for up to 20 ms.
$ref: /schemas/types.yaml#/definitions/flag
+ cirrus,dynamic-mode:
+ description:
+ In dynamic mode, the CLK_IN input is used to drive the
+ digital PLL of the silicon.
+ If not given, the static mode shall be used to derive the
+ output signal directly from the REF_CLK input.
+ $ref: /schemas/types.yaml#/definitions/flag
+
required:
- compatible
- reg
--
2.31.1
^ permalink raw reply related
* [PATCH RESEND v4 7/9] clk: cs2000-cp: make clock skip setting configurable
From: Daniel Mack @ 2022-01-25 9:33 UTC (permalink / raw)
To: mturquette, sboyd
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-1-daniel@zonque.org>
The clock skip function of this chip is not necessarily desirable in
all hardware appliances. This patch makes the feature configurable
through a device-tree property.
Signed-off-by: Daniel Mack <daniel@zonque.org>
---
drivers/clk/clk-cs2000-cp.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
index bd030e156d65..9f99e39b41f2 100644
--- a/drivers/clk/clk-cs2000-cp.c
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -81,6 +81,7 @@ struct cs2000_priv {
bool dynamic_mode;
bool lf_ratio;
+ bool clk_skip;
/* suspend/resume */
unsigned long saved_rate;
@@ -133,7 +134,7 @@ static int cs2000_enable_dev_config(struct cs2000_priv *priv, bool enable)
return ret;
ret = cs2000_bset(priv, FUNC_CFG1, CLKSKIPEN,
- enable ? CLKSKIPEN : 0);
+ (enable && priv->clk_skip) ? CLKSKIPEN : 0);
if (ret < 0)
return ret;
@@ -464,6 +465,8 @@ static int cs2000_clk_register(struct cs2000_priv *priv)
if (ret < 0)
return ret;
+ priv->clk_skip = of_property_read_bool(np, "cirrus,clock-skip");
+
ref_clk_rate = clk_get_rate(priv->ref_clk);
ret = cs2000_ref_clk_bound_rate(priv, ref_clk_rate);
if (ret < 0)
--
2.31.1
^ permalink raw reply related
* [RFC PATCH 0/2] Multicolor PWM LED support
From: sven @ 2022-01-25 9:22 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, dmurphy, robh+dt, thierry.reding,
u.kleine-koenig, lee.jones
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Hi,
As previously discussed [1] on the linux-leds list I am missing
multicolor PWM LED support. In the mean time I have put together a
working prototype for such a driver. This is my first Linux driver
so I'm hoping for some feedback. Here are some questions that came up
while putting this thing together:
1. Currently, the max-brightness property is expected as a property to
the multi-led node. That seems consistent with the existing
multicolor class code, but I'm wondering whether it would make
sense to have a max-brigthness for the individual LEDs as well?
2. The current multi-led node definition calls for a node index which
would in turn require the reg property to be set within the node.
In this context, that doesn't seem to make sense. Should this
requirement be lifted from leds-class-multicolor.yaml?
3. I'm not currently reusing any leds-pwm code because there aren't
too many overlaps. Does anyone have suggestions what could be
factored out into a common source file?
I would appreciate if anyone would test this code. It runs on my
i.MX6ULL-based hardware.
Best regards,
Sven
[1]: https://www.spinics.net/lists/linux-leds/msg19988.html
Sven Schwermer (2):
dt-bindings: leds: Add multicolor PWM LED bindings
leds: Add PWM multicolor driver
.../bindings/leds/leds-pwm-multicolor.yaml | 73 +++++++
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pwm-multicolor.c | 184 ++++++++++++++++++
4 files changed, 266 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
create mode 100644 drivers/leds/leds-pwm-multicolor.c
--
2.35.0
^ permalink raw reply
* [RFC PATCH 2/2] leds: Add PWM multicolor driver
From: sven @ 2022-01-25 9:22 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, dmurphy, robh+dt, thierry.reding,
u.kleine-koenig, lee.jones
In-Reply-To: <20220125092239.2006333-1-sven@svenschwermer.de>
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
By allowing to group multiple monochrome PWM LEDs into multicolor LEDs,
all involved LEDs can be controlled in-sync. This enables using effects
using triggers, etc.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-pwm-multicolor.c | 184 +++++++++++++++++++++++++++++
3 files changed, 193 insertions(+)
create mode 100644 drivers/leds/leds-pwm-multicolor.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b6742b4231bf..2e5058696fa6 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -586,6 +586,14 @@ config LEDS_PWM
help
This option enables support for pwm driven LEDs
+config LEDS_PWM_MULTICOLOR
+ tristate "PWM driven multi-color LED Support"
+ depends on LEDS_CLASS_MULTICOLOR
+ depends on PWM
+ help
+ This option enables support for PWM driven monochrome LEDs that are
+ grouped into multicolor LEDs.
+
config LEDS_REGULATOR
tristate "REGULATOR driven LED support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2a698df9da57..152f69374632 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA963X) += leds-pca963x.o
obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
+obj-$(CONFIG_LEDS_PWM_MULTICOLOR) += leds-pwm-multicolor.o
obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
diff --git a/drivers/leds/leds-pwm-multicolor.c b/drivers/leds/leds-pwm-multicolor.c
new file mode 100644
index 000000000000..c54bed4536d3
--- /dev/null
+++ b/drivers/leds/leds-pwm-multicolor.c
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PWM-based multi-color LED control
+ *
+ * Copyright 2022 Sven Schwermer <sven.schwermer@disruptive-technologies.com>
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/leds.h>
+#include <linux/err.h>
+#include <linux/pwm.h>
+#include <linux/mutex.h>
+
+struct pwm_led {
+ struct pwm_device *pwm;
+ struct pwm_state pwmstate;
+};
+
+struct pwm_mc_led {
+ struct led_classdev_mc mc_cdev;
+ struct mutex lock;
+ struct pwm_led leds[];
+};
+
+static int led_pwm_mc_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ int i;
+ unsigned long long duty;
+ int ret = 0;
+ struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(cdev);
+ struct pwm_mc_led *priv = container_of(mc_cdev, struct pwm_mc_led, mc_cdev);
+
+ led_mc_calc_color_components(mc_cdev, brightness);
+
+ mutex_lock(&priv->lock);
+
+ for (i = 0; i < mc_cdev->num_colors; ++i) {
+ duty = priv->leds[i].pwmstate.period;
+ duty *= mc_cdev->subled_info[i].brightness;
+ do_div(duty, cdev->max_brightness);
+
+ priv->leds[i].pwmstate.duty_cycle = duty;
+ priv->leds[i].pwmstate.enabled = duty > 0;
+ ret = pwm_apply_state(priv->leds[i].pwm,
+ &priv->leds[i].pwmstate);
+ if (ret)
+ break;
+ }
+
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int led_pwm_mc_probe(struct platform_device *pdev)
+{
+ struct fwnode_handle *mcnode, *fwnode;
+ int count = 0;
+ struct pwm_mc_led *priv;
+ struct mc_subled *subled;
+ struct led_classdev *cdev;
+ struct pwm_led *pwmled;
+ u32 color;
+ int ret = 0;
+ struct led_init_data init_data = {};
+
+ mcnode = device_get_named_child_node(&pdev->dev, "multi-led");
+ if (!mcnode) {
+ dev_err(&pdev->dev, "expected multi-led node\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ /* count the nodes inside the multi-led node */
+ fwnode_for_each_child_node(mcnode, fwnode)
+ ++count;
+
+ priv = devm_kzalloc(&pdev->dev, struct_size(priv, leds, count),
+ GFP_KERNEL);
+ if (!priv) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ mutex_init(&priv->lock);
+
+ subled = devm_kcalloc(&pdev->dev, count, sizeof(*subled), GFP_KERNEL);
+ if (!subled) {
+ ret = -ENOMEM;
+ goto destroy_mutex;
+ }
+ priv->mc_cdev.subled_info = subled;
+
+ /* init the multicolor's LED class device */
+ cdev = &priv->mc_cdev.led_cdev;
+ fwnode_property_read_string(mcnode, "label", &cdev->name);
+ cdev->brightness = LED_OFF;
+ fwnode_property_read_u32(mcnode, "max-brightness",
+ &cdev->max_brightness);
+ cdev->flags = LED_CORE_SUSPENDRESUME;
+ cdev->brightness_set_blocking = led_pwm_mc_set;
+
+ /* iterate over the nodes inside the multi-led node */
+ fwnode_for_each_child_node(mcnode, fwnode) {
+ pwmled = &priv->leds[priv->mc_cdev.num_colors];
+ pwmled->pwm = devm_fwnode_pwm_get(&pdev->dev, fwnode, NULL);
+ if (IS_ERR(pwmled->pwm)) {
+ ret = PTR_ERR(pwmled->pwm);
+ dev_err(&pdev->dev, "unable to request PWM: %d\n", ret);
+ goto destroy_mutex;
+ }
+ pwm_init_state(pwmled->pwm, &pwmled->pwmstate);
+
+ ret = fwnode_property_read_u32(fwnode, "color", &color);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot read color: %d\n", ret);
+ goto destroy_mutex;
+ }
+
+ subled[priv->mc_cdev.num_colors].color_index = color;
+ subled[priv->mc_cdev.num_colors].channel =
+ priv->mc_cdev.num_colors;
+ ++priv->mc_cdev.num_colors;
+ }
+
+ init_data.fwnode = mcnode;
+ ret = devm_led_classdev_multicolor_register_ext(&pdev->dev,
+ &priv->mc_cdev,
+ &init_data);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to register multicolor PWM led for %s: %d\n",
+ cdev->name, ret);
+ goto destroy_mutex;
+ }
+
+ ret = led_pwm_mc_set(cdev, cdev->brightness);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to set led PWM value for %s: %d",
+ cdev->name, ret);
+ goto destroy_mutex;
+ }
+
+ platform_set_drvdata(pdev, priv);
+ return 0;
+
+destroy_mutex:
+ mutex_destroy(&priv->lock);
+out:
+ return ret;
+}
+
+static int led_pwm_mc_remove(struct platform_device *pdev)
+{
+ struct pwm_mc_led *priv = platform_get_drvdata(pdev);
+
+ mutex_destroy(&priv->lock);
+ return 0;
+}
+
+static const struct of_device_id of_pwm_leds_mc_match[] = {
+ { .compatible = "pwm-leds-multicolor", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_leds_mc_match);
+
+static struct platform_driver led_pwm_mc_driver = {
+ .probe = led_pwm_mc_probe,
+ .remove = led_pwm_mc_remove,
+ .driver = {
+ .name = "leds_pwm_multicolor",
+ .of_match_table = of_pwm_leds_mc_match,
+ },
+};
+
+module_platform_driver(led_pwm_mc_driver);
+
+MODULE_AUTHOR("Sven Schwermer <sven.schwermer@disruptive-technologies.com>");
+MODULE_DESCRIPTION("multi-color PWM LED driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:leds-pwm-multicolor");
--
2.35.0
^ permalink raw reply related
* [RFC PATCH 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: sven @ 2022-01-25 9:22 UTC (permalink / raw)
To: linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, dmurphy, robh+dt, thierry.reding,
u.kleine-koenig, lee.jones
In-Reply-To: <20220125092239.2006333-1-sven@svenschwermer.de>
From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
This allows to group multiple PWM-connected monochrome LEDs into
multicolor LEDs, e.g. RGB LEDs.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
---
.../bindings/leds/leds-pwm-multicolor.yaml | 73 +++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
new file mode 100644
index 000000000000..8552a5498bdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-pwm-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Multi-color LEDs connected to PWM
+
+maintainers:
+ - Sven Schwermer <sven.schwermer@disruptive-technologies.com>
+
+description: |
+ This driver combines several monochrome PWM LEDs into one multi-color
+ LED using the multicolor LED class.
+
+properties:
+ compatible: pwm-leds-multicolor
+
+patternProperties:
+ '^multi-led@[0-9a-f]$':
+ type: object
+ allOf:
+ - $ref: leds-class-multicolor.yaml#
+
+ patternProperties:
+ "^led-[0-9a-z]+$":
+ type: object
+ properties:
+ pwms:
+ maxItems: 1
+
+ pwm-names: true
+
+ color:
+ $ref: common.yaml#/properties/color
+
+required:
+ - compatible
+ - pwms
+ - color
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ rgb-led {
+ compatible = "pwm-leds-multicolor";
+
+ multi-led@0 {
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ max-brightness = <65535>;
+
+ led-red {
+ pwms = <&pwm1 0 1000000>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led-green {
+ pwms = <&pwm2 0 1000000>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led-blue {
+ pwms = <&pwm3 0 1000000>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+
+...
--
2.35.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: mediatek: mt8186: Add binding for MM iommu
From: Yong Wu @ 2022-01-25 9:32 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, yong.wu, youlin.pei, anan.sun, xueqi.zhang,
yen-chang.chen, AngeloGioacchino Del Regno, mingyuan.ma, yf.wang,
libo.kang, chengci.xu
In-Reply-To: <20220125093244.18230-1-yong.wu@mediatek.com>
Add mt8186 iommu binding. "-mm" means the iommu is for Multimedia.
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
.../bindings/iommu/mediatek,iommu.yaml | 4 +
.../dt-bindings/memory/mt8186-memory-port.h | 217 ++++++++++++++++++
2 files changed, 221 insertions(+)
create mode 100644 include/dt-bindings/memory/mt8186-memory-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
index c528a299afa9..6cc886eb55af 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml
@@ -76,6 +76,7 @@ properties:
- mediatek,mt8167-m4u # generation two
- mediatek,mt8173-m4u # generation two
- mediatek,mt8183-m4u # generation two
+ - mediatek,mt8186-iommu-mm # generation two
- mediatek,mt8192-m4u # generation two
- mediatek,mt8195-iommu-vdo # generation two
- mediatek,mt8195-iommu-vpp # generation two
@@ -120,6 +121,7 @@ properties:
dt-binding/memory/mt8167-larb-port.h for mt8167,
dt-binding/memory/mt8173-larb-port.h for mt8173,
dt-binding/memory/mt8183-larb-port.h for mt8183,
+ dt-binding/memory/mt8186-memory-port.h for mt8186,
dt-binding/memory/mt8192-larb-port.h for mt8192.
dt-binding/memory/mt8195-memory-port.h for mt8195.
@@ -141,6 +143,7 @@ allOf:
- mediatek,mt2701-m4u
- mediatek,mt2712-m4u
- mediatek,mt8173-m4u
+ - mediatek,mt8186-iommu-mm
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
@@ -153,6 +156,7 @@ allOf:
properties:
compatible:
enum:
+ - mediatek,mt8186-iommu-mm
- mediatek,mt8192-m4u
- mediatek,mt8195-iommu-vdo
- mediatek,mt8195-iommu-vpp
diff --git a/include/dt-bindings/memory/mt8186-memory-port.h b/include/dt-bindings/memory/mt8186-memory-port.h
new file mode 100644
index 000000000000..bda265725870
--- /dev/null
+++ b/include/dt-bindings/memory/mt8186-memory-port.h
@@ -0,0 +1,217 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2022 MediaTek Inc.
+ *
+ * Author: Anan Sun <anan.sun@mediatek.com>
+ * Author: Yong Wu <yong.wu@mediatek.com>
+ */
+#ifndef _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_
+#define _DT_BINDINGS_MEMORY_MT8186_LARB_PORT_H_
+
+#include <dt-bindings/memory/mtk-memory-port.h>
+
+/*
+ * MM IOMMU supports 16GB dma address. We separate it to four ranges:
+ * 0 ~ 4G; 4G ~ 8G; 8G ~ 12G; 12G ~ 16G, we could adjust these masters
+ * locate in anyone bank. BUT:
+ * a) Make sure all the ports inside a larb are in one range.
+ * b) The iova of any master can NOT cross the 4G/8G/12G boundary.
+ *
+ * This is the suggested mapping in this SoC:
+ *
+ * modules dma-address-region larbs-ports
+ * disp 0 ~ 4G larb0/1/2
+ * vcodec 4G ~ 8G larb4/7
+ * cam/mdp 8G ~ 12G the other larbs.
+ * N/A 12G ~ 16G
+ * CCU0 0x24000_0000 ~ 0x243ff_ffff larb13: port 9/10
+ * CCU1 0x24400_0000 ~ 0x247ff_ffff larb14: port 4/5
+ */
+
+/* MM IOMMU ports */
+/* LARB 0 -- MMSYS */
+#define IOMMU_PORT_L0_DISP_POSTMASK0 MTK_M4U_ID(0, 0)
+#define IOMMU_PORT_L0_REVERSED MTK_M4U_ID(0, 1)
+#define IOMMU_PORT_L0_OVL_RDMA0 MTK_M4U_ID(0, 2)
+#define IOMMU_PORT_L0_DISP_FAKE0 MTK_M4U_ID(0, 3)
+
+/* LARB 1 -- MMSYS */
+#define IOMMU_PORT_L1_DISP_RDMA1 MTK_M4U_ID(1, 0)
+#define IOMMU_PORT_L1_OVL_2L_RDMA0 MTK_M4U_ID(1, 1)
+#define IOMMU_PORT_L1_DISP_RDMA0 MTK_M4U_ID(1, 2)
+#define IOMMU_PORT_L1_DISP_WDMA0 MTK_M4U_ID(1, 3)
+#define IOMMU_PORT_L1_DISP_FAKE1 MTK_M4U_ID(1, 4)
+
+/* LARB 2 -- MMSYS */
+#define IOMMU_PORT_L2_MDP_RDMA0 MTK_M4U_ID(2, 0)
+#define IOMMU_PORT_L2_MDP_RDMA1 MTK_M4U_ID(2, 1)
+#define IOMMU_PORT_L2_MDP_WROT0 MTK_M4U_ID(2, 2)
+#define IOMMU_PORT_L2_MDP_WROT1 MTK_M4U_ID(2, 3)
+#define IOMMU_PORT_L2_DISP_FAKE0 MTK_M4U_ID(2, 4)
+
+/* LARB 4 -- VDEC */
+#define IOMMU_PORT_L4_HW_VDEC_MC_EXT MTK_M4U_ID(4, 0)
+#define IOMMU_PORT_L4_HW_VDEC_UFO_EXT MTK_M4U_ID(4, 1)
+#define IOMMU_PORT_L4_HW_VDEC_PP_EXT MTK_M4U_ID(4, 2)
+#define IOMMU_PORT_L4_HW_VDEC_PRED_RD_EXT MTK_M4U_ID(4, 3)
+#define IOMMU_PORT_L4_HW_VDEC_PRED_WR_EXT MTK_M4U_ID(4, 4)
+#define IOMMU_PORT_L4_HW_VDEC_PPWRAP_EXT MTK_M4U_ID(4, 5)
+#define IOMMU_PORT_L4_HW_VDEC_TILE_EXT MTK_M4U_ID(4, 6)
+#define IOMMU_PORT_L4_HW_VDEC_VLD_EXT MTK_M4U_ID(4, 7)
+#define IOMMU_PORT_L4_HW_VDEC_VLD2_EXT MTK_M4U_ID(4, 8)
+#define IOMMU_PORT_L4_HW_VDEC_AVC_MV_EXT MTK_M4U_ID(4, 9)
+#define IOMMU_PORT_L4_HW_VDEC_UFO_ENC_EXT MTK_M4U_ID(4, 10)
+#define IOMMU_PORT_L4_HW_VDEC_RG_CTRL_DMA_EXT MTK_M4U_ID(4, 11)
+#define IOMMU_PORT_L4_HW_MINI_MDP_R0_EXT MTK_M4U_ID(4, 12)
+#define IOMMU_PORT_L4_HW_MINI_MDP_W0_EXT MTK_M4U_ID(4, 13)
+
+/* LARB 7 -- VENC */
+#define IOMMU_PORT_L7_VENC_RCPU MTK_M4U_ID(7, 0)
+#define IOMMU_PORT_L7_VENC_REC MTK_M4U_ID(7, 1)
+#define IOMMU_PORT_L7_VENC_BSDMA MTK_M4U_ID(7, 2)
+#define IOMMU_PORT_L7_VENC_SV_COMV MTK_M4U_ID(7, 3)
+#define IOMMU_PORT_L7_VENC_RD_COMV MTK_M4U_ID(7, 4)
+#define IOMMU_PORT_L7_VENC_CUR_LUMA MTK_M4U_ID(7, 5)
+#define IOMMU_PORT_L7_VENC_CUR_CHROMA MTK_M4U_ID(7, 6)
+#define IOMMU_PORT_L7_VENC_REF_LUMA MTK_M4U_ID(7, 7)
+#define IOMMU_PORT_L7_VENC_REF_CHROMA MTK_M4U_ID(7, 8)
+#define IOMMU_PORT_L7_JPGENC_Y_RDMA MTK_M4U_ID(7, 9)
+#define IOMMU_PORT_L7_JPGENC_C_RDMA MTK_M4U_ID(7, 10)
+#define IOMMU_PORT_L7_JPGENC_Q_TABLE MTK_M4U_ID(7, 11)
+#define IOMMU_PORT_L7_JPGENC_BSDMA MTK_M4U_ID(7, 12)
+
+/* LARB 8 -- WPE */
+#define IOMMU_PORT_L8_WPE_RDMA_0 MTK_M4U_ID(8, 0)
+#define IOMMU_PORT_L8_WPE_RDMA_1 MTK_M4U_ID(8, 1)
+#define IOMMU_PORT_L8_WPE_WDMA_0 MTK_M4U_ID(8, 2)
+
+/* LARB 9 -- IMG-1 */
+#define IOMMU_PORT_L9_IMG_IMGI_D1 MTK_M4U_ID(9, 0)
+#define IOMMU_PORT_L9_IMG_IMGBI_D1 MTK_M4U_ID(9, 1)
+#define IOMMU_PORT_L9_IMG_DMGI_D1 MTK_M4U_ID(9, 2)
+#define IOMMU_PORT_L9_IMG_DEPI_D1 MTK_M4U_ID(9, 3)
+#define IOMMU_PORT_L9_IMG_LCE_D1 MTK_M4U_ID(9, 4)
+#define IOMMU_PORT_L9_IMG_SMTI_D1 MTK_M4U_ID(9, 5)
+#define IOMMU_PORT_L9_IMG_SMTO_D2 MTK_M4U_ID(9, 6)
+#define IOMMU_PORT_L9_IMG_SMTO_D1 MTK_M4U_ID(9, 7)
+#define IOMMU_PORT_L9_IMG_CRZO_D1 MTK_M4U_ID(9, 8)
+#define IOMMU_PORT_L9_IMG_IMG3O_D1 MTK_M4U_ID(9, 9)
+#define IOMMU_PORT_L9_IMG_VIPI_D1 MTK_M4U_ID(9, 10)
+#define IOMMU_PORT_L9_IMG_SMTI_D5 MTK_M4U_ID(9, 11)
+#define IOMMU_PORT_L9_IMG_TIMGO_D1 MTK_M4U_ID(9, 12)
+#define IOMMU_PORT_L9_IMG_UFBC_W0 MTK_M4U_ID(9, 13)
+#define IOMMU_PORT_L9_IMG_UFBC_R0 MTK_M4U_ID(9, 14)
+#define IOMMU_PORT_L9_IMG_WPE_RDMA1 MTK_M4U_ID(9, 15)
+#define IOMMU_PORT_L9_IMG_WPE_RDMA0 MTK_M4U_ID(9, 16)
+#define IOMMU_PORT_L9_IMG_WPE_WDMA MTK_M4U_ID(9, 17)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA0 MTK_M4U_ID(9, 18)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA1 MTK_M4U_ID(9, 19)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA2 MTK_M4U_ID(9, 20)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA3 MTK_M4U_ID(9, 21)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA4 MTK_M4U_ID(9, 22)
+#define IOMMU_PORT_L9_IMG_MFB_RDMA5 MTK_M4U_ID(9, 23)
+#define IOMMU_PORT_L9_IMG_MFB_WDMA0 MTK_M4U_ID(9, 24)
+#define IOMMU_PORT_L9_IMG_MFB_WDMA1 MTK_M4U_ID(9, 25)
+#define IOMMU_PORT_L9_IMG_RESERVE6 MTK_M4U_ID(9, 26)
+#define IOMMU_PORT_L9_IMG_RESERVE7 MTK_M4U_ID(9, 27)
+#define IOMMU_PORT_L9_IMG_RESERVE8 MTK_M4U_ID(9, 28)
+
+/* LARB 11 -- IMG-2 */
+#define IOMMU_PORT_L11_IMG_IMGI_D1 MTK_M4U_ID(11, 0)
+#define IOMMU_PORT_L11_IMG_IMGBI_D1 MTK_M4U_ID(11, 1)
+#define IOMMU_PORT_L11_IMG_DMGI_D1 MTK_M4U_ID(11, 2)
+#define IOMMU_PORT_L11_IMG_DEPI_D1 MTK_M4U_ID(11, 3)
+#define IOMMU_PORT_L11_IMG_LCE_D1 MTK_M4U_ID(11, 4)
+#define IOMMU_PORT_L11_IMG_SMTI_D1 MTK_M4U_ID(11, 5)
+#define IOMMU_PORT_L11_IMG_SMTO_D2 MTK_M4U_ID(11, 6)
+#define IOMMU_PORT_L11_IMG_SMTO_D1 MTK_M4U_ID(11, 7)
+#define IOMMU_PORT_L11_IMG_CRZO_D1 MTK_M4U_ID(11, 8)
+#define IOMMU_PORT_L11_IMG_IMG3O_D1 MTK_M4U_ID(11, 9)
+#define IOMMU_PORT_L11_IMG_VIPI_D1 MTK_M4U_ID(11, 10)
+#define IOMMU_PORT_L11_IMG_SMTI_D5 MTK_M4U_ID(11, 11)
+#define IOMMU_PORT_L11_IMG_TIMGO_D1 MTK_M4U_ID(11, 12)
+#define IOMMU_PORT_L11_IMG_UFBC_W0 MTK_M4U_ID(11, 13)
+#define IOMMU_PORT_L11_IMG_UFBC_R0 MTK_M4U_ID(11, 14)
+#define IOMMU_PORT_L11_IMG_WPE_RDMA1 MTK_M4U_ID(11, 15)
+#define IOMMU_PORT_L11_IMG_WPE_RDMA0 MTK_M4U_ID(11, 16)
+#define IOMMU_PORT_L11_IMG_WPE_WDMA MTK_M4U_ID(11, 17)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA0 MTK_M4U_ID(11, 18)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA1 MTK_M4U_ID(11, 19)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA2 MTK_M4U_ID(11, 20)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA3 MTK_M4U_ID(11, 21)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA4 MTK_M4U_ID(11, 22)
+#define IOMMU_PORT_L11_IMG_MFB_RDMA5 MTK_M4U_ID(11, 23)
+#define IOMMU_PORT_L11_IMG_MFB_WDMA0 MTK_M4U_ID(11, 24)
+#define IOMMU_PORT_L11_IMG_MFB_WDMA1 MTK_M4U_ID(11, 25)
+#define IOMMU_PORT_L11_IMG_RESERVE6 MTK_M4U_ID(11, 26)
+#define IOMMU_PORT_L11_IMG_RESERVE7 MTK_M4U_ID(11, 27)
+#define IOMMU_PORT_L11_IMG_RESERVE8 MTK_M4U_ID(11, 28)
+
+/* LARB 13 -- CAM */
+#define IOMMU_PORT_L13_CAM_MRAWI MTK_M4U_ID(13, 0)
+#define IOMMU_PORT_L13_CAM_MRAWO_0 MTK_M4U_ID(13, 1)
+#define IOMMU_PORT_L13_CAM_MRAWO_1 MTK_M4U_ID(13, 2)
+#define IOMMU_PORT_L13_CAM_CAMSV_4 MTK_M4U_ID(13, 6)
+#define IOMMU_PORT_L13_CAM_CAMSV_5 MTK_M4U_ID(13, 7)
+#define IOMMU_PORT_L13_CAM_CAMSV_6 MTK_M4U_ID(13, 8)
+#define IOMMU_PORT_L13_CAM_CCUI MTK_M4U_ID(13, 9)
+#define IOMMU_PORT_L13_CAM_CCUO MTK_M4U_ID(13, 10)
+#define IOMMU_PORT_L13_CAM_FAKE MTK_M4U_ID(13, 11)
+
+/* LARB 14 -- CAM */
+#define IOMMU_PORT_L14_CAM_CCUI MTK_M4U_ID(14, 4)
+#define IOMMU_PORT_L14_CAM_CCUO MTK_M4U_ID(14, 5)
+
+/* LARB 16 -- RAW-A */
+#define IOMMU_PORT_L16_CAM_IMGO_R1_A MTK_M4U_ID(16, 0)
+#define IOMMU_PORT_L16_CAM_RRZO_R1_A MTK_M4U_ID(16, 1)
+#define IOMMU_PORT_L16_CAM_CQI_R1_A MTK_M4U_ID(16, 2)
+#define IOMMU_PORT_L16_CAM_BPCI_R1_A MTK_M4U_ID(16, 3)
+#define IOMMU_PORT_L16_CAM_YUVO_R1_A MTK_M4U_ID(16, 4)
+#define IOMMU_PORT_L16_CAM_UFDI_R2_A MTK_M4U_ID(16, 5)
+#define IOMMU_PORT_L16_CAM_RAWI_R2_A MTK_M4U_ID(16, 6)
+#define IOMMU_PORT_L16_CAM_RAWI_R3_A MTK_M4U_ID(16, 7)
+#define IOMMU_PORT_L16_CAM_AAO_R1_A MTK_M4U_ID(16, 8)
+#define IOMMU_PORT_L16_CAM_AFO_R1_A MTK_M4U_ID(16, 9)
+#define IOMMU_PORT_L16_CAM_FLKO_R1_A MTK_M4U_ID(16, 10)
+#define IOMMU_PORT_L16_CAM_LCESO_R1_A MTK_M4U_ID(16, 11)
+#define IOMMU_PORT_L16_CAM_CRZO_R1_A MTK_M4U_ID(16, 12)
+#define IOMMU_PORT_L16_CAM_LTMSO_R1_A MTK_M4U_ID(16, 13)
+#define IOMMU_PORT_L16_CAM_RSSO_R1_A MTK_M4U_ID(16, 14)
+#define IOMMU_PORT_L16_CAM_AAHO_R1_A MTK_M4U_ID(16, 15)
+#define IOMMU_PORT_L16_CAM_LSCI_R1_A MTK_M4U_ID(16, 16)
+
+/* LARB 17 -- RAW-B */
+#define IOMMU_PORT_L17_CAM_IMGO_R1_B MTK_M4U_ID(17, 0)
+#define IOMMU_PORT_L17_CAM_RRZO_R1_B MTK_M4U_ID(17, 1)
+#define IOMMU_PORT_L17_CAM_CQI_R1_B MTK_M4U_ID(17, 2)
+#define IOMMU_PORT_L17_CAM_BPCI_R1_B MTK_M4U_ID(17, 3)
+#define IOMMU_PORT_L17_CAM_YUVO_R1_B MTK_M4U_ID(17, 4)
+#define IOMMU_PORT_L17_CAM_UFDI_R2_B MTK_M4U_ID(17, 5)
+#define IOMMU_PORT_L17_CAM_RAWI_R2_B MTK_M4U_ID(17, 6)
+#define IOMMU_PORT_L17_CAM_RAWI_R3_B MTK_M4U_ID(17, 7)
+#define IOMMU_PORT_L17_CAM_AAO_R1_B MTK_M4U_ID(17, 8)
+#define IOMMU_PORT_L17_CAM_AFO_R1_B MTK_M4U_ID(17, 9)
+#define IOMMU_PORT_L17_CAM_FLKO_R1_B MTK_M4U_ID(17, 10)
+#define IOMMU_PORT_L17_CAM_LCESO_R1_B MTK_M4U_ID(17, 11)
+#define IOMMU_PORT_L17_CAM_CRZO_R1_B MTK_M4U_ID(17, 12)
+#define IOMMU_PORT_L17_CAM_LTMSO_R1_B MTK_M4U_ID(17, 13)
+#define IOMMU_PORT_L17_CAM_RSSO_R1_B MTK_M4U_ID(17, 14)
+#define IOMMU_PORT_L17_CAM_AAHO_R1_B MTK_M4U_ID(17, 15)
+#define IOMMU_PORT_L17_CAM_LSCI_R1_B MTK_M4U_ID(17, 16)
+
+/* LARB 19 -- IPE */
+#define IOMMU_PORT_L19_IPE_DVS_RDMA MTK_M4U_ID(19, 0)
+#define IOMMU_PORT_L19_IPE_DVS_WDMA MTK_M4U_ID(19, 1)
+#define IOMMU_PORT_L19_IPE_DVP_RDMA MTK_M4U_ID(19, 2)
+#define IOMMU_PORT_L19_IPE_DVP_WDMA MTK_M4U_ID(19, 3)
+
+/* LARB 20 -- IPE */
+#define IOMMU_PORT_L20_IPE_FDVT_RDA MTK_M4U_ID(20, 0)
+#define IOMMU_PORT_L20_IPE_FDVT_RDB MTK_M4U_ID(20, 1)
+#define IOMMU_PORT_L20_IPE_FDVT_WRA MTK_M4U_ID(20, 2)
+#define IOMMU_PORT_L20_IPE_FDVT_WRB MTK_M4U_ID(20, 3)
+#define IOMMU_PORT_L20_IPE_RSC_RDMA0 MTK_M4U_ID(20, 4)
+#define IOMMU_PORT_L20_IPE_RSC_WDMA MTK_M4U_ID(20, 5)
+
+#endif
--
2.18.0
^ permalink raw reply related
* [PATCH 2/2] iommu/mediatek: Add mt8186 iommu support
From: Yong Wu @ 2022-01-25 9:32 UTC (permalink / raw)
To: Joerg Roedel, Rob Herring, Matthias Brugger, Will Deacon
Cc: Robin Murphy, Krzysztof Kozlowski, Tomasz Figa, linux-mediatek,
srv_heupstream, devicetree, linux-kernel, linux-arm-kernel, iommu,
Hsin-Yi Wang, yong.wu, youlin.pei, anan.sun, xueqi.zhang,
yen-chang.chen, AngeloGioacchino Del Regno, mingyuan.ma, yf.wang,
libo.kang, chengci.xu
In-Reply-To: <20220125093244.18230-1-yong.wu@mediatek.com>
Add mt8186 iommu supports.
Signed-off-by: Anan Sun <anan.sun@mediatek.com>
Signed-off-by: Yong Wu <yong.wu@mediatek.com>
---
drivers/iommu/mtk_iommu.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index be36e73e4bcc..a3124f48f9e1 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -160,6 +160,7 @@ enum mtk_iommu_plat {
M4U_MT8167,
M4U_MT8173,
M4U_MT8183,
+ M4U_MT8186,
M4U_MT8192,
M4U_MT8195,
};
@@ -1401,6 +1402,21 @@ static const struct mtk_iommu_plat_data mt8183_data = {
.larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
};
+static const struct mtk_iommu_plat_data mt8186_data_mm = {
+ .m4u_plat = M4U_MT8186,
+ .flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
+ WR_THROT_EN | IOVA_34_EN | NOT_STD_AXI_MODE |
+ MTK_IOMMU_TYPE_MM,
+ .larbid_remap = {{0}, {1, MTK_INVALID_LARBID, 8}, {4}, {7}, {2}, {9, 11, 19, 20},
+ {MTK_INVALID_LARBID, 14, 16},
+ {MTK_INVALID_LARBID, 13, MTK_INVALID_LARBID, 17}},
+ .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
+ .banks_num = 1,
+ .banks_enable = {true},
+ .iova_region = mt8192_multi_dom,
+ .iova_region_nr = ARRAY_SIZE(mt8192_multi_dom),
+};
+
static const struct mtk_iommu_plat_data mt8192_data = {
.m4u_plat = M4U_MT8192,
.flags = HAS_BCLK | HAS_SUB_COMM_2BITS | OUT_ORDER_WR_EN |
@@ -1470,6 +1486,7 @@ static const struct of_device_id mtk_iommu_of_ids[] = {
{ .compatible = "mediatek,mt8167-m4u", .data = &mt8167_data},
{ .compatible = "mediatek,mt8173-m4u", .data = &mt8173_data},
{ .compatible = "mediatek,mt8183-m4u", .data = &mt8183_data},
+ { .compatible = "mediatek,mt8186-iommu-mm", .data = &mt8186_data_mm},
{ .compatible = "mediatek,mt8192-m4u", .data = &mt8192_data},
{ .compatible = "mediatek,mt8195-iommu-infra", .data = &mt8195_data_infra},
{ .compatible = "mediatek,mt8195-iommu-vdo", .data = &mt8195_data_vdo},
--
2.18.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox