* Re: [PATCH net] net: airoha: dma map xmit frags with skb_frag_dma_map()
From: patchwork-bot+netdevbpf @ 2026-06-27 22:50 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260625-airoha-eth-skb_frag_dma_map-v1-1-31d9e460aae6@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 25 Jun 2026 11:42:46 +0200 you wrote:
> Map xmit skb fragments using skb_frag_dma_map() instead of
> dma_map_single(skb_frag_address()). skb_frag_address() relies on
> page_address() to obtain a kernel virtual address, which is not
> guaranteed to work for all page types (e.g. highmem pages or
> user-pinned pages from MSG_ZEROCOPY).
> skb_frag_dma_map() maps the fragment directly via its struct page and
> offset through dma_map_page(), avoiding the need for a kernel virtual
> address entirely.
> Introduce an enum airoha_dma_map_type to track how each queue entry was
> mapped (single vs page), so that the matching unmap function is called
> on completion and in error paths.
>
> [...]
Here is the summary with links:
- [net] net: airoha: dma map xmit frags with skb_frag_dma_map()
https://git.kernel.org/netdev/net/c/32f1c2bbb26a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver
From: David Lechner @ 2026-06-27 20:52 UTC (permalink / raw)
To: Chi-Wen Weng, jic23, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-3-cwweng.linux@gmail.com>
On 6/25/26 6:06 AM, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add an IIO driver for the Nuvoton MA35D1 Enhanced ADC controller.
>
> The driver supports direct raw reads and triggered buffered capture. The
> controller end-of-conversion interrupt is exposed as the device trigger
> and is used to push samples into the IIO buffer.
>
> Channels are described by firmware child nodes and can be configured as
> single-ended or differential inputs. Since the differential enable bit is
> global, mixed single-ended and differential buffered scans are rejected.
>
> DMA support is intentionally not included in this initial upstream driver;
> conversions are handled through the interrupt-driven path.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> ---
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ma35d1_eadc.c | 636 ++++++++++++++++++++++++++++++++++
> 3 files changed, 647 insertions(+)
> create mode 100644 drivers/iio/adc/ma35d1_eadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 1c663c98c6c9..43409999a94b 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -981,6 +981,16 @@ config LTC2497
> To compile this driver as a module, choose M here: the module will be
> called ltc2497.
>
> +config MA35D1_EADC
> + tristate "MA35D1 EADC driver"
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say yes here to build support for MA35D1 EADC.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called ma35d1.
> +
> config MAX1027
> tristate "Maxim max1027 ADC driver"
> depends on SPI
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 707dd708912f..7b9b38688223 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -85,6 +85,7 @@ obj-$(CONFIG_LTC2471) += ltc2471.o
> obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_LTC2496) += ltc2496.o ltc2497-core.o
> obj-$(CONFIG_LTC2497) += ltc2497.o ltc2497-core.o
> +obj-$(CONFIG_MA35D1_EADC) += ma35d1_eadc.o
> obj-$(CONFIG_MAX1027) += max1027.o
> obj-$(CONFIG_MAX11100) += max11100.o
> obj-$(CONFIG_MAX1118) += max1118.o
> diff --git a/drivers/iio/adc/ma35d1_eadc.c b/drivers/iio/adc/ma35d1_eadc.c
> new file mode 100644
> index 000000000000..0c075126e139
> --- /dev/null
> +++ b/drivers/iio/adc/ma35d1_eadc.c
> @@ -0,0 +1,636 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Nuvoton MA35D1 EADC driver
> + *
> + * Copyright (c) 2026 Nuvoton Technology Corp.
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +#include <linux/bitmap.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +#include <linux/property.h>
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/iio.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +
> +#define MA35D1_EADC_DAT(n) (0x00 + (n) * 0x04)
> +#define MA35D1_EADC_CTL 0x50
> +#define MA35D1_EADC_SWTRG 0x54
> +#define MA35D1_EADC_SCTL(n) (0x80 + (n) * 0x04)
> +#define MA35D1_EADC_INTSRC0 0xd0
> +#define MA35D1_EADC_STATUS2 0xf8
> +#define MA35D1_EADC_SELSMP0 0x140
> +#define MA35D1_EADC_REFADJCTL 0x150
> +
> +#define MA35D1_EADC_CTL_ADCEN BIT(0)
> +#define MA35D1_EADC_CTL_ADCIEN0 BIT(2)
> +#define MA35D1_EADC_CTL_DIFFEN BIT(8)
> +
> +#define MA35D1_EADC_SCTL_CHSEL_MASK GENMASK(3, 0)
> +#define MA35D1_EADC_SCTL_TRGDLY_MASK GENMASK(15, 8)
> +#define MA35D1_EADC_SCTL_TRGSEL_MASK GENMASK(21, 16)
> +#define MA35D1_EADC_SCTL_TRGSEL_ADINT0 \
> + FIELD_PREP(MA35D1_EADC_SCTL_TRGSEL_MASK, 2)
> +
> +#define MA35D1_EADC_DAT_MASK GENMASK(11, 0)
> +#define MA35D1_EADC_STATUS2_ADIF0 BIT(0)
> +#define MA35D1_EADC_INTSRC0_ADINT0 BIT(0)
> +#define MA35D1_EADC_REFADJCTL_EXT_VREF BIT(0)
> +
> +#define MA35D1_EADC_MAX_CHANNELS 9
> +#define MA35D1_EADC_MAX_SAMPLE_MODULES 16
> +#define MA35D1_EADC_CHAN_NAME_LEN 16
> +#define MA35D1_EADC_TIMEOUT msecs_to_jiffies(1000)
> +
> +struct ma35d1_adc {
> + struct device *dev;
It looks like this is never used, so we can drop it.
> + void __iomem *regs;
> + struct clk *clk;
> + struct completion completion;
> + /* Protects direct conversions against concurrent register access. */
> + struct mutex lock;
> + struct iio_trigger *trig;
> + unsigned int scan_chancnt;
> + bool scan_differential;
> + char chan_name[MA35D1_EADC_MAX_CHANNELS][MA35D1_EADC_CHAN_NAME_LEN];
> + struct {
> + u16 channels[MA35D1_EADC_MAX_SAMPLE_MODULES];
> + aligned_s64 timestamp;
> + } scan;
Unless the hardware requires all channels to be read at once, we should
use this instead:
IIO_DECLARE_BUFFER_WITH_TS(u16, scan, MA35D1_EADC_MAX_SAMPLE_MODULES);
It means an array with enough room for MA35D1_EADC_MAX_SAMPLE_MODULES u16
data points plus an aligned timestamp, but doesn't specify where the
timestamp will be as it could be in a different place depending on how
many channels are read.
Also, this is only used in one function, so can just be stack-allocated
in that function (with ` = { };` to zero it) instead of allocating it here.
> +};
> +
> +static inline u32 ma35d1_adc_read(struct ma35d1_adc *adc, u32 reg)
> +{
> + return readl(adc->regs + reg);
> +}
> +
> +static inline void ma35d1_adc_write(struct ma35d1_adc *adc, u32 reg, u32 val)
> +{
> + writel(val, adc->regs + reg);
> +}
> +
> +static void ma35d1_adc_rmw(struct ma35d1_adc *adc, u32 reg, u32 mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp = ma35d1_adc_read(adc, reg);
> + tmp &= ~mask;
> + tmp |= val;
> + ma35d1_adc_write(adc, reg, tmp);
> +}
Why not use regmap?
> +
> +static void ma35d1_adc_set_diff(struct ma35d1_adc *adc, bool differential)
> +{
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_DIFFEN,
> + differential ? MA35D1_EADC_CTL_DIFFEN : 0);
> +}
> +
> +static void ma35d1_adc_config_sample(struct ma35d1_adc *adc,
> + unsigned int sample, unsigned int channel)
> +{
> + u32 reg = MA35D1_EADC_SCTL(sample);
> +
> + ma35d1_adc_rmw(adc, reg,
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK, channel) |
> + MA35D1_EADC_SCTL_TRGSEL_ADINT0);
> +}
> +
> +static void ma35d1_adc_disable_irq(struct ma35d1_adc *adc)
> +{
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0, 0);
> +}
> +
> +static void ma35d1_adc_hw_init(struct ma35d1_adc *adc)
> +{
> + ma35d1_adc_disable_irq(adc);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL,
> + MA35D1_EADC_CTL_ADCEN, MA35D1_EADC_CTL_ADCEN);
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
As mentioned elsewhere, external reference doesn't make sense unless
we can get the reference voltage from it.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
> +}
> +
> +static void ma35d1_adc_hw_disable(void *data)
> +{
> + struct ma35d1_adc *adc = data;
> +
> + ma35d1_adc_disable_irq(adc);
ma35d1_adc_hw_init() doesn't enable the IRQ, so this seems a bit unbalanced.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCEN, 0);
> +}
> +
> +static irqreturn_t ma35d1_adc_isr(int irq, void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + u32 status;
> +
> + status = ma35d1_adc_read(adc, MA35D1_EADC_STATUS2);
> + if (!(status & MA35D1_EADC_STATUS2_ADIF0))
> + return IRQ_NONE;
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> +
> + if (iio_buffer_enabled(indio_dev)) {
> + ma35d1_adc_disable_irq(adc);
> + iio_trigger_poll(adc->trig);
> + } else {
> + complete(&adc->completion);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t ma35d1_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
> + adc->scan.channels[i] =
> + ma35d1_adc_read(adc, MA35D1_EADC_DAT(i)) &
> + MA35D1_EADC_DAT_MASK;
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan, pf->timestamp);
> + iio_trigger_notify_done(adc->trig);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int ma35d1_adc_read_conversion(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + long timeout;
> +
> + reinit_completion(&adc->completion);
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(0),
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK,
> + chan->channel));
> + ma35d1_adc_set_diff(adc, chan->differential);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + timeout = wait_for_completion_interruptible_timeout(&adc->completion,
> + MA35D1_EADC_TIMEOUT);
> + ma35d1_adc_disable_irq(adc);
> +
> + if (timeout < 0)
> + return timeout;
> + if (!timeout)
> + return -ETIMEDOUT;
> +
> + *val = ma35d1_adc_read(adc, MA35D1_EADC_DAT(0)) & MA35D1_EADC_DAT_MASK;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> +
> + mutex_lock(&adc->lock);
> + ret = ma35d1_adc_read_conversion(indio_dev, chan, val);
> + mutex_unlock(&adc->lock);
> +
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ma35d1_adc_validate_scan(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + const struct iio_chan_spec *chan;
> + bool have_single = false;
> + bool have_diff = false;
> + unsigned int count = 0;
> + unsigned long bit;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> +
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
Timestamp channel will never be set (it is handled differently), so we
don't need to check here.
> + count++;
> + if (chan->differential)
> + have_diff = true;
> + else
> + have_single = true;
> + }
> +
> + if (!count || count > MA35D1_EADC_MAX_SAMPLE_MODULES)
> + return -EINVAL;
> +
> + if (have_single && have_diff)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_update_scan_mode(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + const struct iio_chan_spec *chan;
> + unsigned int sample = 0;
> + unsigned long bit;
> + bool differential = false;
> + int ret;
> +
> + ret = ma35d1_adc_validate_scan(indio_dev, scan_mask);
> + if (ret)
> + return ret;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
Same here.
> +
> + if (!sample)
> + differential = chan->differential;
> +
> + ma35d1_adc_config_sample(adc, sample, chan->channel);
> + sample++;
> + }
> +
> + adc->scan_chancnt = sample;
> + adc->scan_differential = differential;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + if (!adc->scan_chancnt)
> + return -EINVAL;
Should this even be possible because of ma35d1_adc_validate_scan()?
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
How can we use the external V_REF without knowing what is connected to it?
I would expect this to use internal reference unless the devicetree specified
a vref-supply.
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
There should be a macro to say what field GENMASK(1, 0) is.
> + ma35d1_adc_set_diff(adc, adc->scan_differential);
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGDLY_MASK,
> + MA35D1_EADC_SCTL_TRGDLY_MASK);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + ma35d1_adc_disable_irq(adc);
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGSEL_MASK, 0);
> +
> + return 0;
> +}
> +
> +static const struct iio_buffer_setup_ops ma35d1_adc_buffer_ops = {
> + .postenable = ma35d1_adc_buffer_postenable,
> + .predisable = ma35d1_adc_buffer_predisable,
> +};
> +
> +static const struct iio_info ma35d1_adc_info = {
> + .read_raw = ma35d1_adc_read_raw,
> + .update_scan_mode = ma35d1_adc_update_scan_mode,
> +};
> +
> +static const struct iio_trigger_ops ma35d1_adc_trigger_ops = {
> + .validate_device = iio_trigger_validate_own_device,
> +};
> +
> +static void ma35d1_adc_init_channel(struct ma35d1_adc *adc,
> + struct iio_chan_spec *chan, u32 vinp,
> + u32 vinn, int scan_index, bool differential)
> +{
> + char *name = adc->chan_name[vinp];
> +
> + chan->type = IIO_VOLTAGE;
> + chan->indexed = 1;
> + chan->channel = vinp;
> + chan->address = vinp;
Setting address is reduant if it is always going to be the same as channel.
We can just use channel directly instead. address doesn't appear to be
used anyway.
> + chan->scan_index = scan_index;
> + chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
This should also have IIO_CHAN_INFO_SCALE that is based on the reference source.
> + chan->scan_type.sign = 'u';
This field has a new name:
chan->scan_type.format = IIO_SCAN_FORMAT_UNSIGNED_INT;
> + chan->scan_type.realbits = 12;
> + chan->scan_type.storagebits = 16;
> + chan->scan_type.endianness = IIO_CPU;
> +
> + if (differential) {
> + chan->differential = 1;
> + chan->channel2 = vinn;
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d-in%d", vinp,
> + vinn);
> + } else {
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d", vinp);
> + }
> +
> + chan->datasheet_name = name;
We usually don't use datasheet_name. It would make more sense to implement
labels and get the label from devicetree.
> +}
> +
> +static int ma35d1_adc_parse_channels(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + DECLARE_BITMAP(used_channels, MA35D1_EADC_MAX_CHANNELS);
> + struct fwnode_handle *child;
> + struct iio_chan_spec *channels;
> + int num_channels;
> + int scan_index = 0;
> + int ret;
> +
> + bitmap_zero(used_channels, MA35D1_EADC_MAX_CHANNELS);
> +
> + num_channels = device_get_child_node_count(dev);
> + if (!num_channels)
> + return dev_err_probe(dev, -ENODATA,
> + "no ADC channels configured\n");
> +
> + if (num_channels > MA35D1_EADC_MAX_CHANNELS)
> + return dev_err_probe(dev, -EINVAL, "too many ADC channels\n");
> +
> + channels = devm_kcalloc(dev, num_channels + 1, sizeof(*channels),
> + GFP_KERNEL);
> + if (!channels)
> + return -ENOMEM;
> +
> + device_for_each_child_node(dev, child) {
Can use device_for_each_child_node_scoped() here to avoid needing to put
handle on all return paths.
> + u32 diff[2];
> + u32 reg;
> + bool differential = false;
> +
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "missing channel reg property\n");
> + }
> +
> + if (reg >= MA35D1_EADC_MAX_CHANNELS) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid ADC channel %u\n", reg);
> + }
> +
> + if (test_and_set_bit(reg, used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "duplicate ADC channel %u\n", reg);
> + }
> +
> + if (fwnode_property_present(child, "diff-channels")) {
> + ret = fwnode_property_read_u32_array(child,
> + "diff-channels",
> + diff,
> + ARRAY_SIZE(diff));
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "invalid diff-channels for channel %u\n",
> + reg);
> + }
> +
> + if (diff[0] != reg ||
> + diff[1] >= MA35D1_EADC_MAX_CHANNELS ||
> + diff[0] == diff[1]) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid differential ADC channel %u-%u\n",
> + diff[0], diff[1]);
> + }
> +
> + if (test_and_set_bit(diff[1], used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "ADC channel %u already used\n",
> + diff[1]);
> + }
> +
> + differential = true;
> + }
> +
> + ma35d1_adc_init_channel(adc, &channels[scan_index], reg,
> + differential ? diff[1] : 0,
> + scan_index, differential);
> + scan_index++;
> + }
> +
> + channels[scan_index] = (struct iio_chan_spec)
The macro already includes (struct iio_chan_spec) so we don't need it here.
> + IIO_CHAN_SOFT_TIMESTAMP(scan_index);
> +
> + indio_dev->channels = channels;
> + indio_dev->num_channels = scan_index + 1;
> + indio_dev->masklength = indio_dev->num_channels;
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_setup_trigger(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + adc->trig = devm_iio_trigger_alloc(dev, "%s-trigger", dev_name(dev));
> + if (!adc->trig)
> + return -ENOMEM;
> +
> + adc->trig->ops = &ma35d1_adc_trigger_ops;
> + iio_trigger_set_drvdata(adc->trig, indio_dev);
> +
> + ret = devm_iio_trigger_register(dev, adc->trig);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register trigger\n");
> +
> + ret = iio_trigger_set_immutable(indio_dev, adc->trig);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to set trigger\n");
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct iio_dev *indio_dev;
> + struct ma35d1_adc *adc;
> + int irq;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*adc));
> + if (!indio_dev)
> + return -ENOMEM;
> + adc = iio_priv(indio_dev);
> + adc->dev = dev;
> + mutex_init(&adc->lock);
devm_mutex_init()
> + init_completion(&adc->completion);
> +
> + adc->regs = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(adc->regs))
> + return dev_err_probe(dev, PTR_ERR(adc->regs),
> + "failed to map registers\n");
> +
> + adc->clk = devm_clk_get_enabled(dev, NULL);
> + if (IS_ERR(adc->clk))
> + return dev_err_probe(dev, PTR_ERR(adc->clk),
> + "failed to get and enable ADC clock\n");
> +
> + indio_dev->name = "ma35d1-eadc";
> + indio_dev->modes = INDIO_DIRECT_MODE | INDIO_BUFFER_TRIGGERED;
devm_iio_triggered_buffer_setup() sets the INDIO_BUFFER_TRIGGERED
flag, so we don't need it here.
> + indio_dev->info = &ma35d1_adc_info;
> +
> + ret = ma35d1_adc_parse_channels(indio_dev, dev);
> + if (ret)
> + return ret;
> +
> + ma35d1_adc_hw_init(adc);
> +
> + ret = devm_add_action_or_reset(dev, ma35d1_adc_hw_disable, adc);
> + if (ret)
> + return ret;
> +
> + ret = ma35d1_adc_setup_trigger(indio_dev, dev);
> + if (ret)
> + return ret;
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0)
> + return irq;
> +
> + ret = devm_request_irq(dev, irq, ma35d1_adc_isr, 0, dev_name(dev),
> + indio_dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to request IRQ %d\n", irq);
> +
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + iio_pollfunc_store_time,
> + ma35d1_adc_trigger_handler,
> + &ma35d1_adc_buffer_ops);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to setup triggered buffer\n");
> +
> + platform_set_drvdata(pdev, indio_dev);
> +
> + ret = devm_iio_device_register(dev, indio_dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register IIO device\n");
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_suspend(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> +
> + if (iio_buffer_enabled(indio_dev))
> + return -EBUSY;
> +
> + ma35d1_adc_hw_disable(adc);
> + clk_disable_unprepare(adc->clk);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_resume(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int ret;
> +
> + ret = clk_prepare_enable(adc->clk);
> + if (ret)
> + return ret;
> +
> + ma35d1_adc_hw_init(adc);
> +
> + return 0;
> +}
> +
> +static DEFINE_SIMPLE_DEV_PM_OPS(ma35d1_adc_pm_ops,
> + ma35d1_adc_suspend, ma35d1_adc_resume);
> +
> +static const struct of_device_id ma35d1_adc_of_match[] = {
> + { .compatible = "nuvoton,ma35d1-eadc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ma35d1_adc_of_match);
> +
> +static struct platform_driver ma35d1_adc_driver = {
> + .probe = ma35d1_adc_probe,
> + .driver = {
> + .name = "ma35d1-eadc",
> + .of_match_table = ma35d1_adc_of_match,
> + .pm = pm_sleep_ptr(&ma35d1_adc_pm_ops),
> + },
> +};
> +module_platform_driver(ma35d1_adc_driver);
> +
> +MODULE_AUTHOR("Chi-Wen Weng <cwweng@nuvoton.com>");
> +MODULE_DESCRIPTION("Nuvoton MA35D1 EADC driver");
> +MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
From: David Lechner @ 2026-06-27 20:05 UTC (permalink / raw)
To: Chi-Wen Weng, jic23, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-2-cwweng.linux@gmail.com>
On 6/25/26 6:06 AM, Chi-Wen Weng wrote:
> From: Chi-Wen Weng <cwweng@nuvoton.com>
>
> Add devicetree binding for the Enhanced ADC controller found on
> Nuvoton MA35D1 SoCs.
>
> The controller has one register region, one interrupt and one functional
> clock. ADC inputs are described using standard channel child nodes,
> including optional differential channel pairs.
>
> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> ---
> .../bindings/iio/adc/nuvoton,ma35d1-eadc.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> new file mode 100644
> index 000000000000..ae7ad0f7689a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,ma35d1-eadc.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/nuvoton,ma35d1-eadc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Nuvoton MA35D1 Enhanced Analog to Digital Converter
> +
> +maintainers:
> + - Chi-Wen Weng <cwweng@nuvoton.com>
> +
> +description: |
> + The Nuvoton MA35D1 Enhanced Analog to Digital Converter (EADC) is a
> + 12-bit ADC controller integrated in the MA35D1 SoC. Each enabled ADC
> + input is described by a child channel node.
> +
> +properties:
> + compatible:
> + const: nuvoton,ma35d1-eadc
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
Datasheet says there are 4 interrupts.
> +
> + clocks:
> + maxItems: 1
Should there be an optional vref-supply for the V_REF pin?
Should there be a dmas property? Datasheet says it supports
PDMA transfer.
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> +patternProperties:
> + '^channel@[0-8]$':
> + type: object
> + $ref: adc.yaml
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + minimum: 0
> + maximum: 8
I assume 8 is for the internal batter voltage channel? Often, we don't
include fixed internal channels like this in the devicetree since they
are always the same and don't depend on external wiring.
> +
> + diff-channels:
> + minItems: 2
> + maxItems: 2
adc.yaml already specifies minItems and maxItems, so we don't need to repeat it.
> + items:
> + minimum: 0
> + maximum: 8
This (and reg) are uint32, so don't really need minimum: 0.
Also, I assume that 8 is for the internal battery voltage channel, which
wouldn't make sense as part of a differential input.
> +
> + required:
> + - reg
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - '#address-cells'
> + - '#size-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + adc@40430000 {
> + compatible = "nuvoton,ma35d1-eadc";
> + reg = <0x0 0x40430000 0x0 0x10000>;
> + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk EADC_GATE>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@0 {
> + reg = <0>;
> + };
> +
> + channel@1 {
> + reg = <1>;
> + };
> +
> + channel@2 {
> + reg = <2>;
> + diff-channels = <2 3>;
> + };
> + };
> + };
> +...
^ permalink raw reply
* Re: [PATCH] Documentation: parport-lowlevel: Fix curly bracket
From: Randy Dunlap @ 2026-06-27 18:13 UTC (permalink / raw)
To: Manuel Ebner, Sudip Mukherjee, Jonathan Corbet, Shuah Khan,
Andreas Faerber, Manivannan Sadhasivam, open list:DOCUMENTATION,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE,
moderated list:ARM/ACTIONS SEMI ARCHITECTURE, open list
In-Reply-To: <20260627092359.30044-3-manuelebner@mailbox.org>
On 6/27/26 2:24 AM, Manuel Ebner wrote:
> Remove needless '}'
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/driver-api/parport-lowlevel.rst | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/driver-api/parport-lowlevel.rst b/Documentation/driver-api/parport-lowlevel.rst
> index a907e279f509..af73741289c9 100644
> --- a/Documentation/driver-api/parport-lowlevel.rst
> +++ b/Documentation/driver-api/parport-lowlevel.rst
> @@ -341,7 +341,6 @@ EXAMPLE
> /* Try to detect a device on the port... */
> ...
> }
> - }
>
> ...
> }
--
~Randy
^ permalink raw reply
* Re: [PATCH] fix: clk/samsung: exynos_clkout_probe: success path leaks parent clock references from of_clk_get_by_name
From: Greg KH @ 2026-06-27 17:26 UTC (permalink / raw)
To: WenTao Liang
Cc: krzk, s.nawrocki, cw00.choi, mturquette, sboyd, alim.akhtar,
bmasney, linux-samsung-soc, linux-clk, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <10D15C29-89E4-4A0B-BB89-F03A86963DDA@iscas.ac.cn>
On Sat, Jun 27, 2026 at 07:42:36PM +0800, WenTao Liang wrote:
>
>
> > 2026年6月26日 22:24，Greg KH <gregkh@linuxfoundation.org> 写道：
> >
> > On Fri, Jun 26, 2026 at 08:01:35PM +0800, WenTao Liang wrote:
> >> of_clk_get_by_name() acquires clock references stored in the local
> >> parents[] array. All error paths correctly release these via the clks_put
> >> label, but the success path returns 0 without releasing the parent
> >> references. The references were only needed to obtain clock names for
> >> registration and are permanently leaked after probe completes.
> >>
> >> Cc: stable@vger.kernel.org
> >> Fixes: 9484f2cb8332 ("clk: samsung: exynos-clkout: convert to module driver")
> >> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
> >> ---
> >> drivers/clk/samsung/clk-exynos-clkout.c | 4 ++++
> >> 1 file changed, 4 insertions(+)
> >
> > For all of these, you are not using the normal kernel style, which means
> > a LLM is generating them, which implies that you did not properly
> > document what tool found/fixed all of these. So please go back and fix
> > them all up and resend them properly, after telling the
> > maintainers/developers that the originals should be ignored.
> >
> > thanks,
> >
> > greg k-h
>
>
>
> Thank you for the review and guidance. I understand the issues now.
>
> I will:
> 1. Study the proper kernel coding style
> 2. If using any automated tools, document them properly in the commit
> message
> 3. Fix all the patches following the correct style
> 4. Send a v2 series with proper version history
> 5. Inform all maintainers that the original patches should be ignored
Do this right now please!
> I apologize for the inconvenience and will ensure future submissions
> follow all kernel submission guidelines properly.
Also try learning this by doing just a few patches first, not hundreds,
otherwise you run the risk of being outright banned from development.
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH v2 5.15.y] kselftest/arm64: signal: Skip SVE signal test if not enough VLs supported
From: Sasha Levin @ 2026-06-27 16:35 UTC (permalink / raw)
To: stable, gregkh
Cc: Sasha Levin, andre.przywara, linux-kernel, cristian.marussi, will,
catalin.marinas, broonie, shuah, linux-arm-kernel,
linux-kselftest, Yijia Wang
In-Reply-To: <20260627032259.2086191-1-wangyijia.yeah@bytedance.com>
On Sat, 27 Jun 2026 11:22 +0800, Yijia Wang <wangyijia.yeah@bytedance.com> wrote:
> [PATCH v2 5.15.y] kselftest/arm64: signal: Skip SVE signal test if not enough VLs supported
Queued for 5.15.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 3/3] dmaengine: xilinx_dma: Optimize control register write and channel start logic for AXIDMA and MCDMA in corresponding start_transfer()
From: Pandey, Radhey Shyam @ 2026-06-27 16:32 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-4-suraj.gupta2@amd.com>
> Optimize AXI DMA control register programming by consolidating
> coalesce count and delay configuration into a single register write.
> Previously, the coalesce count was written separately from the delay
> configuration, resulting in two register writes. Combine these into
> one write operation to reduce bus overhead.
> Additionally, avoid redundant channel starts in xilinx_dma_start_transfer()
> and xilinx_mcdma_start_transfer() by only calling xilinx_dma_start() when
> the channel is actually idle.
>
> Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> ---
> drivers/dma/xilinx/xilinx_dma.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 6e7b183cb499..829601d8a16f 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1603,7 +1603,6 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> reg &= ~XILINX_DMA_CR_COALESCE_MAX;
> reg |= chan->desc_pendingcount <<
> XILINX_DMA_CR_COALESCE_SHIFT;
> - dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
> }
>
> if (chan->has_sg && list_empty(&chan->active_list))
> @@ -1614,7 +1613,8 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> reg |= XILINX_DMA_DMAXR_ALL_IRQ_MASK;
> dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
>
> - xilinx_dma_start(chan);
> + if (chan->idle)
> + xilinx_dma_start(chan);
>
> if (chan->err)
> return;
> @@ -1703,7 +1703,8 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> reg |= XILINX_MCDMA_CR_RUNSTOP_MASK;
> dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
>
> - xilinx_dma_start(chan);
> + if (chan->idle)
> + xilinx_dma_start(chan);
>
> if (chan->err)
> return;
^ permalink raw reply
* Re: [PATCH v3 2/3] dmaengine: xilinx_dma: Enable transfer chaining for AXIDMA and MCDMA by removing idle restriction
From: Pandey, Radhey Shyam @ 2026-06-27 16:29 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-3-suraj.gupta2@amd.com>
> Relax the idle check in xilinx_dma_start_transfer() and
> xilinx_mcdma_start_transfer() that prevented new transfers from being
> queued when the channel was busy, so scatter-gather transfers can be
> chained onto an in-flight transfer.
>
> In scatter-gather mode, only update the CURDESC register when the active
> list is empty to avoid interfering with transfers already in progress.
> When the active list contains transfers, the hardware tail pointer
> extension mechanism handles chaining automatically via the descriptor
> next pointer chain, which is set up at channel allocation and preserved
> across descriptor recycling.
>
> Direct (non-SG) mode has no descriptor queue: writing the BTT register
> launches a transfer immediately, so a new transfer must not be programmed
> while one is in flight. Keep those transfers serialized by retaining the
> idle check on the non-SG path. MCDMA always operates in scatter-gather
> mode, so it is unaffected.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> ---
> drivers/dma/xilinx/xilinx_dma.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index ca396b709742..6e7b183cb499 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1580,7 +1580,14 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> return;
> }
>
> - if (!chan->idle)
> + /*
> + * Direct (non-SG) mode has no descriptor queue: writing the BTT
> + * register launches a transfer immediately, so a new transfer must
> + * not be programmed while one is in flight. Keep such transfers
> + * serialized. SG mode supports chaining onto a running transfer via
> + * tail-pointer extension, so it is allowed to proceed when busy.
> + */
> + if (!chan->has_sg && !chan->idle)
> return;
>
> head_desc = list_first_entry(&chan->pending_list,
> @@ -1599,7 +1606,7 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
> }
>
> - if (chan->has_sg)
> + if (chan->has_sg && list_empty(&chan->active_list))
> xilinx_write(chan, XILINX_DMA_REG_CURDESC,
> head_desc->async_tx.phys);
> reg &= ~XILINX_DMA_CR_DELAY_MAX;
> @@ -1660,9 +1667,6 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->err)
> return;
>
> - if (!chan->idle)
> - return;
> -
> if (list_empty(&chan->pending_list))
> return;
>
> @@ -1685,8 +1689,9 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
>
> /* Program current descriptor */
> - xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
> - head_desc->async_tx.phys);
> + if (chan->has_sg && list_empty(&chan->active_list))
> + xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
> + head_desc->async_tx.phys);
>
> /* Program channel enable register */
> reg = dma_ctrl_read(chan, XILINX_MCDMA_CHEN_OFFSET);
^ permalink raw reply
* Re: [PATCH v3 1/3] dmaengine: xilinx_dma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers
From: Pandey, Radhey Shyam @ 2026-06-27 16:29 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek, dev
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-2-suraj.gupta2@amd.com>
> Fix a race condition in AXIDMA and MCDMA irq handlers where the channel
> could be incorrectly marked as idle and attempt spurious transfers when
> descriptors are still being processed.
>
> The issue occurs when:
> 1. Multiple descriptors are queued and active.
> 2. An interrupt fires after completing some descriptors.
> 3. xilinx_dma_complete_descriptor() moves completed descriptors to
> done_list.
> 4. Channel is marked idle and start_transfer() is called even though
> active_list still contains unprocessed descriptors.
> 5. This leads to premature transfer attempts and potential descriptor
> corruption or missed completions.
>
> Only mark the channel as idle and start new transfers when the active list
> is actually empty, ensuring proper channel state management and avoiding
> spurious transfer attempts.
>
> Fixes: c0bba3a99f07 ("dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine")
> Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> ---
> drivers/dma/xilinx/xilinx_dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 404235c17353..ca396b709742 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1893,8 +1893,10 @@ static irqreturn_t xilinx_mcdma_irq_handler(int irq, void *data)
> if (status & XILINX_MCDMA_IRQ_IOC_MASK) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> - chan->idle = true;
> - chan->start_transfer(chan);
> + if (list_empty(&chan->active_list)) {
> + chan->idle = true;
> + chan->start_transfer(chan);
> + }
> spin_unlock(&chan->lock);
> }
>
> @@ -1950,8 +1952,10 @@ static irqreturn_t xilinx_dma_irq_handler(int irq, void *data)
> XILINX_DMA_DMASR_DLY_CNT_IRQ)) {
> spin_lock(&chan->lock);
> xilinx_dma_complete_descriptor(chan);
> - chan->idle = true;
> - chan->start_transfer(chan);
> + if (list_empty(&chan->active_list)) {
> + chan->idle = true;
> + chan->start_transfer(chan);
> + }
> spin_unlock(&chan->lock);
> }
>
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Radhey Shyam Pandey as ZynqMP PHY maintainer
From: Radhey Shyam Pandey @ 2026-06-27 16:22 UTC (permalink / raw)
To: laurent.pinchart, tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Radhey Shyam Pandey
I am maintaining phy-zynqmp driver in xilinx tree and would like to
maintain it in the mainline kernel as well. Hence adding myself as a
maintainer.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1705eb823dd0..90dd86437c5c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29645,6 +29645,7 @@ F: drivers/edac/zynqmp_edac.c
XILINX ZYNQMP PSGTR PHY DRIVER
M: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+M: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
L: linux-kernel@vger.kernel.org
S: Supported
T: git https://github.com/Xilinx/linux-xlnx.git
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 3/3] phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Nava kishore Manne,
stable, Radhey Shyam Pandey
In-Reply-To: <20260627155229.2791113-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
USB Gen1 requires scrambling and 8b/10b encoding to be performed in the
physical layer. Do not bypass PHY-side scrambler or encoder/decoder for
USB operation, as mandated by the USB 3.x specification.
Scrambler and 8b/10b bypass remain restricted to SATA and SGMII
modes, where encoding is handled in the controller.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 39 ++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index 6c56c4df8523..087fe402e4e2 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -502,15 +502,30 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
}
}
-/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
-static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
+/**
+ * xpsgtr_bypass_scrambler_8b10b - Configure scrambler/encoder behavior
+ * @gtr_phy: pointer to lane context
+ * @bypass: true to enable scrambler/encoder bypass (SATA/SGMII),
+ * false to disable scrambler/encoder bypass (USB3)
+ *
+ * Uses RMW to preserve reserved and unrelated register fields.
+ */
+static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy,
+ bool bypass)
{
- xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
- L0_TM_DIS_DESCRAMBLE_DECODER,
- L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
- L0_TM_DISABLE_SCRAMBLE_ENCODER,
- L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ if (bypass) {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ } else {
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER, 0);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER, 0);
+ }
}
/* DP-specific initialization. */
@@ -531,7 +546,7 @@ static void xpsgtr_phy_init_sata(struct xpsgtr_phy *gtr_phy)
{
struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
writel(gtr_phy->lane, gtr_dev->siou + SATA_CONTROL_OFFSET);
}
@@ -547,7 +562,7 @@ static void xpsgtr_phy_init_sgmii(struct xpsgtr_phy *gtr_phy)
xpsgtr_clr_set(gtr_dev, TX_PROT_BUS_WIDTH, mask, val);
xpsgtr_clr_set(gtr_dev, RX_PROT_BUS_WIDTH, mask, val);
- xpsgtr_bypass_scrambler_8b10b(gtr_phy);
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, true);
}
/* Configure TX de-emphasis and margining for DP. */
@@ -707,6 +722,10 @@ static int xpsgtr_phy_init(struct phy *phy)
case ICM_PROTOCOL_SGMII:
xpsgtr_phy_init_sgmii(gtr_phy);
break;
+
+ case ICM_PROTOCOL_USB:
+ xpsgtr_bypass_scrambler_8b10b(gtr_phy, false);
+ break;
}
out:
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 2/3] phy: zynqmp: use read-modify-write for SERDES scrambler bypass
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Nava kishore Manne,
stable, Radhey Shyam Pandey
In-Reply-To: <20260627155229.2791113-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which performs
a full register write, silently clearing any bits beyond the intended
bypass control fields.
Switch to xpsgtr_clr_set_phy() with clr=mask, set=mask to set only
the bypass bits while preserving the remaining bits in each register.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index c037d7c13d48..6c56c4df8523 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -505,8 +505,12 @@ static void xpsgtr_lane_set_protocol(struct xpsgtr_phy *gtr_phy)
/* Bypass (de)scrambler and 8b/10b decoder and encoder. */
static void xpsgtr_bypass_scrambler_8b10b(struct xpsgtr_phy *gtr_phy)
{
- xpsgtr_write_phy(gtr_phy, L0_TM_DIG_6, L0_TM_DIS_DESCRAMBLE_DECODER);
- xpsgtr_write_phy(gtr_phy, L0_TX_DIG_61, L0_TM_DISABLE_SCRAMBLE_ENCODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TM_DIG_6,
+ L0_TM_DIS_DESCRAMBLE_DECODER,
+ L0_TM_DIS_DESCRAMBLE_DECODER);
+ xpsgtr_clr_set_phy(gtr_phy, L0_TX_DIG_61,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER,
+ L0_TM_DISABLE_SCRAMBLE_ENCODER);
}
/* DP-specific initialization. */
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 1/3] phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Nava kishore Manne,
stable, Radhey Shyam Pandey
In-Reply-To: <20260627155229.2791113-1-radhey.shyam.pandey@amd.com>
From: Nava kishore Manne <nava.kishore.manne@amd.com>
The L0_TX_DIG_61 register bit 2 is a reserved read-only field.
The previous mask value 0x0f incorrectly included bit 2, causing
unintended writes to a reserved bit on every scrambler bypass
operation.
Correct the mask to (BIT(3) | GENMASK(1, 0)) to cover only the
valid scramble bypass control bits.
Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver")
Cc: stable@vger.kernel.org
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
drivers/phy/xilinx/phy-zynqmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
index fe6b4925d166..c037d7c13d48 100644
--- a/drivers/phy/xilinx/phy-zynqmp.c
+++ b/drivers/phy/xilinx/phy-zynqmp.c
@@ -53,7 +53,7 @@
#define L0_TM_DIG_6 0x106c
#define L0_TM_DIS_DESCRAMBLE_DECODER 0x0f
#define L0_TX_DIG_61 0x00f4
-#define L0_TM_DISABLE_SCRAMBLE_ENCODER 0x0f
+#define L0_TM_DISABLE_SCRAMBLE_ENCODER (BIT(3) | GENMASK(1, 0))
/* PLL Test Mode register parameters */
#define L0_TM_PLL_DIG_37 0x2094
--
2.43.0
^ permalink raw reply related
* [RESEND PATCH 0/3] phy: zynqmp: fix SERDES scrambler register handling and enable for USB
From: Radhey Shyam Pandey @ 2026-06-27 15:52 UTC (permalink / raw)
To: tomi.valkeinen, vkoul, michal.simek
Cc: linux-kernel, linux-phy, linux-arm-kernel, Radhey Shyam Pandey
This series fixes three related issues in the ZynqMP SERDES PHY
scrambler/encoder bypass path:
1. The L0_TM_DISABLE_SCRAMBLE_ENCODER mask incorrectly included bit 2
of L0_TX_DIG_61, which is a reserved read-only field. Correct the
mask to (BIT(3) | GENMASK(1, 0)).
2. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which
performs a full register write, clobbering unrelated bits. Switch
to xpsgtr_clr_set_phy() with clr=mask, set=mask to preserve other
register fields.
3. USB Gen1 requires PHY-side scrambling and 8b/10b encoding as
mandated by the USB 3.x specification. The driver was incorrectly
bypassing these for USB, the same as SATA and SGMII where encoding
is handled in the controller.
Issues reported by sashiko[1] are pre-existing issues and will
taken as separate followup series.
[1]:
https://lore.kernel.org/all/20260512213513.852EEC2BCB0@smtp.kernel.org
https://lore.kernel.org/all/20260512223142.1AFC4C2BCB0@smtp.kernel.org
Nava kishore Manne (3):
phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
phy: zynqmp: use read-modify-write for SERDES scrambler bypass
phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
drivers/phy/xilinx/phy-zynqmp.c | 37 ++++++++++++++++++++++++++-------
1 file changed, 30 insertions(+), 7 deletions(-)
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
--
2.43.0
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-06-27 14:46 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Josua Mayer,
Dario Binacchi, Alexander Stein, Ernest Van Hoecke,
Maud Spierings, Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1782571383.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX8M-MINI system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Remove HDMI from commit message
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mm-var-dart-sonata.dts | 517 ++++++++++++++++++
2 files changed, 518 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..694c9aa32779 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-prt8mm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tqma8mqml-mba8mx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-mini-111.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony-legacy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
new file mode 100644
index 000000000000..93b0076987b8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
@@ -0,0 +1,517 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX8M-MINI
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mm-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-MINI on Sonata-Board";
+ compatible = "variscite,var-dart-mx8mm-sonata",
+ "variscite,var-dart-mx8mm",
+ "fsl,imx8mm";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led-emmc {
+ gpios = <&gpio4 18 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc2";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ pcie0_refclk: pcie0-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_vmmc_usdhc2>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>,
+ <&gpio1 12 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* Resistive touch controller */
+ ads7846: touchscreen@0 {
+ compatible = "ti,ads7846";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_restouch>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <1500000>;
+ pendown-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ ti,x-min = /bits/ 16 <125>;
+ ti,x-max = /bits/ 16 <4008>;
+ ti,y-min = /bits/ 16 <282>;
+ ti,y-max = /bits/ 16 <3864>;
+ ti,x-plate-ohms = /bits/ 16 <180>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,debounce-max = /bits/ 16 <10>;
+ ti,debounce-tol = /bits/ 16 <3>;
+ ti,debounce-rep = /bits/ 16 <1>;
+ ti,settle-delay-usec = /bits/ 16 <150>;
+ ti,keep-vref-on;
+ wakeup-source;
+ };
+
+ can0: can@1 {
+ compatible = "microchip,mcp251xfd";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ microchip,rx-int-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch>;
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
+ extcon_ptn5150: typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_extcon>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pca6408>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ label = "tpm";
+ reset-gpios = <&pca9534 0 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ fsl,tx-deemph-gen1 = <0x2d>;
+ fsl,tx-deemph-gen2 = <0xf>;
+ clocks = <&pcie0_refclk>;
+ status = "okay";
+};
+
+&pcie0 {
+ reset-gpios = <&pca6408_2 3 GPIO_ACTIVE_LOW>;
+ clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&pcie0_refclk>,
+ <&clk IMX8MM_CLK_PCIE1_AUX>;
+ assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+ <&clk IMX8MM_CLK_PCIE1_CTRL>;
+ assigned-clock-rates = <10000000>, <250000000>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+ <&clk IMX8MM_SYS_PLL2_250M>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm>;
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&snvs_rtc {
+ status = "disabled";
+};
+
+/* Console */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ wakeup-source;
+ status = "okay";
+};
+
+/* Header */
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* Header */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ disable-over-current;
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x16
+ MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 0x16
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x13
+ MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x13
+ MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x13
+ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x13
+ MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x13
+ MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 0x13
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x19
+ >;
+ };
+
+ pinctrl_gpio_leds: ledgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI1_TXD6_GPIO4_IO18 0x1c6
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2_gpio: i2c2-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 0x400001c3
+ MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4_gpio: i2c4-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C4_SCL_GPIO5_IO20 0x400001c3
+ MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21 0x400001c3
+ >;
+ };
+
+ pinctrl_pca6408: pca6408grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x1c6
+ >;
+ };
+
+ pinctrl_pwm: pwmgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT 0x06
+ >;
+ };
+
+ pinctrl_vmmc_usdhc2: regvmmc-usdhc2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0xc1
+ >;
+ };
+
+ pinctrl_restouch: restouchgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c0
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x1c1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140
+ MX8MM_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART2_RXD_UART2_DCE_RX 0x140
+ MX8MM_IOMUXC_UART2_TXD_UART2_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX 0x140
+ MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0xc1
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
From: Stefano Radaelli @ 2026-06-27 14:46 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Josua Mayer,
Dario Binacchi, Alexander Stein, Ernest Van Hoecke,
Maud Spierings, Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1782571383.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX8MM system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX8M Mini MPU processor
- Up to 4GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Fixed eth regulator
.../boot/dts/freescale/imx8mm-var-dart.dtsi | 558 ++++++++++++++++++
1 file changed, 558 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
new file mode 100644
index 000000000000..2324063f8fd9
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
@@ -0,0 +1,558 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX8M-MINI
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx8mm.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-MINI Module";
+ compatible = "variscite,var-dart-mx8mm", "fsl,imx8mm";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+
+ reg_audio_supply: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8904-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_eth_phy: regulator-eth-phy {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_eth_phy>;
+ regulator-name = "eth_phy_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <20000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_phy_vddio: regulator-phy-vddio {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai3>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&fec1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec1>;
+ pinctrl-1 = <&pinctrl_fec1_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ phy-supply = <®_eth_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ vddio-supply = <®_phy_vddio>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pmic@4b {
+ compatible = "rohm,bd71847";
+ reg = <0x4b>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ rohm,reset-snvs-powered;
+
+ regulators {
+ buck1_reg: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <1000000>;
+ rohm,dvs-idle-voltage = <900000>;
+ };
+
+ buck3_reg: BUCK3 {
+ // BUCK5 in datasheet
+ regulator-name = "buck3";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4_reg: BUCK4 {
+ // BUCK6 in datasheet
+ regulator-name = "buck4";
+ regulator-min-microvolt = <2600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5_reg: BUCK5 {
+ // BUCK7 in datasheet
+ regulator-name = "buck5";
+ regulator-min-microvolt = <1605000>;
+ regulator-max-microvolt = <1995000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6_reg: BUCK6 {
+ // BUCK8 in datasheet
+ regulator-name = "buck6";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX8MM_CLK_SAI3_ROOT>;
+ clock-names = "mclk";
+ AVDD-supply = <&ldo5_reg>;
+ CPVDD-supply = <&ldo5_reg>;
+ DBVDD-supply = <®_audio_supply>;
+ DCVDD-supply = <&ldo5_reg>;
+ MICVDD-supply = <&ldo5_reg>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ };
+};
+
+&mu {
+ status = "okay";
+};
+
+&sai3 {
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MM_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <1536000>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* BT module */
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth_iw61x: bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+/* WIFI */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>;
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1
+ MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0xc1
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
+ MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_fec1_sleep: fec1sleepgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_GPIO1_IO16 0x120
+ MX8MM_IOMUXC_ENET_MDIO_GPIO1_IO17 0x120
+ MX8MM_IOMUXC_ENET_TD3_GPIO1_IO18 0x120
+ MX8MM_IOMUXC_ENET_TD2_GPIO1_IO19 0x120
+ MX8MM_IOMUXC_ENET_TD1_GPIO1_IO20 0x120
+ MX8MM_IOMUXC_ENET_TD0_GPIO1_IO21 0x120
+ MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29 0x120
+ MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28 0x120
+ MX8MM_IOMUXC_ENET_RD1_GPIO1_IO27 0x120
+ MX8MM_IOMUXC_ENET_RD0_GPIO1_IO26 0x120
+ MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23 0x120
+ MX8MM_IOMUXC_ENET_RXC_GPIO1_IO25 0x120
+ MX8MM_IOMUXC_ENET_RX_CTL_GPIO1_IO24 0x120
+ MX8MM_IOMUXC_ENET_TX_CTL_GPIO1_IO22 0x120
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x100
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c1_gpio: i2c1-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C1_SCL_GPIO5_IO14 0x400001c3
+ MX8MM_IOMUXC_I2C1_SDA_GPIO5_IO15 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3_gpio: i2c3-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 0x400001c3
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x140
+ >;
+ };
+
+ pinctrl_reg_eth_phy: regeth-phygrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x41
+ >;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI3_RXFS_SAI3_RX_SYNC 0xd6
+ MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC 0xd6
+ MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI3_TXD_SAI3_TX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI3_MCLK_SAI3_MCLK 0xd6
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x140
+ MX8MM_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x140
+ MX8MM_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x140
+ MX8MM_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x140
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d0
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d0
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d0
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d0
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d4
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d4
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d4
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d4
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d6
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d6
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d6
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d6
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x190
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 0x140
+ MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10 0xc1
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M-MINI Boards
From: Stefano Radaelli @ 2026-06-27 14:46 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Josua Mayer,
Dario Binacchi, Alexander Stein, Ernest Van Hoecke,
Maud Spierings, Francesco Dolcini, Hugo Villeneuve,
Krzysztof Kozlowski
In-Reply-To: <cover.1782571383.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX8MM SoM and Variscite
development carrier Board.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59..c942d3d06469 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1064,6 +1064,12 @@ properties:
- const: solidrun,imx8mm-sr-som
- const: fsl,imx8mm
+ - description: Variscite DART-MX8MM based boards
+ items:
+ - const: variscite,var-dart-mx8mm-sonata # Variscite DART-MX8MM on Sonata Development Board
+ - const: variscite,var-dart-mx8mm # Variscite DART-MX8M-MINI SOM
+ - const: fsl,imx8mm
+
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/3] Add support for Variscite DART-MX8M-MINI and Sonata board
From: Stefano Radaelli @ 2026-06-27 14:46 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Josua Mayer,
Dario Binacchi, Alexander Stein, Ernest Van Hoecke,
Maud Spierings, Francesco Dolcini, Hugo Villeneuve
This patch series adds support for the Variscite DART-MX8M-MINI
system on module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
v1->v2:
- Remove HDMI from commit message
- Fixed eth regulator
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX8M-MINI Boards
arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mm-var-dart-sonata.dts | 517 ++++++++++++++++
.../boot/dts/freescale/imx8mm-var-dart.dtsi | 558 ++++++++++++++++++
4 files changed, 1082 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
base-commit: 23a7098c710673ce8f245af317903ae46325a694
--
2.47.3
^ permalink raw reply
* Re: [PATCH v2] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-27 14:20 UTC (permalink / raw)
To: Ferass El Hafidi
Cc: linux-amlogic, Jerome Brunet, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Neil Armstrong, Kevin Hilman,
Martin Blumenstingl, linux-sound, linux-arm-kernel, linux-kernel
In-Reply-To: <thanni.i9bbkrc1oza2@postmarketos.org>
> On 27 Jun 2026, at 5:08 pm, Ferass El Hafidi <funderscore@postmarketos.org> wrote:
>
> Hi Christian,
>
> On Sat, 27 Jun 2026 12:50, Christian Hewitt <christianshewitt@gmail.com> wrote:
>> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
>> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
>> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
>> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
>> producing the "machine gun noise" buffer underrun - on start when switching
>> outputs, and on stop when playback ends. The latter is audible on devices
>> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>>
>> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
>> both enable and disable (audio_hw_958_enable), and when reconfiguring
>> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
>> reset before enabling the DCU on start, and after disabling it on stop.
>>
>> Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support")
>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>
> You may have forgotten to add Martin's R-b here.
100%, but I also missed amending the commit description for the v2 change so
there’s a v3 where it’s been added. Sorry for the noise everyone, seems I am
a little out of practice at submitting things.
CH.
^ permalink raw reply
* Re: [PATCH v2] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Ferass El Hafidi @ 2026-06-27 13:08 UTC (permalink / raw)
To: linux-amlogic, Christian Hewitt, Jerome Brunet, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Neil Armstrong,
Kevin Hilman, Martin Blumenstingl, linux-sound, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260627125030.808058-1-christianshewitt@gmail.com>
Hi Christian,
On Sat, 27 Jun 2026 12:50, Christian Hewitt <christianshewitt@gmail.com> wrote:
>The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
>AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
>vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
>it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
>producing the "machine gun noise" buffer underrun - on start when switching
>outputs, and on stop when playback ends. The latter is audible on devices
>with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>
>The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
>both enable and disable (audio_hw_958_enable), and when reconfiguring
>(audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
>reset before enabling the DCU on start, and after disabling it on stop.
>
>Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support")
>Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
You may have forgotten to add Martin's R-b here.
Best regards,
Ferass
^ permalink raw reply
* Re: [GIT PULL] ARM: mvebu: dt64 for v7.2 (#1)
From: Aleksander Jan Bajkowski @ 2026-06-27 13:45 UTC (permalink / raw)
To: Arnd Bergmann, Gregory Clement, arm, soc
Cc: Andrew Lunn, Sebastian Hesselbarth, linux-arm-kernel
In-Reply-To: <956403e3-d47f-498c-9f62-79d39c1cf5db@app.fastmail.com>
Hi Arnd,
On 09/06/2026 21:29, Arnd Bergmann wrote:
> On Tue, Jun 9, 2026, at 19:35, Aleksander Jan Bajkowski wrote:
>> On 09/06/2026 18:11, Arnd Bergmann wrote:
>>> I'm a bit surprised by this oneline change. Since you successfully tested
>>> this, I assume the change is correct, but I have two questions that
>>> I would like to have an answer for before I pull it.
>> By the way, the upstream safexcel driver works correctly only on
>> coherent
>> platforms. On non-coherent platforms (MediaTek), the SHA-384 and SHA-512
>> selftests fail. Since the selftests pass on Armada's SoC, I assume I'm
>> right.
> It's not necessarily proof that this is correct, but it is quite likely.
>
> After checking the datasheet some more and finding that this should
> indeed be coherent everywhere, I remembered that even the old
> 32-bit Armada 370 had a coherency manager. At the time, we used a hack
> in arch/arm/mach-mvebu/coherency.c to mark all device nodes as coherent,
> since the original DTB did not contain the correct annotations.
>
> I suspect that the Armada 37xx started out with a copy of the
> old DT files and also never had the annotation, but then never
> had the same hack because arch/arm64 does not have platform
> specific code.
>
>> I have a plan to send a patch upstream, which has long been maintained
>> downstream in OpenWRT[1]. But I need to think a bit more about how to do
>> this properly.
>> [1]
>> https://github.com/openwrt/openwrt/blob/main/target/linux/mediatek/patches-6.18/401-crypto-fix-eip97-cache-incoherent.patch
> The patch is basically correct, I think you should just change two
> details:
>
> - instead of defining your own SYSTEM_CACHELINE_SIZE macro, just use
> the existing CRYPTO_DMA_ALIGN macro that is used in crypto_dma_align
>
> - move the 'state[]' and 'cache[]' arrays to the beginning of
> safexcel_ahash_req so you don't have to manually align them.
My biggest concern is the increased memory overhead. On Marvell
platforms, this increases the structure size by 150 bytes. I’ve
checked, and both CRYPTO_DMA_ALIGN and ARCH_DMA_MINALIGN always
have a value of 128. On MIPS platforms, ARCH_DMA_MINALIGN is set
per SoC in the mach files. I assume that on a Marvell platform
with coherent DMA, I should set the value to 4, and on a
non-coherent MediaTek platform, to 64. How should this be handled
on an ARM platform?
Best Regards,
Aleksander
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Sudeep Holla @ 2026-06-27 14:13 UTC (permalink / raw)
To: Pragnesh Papaniya
Cc: Cristian Marussi, Sudeep Holla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sibi Sankar, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, Dmitry Osipenko, Thierry Reding, Jonathan Hunter,
Bjorn Andersson, Konrad Dybcio, Rajendra Nayak, Pankaj Patil,
linux-arm-msm, linux-kernel, arm-scmi, linux-arm-kernel,
devicetree, linux-pm, linux-tegra, Amir Vajid,
Ramakrishna Gottimukkula
In-Reply-To: <ea9d0c11-e110-4d13-b165-1548875ef9cd@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 10:57:40AM +0530, Pragnesh Papaniya wrote:
>
>
> On 23-Jun-26 2:17 PM, Sudeep Holla wrote:
> > On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote:
> >>
> >> On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
> >>
> >>> Not sure if it was discussed in the previous versions or not, it would be
> >>> good if you can capture why some of bus scaling doesn't work with the existing
> >>> SCMI performance protocol and the monitors don't fit the MPAM mode.
> >>>
> >>> Please capture them in 1/9 as a motivation for this vendor protocol. It will
> >>> then help to understand it better as I am still struggling to. Sorry for that.
> >>
> >> Thanks for the input!
> >>
> >> SCMI perf protocol exports perf domains to kernel where kernel can set
> >> the frequency but here the scaling governor runs on the SCP while kernel
> >> just observes frequency changes made by remote governor.
> >
> > OK if it is sort of read-only w.r.t kernel, why not perf domain notifications
> > work to consume the change done by the SCMI platform.
> >
> > And why do you have set operations in the vendor protocol being proposed then.
> > It all looks like something just cooked up to make things work. I need
> > detailed reasoning as why the existing perf protocol can't work considering
> > all the existing notifications in place.
>
> Please do take another look at the documentation and driver changes to see
> how it all comes together, since it's apparent that we use SET operation for
> a ton of things. Taking another stab at explaining how the MEMLAT uses all
> the ops exposed by the vendor protocol.
>
Sure I will have a look at the documentation again and sorry if I missed
anything. But in general I would expect the document to be self-explanatory
and not having to look at the driver on how it is used to understand the
firmware interface. Please make sure of that if not already.
> We use the SET operation to pass on various tuneables (IPM CEIL, stall floors,
> write-back filter, freq-scale params, adaptive low/high freq, sample ms),
> the core-freq -> mem-freq map, and min/max clamps) required to run the
> MEMLAT algorithm on the SCP. You might ask why can't we have these values
> stored somewhere on the SCP itself?
Exactly, thanks for saving a round trip.
> We would like to but all of these are tuneable values, that can change for
> various boards for the same SoC.
>
Sure and where do these boards get these values from ? I assume device tree ?
If so, are the fixed and can be done once at boot ?
> The START/STOP operations are meant to start/stop the algorithm, in this case
> the bus scaling algorithm.
>
Yes you need to add more details on that algorithm. Can firmware take random
strings as input. I guess not. Please list the valid strings and explain them.
Filter invalid strings in the driver if only handful of values are valid.
> We use the GET operation to get the current frequency of memory that we
> are trying to scale. It can be also used to read back all the parameters
> that we are trying to set. Another thing to note is that exposing the current
> frequency to the userspace was something that the community wanted.
>
More fun, user ABI involved, so the firmware interface needs to be as clear
as possible.
> With all of ^^ in mind, re-using the perf protocol becomes impossible.
>
> https://lore.kernel.org/lkml/k4lpzxtrq3x6riyv6etxiobn7nbpczf2bp3m4oc752nhjknlit@uo53kbppzim7/
> https://lore.kernel.org/lkml/20241115003809epcms1p518df149458f3023d33ec6d87a315e8f6@epcms1p5/
>
It is good to capture summary of these old discussions if they are relevant.
> We'll add more call flow diagrams as part of the documentation for the next
> re-spin to make reviews a bit more easier.
>
Anything that improves and helps in understanding this is always welcome.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] dmaengine: mediatek: hsdma: fix runtime PM leak on init failure
From: Myeonghun Pak @ 2026-06-27 13:49 UTC (permalink / raw)
To: Sean Wang, Vinod Koul, Frank Li, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: dmaengine, linux-arm-kernel, linux-mediatek, linux-kernel,
Myeonghun Pak, Ijae Kim
mtk_hsdma_hw_init() enables runtime PM and gets a runtime PM reference
before enabling the HSDMA clock. It currently ignores failures from
pm_runtime_get_sync(); if runtime resume fails, the usage count remains
held. If clk_prepare_enable() then fails, the usage count remains held.
Use devm_pm_runtime_enable() to manage runtime PM enablement, and use
pm_runtime_resume_and_get() so resume failures do not leak the usage count.
If clk_prepare_enable() fails after a successful runtime resume, drop the
runtime PM reference before returning.
The probe path also ignores the return value from mtk_hsdma_hw_init(), so a
failed hardware init can continue as a successful probe. Propagate
mtk_hsdma_hw_init() failures from probe, while keeping a separate unwind
label so mtk_hsdma_hw_deinit() is only called after hardware init succeeds.
Fixes: 548c4597e984 ("dmaengine: mediatek: Add MediaTek High-Speed DMA controller for MT7622 and MT7623 SoC")
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
---
Changes in v2:
- Use devm_pm_runtime_enable() for runtime PM enablement.
- Drop manual pm_runtime_disable() calls from init/deinit paths.
drivers/dma/mediatek/mtk-hsdma.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/mediatek/mtk-hsdma.c b/drivers/dma/mediatek/mtk-hsdma.c
index a43412ff5e..27cb370106 100644
--- a/drivers/dma/mediatek/mtk-hsdma.c
+++ b/drivers/dma/mediatek/mtk-hsdma.c
@@ -848,17 +848,27 @@ static int mtk_hsdma_hw_init(struct mtk_hsdma_device *hsdma)
{
int err;
- pm_runtime_enable(hsdma2dev(hsdma));
- pm_runtime_get_sync(hsdma2dev(hsdma));
+ err = devm_pm_runtime_enable(hsdma2dev(hsdma));
+ if (err)
+ return err;
+
+ err = pm_runtime_resume_and_get(hsdma2dev(hsdma));
+ if (err < 0)
+ return err;
err = clk_prepare_enable(hsdma->clk);
if (err)
- return err;
+ goto err_put_pm;
mtk_dma_write(hsdma, MTK_HSDMA_INT_ENABLE, 0);
mtk_dma_write(hsdma, MTK_HSDMA_GLO, MTK_HSDMA_GLO_DEFAULT);
return 0;
+
+err_put_pm:
+ pm_runtime_put_sync(hsdma2dev(hsdma));
+
+ return err;
}
static int mtk_hsdma_hw_deinit(struct mtk_hsdma_device *hsdma)
@@ -868,7 +878,6 @@ static int mtk_hsdma_hw_deinit(struct mtk_hsdma_device *hsdma)
clk_disable_unprepare(hsdma->clk);
pm_runtime_put_sync(hsdma2dev(hsdma));
- pm_runtime_disable(hsdma2dev(hsdma));
return 0;
}
@@ -983,7 +992,9 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
goto err_unregister;
}
- mtk_hsdma_hw_init(hsdma);
+ err = mtk_hsdma_hw_init(hsdma);
+ if (err)
+ goto err_free;
err = devm_request_irq(&pdev->dev, hsdma->irq,
mtk_hsdma_irq, 0,
@@ -991,7 +1002,7 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
if (err) {
dev_err(&pdev->dev,
"request_irq failed with err %d\n", err);
- goto err_free;
+ goto err_deinit;
}
platform_set_drvdata(pdev, hsdma);
@@ -1000,8 +1011,9 @@ static int mtk_hsdma_probe(struct platform_device *pdev)
return 0;
-err_free:
+err_deinit:
mtk_hsdma_hw_deinit(hsdma);
+err_free:
of_dma_controller_free(pdev->dev.of_node);
err_unregister:
dma_async_device_unregister(dd);
--
2.47.1
^ permalink raw reply related
* [PATCH v3] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-27 13:12 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
linux-sound, linux-arm-kernel, linux-amlogic, linux-kernel
The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
producing the "machine gun noise" buffer underrun - on start when switching
outputs, and on stop when playback ends. The latter is audible on devices
with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
both enable and disable (audio_hw_958_enable), and when reconfiguring
(audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
reset before enabling the DCU on start, and before disabling on stop.
Fixes: 6ae9ca9ce986bf ("ASoC: meson: aiu: add i2s and spdif support")
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Changes from v2:
- Ammend description to match the change in v2
- Add Martin's reviewed-by
Changes from v1:
- Add missing fixes tag
- Trigger AIU_RST_SOFT_958_FAST before disabling DCU matching the
stop flow in the vendor driver, as noted by Martin (tests ok)
---
sound/soc/meson/aiu-fifo-spdif.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/sound/soc/meson/aiu-fifo-spdif.c b/sound/soc/meson/aiu-fifo-spdif.c
index e0e00ec026dc..a9861c5d6637 100644
--- a/sound/soc/meson/aiu-fifo-spdif.c
+++ b/sound/soc/meson/aiu-fifo-spdif.c
@@ -24,6 +24,7 @@
#define AIU_MEM_IEC958_CONTROL_MODE_16BIT BIT(7)
#define AIU_MEM_IEC958_CONTROL_MODE_LINEAR BIT(8)
#define AIU_MEM_IEC958_BUF_CNTL_INIT BIT(0)
+#define AIU_RST_SOFT_958_FAST BIT(2)
#define AIU_FIFO_SPDIF_BLOCK 8
@@ -68,11 +69,15 @@ static int fifo_spdif_trigger(struct snd_pcm_substream *substream, int cmd,
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ snd_soc_component_write(component, AIU_RST_SOFT,
+ AIU_RST_SOFT_958_FAST);
fifo_spdif_dcu_enable(component, true);
break;
case SNDRV_PCM_TRIGGER_SUSPEND:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
case SNDRV_PCM_TRIGGER_STOP:
+ snd_soc_component_write(component, AIU_RST_SOFT,
+ AIU_RST_SOFT_958_FAST);
fifo_spdif_dcu_enable(component, false);
break;
default:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] drm/sun4i: Remove dependency on DRM simple helpers
From: Diogo @ 2026-06-27 13:07 UTC (permalink / raw)
To: Jernej Škrabec, Chen-Yu Tsai, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Samuel Holland
Cc: dri-devel, linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <PMdb9FVETQuPUnyh12NM2Q@gmail.com>
Hey,
I saw the task to open-code the drm_simple_encoder_init in the DRM tasks, and thought that sending individual patches for each platform would be the easiest.
Thomas Zimmermann, is it ok if I do all drivers at once as a patch series?
BR,
Diogo
On 27 June 2026 08:55:04 CEST, "Jernej Škrabec" <jernej.skrabec@gmail.com> wrote:
>Dne torek, 23. junij 2026 ob 22:34:40 Srednjeevropski poletni čas je Diogo Silva napisal(a):
>> Simple KMS helper are deprecated since they only add an intermediate
>> layer between drivers and the atomic modesetting.
>> This patch removes the dependency on drm simple helpers from sun4i
>> DRM drivers.
>>
>> Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
>
>This doesn't look as useful change. Is this tree-wide attempt? If so, it
>should be done in one go in one patch series, coordinated with DRM
>maintainers.
>
>Best regards,
>Jernej
>
>
^ 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