* Re: [PATCH] arm64: dts: allwinner: Cubie A5E: enable SPI flash
From: Andre Przywara @ 2026-05-13 9:19 UTC (permalink / raw)
To: wens
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi
In-Reply-To: <CAGb2v64u4sqwiiQcEBg-XvmJ2DLEpSj-_AWNbp14RAp-GXP7OA@mail.gmail.com>
Hi Chen-Yu,
thanks for chipping in!
On 5/13/26 07:21, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, May 12, 2026 at 6:18 AM Andre Przywara <andre.przywara@arm.com> wrote:
>>
>> The Cubie A5E board comes with 16MiB of SPI NOR flash.
>>
>> Enable the SPI0 DT node and describe the configuration.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> .../boot/dts/allwinner/sun55i-a527-cubie-a5e.dts | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> index bfdf1728cd14b..7ad22fc85d1fd 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun55i-a527-cubie-a5e.dts
>> @@ -344,6 +344,21 @@ &r_pio {
>> vcc-pm-supply = <®_aldo3>;
>> };
>>
>> +&spi0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&spi0_pc_pins>, <&spi0_cs0_pc_pin>,
>> + <&spi0_hold_pc_pin>, <&spi0_wp_pc_pin>;
>
> This whole thing needs to be an overlay. The HOLD and WP pins
> conflict with eMMC usage, so it seems that Radxa only populates
> one or the other.
>
> If you look at the pictures on their official website, you'll see the
> SPI NOR chip populated, but not the eMMC chip. On the linux-sunxi wiki
> page, you'll see the opposite.
Well, I have a hard time spotting any actual eMMC SKUs in the shops anyway.
But you are right, the hold and WP pins conflict with eMMC, whereas the
other pins are not.
> And you probably want to enable QSPI, like Sashiko mentioned.
Well, in the interest of keeping this simple and enabling the usage of
SPI flash for all the users out there, I'd rather drop the extra pins.
This is mostly really useful for booting the firmware, maybe loading a
tiny kernel or other data once, so performance is not a big concern in
this use case. The BootROM surely does not use QSPI.
And as you say, if people are really interested in the last bit of
performance, they can use an overlay.
Cheers,
Andre
>
>
> ChenYu
>
>
>> + status = "okay";
>> +
>> + flash@0 {
>> + compatible = "winbond,w25q128", "jedec,spi-nor";
>> + reg = <0>;
>> + spi-max-frequency = <40000000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + };
>> +};
>> +
>> &uart0 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&uart0_pb_pins>;
>> --
>> 2.46.4
>>
>
^ permalink raw reply
* Re: [PATCH v7 10/20] KVM: arm64: Context swap Partitioned PMU guest registers
From: Oliver Upton @ 2026-05-13 9:18 UTC (permalink / raw)
To: Colton Lewis
Cc: kvm, Alexandru Elisei, Paolo Bonzini, Jonathan Corbet,
Russell King, Catalin Marinas, Will Deacon, Marc Zyngier,
Oliver Upton, Mingwei Zhang, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Mark Rutland, Shuah Khan, Ganapatrao Kulkarni,
James Clark, linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest
In-Reply-To: <20260504211813.1804997-11-coltonlewis@google.com>
On Mon, May 04, 2026 at 09:18:03PM +0000, Colton Lewis wrote:
> +
> +/**
> + * kvm_pmu_host_counter_mask() - Compute bitmask of host-reserved counters
> + * @pmu: Pointer to arm_pmu struct
> + *
> + * Compute the bitmask that selects the host-reserved counters in the
> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
> + * in HPMN..N
> + *
> + * Return: Bitmask
> + */
> +u64 kvm_pmu_host_counter_mask(struct arm_pmu *pmu)
> +{
> + u8 nr_counters = *host_data_ptr(nr_event_counters);
> +
> + if (kvm_pmu_is_partitioned(pmu))
> + return GENMASK(nr_counters - 1, pmu->max_guest_counters);
> +
> + return ARMV8_PMU_CNT_MASK_ALL;
> +}
> +
> +/**
> + * kvm_pmu_guest_counter_mask() - Compute bitmask of guest-reserved counters
> + * @pmu: Pointer to arm_pmu struct
> + *
> + * Compute the bitmask that selects the guest-reserved counters in the
> + * {PMCNTEN,PMINTEN,PMOVS}{SET,CLR} registers. These are the counters
> + * in 0..HPMN and the cycle and instruction counters.
> + *
> + * Return: Bitmask
> + */
> +u64 kvm_pmu_guest_counter_mask(struct arm_pmu *pmu)
> +{
> + if (kvm_pmu_is_partitioned(pmu))
> + return ARMV8_PMU_CNT_MASK_C | GENMASK(pmu->max_guest_counters - 1, 0);
> +
> + return 0;
> +}
> +
> +/**
> + * kvm_pmu_load() - Load untrapped PMU registers
> + * @vcpu: Pointer to struct kvm_vcpu
> + *
> + * Load all untrapped PMU registers from the VCPU into the PCPU. Mask
> + * to only bits belonging to guest-reserved counters and leave
> + * host-reserved counters alone in bitmask registers.
> + */
> +void kvm_pmu_load(struct kvm_vcpu *vcpu)
> +{
> + struct arm_pmu *pmu;
> + unsigned long guest_counters;
> + u64 mask;
> + u8 i;
> + u64 val;
> +
> + /*
> + * If we aren't guest-owned then we know the guest isn't using
> + * the PMU anyway, so no need to bother with the swap.
> + */
> + if (!kvm_vcpu_pmu_is_partitioned(vcpu))
> + return;
> +
> + preempt_disable();
> +
> + pmu = vcpu->kvm->arch.arm_pmu;
> + guest_counters = kvm_pmu_guest_counter_mask(pmu);
> +
> + for_each_set_bit(i, &guest_counters, ARMPMU_MAX_HWEVENTS) {
> + val = __vcpu_sys_reg(vcpu, PMEVCNTR0_EL0 + i);
> +
> + if (i == ARMV8_PMU_CYCLE_IDX) {
> + write_sysreg(val, pmccntr_el0);
> + } else {
> + write_sysreg(i, pmselr_el0);
> + write_sysreg(val, pmxevcntr_el0);
This is wrong, you would need an intervening ISB. It'd be better to
avoid the ISB altogether and just use {read,write}_pmevcntrn().
Thanks,
Oliver
^ permalink raw reply
* [PATCH v2 01/11] m68k: mcf5441x: fix clocks numbering
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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
* [PATCH v2 11/11] iio: dac: add mcf54415 DAC
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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
---
drivers/iio/dac/Kconfig | 10 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 203 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 214 insertions(+)
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index cd4870b65415..85147df00aa3 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -516,6 +516,16 @@ 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
+ 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..e95ab6b89b17
--- /dev/null
+++ b/drivers/iio/dac/mcf54415_dac.c
@@ -0,0 +1,203 @@
+// 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/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 clk *clk;
+ struct regmap *map;
+};
+
+static const struct regmap_config mcf54415_dac_regmap_config = {
+ .reg_bits = 16,
+ .reg_stride = 2,
+ .val_bits = 16,
+ .io_port = true,
+ .max_register = 0x1F,
+};
+
+static void mcf54415_dac_init(struct mcf54415_dac *info)
+{
+ /* Keeping defaults and enable DAC (bit 0 set to 0) */
+ regmap_write(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_FILT |
+ FIELD_PREP(MCF54415_DAC_CR_WMLVL, 1));
+
+ /* DAC is ready after 12us, from RM table 40-3 */
+ fsleep(12);
+}
+
+static void mcf54415_dac_exit(void *data)
+{
+ struct mcf54415_dac *info = data;
+
+ regmap_update_bits(info->map, MCF54415_DAC_CR, MCF54415_DAC_CR_PDN,
+ MCF54415_DAC_CR_PDN);
+}
+
+#define MCF54415_DAC_CHAN \
+{ \
+ .type = IIO_VOLTAGE, \
+ .output = 1, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+}
+
+static const struct iio_chan_spec mcf54415_dac_iio_channels[] = {
+ MCF54415_DAC_CHAN,
+};
+
+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);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ regmap_read(info->map, MCF54415_DAC_DATA, val);
+ *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:
+ if (val < 0 || val > 4095)
+ return -EINVAL;
+ regmap_write(info->map, MCF54415_DAC_DATA, val);
+ return 0;
+ 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_channels;
+ indio_dev->num_channels = ARRAY_SIZE(mcf54415_dac_iio_channels);
+
+ mcf54415_dac_init(info);
+
+ 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 iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct mcf54415_dac *info = iio_priv(indio_dev);
+
+ mcf54415_dac_exit(info);
+ clk_disable_unprepare(info->clk);
+
+ return 0;
+}
+
+static int mcf54415_dac_resume(struct device *dev)
+{
+ struct iio_dev *indio_dev = dev_get_drvdata(dev);
+ struct mcf54415_dac *info = iio_priv(indio_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 v2 04/11] m68k: defconfig: update stmark2 defconfig
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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 v2 10/11] m68k: stmark2: enable DACs outputs
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Enabled DAC0 and DAC1 outpus disabling shared ADC inputs on ADC3 and ADC7.
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 a5b36af8e70a..a82e1b286770 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -117,6 +117,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);
@@ -129,6 +131,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 v2 09/11] m68k: stmark2: use ioport.h macros for resources
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Align also other resource declaration using DEFINE_RES_.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
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 aa2b4d2a8a64..a5b36af8e70a 100644
--- a/arch/m68k/coldfire/stmark2.c
+++ b/arch/m68k/coldfire/stmark2.c
@@ -63,21 +63,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_DMA(12),
+ DEFINE_RES_DMA(13),
+ DEFINE_RES_IRQ(MCF_IRQ_DSPI0),
};
static u64 stmark2_dspi_mask = DMA_BIT_MASK(32);
--
2.54.0
^ permalink raw reply related
* [PATCH v2 08/11] m68k: stmark2: add mcf5441x DAC platform devices
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add mcf5441x DAC platform devices.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
Changes in v2:
- fix copy-paste error on naming
- use DEFINE_RES()
---
arch/m68k/coldfire/stmark2.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/m68k/coldfire/stmark2.c b/arch/m68k/coldfire/stmark2.c
index 9263b77bd09a..aa2b4d2a8a64 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>
@@ -94,8 +95,32 @@ 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 = ARRAY_SIZE(dac0_resource),
+ .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 = ARRAY_SIZE(dac1_resource),
+ .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 v2 05/11] m68k: add DAC modules base addresses
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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 v2 07/11] m68k: mcf5441x: add CCR MISCCR2 bitfields
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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 v2 06/11] m68k: mcf5441x: add CCM registers
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@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 v2 03/11] m68k: mcf5441x: setup DAC clock name as per driver name
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Later in this patchset, the mcf54415 DAC driver is added.
Considering some other different ColdFire cpu DACs exists, the DAC driver
is named as "mcf54415_dac", related to the mcf5441x family SoCs with
DACs (mcf54415/6/7/8).
So updating DAC clock names to bind with proper driver name.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 5b5e09ecf487..b724d7fc1a08 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -43,8 +43,8 @@ DEFINE_CLK(0, "mcfpit.2", 34, MCF_BUSCLK);
DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
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, "mcfdac.1", 39, MCF_CLK);
+DEFINE_CLK(0, "mcf54415_dac.0", 38, MCF_CLK);
+DEFINE_CLK(0, "mcf54415_dac.1", 39, 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);
@@ -106,8 +106,8 @@ static struct clk_lookup m5411x_clk_lookup[] = {
CLKDEV_INIT("mcfpit.3", NULL, &__clk_0_35),
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("mcfdac.1", NULL, &__clk_0_39),
+ CLKDEV_INIT("mcf54415_dac.0", NULL, &__clk_0_38),
+ CLKDEV_INIT("mcf54415_dac.1", NULL, &__clk_0_39),
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),
--
2.54.0
^ permalink raw reply related
* [PATCH v2 02/11] m68k: mcf5441x: add clock for DAC channel 1
From: Angelo Dureghello @ 2026-05-13 9:14 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: <20260513-wip-stmark2-dac-v2-0-fcdae50cf51a@baylibre.com>
From: Angelo Dureghello <adureghello@baylibre.com>
Add missing clock for mcf5441x DAC channel 1.
Signed-off-by: Angelo Dureghello <adureghello@baylibre.com>
---
arch/m68k/coldfire/m5441x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/coldfire/m5441x.c b/arch/m68k/coldfire/m5441x.c
index 613b0275d9d8..5b5e09ecf487 100644
--- a/arch/m68k/coldfire/m5441x.c
+++ b/arch/m68k/coldfire/m5441x.c
@@ -44,6 +44,7 @@ DEFINE_CLK(0, "mcfpit.3", 35, MCF_BUSCLK);
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, "mcfdac.1", 39, 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);
@@ -106,6 +107,7 @@ static struct clk_lookup m5411x_clk_lookup[] = {
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("mcfdac.1", NULL, &__clk_0_39),
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),
@@ -176,6 +178,7 @@ static struct clk * const disable_clks[] __initconst = {
&__clk_0_35, /* pit.3 */
&__clk_0_37, /* adc */
&__clk_0_38, /* dac.0 */
+ &__clk_0_39, /* dac.1 */
&__clk_0_44, /* usb otg */
&__clk_0_45, /* usb host */
&__clk_0_47, /* ssi.0 */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 00/11] add mcf54415 DAC driver
From: Angelo Dureghello @ 2026-05-13 9:14 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
This patchset adds a minimalistic DAC driver for the NXP mcf54415/6/7/8
ibuiltin DACs.
Currently the driver enables the raw write only. Feature as dma, sync, or
format are not supoprted for this version.
Additional options suppoerted by the DAC module will be added to the driver
later on, as needed.
The same patchset prepares the m68k/coldfire architecture to support
the driver.
Below soem basic tests done on stmark2 mcf54415-based board, voltage check
on DAC0 and DAC1:
~ # cd /sys/bus/iio/devices/iio:device0/
/sys/bus/iio/devices/iio:device0 # ls
name out_voltage_scale uevent
out_voltage_raw subsystem
/sys/bus/iio/devices/iio:device0 # cat name
mcf54415
/sys/bus/iio/devices/iio:device0 # echo 4095 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 2048 > out_voltage_raw
/sys/bus/iio/devices/iio:device0 # echo 4096 > out_voltage_raw
sh: write error: Invalid argument
/sys/bus/iio/devices/iio:device0 # cat out_voltage_raw
2048
/sys/bus/iio/devices/iio:device0 #
Same behavior for /sys/bus/iio/devices/iio:device1.
Generated a sine wave by shell script, sine shape is good.
Note: this patchset depends on mew mcf_read/mcf_write implementation:
Link: https://lore.kernel.org/linux-m68k/209d0653-6386-4b64-9e15-e358f84453ab@app.fastmail.com/T/#t
---
Changes in v2:
- keeping changelog in each single patch, where any
- Link to v1: https://patch.msgid.link/20260504-wip-stmark2-dac-v1-0-874c36a4910d@baylibre.com
---
Angelo Dureghello (11):
m68k: mcf5441x: fix clocks numbering
m68k: mcf5441x: add clock for DAC channel 1
m68k: mcf5441x: setup DAC clock name as per driver name
m68k: defconfig: update stmark2 defconfig
m68k: add DAC modules base addresses
m68k: mcf5441x: add CCM registers
m68k: mcf5441x: add CCR MISCCR2 bitfields
m68k: stmark2: add mcf5441x DAC platform devices
m68k: stmark2: use ioport.h macros for resources
m68k: stmark2: enable DACs outputs
iio: dac: add mcf54415 DAC
arch/m68k/coldfire/m5441x.c | 21 ++--
arch/m68k/coldfire/stmark2.c | 51 ++++++---
arch/m68k/configs/stmark2_defconfig | 2 +
arch/m68k/include/asm/m5441xsim.h | 42 ++++++++
drivers/iio/dac/Kconfig | 10 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/mcf54415_dac.c | 203 ++++++++++++++++++++++++++++++++++++
7 files changed, 306 insertions(+), 24 deletions(-)
---
base-commit: 25c66a1b49f3c5463ee8266a3fd5256cbc794610
change-id: 20260430-wip-stmark2-dac-7060f49dd94f
Best regards,
--
Angelo Dureghello <adureghello@baylibre.com>
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: phy: rockchip,inno-usb2phy: Add compatible for RK3528
From: Diederik de Haas @ 2026-05-13 9:09 UTC (permalink / raw)
To: Heiko Stuebner, vkoul
Cc: neil.armstrong, robh, krzk+dt, conor+dt, linux-phy, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, jonas
In-Reply-To: <20260505170410.3265305-4-heiko@sntech.de>
Hi Heiko,
On Tue May 5, 2026 at 7:04 PM CEST, Heiko Stuebner wrote:
> From: Jonas Karlman <jonas@kwiboo.se>
>
> The embedded USB2 PHY on RK3528 is very similar to the one in RK3568,
> the main difference being that it only uses two clocks instead of three.
>
> Add compatible to support the USB2 PHY in RK3528.
>
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> .../bindings/phy/rockchip,inno-usb2phy.yaml | 30 ++++++++++++++++---
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> index b95c9e3e44fe..f50fc69fbbe4 100644
> --- a/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/rockchip,inno-usb2phy.yaml
> @@ -20,6 +20,7 @@ properties:
> - rockchip,rk3328-usb2phy
> - rockchip,rk3366-usb2phy
> - rockchip,rk3399-usb2phy
> + - rockchip,rk3528-usb2phy
> - rockchip,rk3562-usb2phy
> - rockchip,rk3568-usb2phy
> - rockchip,rk3576-usb2phy
> @@ -41,11 +42,15 @@ properties:
> maxItems: 3
>
> clock-names:
> - minItems: 1
> - items:
> + oneOf:
> - const: phyclk
> - - const: aclk
> - - const: aclk_slv
> + - items:
> + - const: phyclk
> + - const: pclk
> + - items:
> + - const: phyclk
> + - const: aclk
> + - const: aclk_slv
>
> assigned-clocks:
> description:
> @@ -65,6 +70,9 @@ properties:
> description: Muxed interrupt for both ports
> maxItems: 1
>
> + power-domains:
> + maxItems: 1
> +
The commit message talks about (the differences in) clocks, but says
nothing about power-domains. Shouldn't that be mentioned and/or split
off into its own patch? (FWIW: I like the change itself)
Cheers,
Diederik
> resets:
> maxItems: 2
>
> @@ -150,6 +158,7 @@ allOf:
> compatible:
> contains:
> enum:
> + - rockchip,rk3528-usb2phy
> - rockchip,rk3568-usb2phy
> - rockchip,rv1108-usb2phy
> then:
> @@ -218,6 +227,19 @@ allOf:
> clock-names:
> maxItems: 1
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3528-usb2phy
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + clock-names:
> + minItems: 2
> +
> - if:
> properties:
> compatible:
^ permalink raw reply
* Re: [PATCH v5 18/29] media: rockchip: rga: check scaling factor
From: Sven Püschel @ 2026-05-13 9:09 UTC (permalink / raw)
To: Nicolas Dufresne, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <67c2e5b74340a3a33a5e1e377e88298250a6d3c5.camel@ndufresne.ca>
Hi Nicolas,
On 5/9/26 1:11 AM, Nicolas Dufresne wrote:
> Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
>> Check the scaling factor to avoid potential problems. This is relevant
>> for the upcoming RGA3 support, as it can hang when the scaling factor
>> is exceeded.
>>
>> There are two relevant scenarios that have to be considered to protect
>> against invalid scaling values:
>>
>> When the output or capture is already streaming, setting the format on
>> the other side should consider the max scaling factor and clamp it
>> accordingly. This is only done in the streaming case, as it otherwise
>> may unintentionally clamp the value when the application sets the first
>> format (due to a default format on the other side).
>>
>> When the format is set on both sides first, then the format won't be
>> corrected by above means. Therefore the second streamon call has to
>> check the scaling factor and fail otherwise.
>>
>> As try functions should only be state aware if specified, the scaling
>> limitation is only done in s_fmt.
>>
>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
>> ---
>> drivers/media/platform/rockchip/rga/rga-hw.c | 1 +
>> drivers/media/platform/rockchip/rga/rga-hw.h | 1 +
>> drivers/media/platform/rockchip/rga/rga.c | 47 ++++++++++++++++++++++++++++
>> drivers/media/platform/rockchip/rga/rga.h | 1 +
>> 4 files changed, 50 insertions(+)
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
>> index 11079477a3008..11a1a914668f6 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.c
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
>> @@ -595,6 +595,7 @@ const struct rga_hw rga2_hw = {
>> .max_width = MAX_WIDTH,
>> .min_height = MIN_HEIGHT,
>> .max_height = MAX_HEIGHT,
>> + .max_scaling_factor = MAX_SCALING_FACTOR,
>> .stride_alignment = 4,
>>
>> .setup_cmdbuf = rga_hw_setup_cmdbuf,
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.h b/drivers/media/platform/rockchip/rga/rga-hw.h
>> index c2e34be751939..805ec23e5e3f4 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.h
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.h
>> @@ -14,6 +14,7 @@
>>
>> #define MIN_WIDTH 34
>> #define MIN_HEIGHT 34
>> +#define MAX_SCALING_FACTOR 16
>>
>> #define RGA_TIMEOUT 500
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga.c b/drivers/media/platform/rockchip/rga/rga.c
>> index d111b348255e2..75d05c86b1c00 100644
>> --- a/drivers/media/platform/rockchip/rga/rga.c
>> +++ b/drivers/media/platform/rockchip/rga/rga.c
>> @@ -405,10 +405,36 @@ static int vidioc_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
>> struct v4l2_pix_format_mplane *pix_fmt = &f->fmt.pix_mp;
>> struct rga_ctx *ctx = file_to_rga_ctx(file);
>> struct rockchip_rga *rga = ctx->rga;
>> + const struct rga_hw *hw = rga->hw;
>> struct vb2_queue *vq;
>> struct rga_frame *frm;
>> int ret = 0;
>> int i;
>> + struct rga_frame *limit_frm = NULL;
>> +
>> + /* Limit before try_fmt to avoid recalculating the stride */
>> + if (V4L2_TYPE_IS_OUTPUT(f->type) &&
>> + v4l2_m2m_get_dst_vq(ctx->fh.m2m_ctx)->streaming)
>> + limit_frm = &ctx->out;
> If you need to, use helpers such as vb2_is_streaming(), though in this case, I
> think you want to use vb2_is_busy(), which protects against changing the format
> of a queue that is already allocated. This is needed because drivers, except vp9
> and av1 stateless decoders, don't track the format per buffer.
>
>> + if (V4L2_TYPE_IS_CAPTURE(f->type) &&
>> + v4l2_m2m_get_src_vq(ctx->fh.m2m_ctx)->streaming)
> Same.
>
>> + limit_frm = &ctx->in;
>> + if (limit_frm) {
>> + const struct v4l2_frmsize_stepwise frmsize = {
>> + .min_width = DIV_ROUND_UP(limit_frm->pix.width,
>> + hw->max_scaling_factor),
>> + .max_width =
>> + limit_frm->pix.width * hw->max_scaling_factor,
> Shouldn't you control the absolute min/max for this IP ?
That is done later in try_fmt. This is separately done in s_fmt to avoid
making try_fmt stateful. I'll add a comment to make it more clear that
this is only for the theoretical scaling limits.
>
>> + .min_height = DIV_ROUND_UP(limit_frm->pix.height,
>> + hw->max_scaling_factor),
>> + .max_height =
>> + limit_frm->pix.height * hw->max_scaling_factor,
>> + .step_width = 1,
>> + .step_height = 1,
> Shouldn't that step match the subsampling like you did earlier ?
same as above.
Sincerely
Sven
>
> Nicolas
>
>> + };
>> + v4l2_apply_frmsize_constraints(&pix_fmt->width,
>> + &pix_fmt->height, &frmsize);
>> + }
>>
>> /* Adjust all values accordingly to the hardware capabilities
>> * and chosen format.
>> @@ -568,12 +594,33 @@ static int vidioc_s_selection(struct file *file, void *priv,
>> return ret;
>> }
>>
>> +static bool check_scaling(const struct rga_hw *hw, u32 src_size, u32 dst_size)
>> +{
>> + if (src_size < dst_size)
>> + return src_size * hw->max_scaling_factor >= dst_size;
>> + else
>> + return dst_size * hw->max_scaling_factor >= src_size;
>> +}
>> +
>> static int vidioc_streamon(struct file *file, void *priv,
>> enum v4l2_buf_type type)
>> {
>> struct rga_ctx *ctx = file_to_rga_ctx(file);
>> const struct rga_hw *hw = ctx->rga->hw;
>>
>> + if ((V4L2_TYPE_IS_OUTPUT(type) &&
>> + v4l2_m2m_get_dst_vq(ctx->fh.m2m_ctx)->streaming) ||
>> + (V4L2_TYPE_IS_CAPTURE(type) &&
>> + v4l2_m2m_get_src_vq(ctx->fh.m2m_ctx)->streaming)) {
>> + /*
>> + * As the other side is already streaming,
>> + * check that the max scaling factor isn't exceeded.
>> + */
>> + if (!check_scaling(hw, ctx->in.pix.width, ctx->out.pix.width) ||
>> + !check_scaling(hw, ctx->in.pix.height, ctx->out.pix.height))
>> + return -EINVAL;
>> + }
>> +
>> hw->setup_cmdbuf(ctx);
>>
>> return v4l2_m2m_streamon(file, ctx->fh.m2m_ctx, type);
>> diff --git a/drivers/media/platform/rockchip/rga/rga.h b/drivers/media/platform/rockchip/rga/rga.h
>> index c741213710b32..454af283b1694 100644
>> --- a/drivers/media/platform/rockchip/rga/rga.h
>> +++ b/drivers/media/platform/rockchip/rga/rga.h
>> @@ -150,6 +150,7 @@ struct rga_hw {
>> size_t cmdbuf_size;
>> u32 min_width, min_height;
>> u32 max_width, max_height;
>> + u8 max_scaling_factor;
>> u8 stride_alignment;
>>
>> void (*setup_cmdbuf)(struct rga_ctx *ctx);
^ permalink raw reply
* [PATCH] clk: scpi: pass child node to of_clk_del_provider() in remove
From: Stepan Ionichev @ 2026-05-13 9:09 UTC (permalink / raw)
To: sudeep.holla
Cc: cristian.marussi, mturquette, sboyd, arm-scmi, linux-arm-kernel,
linux-clk, linux-kernel, sozdayvek
scpi_clocks_remove() iterates over the SCPI clock provider's child
device nodes, but passes the parent node to of_clk_del_provider()
on every iteration:
for_each_available_child_of_node(np, child)
of_clk_del_provider(np);
Providers are registered per-child in scpi_clk_add() (via
of_clk_add_hw_provider(np, ...) where the np argument is the
child node passed in from probe). of_clk_del_provider() looks up
the entry by node equality, so a call with the parent never
matches and silently does nothing.
This leaks the struct of_clk_provider allocations and the
of_node_get() references the helper takes for every registered
child, both on module unload and on the probe error path
(scpi_clk_add() failure for child N leaves children 0..N-1
registered).
Pass child to of_clk_del_provider() instead, matching the
pattern used by clk-stm32mp1.c:2350-2351.
Fixes: cd52c2a4b5c4 ("clk: add support for clocks provided by SCP(System Control Processor)")
Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
---
drivers/clk/clk-scpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-scpi.c b/drivers/clk/clk-scpi.c
index 7806569cd..24cee7c9f 100644
--- a/drivers/clk/clk-scpi.c
+++ b/drivers/clk/clk-scpi.c
@@ -258,7 +258,7 @@ static void scpi_clocks_remove(struct platform_device *pdev)
}
for_each_available_child_of_node(np, child)
- of_clk_del_provider(np);
+ of_clk_del_provider(child);
}
static int scpi_clocks_probe(struct platform_device *pdev)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 02/13] driver core: Enable suppliers to implement fine grained sync_state support
From: Ulf Hansson @ 2026-05-13 9:04 UTC (permalink / raw)
To: Saravana Kannan
Cc: Danilo Krummrich, Rafael J . Wysocki, Greg Kroah-Hartman,
driver-core, linux-pm, Sudeep Holla, Cristian Marussi,
Kevin Hilman, Stephen Boyd, Marek Szyprowski, Bjorn Andersson,
Abel Vesa, Peng Fan, Tomi Valkeinen, Maulik Shah, Konrad Dybcio,
Thierry Reding, Jonathan Hunter, Geert Uytterhoeven,
Dmitry Baryshkov, linux-arm-kernel, linux-kernel
In-Reply-To: <CACRMN=dZFvbXjZGqTvFdNVyXfyvS6YtWNKQnej9A1jihGJHcqA@mail.gmail.com>
On Wed, 13 May 2026 at 07:01, Saravana Kannan <saravanak@kernel.org> wrote:
>
> On Mon, May 11, 2026 at 2:43 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Mon, 11 May 2026 at 07:09, Saravana Kannan <saravanak@kernel.org> wrote:
> > >
> > > On Fri, May 8, 2026 at 5:39 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > The common sync_state support isn't fine grained enough for some types of
> > > > suppliers, like power domains for example. Especially when a supplier
> > > > provides multiple independent power domains, each with their own set of
> > > > consumers. In these cases we need to wait for all consumers for all the
> > > > provided power domains before invoking the supplier's ->sync_state().
> > > >
> > > > To allow a more fine grained sync_state support to be implemented on per
> > > > supplier's driver basis, let's add a new optional callback. As soon as
> > > > there is an update worth to consider in regards to managing sync_state for
> > > > a supplier device, __device_links_queue_sync_state() queues the device in a
> > > > list, allowing the new callback to be invoked when flushing the list in
> > > > device_links_flush_sync_list().
> > > >
> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > > ---
> > > >
> > > > Changes in v3:
> > > > - Re-worked the approach to use a list to queue/flush devices for
> > > > ->queue_sync_state(). This should make sure the device lock is being
> > > > held when it's needed, as pointed out by Danilo.
> > > >
> > >
> > > Hi Ulf,
> > >
> > > Thanks for working on this!
> > >
> > > And please bear with my slow replies.
> >
> > I will try, but taking more than 2 months to reply isn't sustainable,
> > I think. Let's hope you can get some more bandwidth for reviews when
> > moving forward.
> >
> > >
> > > > ---
> > > > drivers/base/base.h | 18 ++++++++
> > > > drivers/base/core.c | 77 ++++++++++++++++++++++++++---------
> > > > drivers/base/driver.c | 7 ++++
> > > > include/linux/device.h | 2 +
> > > > include/linux/device/driver.h | 7 ++++
> > > > 5 files changed, 91 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git a/drivers/base/base.h b/drivers/base/base.h
> > > > index 30b416588617..c8be24af92c3 100644
> > > > --- a/drivers/base/base.h
> > > > +++ b/drivers/base/base.h
> > > > @@ -196,6 +196,24 @@ static inline void dev_sync_state(struct device *dev)
> > > > dev->driver->sync_state(dev);
> > > > }
> > > >
> > > > +static inline bool dev_has_queue_sync_state(struct device *dev)
> > >
> > > Let's please pick a better name. This is too similar to the actual
> > > queue function you call __device_links_queue_sync_state() and is very
> > > confusing. Maybe something that has a meaning along the lines of
> > > "another consumer probed". So, maybe:
> > > * consumer_probed()
> > > * change_of_active_consumers()
> >
> > The whole point of naming it "queue_sync_state" was exactly to refer
> > to __device_links_queue_sync_state(). The point is, the callback can't
> > be invoked unless __device_links_queue_sync_state() has been called
> > for the device first.
> >
> > Not sure why you think that is confusing? To me, that is rather the
> > opposite. :-)
>
>
> sync_state() is a callback telling the driver that it's okay to sync
> the state of the hardware with the software.
>
> queue_sync_state() means nothing to the driver. It's just leaking an
> internal implementation detail (name of the internal function) to the
> driver that's not really relevant. What you are really telling the
> driver is that some additional consumers have probed.
>
> > Before deciding on another name, note also that
> > __device_links_queue_sync_state() is called when resuming sync_state
> > from device_links_supplier_sync_state_resume() and from
> > device_links_driver_bound(). I am not sure "consumer_probed" a good
> > name that covers both of these cases; what do you think?
>
> Yes, I'm well aware of that :) The contract of sync_state() is that
> it'll come after a point where it's safe to sync the state. Not "as
> soon as it's safe" -- meaning no timing guarantee. Really, this is
> just to make sure sync_state() doesn't come before late initcalls
> (because a lot of frameworks make assumptions around it) are done and
> before all the top level devices are added.
>
> So, even today, sync_state() can come a bit late. In general, the
> driver framework doesn't guarantee immediate action. There is no
> guarantee that a drive probe will be called as soon as it's registered
> (if there is a device) and vice versa. The same will be true for a
> "consumer_probed()" callback too.
>
> Also, your implementation is literally trying to check which consumers
> have probed and which ones haven't. So something like
> "consumer_probed()" or "consumer_change()" should work well and is
> actually meaningful for a driver developer.
I have no strong opinion on the name, so if you prefer
"consumer_probed|changed", let me just pick one of them then.
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH v5 04/10] arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
Add the required HCLK_VO1 bus clock to RK3588 eDP1 node with
corresponding clock-name "hclk". This clock is necessary for
the eDP controller to access video output GRF and work properly.
Previously the clock was enabled implicitly via GRF phandle
reference. Add it explicitly now to align with updated binding.
Fixes: a481bb0b1ad9 ("arm64: dts: rockchip: Add eDP1 dt node for rk3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
---
| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index a2640014ee04..b251bb129cdb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -285,8 +285,8 @@ hdmi1_out: port@1 {
edp1: edp@fded0000 {
compatible = "rockchip,rk3588-edp";
reg = <0x0 0xfded0000 0x0 0x1000>;
- clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>;
- clock-names = "dp", "pclk";
+ clocks = <&cru CLK_EDP1_24M>, <&cru PCLK_EDP1>, <&cru HCLK_VO1>;
+ clock-names = "dp", "pclk", "hclk";
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH 0>;
phys = <&hdptxphy1>;
phy-names = "dp";
--
2.34.1
^ permalink raw reply related
* [PATCH v5 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Damon Ding @ 2026-05-13 7:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260513074414.2053435-1-damon.ding@rock-chips.com>
RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
to access the VO1 GRF registers and enable the video datapath.
Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
phandle reference, which allowed the eDP to work without explicitly
managing the hclk_vo1 clock. However, this is not safe or explicit.
Enforce the correct third clock name on a per-compatible basis to
standardize clock requirements per SoC. This makes the clock
dependency clear and removes reliance on implicit clock enablement
from GRF phandle.
Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v4:
- Modify the commit msg.
Changes in v5:
- Enforce the correct third clock name on a per-compatible basis.
- Modify the commit msg simultaneously.
---
.../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index d99b23b88cc5..8001c1facf98 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -23,10 +23,7 @@ properties:
clock-names:
minItems: 2
- items:
- - const: dp
- - const: pclk
- - const: grf
+ maxItems: 3
power-domains:
maxItems: 1
@@ -60,6 +57,33 @@ required:
allOf:
- $ref: /schemas/display/bridge/analogix,dp.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3288-dp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - rockchip,rk3399-edp
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: grf
+
- if:
properties:
compatible:
@@ -68,6 +92,11 @@ allOf:
- rockchip,rk3588-edp
then:
properties:
+ clock-names:
+ items:
+ - const: dp
+ - const: pclk
+ - const: hclk
resets:
minItems: 2
reset-names:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Petar Stepanovic @ 2026-05-13 8:59 UTC (permalink / raw)
To: Linus Walleij
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAD++jL=51iWK2SyxoWOTxSQHAq-Frd0mm6cPxqYu81qifFfHGg@mail.gmail.com>
On 5/11/2026 10:36 AM, Linus Walleij wrote:
> Are they connected to the same physical output line/pin or
> not? That is the only thing that matters. If they in the end control
> the same physical entitiy, it *is* the same GPIO line from Linux'
> point of view.
No, they are not connected to the same physical line/pin.
DIN and DOUT are separate physical SGPIO signals in this hardware. DIN
signals are input-only and DOUT signals are output-only; they are not
bidirectional or interchangeable paths for the same physical pin.
So I agree that Linux should model physical GPIO entities rather than
internal register bits. My previous wording was not clear enough: the
intention was to describe separate physical SGPIO signals, not just separate
register fields.
>> Because the direction is fixed by hardware, the standard
>> lines-initial-states property, which encodes both direction and initial state,
>> does not map cleanly to this design.
> GPIOs with fixed direction is nothing new for Linux, we've had
> that for ages.
>
> I would just have the driver reject configurations that does
> not apply and bail out.
>
> If you absolutely want to enforce the lines-initial-states to match what the
> hardware can do, then use YAML schema restriuctions on what
> values can be encoded into that array.
>
>> For the output lines (DOUT), should their initial values be described in the
>> device tree, or should they be configured by userspace, with the driver only
>> providing default initialization?
> I don't see why userspace should deal with that. The Linux userspace
> ABI is for hacking and odd usecases (like industrial). The nominal
> use is kernel-internal consumers and those must be able to
> request their GPIOs as well without any userspace shenanigans.
>
> But avoiding to deal with initial line states at all is a solution
> of course.
>
> What I don't understand is what purpose this dout-init actually
> does and why it cannot be set dynamically by the driver at runtime.
Some SGPIO outputs may control host-critical signals. For example, if the
BMC reboots while the host/server remains powered on, changing SGPIO output
values during driver initialization could potentially reset or shut down the
running host.
The purpose of `dout-init` is to provide a deterministic safe output state
during SGPIO initialization, before any GPIO consumer has requested the line.
That said, if the preferred approach is to preserve the existing hardware
DOUT state during probe and only change the value when a GPIO consumer
requests the line, I can rework the driver in that direction.
Thnaks,
Petar
^ permalink raw reply
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Ard Biesheuvel @ 2026-05-13 8:53 UTC (permalink / raw)
To: Mike Rapoport
Cc: Jann Horn, Ard Biesheuvel, linux-arm-kernel, linux-kernel,
Will Deacon, Catalin Marinas, Mark Rutland, Ryan Roberts,
Anshuman Khandual, Liz Prucka, Seth Jenkins, Kees Cook,
David Hildenbrand, Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <agQ7RMAw51RlNUOj@kernel.org>
On Wed, 13 May 2026, at 10:50, Mike Rapoport wrote:
> On Tue, May 12, 2026 at 02:56:16PM +0200, Ard Biesheuvel wrote:
>> On Mon, 11 May 2026, at 16:40, Jann Horn wrote:
>> > On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>> >> I think we should simply do something along the lines of the below,
>> >> considering that the size of a data object tends to correlate with
>> >> its minimum alignment.
>> >>
>> >> I do find it rather puzzling that the compiler emits empty_zero_page
>> >> *after* zero_page_pfn - ideally, we'd combine the below with
>> >> -fdata-sections so that the linker sees all individual objects, but
>> >> I suspect that would create some problems elsewhere.
>> >>
>> >>
>> >> --- a/include/asm-generic/vmlinux.lds.h
>> >> +++ b/include/asm-generic/vmlinux.lds.h
>> >> @@ -452,7 +452,7 @@
>> >> #define RO_AFTER_INIT_DATA \
>> >> . = ALIGN(8); \
>> >> __start_ro_after_init = .; \
>> >> - *(.data..ro_after_init) \
>> >> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
>> >
>> > Oh, neat, I didn't realize that's possible. That seems like a nicer
>> > approach...
>>
>> Neat but rather ineffective, unfortunately. (I don't see a size
>> difference with the arm64 defconfig kernel)
>>
>> Given that empty_zero_page only ever gets its address taken, we
>> might just move it into the linker script if that requires tweaking
>> anyway. We can just place it at the start of .rodata, which is
>> already page aligned on most architectures (and will become page
>> aligned unless EMPTY_ZERO_PAGE is #define'd by the arch linker
>> script to something else)
>>
>>
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -472,6 +472,17 @@
>> #endif
>> #endif
>>
>> +#ifndef EMPTY_ZERO_PAGE
>> +#ifndef __HAVE_COLOR_ZERO_PAGE
>
> I don't think we want let architectures that don't use colored zero pages
> redefine it.
> If it will be really required we can add the ability to redefine
> EMPTY_ZERO_PAGE later.
>
I was actually intending to add use this for arm64 in the next patch. It
already has a reserved_pg_dir in .rodata which is page-sized (i.e., up
to 64k in size) and guaranteed to remain all zeroes, so empty_zero_page
could actually be an alias for that. This is what I had in a previous
revision, before you turned the empty_zero_page definition into common
code:
https://lore.kernel.org/all/20260320145934.2349881-16-ardb+git@google.com/
^ permalink raw reply
* Re: [PATCH v4 2/2] coco: guest: arm64: Drop dummy RSI platform device stub
From: Aneesh Kumar K.V @ 2026-05-13 8:53 UTC (permalink / raw)
To: Greg KH
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Jeremy Linton,
Jonathan Cameron, Lorenzo Pieralisi, Mark Rutland, Sudeep Holla,
Will Deacon, Jonathan Cameron, Suzuki K Poulose
In-Reply-To: <2026051352-albatross-contents-7113@gregkh>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Wed, May 13, 2026 at 12:28:12PM +0530, Aneesh Kumar K.V wrote:
>> Catalin Marinas <catalin.marinas@arm.com> writes:
>>
>> > + Suzuki again
>> >
>> > On Mon, Apr 27, 2026 at 11:46:15AM +0530, Aneesh Kumar K.V (Arm) wrote:
>> >> The SMCCC firmware driver now creates the `arm-smccc` platform device
>> >> and also creates the CCA auxiliary devices once the RSI ABI is
>> >> discovered. This makes the arch-specific arm64_create_dummy_rsi_dev()
>> >> helper redundant. Remove the arm-cca-dev platform device registration
>> >> and let the SMCCC probe manage the RSI device.
>> >>
>> >> systemd match on platform:arm-cca-dev for confidential vm detection [1].
>> >> Losing the platform device registration can break that. Keeping this
>> >> removal in its own change makes it easy to revert if that regression
>> >> blocks the rollout.
>> >>
>> >> [1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
>> >
>> > I wouldn't merge this now given that systemd checks this file. Could we
>> > have a symbolic link instead for some time until systemd eventually gets
>> > updated (years?).
>> >
>>
>> I’ll add this in the next revision.
>>
>> static int create_rsi_compat_link(struct device *target_dev)
>> {
>> struct kobject *platform_kobj;
>> /*
>> * target_dev is:
>> * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
>> * Create compat link /sys/devices/platform/arm-cca-dev
>> */
>> platform_kobj = target_dev->kobj.parent->parent;
>
> What? That is crazy, you don't know that is always going to be ok.
>
>> return sysfs_create_link(platform_kobj,
>> &target_dev->kobj,
>> "arm-cca-dev");
>
> No, don't do that, if a driver calls a sysfs* function, something is
> almost always wrong. Don't be making random sysfs symlinks please.
>
Sure, but could you explain why this is wrong? Below is the full version
of the updated patch.
coco: guest: arm64 Replace RSI platform device with compat symlink
The SMCCC firmware driver now creates the arm-smccc platform device and
registers the RSI device as an auxiliary device once the RSI ABI has been
discovered. This makes the arch-specific arm64 arm-cca-dev platform device
redundant.
Remove the arm64 platform device stub and let the SMCCC core manage RSI
device creation.
This changes the real device location from the old platform device path to:
/sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
Keep userspace compatibility by creating a sysfs symlink at the old path:
/sys/devices/platform/arm-cca-dev
A Debian Code Search check found systemd matching on the old
platform:arm-cca-dev device path for confidential VM detection. No other
userspace dependency on the old platform device path was found, but keeping
the compatibility symlink avoids breaking existing systemd-based detection
[1].
[1] https://lore.kernel.org/all/4a7d84b2-2ec4-4773-a2d5-7b63d5c683cf@arm.com
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
modified arch/arm64/kernel/rsi.c
@@ -159,18 +159,3 @@ void __init arm64_rsi_init(void)
static_branch_enable(&rsi_present);
}
-
-static struct platform_device rsi_dev = {
- .name = "arm-cca-dev",
- .id = PLATFORM_DEVID_NONE
-};
-
-static int __init arm64_create_dummy_rsi_dev(void)
-{
- if (is_realm_world() &&
- platform_device_register(&rsi_dev))
- pr_err("failed to register rsi platform device\n");
- return 0;
-}
-
-arch_initcall(arm64_create_dummy_rsi_dev)
modified drivers/firmware/smccc/rmm.c
@@ -4,13 +4,31 @@
*/
#include <linux/auxiliary_bus.h>
+#include <linux/sysfs.h>
+#include <linux/device.h>
#include "rmm.h"
+static int create_rsi_compat_link(struct device *target_dev)
+{
+ struct kobject *platform_kobj;
+ /*
+ * target_dev is:
+ * /sys/devices/platform/arm-smccc/arm_cca_guest.arm-rsi-dev.0
+ * Create compat link /sys/devices/platform/arm-cca-dev
+ */
+ platform_kobj = target_dev->kobj.parent->parent;
+
+ return sysfs_create_link(platform_kobj,
+ &target_dev->kobj,
+ "arm-cca-dev");
+}
+
void __init register_rsi_device(struct platform_device *pdev)
{
unsigned long ret;
unsigned long ver_lower, ver_higher;
+ struct auxiliary_device *adev;
if (arm_smccc_1_1_get_conduit() != SMCCC_CONDUIT_SMC)
return;
@@ -19,6 +37,10 @@ void __init register_rsi_device(struct platform_device *pdev)
if (ret != RSI_SUCCESS)
return;
- __devm_auxiliary_device_create(&pdev->dev,
- "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+ adev = __devm_auxiliary_device_create(&pdev->dev,
+ "arm_cca_guest", RSI_DEV_NAME, NULL, 0);
+ if (!adev)
+ return;
+
+ create_rsi_compat_link(&adev->dev);
}
>
> If userspace can not find the device anymore, that's fine, that's how
> sysfs works, devices move around all the time. Especially platform
> devices as those are almost always not supposed to be platform devices :)
>
> thanks,
>
> greg k-h
-aneesh
^ permalink raw reply
* Re: [PATCH 09/10] clk: amlogic: Add A9 peripherals clock controller driver
From: Jian Hu @ 2026-05-13 8:50 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <agH4_gClJW8CVV75@redhat.com>
On 5/11/2026 11:42 PM, Brian Masney wrote:
> [ EXTERNAL EMAIL ]
>
> Hi Jian,
>
> On Mon, May 11, 2026 at 08:47:31PM +0800, Jian Hu via B4 Relay wrote:
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the peripherals clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/Kconfig | 15 +
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/a9-peripherals.c | 2317 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 2333 insertions(+)
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index 3549e67d6988..48a15a5e1323 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -145,6 +145,21 @@ config COMMON_CLK_A9_PLL
>> device, AKA A9. PLLs are required by most peripheral to operate.
>> Say Y if you want A9 PLL clock controller to work.
>>
>> +config COMMON_CLK_A9_PERIPHERALS
>> + tristate "Amlogic A9 SoC peripherals clock controller support"
>> + depends on ARM64
> depends on ARM64 || COMPILE_TEST
Ok, I will add COMPILE_TEST in the next version.
>> + default ARCH_MESON
>> + select COMMON_CLK_MESON_REGMAP
>> + select COMMON_CLK_MESON_CLKC_UTILS
>> + select COMMON_CLK_MESON_DUALDIV
>> + select COMMON_CLK_MESON_VID_PLL_DIV
>> + imply COMMON_CLK_SCMI
>> + imply COMMON_CLK_A9_PLL
>> + help
>> + Support for the peripherals clock controller on Amlogic A311Y3 based
>> + device, AKA A9. Peripherals are required by most peripheral to operate.
>> + Say Y if you want A9 peripherals clock controller to work.
>> +
>> config COMMON_CLK_C3_PLL
>> tristate "Amlogic C3 PLL clock controller"
>> depends on ARM64
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 77636033061f..2b5b67b14efc 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
>> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_A9_PLL) += a9-pll.o
>> +obj-$(CONFIG_COMMON_CLK_A9_PERIPHERALS) += a9-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_C3_PLL) += c3-pll.o
>> obj-$(CONFIG_COMMON_CLK_C3_PERIPHERALS) += c3-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>> diff --git a/drivers/clk/meson/a9-peripherals.c b/drivers/clk/meson/a9-peripherals.c
>> new file mode 100644
>> index 000000000000..338a91c473ea
>> --- /dev/null
>> +++ b/drivers/clk/meson/a9-peripherals.c
>> @@ -0,0 +1,2317 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>> +/*
>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> + */
>> +
>> +#include <linux/clk-provider.h>
>> +#include <linux/platform_device.h>
>> +#include <dt-bindings/clock/amlogic,a9-peripherals-clkc.h>
>> +#include "clk-regmap.h"
>> +#include "clk-dualdiv.h"
>> +#include "vid-pll-div.h"
>> +#include "meson-clkc-utils.h"
> Sort the headers.
Ok, I will place them in order.
After updated:
#include <dt-bindings/clock/amlogic,a9-peripherals-clkc.h>
#include <linux/clk-provider.h>
#include <linux/platform_device.h>
#include "clk-regmap.h"
#include "clk-dualdiv.h"
#include "meson-clkc-utils.h"
#include "vid-pll-div.h"
[......]
>> +static const struct clk_parent_data a9_nna_parents[] = {
>> + { .fw_name = "xtal", },
>> + { .fw_name = "fdiv2p5", },
>> + { .fw_name = "fdiv4", },
>> + { .fw_name = "fdiv3", },
>> + { .fw_name = "fdiv5", },
>> + { .fw_name = "fdiv2", },
>> + { .fw_name = "gp2", },
>> + { .fw_name = "hifi", }
> hifi isn't in the dt bindings. Should this be hifi0 and/or hifi1?
It should be hifi0，I will fix it in the next version.
Thank you for pointing it out.
[......]
>> +
>> +static struct clk_regmap a9_sc = {
>> + .data = &(struct clk_regmap_div_data) {
>> + .offset = SC_CLK_CTRL,
>> + .shift = 16,
>> + .width = 4,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "sc",
>> + .ops = &clk_regmap_divider_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_sc_pre.hw
>> + },
>> + .num_parents = 1,
>> + .flags = CLK_SET_RATE_PARENT,
>> + },
> You can use CLK_HW_INIT_HWS() here.
>
> Brian
Ok, I will use CLK_HW_INIT_HWS instead, and the same below.
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v4 02/15] mm: Make empty_zero_page __ro_after_init
From: Mike Rapoport @ 2026-05-13 8:50 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Jann Horn, Ard Biesheuvel, linux-arm-kernel, linux-kernel,
Will Deacon, Catalin Marinas, Mark Rutland, Ryan Roberts,
Anshuman Khandual, Liz Prucka, Seth Jenkins, Kees Cook,
David Hildenbrand, Andrew Morton, linux-mm, linux-hardening
In-Reply-To: <fb5749bb-bc87-4f0b-9ec9-8a1eb7ded3b5@app.fastmail.com>
On Tue, May 12, 2026 at 02:56:16PM +0200, Ard Biesheuvel wrote:
> On Mon, 11 May 2026, at 16:40, Jann Horn wrote:
> > On Mon, May 11, 2026 at 10:59 AM Ard Biesheuvel <ardb@kernel.org> wrote:
> >> I think we should simply do something along the lines of the below,
> >> considering that the size of a data object tends to correlate with
> >> its minimum alignment.
> >>
> >> I do find it rather puzzling that the compiler emits empty_zero_page
> >> *after* zero_page_pfn - ideally, we'd combine the below with
> >> -fdata-sections so that the linker sees all individual objects, but
> >> I suspect that would create some problems elsewhere.
> >>
> >>
> >> --- a/include/asm-generic/vmlinux.lds.h
> >> +++ b/include/asm-generic/vmlinux.lds.h
> >> @@ -452,7 +452,7 @@
> >> #define RO_AFTER_INIT_DATA \
> >> . = ALIGN(8); \
> >> __start_ro_after_init = .; \
> >> - *(.data..ro_after_init) \
> >> + *(SORT_BY_ALIGNMENT(.data..ro_after_init)) \
> >
> > Oh, neat, I didn't realize that's possible. That seems like a nicer
> > approach...
>
> Neat but rather ineffective, unfortunately. (I don't see a size
> difference with the arm64 defconfig kernel)
>
> Given that empty_zero_page only ever gets its address taken, we
> might just move it into the linker script if that requires tweaking
> anyway. We can just place it at the start of .rodata, which is
> already page aligned on most architectures (and will become page
> aligned unless EMPTY_ZERO_PAGE is #define'd by the arch linker
> script to something else)
>
>
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -472,6 +472,17 @@
> #endif
> #endif
>
> +#ifndef EMPTY_ZERO_PAGE
> +#ifndef __HAVE_COLOR_ZERO_PAGE
I don't think we want let architectures that don't use colored zero pages
redefine it.
If it will be really required we can add the ability to redefine
EMPTY_ZERO_PAGE later.
> +#define EMPTY_ZERO_PAGE \
> + . = ALIGN(PAGE_SIZE); \
> + empty_zero_page = .; \
> + . += PAGE_SIZE;
> +#else
> +#define EMPTY_ZERO_PAGE
> +#endif
> +#endif
> +
> /*
> * Read only Data
> */
> @@ -479,6 +490,7 @@
> . = ALIGN((align)); \
> .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \
> __start_rodata = .; \
> + EMPTY_ZERO_PAGE \
> *(.rodata) *(.rodata.*) *(.data.rel.ro*) \
> SCHED_DATA \
>
--
Sincerely yours,
Mike.
^ 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