* [PATCH v3 11/11] iio: dac: add mcf54415 DAC
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add basic version of mcf54415 DAC driver. DAC is embedded in the cpu and
DAC configuration registers are mapped in the internal IO address space.
The DAC accepts a 12-bit digital signal and creates a monotonic 12-bit
analog output varying from DAC_VREFL to DAC_VREFH. The DAC module
consists of a conversion unit, an output amplifier, and the associated
digital control blocks. Default register values for DAC_VREFL and DAC_VREFH
are respectively 0 and 0xfff, left untouched in this initial version.
This initial version of the driver is minimalistic, "output raw" only, to
be extended in the future. DMA and external sync are disabled, default mode
is high speed, default format is right-justified 12bit on 16bit word.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- remove tests from commit message, moved to patch 0
- remove additional blank lines
- remove dead code and unused definitions
- use regmap
- add limit check on raw write
- non functional style fixes
- add COMPILE_TEST to Kconfig
Changes in v3:
- add comments where needed
- code style changes
- remove unneeded variables
- use regmap_set_bits where possible
- remove macro not needed to define a single channel
- set up regmap to big_endian accesses for next patches that will come,
that will adjust ColdFire readx/writex as standard LE (links in 0/x).
- add return value check on regmap calls
- sashiko: remove unneeded .io_port from regmap init.
- sashiko: add select REGMAP_MMIO in Kconfig
---
drivers/iio/dac/Kconfig | 11 +++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 207 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index cd4870b65415..b1a578076188 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -516,6 +516,17 @@ config MAX5821
Say yes here to build support for Maxim MAX5821
10 bits DAC.
+config MCF54415_DAC
+ tristate "NXP MCF54415 DAC driver"
+ depends on M5441x || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Say yes here to build support for NXP MCF54415
+ 12bit DAC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called mcf54415_dac.
+
config MCP4725
tristate "MCP4725/6 DAC driver"
depends on I2C
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 2a80bbf4e80a..1cb93e83d0eb 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_MAX517) += max517.o
obj-$(CONFIG_MAX22007) += max22007.o
obj-$(CONFIG_MAX5522) += max5522.o
obj-$(CONFIG_MAX5821) += max5821.o
+obj-$(CONFIG_MCF54415_DAC) += mcf54415_dac.o
obj-$(CONFIG_MCP4725) += mcp4725.o
obj-$(CONFIG_MCP4728) += mcp4728.o
obj-$(CONFIG_MCP47FEB02) += mcp47feb02.o
diff --git a/drivers/iio/dac/mcf54415_dac.c b/drivers/iio/dac/mcf54415_dac.c
new file mode 100644
index 000000000000..c8c87572d43d
--- /dev/null
+++ b/drivers/iio/dac/mcf54415_dac.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * NXP mcf54415 DAC driver
+ *
+ * Copyright 2026 BayLibre - adureghello@baylibre.com
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/clk.h>
+#include <linux/compiler_types.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <linux/iio/iio.h>
+
+#define MCF54415_DAC_CR 0x00
+#define MCF54415_DAC_CR_PDN BIT(0)
+#define MCF54415_DAC_CR_HSLS BIT(6)
+#define MCF54415_DAC_CR_WMLVL GENMASK(9, 8)
+#define MCF54415_DAC_CR_FILT BIT(12)
+
+#define MCF54415_DAC_DATA 0x02
+
+struct mcf54415_dac {
+ struct regmap *map;
+ struct clk *clk;
+};
+
+static const struct regmap_config mcf54415_dac_regmap_config = {
+ .reg_bits = 16,
+ .reg_stride = 2,
+ .val_bits = 16,
+ .max_register = 0x0c, /* DACX_FILTCNT, R.M. Table 30-2 */
+ .val_format_endian = REGMAP_ENDIAN_BIG,
+ .reg_format_endian = REGMAP_ENDIAN_BIG,
+};
+
+static int mcf54415_dac_init(struct mcf54415_dac *info)
+{
+ int ret;
+
+ /* Keeping defaults and enable DAC (bit 0 set to 0) */
+ ret = regmap_write(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_FILT |
+ FIELD_PREP(MCF54415_DAC_CR_WMLVL, 1));
+ if (ret)
+ return ret;
+
+ /* DAC is ready after 12us, from RM table 40-3 */
+ fsleep(12);
+
+ return 0;
+}
+
+static void mcf54415_dac_exit(void *data)
+{
+ struct mcf54415_dac *info = data;
+
+ regmap_set_bits(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_PDN);
+}
+
+static const struct iio_chan_spec mcf54415_dac_iio_channel = {
+ .type = IIO_VOLTAGE,
+ .output = 1,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),
+};
+
+static int mcf54415_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = regmap_read(info->map, MCF54415_DAC_DATA, val);
+ if (ret)
+ return -EIO;
+ *val &= 0xfff;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ /* Reference voltage as per ColdFire datasheet is 3.3V */
+ *val = 3300 /* mV */;
+ *val2 = 12;
+ return IIO_VAL_FRACTIONAL_LOG2;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int mcf54415_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ /* Check based on RM 30.3.2 (DACn_DATA) reg. resolution */
+ if (val < 0 || val > 4095)
+ return -EINVAL;
+ return regmap_write(info->map, MCF54415_DAC_DATA, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static const struct iio_info mcf54415_dac_iio_info = {
+ .read_raw = &mcf54415_read_raw,
+ .write_raw = &mcf54415_write_raw,
+};
+
+static int mcf54415_dac_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct iio_dev *indio_dev;
+ struct mcf54415_dac *info;
+ void __iomem *regs;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+
+ regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(regs))
+ return dev_err_probe(dev, PTR_ERR(regs),
+ "failed to get io regs\n");
+
+ info->map = devm_regmap_init_mmio(dev, regs,
+ &mcf54415_dac_regmap_config);
+ if (IS_ERR(info->map))
+ return PTR_ERR(info->map);
+
+ info->clk = devm_clk_get_enabled(dev, "dac");
+ if (IS_ERR(info->clk))
+ return dev_err_probe(dev, PTR_ERR(info->clk),
+ "failed getting clock\n");
+
+ platform_set_drvdata(pdev, indio_dev);
+
+ indio_dev->name = "mcf54415";
+ indio_dev->info = &mcf54415_dac_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = &mcf54415_dac_iio_channel;
+ indio_dev->num_channels = 1;
+
+ ret = mcf54415_dac_init(info);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev, mcf54415_dac_exit, info);
+ if (ret)
+ return ret;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static int mcf54415_dac_suspend(struct device *dev)
+{
+ struct mcf54415_dac *info = iio_priv(dev_get_drvdata(dev));
+
+ mcf54415_dac_exit(info);
+ clk_disable_unprepare(info->clk);
+
+ return 0;
+}
+
+static int mcf54415_dac_resume(struct device *dev)
+{
+ struct mcf54415_dac *info = iio_priv(dev_get_drvdata(dev));
+ int ret;
+
+ ret = clk_prepare_enable(info->clk);
+ if (ret)
+ return ret;
+
+ mcf54415_dac_init(info);
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(mcf54415_dac_pm_ops,
+ mcf54415_dac_suspend, mcf54415_dac_resume);
+
+static struct platform_driver mcf54415_dac_driver = {
+ .probe = mcf54415_dac_probe,
+ .driver = {
+ .name = "mcf54415_dac",
+ .pm = pm_sleep_ptr(&mcf54415_dac_pm_ops),
+ },
+};
+module_platform_driver(mcf54415_dac_driver);
+
+MODULE_AUTHOR("Angelo Dureghello <angelo@kernel-space.org>");
+MODULE_DESCRIPTION("NXP MCF54415 DAC driver");
+MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v3 08/11] m68k: stmark2: use ioport.h macros for resources
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Change resource declaration using DEFINE_RES_*() macros.
DEFINE_DMA_RES() is for a single dma channel, not a range, so used twice.
Also, some drivers assume IRQ resources are from index 1, so just to stay
uniform, moved IRQ resource at index 1.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- none
Changes in v3:
- moved this patch (cleanup) before adding new resources
- moved IRQ resource to index pos 1
---
arch/m68k/coldfire/stmark2.c | 19 ++++---------------
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index 9263b77bd09a..536252ccb87e 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -62,21 +62,10 @@ static struct fsl_dspi_platform_data dspi_spi0_info = {
};
static struct resource dspi_spi0_resource[] = {
- [0] = {
- .start = MCFDSPI_BASE0,
- .end = MCFDSPI_BASE0 + 0xFF,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = 12,
- .end = 13,
- .flags = IORESOURCE_DMA,
- },
- [2] = {
- .start = MCF_IRQ_DSPI0,
- .end = MCF_IRQ_DSPI0,
- .flags = IORESOURCE_IRQ,
- },
+ DEFINE_RES_MEM(MCFDSPI_BASE0, 0x100),
+ DEFINE_RES_IRQ(MCF_IRQ_DSPI0),
+ DEFINE_RES_DMA(12),
+ DEFINE_RES_DMA(13),
};
static u64 stmark2_dspi_mask = DMA_BIT_MASK(32);
--
2.54.0
^ permalink raw reply related
* [PATCH v3 09/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add mcf5441x DAC platform devices.
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- fix copy-paste error on naming
- use DEFINE_RES()
Changes in v3:
- simplified DACs as single resource entries in place of an array
---
arch/m68k/coldfire/stmark2.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index 536252ccb87e..d3be4b2953fd 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -8,6 +8,7 @@
* for more details.
*/
+#include <linux/ioport.h>
#include <linux/platform_device.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
@@ -83,8 +84,28 @@ static struct platform_device dspi_spi0_device = {
},
};
+static struct resource dac0_resource = DEFINE_RES_MEM(MCFDAC_BASE0, 0x100);
+
+static struct platform_device dac0_device = {
+ .name = "mcf54415_dac",
+ .id = 0,
+ .num_resources = 1,
+ .resource = &dac0_resource,
+};
+
+static struct resource dac1_resource = DEFINE_RES_MEM(MCFDAC_BASE1, 0x100);
+
+static struct platform_device dac1_device = {
+ .name = "mcf54415_dac",
+ .id = 1,
+ .num_resources = 1,
+ .resource = &dac1_resource,
+};
+
static struct platform_device *stmark2_devices[] __initdata = {
&dspi_spi0_device,
+ &dac0_device,
+ &dac1_device,
};
/*
--
2.54.0
^ permalink raw reply related
* [PATCH v3 10/11] m68k: stmark2: enable DACs outputs
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7.
Reviewed-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- using mcf_read16/mcf_write16
- remove unuseful comment
---
arch/m68k/coldfire/stmark2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index d3be4b2953fd..8aa9286e85d2 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -113,6 +113,8 @@ static struct platform_device *stmark2_devices[] __initdata = {
*/
static int __init init_stmark2(void)
{
+ u16 val;
+
/* DSPI0, all pins as DSPI, and using CS1 */
mcf_write8(0x80, MCFGPIO_PAR_DSPIOWL);
mcf_write8(0xfc, MCFGPIO_PAR_DSPIOWH);
@@ -125,6 +127,11 @@ static int __init init_stmark2(void)
/* CAN pads */
mcf_write8(0x50, MCFGPIO_PAR_CANI2C);
+ val = mcf_read16(MCF_CCM_MISCCR2);
+ val &= ~(MCF_CCM_MISCCR2_ADC3_EN | MCF_CCM_MISCCR2_ADC7_EN);
+ val |= MCF_CCM_MISCCR2_DAC0_SEL | MCF_CCM_MISCCR2_DAC1_SEL;
+ mcf_write16(val, MCF_CCM_MISCCR2);
+
platform_add_devices(stmark2_devices, ARRAY_SIZE(stmark2_devices));
spi_register_board_info(stmark2_board_info,
--
2.54.0
^ permalink raw reply related
* [PATCH v3 04/11] m68k: defconfig: update stmark2 defconfig
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Update stmark2 defconfig enabling MCF5441X DACs.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/configs/stmark2_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/m68k/configs/stmark2_defconfig b/arch/m68k/configs/stmark2_defconfig
index b3fb95f73a95..3941113bc60b 100644
--- a/arch/m68k/configs/stmark2_defconfig
+++ b/arch/m68k/configs/stmark2_defconfig
@@ -76,6 +76,8 @@ CONFIG_DMADEVICES=y
CONFIG_MCF_EDMA=y
# CONFIG_VIRTIO_MENU is not set
# CONFIG_VHOST_MENU is not set
+CONFIG_IIO=y
+CONFIG_MCF54415_DAC=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.54.0
^ permalink raw reply related
* [PATCH v3 06/11] m68k: mcf5441x: add CCM registers
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add CCM module register offsets.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/include/asm/m5441xsim.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index f5acc962bb95..9ce2cbb05316 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -125,6 +125,26 @@
#define MCFPM_PPMHR1 0xfc040038
#define MCFPM_PPMLR1 0xfc04003c
#define MCFPM_LPCR 0xec090007
+
+/*
+ * Chip Configuration Module (CCM).
+ */
+#define MCF_CCM_CCR 0xec090004
+#define MCF_CCM_RCON 0xec090008
+#define MCF_CCM_CIR 0xec09000a
+#define MCF_CCM_MISCCR 0xec09000e
+#define MCF_CCM_CDRH 0xec090010
+#define MCF_CCM_CDRL 0xec090012
+#define MCF_CCM_UOCSR 0xec090014
+#define MCF_CCM_UHCSR 0xec090016
+#define MCF_CCM_MISCCR3 0xec090018
+#define MCF_CCM_MISCCR2 0xec09001a
+#define MCF_CCM_ADCTSR 0xec09001c
+#define MCF_CCM_DACTSR 0xec09001e
+#define MCF_CCM_SBFSR 0xec090020
+#define MCF_CCM_SBFCR 0xec090022
+#define MCF_CCM_FNACR 0xec090024
+
/*
* UART module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v3 05/11] m68k: add DAC modules base addresses
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add DAC controller 0 and 1 base addresses.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/include/asm/m5441xsim.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index f48cf63bd782..f5acc962bb95 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -191,6 +191,11 @@
#define MCFEPORT_EPPAR 0xfc090000
#define MCFEPORT_EPIER 0xfc090003
#define MCFEPORT_EPFR 0xfc090006
+/*
+ * DAC Modules.
+ */
+#define MCFDAC_BASE0 0xfc098000
+#define MCFDAC_BASE1 0xfc09c000
/*
* RTC Module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v3 07/11] m68k: mcf5441x: add CCR MISCCR2 bitfields
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add CCR MISCCR2 register bitfields.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- add "iwyu" include for BIT and GENMASK
- fix MCF_CCM_MISCCR2_PLL_MODE bitfield
---
arch/m68k/include/asm/m5441xsim.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/m68k/include/asm/m5441xsim.h b/arch/m68k/include/asm/m5441xsim.h
index 9ce2cbb05316..ea01c7753b7b 100644
--- a/arch/m68k/include/asm/m5441xsim.h
+++ b/arch/m68k/include/asm/m5441xsim.h
@@ -8,6 +8,8 @@
#ifndef m5441xsim_h
#define m5441xsim_h
+#include <linux/bits.h>
+
#define CPU_NAME "COLDFIRE(m5441x)"
#define CPU_INSTR_PER_JIFFY 2
#define MCF_BUSCLK (MCF_CLK / 2)
@@ -145,6 +147,21 @@
#define MCF_CCM_SBFCR 0xec090022
#define MCF_CCM_FNACR 0xec090024
+/* Bit definitions and macros for MCF_CCM_MISCCR2 */
+#define MCF_CCM_MISCCR2_ULPI BIT(0)
+#define MCF_CCM_MISCCR2_FB_HALF BIT(1)
+#define MCF_CCM_MISCCR2_ADC3_EN BIT(2)
+#define MCF_CCM_MISCCR2_ADC7_EN BIT(3)
+#define MCF_CCM_MISCCR2_ADC_EN BIT(4)
+#define MCF_CCM_MISCCR2_DAC0_SEL BIT(5)
+#define MCF_CCM_MISCCR2_DAC1_SEL BIT(6)
+#define MCF_CCM_MISCCR2_DCC_BYP BIT(7)
+#define MCF_CCM_MISCCR2_PLL_MODE GENMASK(10, 8)
+#define MCF_CCM_MISCCR2_SWT_SCR BIT(12)
+#define MCF_CCM_MISCCR2_RGPIO_HALF BIT(13)
+#define MCF_CCM_MISCCR2_DDR2_CLK BIT(14)
+#define MCF_CCM_MISCCR2_EXTCLK_BYP BIT(15)
+
/*
* UART module.
*/
--
2.54.0
^ permalink raw reply related
* [PATCH v3 01/11] m68k: mcf5441x: fix clocks numbering
From: Angelo Dureghello @ 2026-05-22 21:20 UTC (permalink / raw)
To: Greg Ungerer, Geert Uytterhoeven, Steven King, Arnd Bergmann,
Maxime Coquelin, Alexandre Torgue, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Greg Ungerer, linux-m68k, linux-kernel, linux-stm32,
linux-arm-kernel, linux-iio, Angelo Dureghello
In-Reply-To: <20260522-wip-stmark2-dac-v3-0-16be0ad35a67@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Fix clocks numbering, set correct values for eport and DAC,
as per RM Rev 5, 05/2018, table 9.5.
Fixes: bea8bcb12da09 ("m68knommu: Add support for the Coldfire m5441x.")
Fixes: 007f84ede6e3e ("m68k: coldfire: remove private clk_get/clk_put")
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 6ce730098ff6..613b0275d9d8 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -41,9 +41,9 @@ DEFINE_CLK(0, "mcfpit.0", 32, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.1", 33, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
-DEFINE_CLK(0, "mcfeport.0", 37, MCF_CLK);
-DEFINE_CLK(0, "mcfadc.0", 38, MCF_CLK);
-DEFINE_CLK(0, "mcfdac.0", 39, MCF_CLK);
+DEFINE_CLK(0, "mcfeport.0", 36, MCF_CLK);
+DEFINE_CLK(0, "mcfadc.0", 37, MCF_CLK);
+DEFINE_CLK(0, "mcfdac.0", 38, MCF_CLK);
DEFINE_CLK(0, "mcfrtc.0", 42, MCF_CLK);
DEFINE_CLK(0, "mcfsim.0", 43, MCF_CLK);
DEFINE_CLK(0, "mcfusb-otg.0", 44, MCF_CLK);
@@ -103,9 +103,9 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfpit.1", NULL, &__clk_0_33),
CLKDEV_INIT("mcfpit.2", NULL, &__clk_0_34),
CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
- CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_37),
- CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_38),
- CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_39),
+ CLKDEV_INIT("mcfeport.0", NULL, &__clk_0_36),
+ CLKDEV_INIT("mcfadc.0", NULL, &__clk_0_37),
+ CLKDEV_INIT("mcfdac.0", NULL, &__clk_0_38),
CLKDEV_INIT("mcfrtc.0", NULL, &__clk_0_42),
CLKDEV_INIT("mcfsim.0", NULL, &__clk_0_43),
CLKDEV_INIT("mcfusb-otg.0", NULL, &__clk_0_44),
@@ -156,7 +156,7 @@ static struct clk * const enable_clks[] __initconst = {
&__clk_0_27, /* uart3 */
&__clk_0_33, /* pit.1 */
- &__clk_0_37, /* eport */
+ &__clk_0_36, /* eport */
&__clk_0_48, /* pll */
&__clk_0_51, /* esdhc */
@@ -174,8 +174,8 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_32, /* pit.0 */
&__clk_0_34, /* pit.2 */
&__clk_0_35, /* pit.3 */
- &__clk_0_38, /* adc */
- &__clk_0_39, /* dac */
+ &__clk_0_37, /* adc */
+ &__clk_0_38, /* dac.0 */
&__clk_0_44, /* usb otg */
&__clk_0_45, /* usb host */
&__clk_0_47, /* ssi.0 */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Randy Dunlap @ 2026-05-22 21:20 UTC (permalink / raw)
To: Stefan Dösinger, linux-kernel
Cc: Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <6270885.lOV4Wx5bFT@strix>
On 5/22/26 12:31 PM, Stefan Dösinger wrote:
> Hi Randy,
>
> Am Freitag, 22. Mai 2026, 20:44:24 Ostafrikanische Zeit schrieben Sie:
>> Does this mean that you will be merging this patch since you merged the
>> original patch?
>
> I am new to the kernel development process, so I don't know what's the
> preferred way. I guess for me it is easier if your patch gets merged as-is.
>
> I can certainly submit a pull request myself though since I made myself the
> maintainer for this thing. Does that go to linux-doc@vger.kernel.org or the
> soc list?
The same way that this commit was merged:
commit 220ae5d36dba
Author: Stefan Dösinger <stefandoesinger@gmail.com>
Date: Tue Jan 27 20:52:08 2026 +0300
ARM: zte: Add zx297520v3 platform support
I guess to the soc list.
--
~Randy
^ permalink raw reply
* [PATCH] ARM: io: avoid KASAN instrumentation of raw halfword I/O
From: Karl Mehltretter @ 2026-05-22 21:20 UTC (permalink / raw)
To: Russell King
Cc: Abbott Liu, Linus Walleij, Ard Biesheuvel, Florian Fainelli,
linux-arm-kernel, linux-kernel, stable, Karl Mehltretter
Commit 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") made KASAN
instrument ARM C memory accesses. For CPUs before ARMv6, __raw_readw()
and __raw_writew() are C volatile halfword accesses, so KASAN instruments
them as normal memory accesses.
That is not valid for MMIO. On the QEMU versatilepb machine with an
ARM926EJ-S CPU and CONFIG_KASAN=y, PL011 probing traps while registering
the UART:
Unable to handle kernel paging request at virtual address bd23e207
PC is at __asan_store2+0x2c/0x9c
LR is at pl011_register_port+0x4c/0x19c
Keep the existing volatile halfword access, but move the pre-ARMv6
definitions into __no_kasan_or_inline functions so raw MMIO halfword
accesses are not instrumented by KASAN. The ARMv6-and-newer inline
assembly path is unchanged.
Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM")
Cc: stable@vger.kernel.org # v5.11+
Assisted-by: Codex:gpt-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
arch/arm/include/asm/io.h | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index bae5edf348ef..e6bd9e79737c 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -56,8 +56,19 @@ void __raw_readsl(const volatile void __iomem *addr, void *data, int longlen);
* the bus. Rather than special-case the machine, just let the compiler
* generate the access for CPUs prior to ARMv6.
*/
-#define __raw_readw(a) (__chk_io_ptr(a), *(volatile unsigned short __force *)(a))
-#define __raw_writew(v,a) ((void)(__chk_io_ptr(a), *(volatile unsigned short __force *)(a) = (v)))
+#define __raw_writew __raw_writew
+static __no_kasan_or_inline void __raw_writew(u16 val, volatile void __iomem *addr)
+{
+ __chk_io_ptr(addr);
+ *(volatile unsigned short __force *)addr = val;
+}
+
+#define __raw_readw __raw_readw
+static __no_kasan_or_inline u16 __raw_readw(const volatile void __iomem *addr)
+{
+ __chk_io_ptr(addr);
+ return *(const volatile unsigned short __force *)addr;
+}
#else
/*
* When running under a hypervisor, we want to avoid I/O accesses with
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH] ARM: entry: use byte load for KASAN VMAP stack shadow
From: Karl Mehltretter @ 2026-05-22 21:15 UTC (permalink / raw)
To: Russell King
Cc: Linus Walleij, Russell King (Oracle), linux-arm-kernel,
linux-kernel, stable, Karl Mehltretter
Commit 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from
VMAP shadow") added a dummy read from the KASAN VMAP stack shadow in
__switch_to(). The read uses ldr, but KASAN shadow memory is
byte-granular and the computed shadow address is not guaranteed to be
word aligned.
Booting the QEMU versatilepb machine with an ARM926EJ-S CPU and
CONFIG_KASAN=y, CONFIG_KASAN_VMALLOC=y and CONFIG_VMAP_STACK=y faults
before init:
Unhandled fault: alignment exception (0x001) at 0xb91037f6
PC is at __switch_to+0x64/0x88
Use ldrb for the dummy shadow access. The code only needs to fault if
the shadow mapping is missing, so a byte load is sufficient and matches
the granularity of KASAN shadow memory.
Fixes: 44e9a3bb76e5 ("ARM: 9430/1: entry: Do a dummy read from VMAP shadow")
Cc: stable@vger.kernel.org # v6.13+
Assisted-by: Codex:gpt-5
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
---
arch/arm/kernel/entry-armv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index ef6a657c8d13..a3d050ce9b79 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -567,7 +567,7 @@ ENTRY(__switch_to)
@ are using KASAN
mov_l r2, KASAN_SHADOW_OFFSET
add r2, r2, ip, lsr #KASAN_SHADOW_SCALE_SHIFT
- ldr r2, [r2]
+ ldrb r2, [r2]
#endif
#endif
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH v02] mailbox/pcc.c shmem map/unmap in callbacks
From: Adam Young @ 2026-05-22 20:52 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar, Huisong Li
Cc: linux-kernel, linux-hwmon, Rafael J . Wysocki, Len Brown,
linux-acpi, Andi Shyti, Guenter Roeck, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, linux-arm-kernel
The mailbox IRQ and shmems are not cleaned up atomically, so there is a
race condition. If the shmem is torn down while the IRQ is active, a late
interrupt can trigger a write to un-mapped memory.
If the shmem is torn down while the IRQ is active, and another thread
requests the channel again, we can end up with a channel that has had
its shmem unmapped.
By moving the map to start up and the unmap to teardown, we can let
the mailbox mechanism prevent re-entrance into the startup/teardown
functions.
Avoid doubly unmapping the region by removing the unmap in the
direct error handler for the request.
Assisted-by: Codex:gpt-5.4
Fixes: fa362ffafa51 ("mailbox: pcc: Always map the shared memory communication address")
Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
---
Previous Version: https://lore.kernel.org/linux-hwmon/20260515161001.699470-1-admiyo@os.amperecomputing.com/
Changes in this Version:
- Move the initial mapping into the startup callback
- No Double unmap on error during setup
---
drivers/mailbox/pcc.c | 42 ++++++++++++++++++------------------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 636879ae1db7..c5873f9f2b91 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -360,7 +360,6 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
struct pcc_mbox_chan *
pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
{
- struct pcc_mbox_chan *pcc_mchan;
struct pcc_chan_info *pchan;
struct mbox_chan *chan;
int rc;
@@ -375,20 +374,10 @@ pcc_mbox_request_channel(struct mbox_client *cl, int subspace_id)
return ERR_PTR(-EBUSY);
}
- pcc_mchan = &pchan->chan;
- pcc_mchan->shmem = acpi_os_ioremap(pcc_mchan->shmem_base_addr,
- pcc_mchan->shmem_size);
- if (!pcc_mchan->shmem)
- return ERR_PTR(-ENXIO);
-
rc = mbox_bind_client(chan, cl);
- if (rc) {
- iounmap(pcc_mchan->shmem);
- pcc_mchan->shmem = NULL;
+ if (rc)
return ERR_PTR(rc);
- }
-
- return pcc_mchan;
+ return &pchan->chan;
}
EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
@@ -401,18 +390,8 @@ EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
void pcc_mbox_free_channel(struct pcc_mbox_chan *pchan)
{
struct mbox_chan *chan = pchan->mchan;
- struct pcc_chan_info *pchan_info;
- struct pcc_mbox_chan *pcc_mbox_chan;
-
if (!chan || !chan->cl)
return;
- pchan_info = chan->con_priv;
- pcc_mbox_chan = &pchan_info->chan;
- if (pcc_mbox_chan->shmem) {
- iounmap(pcc_mbox_chan->shmem);
- pcc_mbox_chan->shmem = NULL;
- }
-
mbox_free_channel(chan);
}
EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
@@ -462,9 +441,15 @@ static bool pcc_last_tx_done(struct mbox_chan *chan)
static int pcc_startup(struct mbox_chan *chan)
{
struct pcc_chan_info *pchan = chan->con_priv;
+ struct pcc_mbox_chan *pcc_mchan;
unsigned long irqflags;
int rc;
+ pcc_mchan = &pchan->chan;
+ pcc_mchan->shmem = acpi_os_ioremap(pcc_mchan->shmem_base_addr,
+ pcc_mchan->shmem_size);
+ if (pcc_mchan->shmem == NULL)
+ return -ENOMEM;
/*
* Clear and acknowledge any pending interrupts on responder channel
* before enabling the interrupt
@@ -479,6 +464,8 @@ static int pcc_startup(struct mbox_chan *chan)
if (unlikely(rc)) {
dev_err(chan->mbox->dev, "failed to register PCC interrupt %d\n",
pchan->plat_irq);
+ iounmap(pcc_mchan->shmem);
+ pcc_mchan->shmem = NULL;
return rc;
}
}
@@ -488,15 +475,22 @@ static int pcc_startup(struct mbox_chan *chan)
/**
* pcc_shutdown - Called from Mailbox Controller code. Used here
- * to free the interrupt.
+ * to free the interrupt and unmap the shared memory.
* @chan: Pointer to Mailbox channel to shutdown.
*/
static void pcc_shutdown(struct mbox_chan *chan)
{
struct pcc_chan_info *pchan = chan->con_priv;
+ struct pcc_mbox_chan *pcc_mbox_chan;
if (pchan->plat_irq > 0)
devm_free_irq(chan->mbox->dev, pchan->plat_irq, chan);
+
+ pcc_mbox_chan = &pchan->chan;
+ if (pcc_mbox_chan->shmem) {
+ iounmap(pcc_mbox_chan->shmem);
+ pcc_mbox_chan->shmem = NULL;
+ }
}
static const struct mbox_chan_ops pcc_chan_ops = {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] pwm: imx27: Fix variable truncation in .apply()
From: Frank Li @ 2026-05-22 20:44 UTC (permalink / raw)
To: Ronaldo Nunez
Cc: linux-pwm, Uwe Kleine-König, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260522191348.6227-1-rnunez@baylibre.com>
On Fri, May 22, 2026 at 04:13:48PM -0300, Ronaldo Nunez wrote:
> Fix a variable truncation when calculating period in microseconds as
> part of the solution for the ERR051198 in .apply() callback.
>
> Example scenario:
> - Period of 3us (PWMPR = 196 and prescaler = 1)
> - Expected value in tmp: 198000000000 (NSEC_PER_SEC * (196 + 2) * 1)
> - Actual value is 431504384 (truncation to u32)
>
> Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v2:
> - Added example with actual PWMPR/prescaler values per Frank Li's feedback
> - Dropped testing section
> ---
> drivers/pwm/pwm-imx27.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index 3d34cdc4a3a5..c8b801fcb525 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -200,7 +200,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
> static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> const struct pwm_state *state)
> {
> - unsigned long period_cycles, duty_cycles, prescale, period_us, tmp;
> + unsigned long period_cycles, duty_cycles, prescale, period_us;
> struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
> unsigned long long c;
> unsigned long long clkrate;
> @@ -208,6 +208,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> int val;
> int ret;
> u32 cr;
> + u64 tmp;
>
> clkrate = clk_get_rate(imx->clks[PWM_IMX27_PER].clk);
> c = clkrate * state->period;
> @@ -249,6 +250,11 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> val = readl(imx->mmio_base + MX3_PWMPR);
> val = val >= MX3_PWMPR_MAX ? MX3_PWMPR_MAX : val;
> cr = readl(imx->mmio_base + MX3_PWMCR);
> +
> + /*
> + * tmp stores period in nanoseconds. Result fits in u64 since
> + * val <= 0xfffe and prescaler in [1, 0x1000].
> + */
> tmp = NSEC_PER_SEC * (u64)(val + 2) * MX3_PWMCR_PRESCALER_GET(cr);
> tmp = DIV_ROUND_UP_ULL(tmp, clkrate);
> period_us = DIV_ROUND_UP_ULL(tmp, 1000);
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v2 1/2] dmaengine: Add helper dmaengine_prep_submit_slave_single()
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
In-Reply-To: <20260522-dma_prep_submit-v2-0-7a87a5a29525@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Previously, DMA users had to call dmaengine_prep_slave_single() followed by
dmaengine_submit(). Many DMA consumers missed call dmaengine_desc_free()
when dmaengine_submit() returned an error.
Introduce dmaengine_prep_submit_slave_single() to combine preparation and
submission into a single step and ensure the descriptor is freed on
submission failure.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- use api function dmaengine_prep_submit_slave_single()
---
drivers/dma/dmaengine.c | 28 ++++++++++++++++++++++++++++
include/linux/dmaengine.h | 17 +++++++++++++++++
2 files changed, 45 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index ca13cd39330ba..1e25be78a22a5 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1619,6 +1619,34 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx)
}
EXPORT_SYMBOL_GPL(dma_run_dependencies);
+#define dmaengine_prep_submit(chan, cb, cb_param, func, ...) \
+({ struct dma_async_tx_descriptor *tx = \
+ dmaengine_prep_##func(chan, __VA_ARGS__); \
+ dma_cookie_t cookie = -ENOMEM; \
+ \
+ if (tx) { \
+ tx->callback = cb; \
+ tx->callback_param = cb_param; \
+ cookie = dmaengine_submit(tx); \
+ \
+ if (dma_submit_error(cookie)) \
+ dmaengine_desc_free(tx); \
+ } \
+ cookie; \
+})
+
+dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param,
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ return dmaengine_prep_submit(chan, cb, cb_param, slave_single,
+ buf, len, dir, flags);
+}
+EXPORT_SYMBOL_GPL(dmaengine_prep_submit_slave_single);
+
static int __init dma_bus_init(void)
{
int err = dmaengine_init_unmap_pool();
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 99efe2b9b4ea9..0f789fac7e91a 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -990,6 +990,13 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
dir, flags, NULL);
}
+dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param,
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags);
+
/**
* dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
* @chan: The channel to be used for this descriptor
@@ -1575,6 +1582,16 @@ static inline int dma_get_slave_caps(struct dma_chan *chan,
{
return -ENXIO;
}
+
+static inline dma_cookie_t
+dmaengine_prep_submit_slave_single(struct dma_chan *chan,
+ dma_async_tx_callback cb, void *cb_param;
+ dma_addr_t buf, size_t len,
+ enum dma_transfer_direction dir,
+ unsigned long flags);
+{
+ return -ENODEV;
+}
#endif
static inline int dmaengine_desc_set_reuse(struct dma_async_tx_descriptor *tx)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
In-Reply-To: <20260522-dma_prep_submit-v2-0-7a87a5a29525@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Use dmaengine_prep_submit() to simple code. No functional change.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 2a0962a0b4417..c90f72eec8498 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -720,7 +720,6 @@ static void lpi2c_dma_callback(void *data)
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -733,15 +732,11 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit_slave_single(txchan, NULL, NULL,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len,
+ DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -751,15 +746,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] dmaengine: add helper macro dmaengine_prep_submit()
From: Frank.Li @ 2026-05-22 20:13 UTC (permalink / raw)
To: Vinod Koul, Dong Aisheng, Andi Shyti, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dmaengine, linux-kernel, linux-i2c, imx, linux-arm-kernel,
carlos.song, Frank Li
Add helper macro dmaengine_prep_submit() to combine prep and submit to
one call.
Pervious try to use cleanup
https://lore.kernel.org/dmaengine/20251002-dma_chan_free-v1-0-4dbf116c2b19@nxp.com/
It is not simple enough and easy missing retain_and_null_ptr() at success
path.
struct dma_async_tx_descriptor *rx_cmd_desc __free(dma_async_tx_descriptor) = NULL;
...
cookie = dmaengine_submit(rx_cmd_desc);
if (dma_submit_error(cookie))
return dma_submit_error(cookie);
...
retain_and_null_ptr(rx_cmd_desc);
}
So create help macro to combine prep and submit by one call.
patch 2.
static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
{
- struct dma_async_tx_descriptor *rx_cmd_desc;
struct lpi2c_imx_dma *dma = lpi2c_imx->dma;
struct dma_chan *txchan = dma->chan_tx;
dma_cookie_t cookie;
@@ -761,15 +760,10 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return -EINVAL;
}
- rx_cmd_desc = dmaengine_prep_slave_single(txchan, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
- DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
- if (!rx_cmd_desc) {
- dev_err(&lpi2c_imx->adapter.dev, "DMA prep slave sg failed, use pio\n");
- goto desc_prepare_err_exit;
- }
-
- cookie = dmaengine_submit(rx_cmd_desc);
+ cookie = dmaengine_prep_submit(txchan, NULL, NULL, slave_single,
+ dma->dma_tx_addr,
+ dma->rx_cmd_buf_len, DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (dma_submit_error(cookie)) {
dev_err(&lpi2c_imx->adapter.dev, "submitting DMA failed, use pio\n");
goto submit_err_exit;
@@ -779,15 +773,9 @@ static int lpi2c_dma_rx_cmd_submit(struct lpi2c_imx_struct *lpi2c_imx)
return 0;
-desc_prepare_err_exit:
- dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
- dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- return -EINVAL;
-
submit_err_exit:
dma_unmap_single(txchan->device->dev, dma->dma_tx_addr,
dma->rx_cmd_buf_len, DMA_TO_DEVICE);
- dmaengine_desc_free(rx_cmd_desc);
return -EINVAL;
}
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- use API dmaengine_prep_submit_slave_single()
- Link to v1: https://lore.kernel.org/r/20260130-dma_prep_submit-v1-0-2198f9e848fa@nxp.com
---
Frank Li (2):
dmaengine: Add helper dmaengine_prep_submit_slave_single()
i2c: imx-lpi2c: use dmaengine_prep_submit() to simple code
drivers/dma/dmaengine.c | 28 ++++++++++++++++++++++++++++
drivers/i2c/busses/i2c-imx-lpi2c.c | 21 +++++----------------
include/linux/dmaengine.h | 17 +++++++++++++++++
3 files changed, 50 insertions(+), 16 deletions(-)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20260130-dma_prep_submit-cbeac742de48
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Stefan Dösinger @ 2026-05-22 19:31 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap
Cc: Linus Walleij, Krzysztof Kozlowski, linux-arm-kernel,
Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <503916c8-da3b-42dd-812e-356f519be47f@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
Hi Randy,
Am Freitag, 22. Mai 2026, 20:44:24 Ostafrikanische Zeit schrieben Sie:
> Does this mean that you will be merging this patch since you merged the
> original patch?
I am new to the kernel development process, so I don't know what's the
preferred way. I guess for me it is easier if your patch gets merged as-is.
I can certainly submit a pull request myself though since I made myself the
maintainer for this thing. Does that go to linux-doc@vger.kernel.org or the
soc list?
Cheers,
Stefan
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v8 01/10] dt-bindings: net: airoha: Add GDM port ethernet child node
From: Lorenzo Bianconi @ 2026-05-22 19:27 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260519-airoha-eth-multi-serdes-v8-1-6bd70e329df6@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
> EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> As a result multiple net_devices can connect to the same GDM{3,4} port
> and there is a theoretical "1:n" relation between GDM ports and
> net_devices.
> Introduce the ethernet node child of a specific GDM port in order to model
> a given net_device that is connected via the external arbiter to the
> GDM{3,4} port. This new ethernet node is defined by the "airoha,eth-port"
> compatible string. Please note GDM1 and GDM2 does not support the
> connection with the external arbiter and they are represented by an
> ethernet node defined by the "airoha,eth-mac" compatible string.
Hi Rob, Krzysztof and Conor,
do you have any comment about this patch? Thanks in advance.
Regards,
Lorenzo
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../devicetree/bindings/net/airoha,en7581-eth.yaml | 56 +++++++++++++++++++++-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> index fbe2ddcdd909..17fe2edf4886 100644
> --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> @@ -130,6 +130,42 @@ patternProperties:
> maximum: 4
> description: GMAC port identifier
>
> + allOf:
> + - if:
> + properties:
> + reg:
> + contains:
> + items:
> + - enum:
> + - 3
> + - 4
> + then:
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^ethernet@[0-5]$":
> + type: object
> + unevaluatedProperties: false
> + $ref: ethernet-controller.yaml#
> + description: External ethernet port ID available on the GDM port
> +
> + properties:
> + compatible:
> + const: airoha,eth-port
> +
> + reg:
> + maximum: 5
> + description: External ethernet port identifier
> +
> + required:
> + - reg
> + - compatible
> +
> required:
> - reg
> - compatible
> @@ -191,9 +227,27 @@ examples:
> #address-cells = <1>;
> #size-cells = <0>;
>
> - mac: ethernet@1 {
> + ethernet@1 {
> compatible = "airoha,eth-mac";
> reg = <1>;
> };
> +
> + ethernet@4 {
> + compatible = "airoha,eth-mac";
> + reg = <4>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "airoha,eth-port";
> + reg = <0>;
> + };
> +
> + ethernet@1 {
> + compatible = "airoha,eth-port";
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.54.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: clocksource/drivers/owl: fix refcount leak
From: Markus Elfring @ 2026-05-22 19:25 UTC (permalink / raw)
To: Alexander A. Klimov, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML, kernel-janitors
In-Reply-To: <fe494c36-04e9-4714-ab49-5f05bed66c9e@al2klimov.de>
>> How will chances evolve to adjust variable scopes accordingly?
>
> Is this even a thing in Linux?
> I mean specifying C variables anywhere ex. at function begin.
Development views are evolving also together with the application of scope-based
resource management, aren't they?
https://elixir.bootlin.com/linux/v7.1-rc4/source/include/linux/cleanup.h#L136-L153
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: Chen-Yu Tsai @ 2026-05-22 19:20 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-4-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Enable the APB bus clock before the SPDIF module clock
> during runtime resume, as register accesses depend on the
> bus clock being enabled first.
That does not even matter here. Access will only happen once the runtime
PM callbacks return.
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index f54eb14c9ed8..102db1a2afbb 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -643,15 +643,15 @@ static int sun4i_spdif_runtime_suspend(struct device *dev)
>
> static int sun4i_spdif_runtime_resume(struct device *dev)
> {
> - struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> + struct sun4i_spdif_dev *host = dev_get_drvdata(dev);
> int ret;
>
> - ret = clk_prepare_enable(host->spdif_clk);
> + ret = clk_prepare_enable(host->apb_clk);
> if (ret)
> return ret;
> - ret = clk_prepare_enable(host->apb_clk);
> + ret = clk_prepare_enable(host->spdif_clk);
> if (ret)
> - clk_disable_unprepare(host->spdif_clk);
> + clk_disable_unprepare(host->apb_clk);
>
> return ret;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 0/2] mm: improve large folio readahead for exec memory
From: Andrew Morton @ 2026-05-22 19:20 UTC (permalink / raw)
To: Usama Arif
Cc: david, willy, ryan.roberts, linux-mm, r, jack, Andrew Donnellan,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam R.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, ljs, mhocko, npache, pasha.tatashin,
rmclure, rppt, surenb, vbabka, Al Viro, wilts.infradead.org,
"linux-fsdevel, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260522162422.3856502-1-usama.arif@linux.dev>
On Fri, 22 May 2026 09:23:46 -0700 Usama Arif <usama.arif@linux.dev> wrote:
> Two checks in do_sync_mmap_readahead() limit large-folio readahead:
>
> 1. The mmap_miss heuristic is meant to throttle wasteful speculative
> readahead. It is currently also applied to the VM_EXEC readahead
> path, which is targeted rather than speculative. Once mmap_miss exceeds
> MMAP_LOTSAMISS, exec readahead - including the large-folio
> order requested by exec_folio_order() - is disabled. On
> configurations where the mmap_miss decrement paths are not
> active (see patch 1) the counter only grows, so exec readahead
> is permanently disabled after the first 100 faults.
>
> 2. The force_thp_readahead path is gated only on
> HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always drives the
> readahead at HPAGE_PMD_ORDER. Configurations where
> HPAGE_PMD_ORDER exceeds MAX_PAGECACHE_ORDER never reach this
> path, even when the mapping itself supports usefully large
> folios well below the cap.
>
> Both issues are most visible on arm64 with a 64K base page size,
> where HPAGE_PMD_ORDER is 13 (512MB) -- above MAX_PAGECACHE_ORDER
> (11) -- and where fault_around_pages collapses to 1 disabling
> should_fault_around() (one of the two mmap_miss decrement sites).
> However the fixes are architecture-agnostic: patch 1 reflects the
> nature of VM_EXEC readahead regardless of base page size, and
> patch 2 generalises the gate so any mapping advertising a usefully
> large maximum folio order can benefit.
>
> I created a benchmark that mmaps a large executable file and calls
> RET-stub functions at PAGE_SIZE offsets across it. "Cold" measures
> fault + readahead cost. "Random" first faults in all pages with a
> sequential sweep (not measured), then measures time for calling random
> offsets, isolating iTLB miss cost for scattered execution.
>
> The benchmark results on Neoverse V2 (Grace), arm64 with 64K base pages,
> 512MB executable file on ext4, averaged over 3 runs:
>
> Phase | Baseline | Patched | Improvement
> -----------|--------------|--------------|------------------
> Cold fault | 83.4 ms | 41.3 ms | 50% faster
> Random | 76.0 ms | 58.3 ms | 23% faster
Well that's nice.
AI review might have found a few things:
https://sashiko.dev/#/patchset/20260522162422.3856502-1-usama.arif@linux.dev
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: sunxi: sun4i-spdif: Resume device before kcontrol register access
From: Chen-Yu Tsai @ 2026-05-22 19:19 UTC (permalink / raw)
To: phucduc.bui
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <20260522095401.72915-3-phucduc.bui@gmail.com>
On Fri, May 22, 2026 at 12:54 PM <phucduc.bui@gmail.com> wrote:
>
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Accessing registers while the device is runtime-suspended
> may lead to invalid hardware accesses on systems where the
> APB bus clock is gated during runtime suspend.
Did you actually reproduce the issue, or did you add the patch simply
because Sashiko mentioned it?
On sunxi, either it will hang the system because the bus transaction
got ignored, or it won't as something else enabled the clock.
And when you do add patches due to Sashiko raising an issue, please
do mention it in the commit message.
> Ensure the device is resumed before accessing registers.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> sound/soc/sunxi/sun4i-spdif.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
> index 89eccc83a130..f54eb14c9ed8 100644
> --- a/sound/soc/sunxi/sun4i-spdif.c
> +++ b/sound/soc/sunxi/sun4i-spdif.c
> @@ -428,6 +428,11 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> +
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
>
> scoped_guard(spinlock_irqsave, &host->lock) {
> regmap_read(host->regmap, SUN4I_SPDIF_TXCHSTA0, ®);
> @@ -443,6 +448,8 @@ static int sun4i_spdif_get_status(struct snd_kcontrol *kcontrol,
> status[5] = (reg >> 8) & 0x3;
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return 0;
> }
>
> @@ -453,8 +460,13 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> struct sun4i_spdif_dev *host = snd_soc_dai_get_drvdata(cpu_dai);
> u8 *status = ucontrol->value.iec958.status;
> unsigned int reg;
> + int ret;
> bool chg0, chg1;
>
> + ret = pm_runtime_resume_and_get(cpu_dai->dev);
> + if (ret)
> + return ret;
> +
> scoped_guard(spinlock_irqsave, &host->lock) {
> reg = (u32)status[3] << 24;
> reg |= (u32)status[2] << 16;
> @@ -479,6 +491,8 @@ static int sun4i_spdif_set_status(struct snd_kcontrol *kcontrol,
> SUN4I_SPDIF_TXCFG_NONAUDIO, reg);
> }
>
> + pm_runtime_put(cpu_dai->dev);
> +
> return chg0 || chg1;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v15 12/28] drm/i915/dp: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:19 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-12-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:03PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for both source and sink support of YCBCR444 in
> intel_dp_sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1920d2f02666..143ed85224be 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1344,6 +1344,20 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector,
> 8, sink_format, true);
> }
>
> +static bool
> +intel_dp_can_ycbcr444(struct intel_dp *intel_dp)
> +{
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444) &&
> + !drm_dp_is_branch(intel_dp->dpcd))
> + return true;
> +
> + if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_RGB) &&
> + dfp_can_convert_from_rgb(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444))
IIRC my previous conclusion was that we don't want the dfp convert
stuff here, at least initially. So this should just are about
source_can_output().
> + return true;
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_dp_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -1364,6 +1378,13 @@ intel_dp_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
Again, would prefer a cleanr 420->444->rgb order.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> + if (!intel_dp_can_ycbcr444(intel_dp))
> + return MODE_BAD;
These two ifs are swapped when compared to the HDMI version for no
good reason that I can see.
And missing the has_hdmi_sink check here as well.
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v15 11/28] drm/i915/hdmi: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-05-22 19:12 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, Daniel Stone, kernel, amd-gfx,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip,
intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <20260522-color-format-v15-11-21fb136c9df2@collabora.com>
On Fri, May 22, 2026 at 02:32:02PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for YCBCR444 support on the sink in sink_bpc_possible, and on the
> source and sink in sink_format_valid.
>
> Acked-by: Daniel Stone <daniel@fooishbar.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9076c2b176ec..97cb321e6568 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1966,6 +1966,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36;
> case 10:
> @@ -1974,6 +1976,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_30;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30;
> case 8:
> @@ -2021,6 +2025,27 @@ intel_hdmi_mode_clock_valid(struct drm_connector *_connector, int clock,
> return status;
> }
>
> +/**
> + * intel_hdmi_can_ycbcr444 - Check whether connector can output YCbCr444
> + * @connector: pointer to &struct intel_connector to check
> + *
> + * Checks whether the hardware that backs @connector is capable of outputting
> + * YCbCr444 video over HDMI. Does not check whether currently connected sink is
> + * capable of receiving it.
> + *
> + * Returns: %true if source supports outputting YCbCr444, %false otherwise.
> + */
We don't need kernel docs for internal stuff.
> +static bool
> +intel_hdmi_can_ycbcr444(struct intel_connector *connector)
> +{
> + const struct intel_display *display = to_intel_display(connector);
> +
> + if (HAS_GMCH(display))
> + return true;
Exactly the wrong way around.
> +
> + return false;
> +}
> +
> static enum drm_mode_status
> intel_hdmi_sink_format_valid(struct intel_connector *connector,
> const struct drm_display_mode *mode,
> @@ -2038,6 +2063,13 @@ intel_hdmi_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
I would put the 444 stuff here between 420 and RGB. Then we logically go
from YCbCr420 -> YCbCr444 -> RGB when reading the code.
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!intel_hdmi_can_ycbcr444(connector))
> + return MODE_BAD;
We're missing the has_hdmi_sink check as well.
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.54.0
--
Ville Syrjälä
Intel
^ permalink raw reply
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