* Re: [RFC PATCH 1/1] dt-bindings: iommu: riscv: Add bindings for Tenstorrent RISC-V IOMMU
From: Drew Fustini @ 2026-04-14 19:26 UTC (permalink / raw)
To: Joerg Roedel
Cc: Joel Stanley, Nicholas Piggin, devicetree, Tomasz Jeznach,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-riscv,
linux-kernel, Michael Ellerman
In-Reply-To: <5tr5kacx27a4g4udx43vemqvwhr4iaflacdrkz3d5tnd6vcldo@s6l34e2xyg5k>
On Mon, Apr 13, 2026 at 01:37:32PM +0200, Joerg Roedel wrote:
> On Thu, Apr 02, 2026 at 01:35:19PM -0700, Drew Fustini wrote:
> > I think it would go through Joerg's iommu tree, but I could if Joerg can
> > an Ack.
>
> I do not have the original patch in my inbox, but looking at it via lore it
> lgtm.
>
> Acked-by: Joerg Roedel <joerg.roedel@amd.com>
Is it okay for me to take it through tenstorrent-dt-for-next or would
you like to take it through iommu tree?
Thanks,
Drew
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: ti,pcm3060: add descriptions and rename binding
From: Kirill Marinushkin @ 2026-04-14 19:16 UTC (permalink / raw)
To: Padmashree S S
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, linux-sound,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <CAEjBr-bdNvgBWjHei4K8LLH6QjkgHXCwtmW5qGoeh_36Vy8kWA@mail.gmail.com>
Hello Padmashree,
Allow me to once more propose this description, which
was in the original .txt, and you included into the patch v1, but
removed for v3:
> + reg:
> + maxItems: 1
> + description: The I2C address of the device or SPI chip select number.
You also probably would like to squash patch v4 with the previous patch v3
Best regards,
Kirill
On 4/14/26 3:22 PM, Padmashree S S wrote:
> On Tue, Apr 14, 2026 at 12:09 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Apr 14, 2026 at 09:18:54AM +0530, Padmashree S S wrote:
>>> Add description to reg property and overall binding mentioning that this
>>> driver supports both I2C and SPI. Rename binding to match compatible
>>> naming convention.
>>>
>>> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
>>> ---
>>> Changes in v4:
>>> - Rename binding from pcm3060 to ti,pcm3060
>>> - Add binding description
>>> - Add description to 'reg' property
>>> - Remove unused label in example
>>>
>>> Changes in v3:
>>> - Remove description from 'reg' property
>>> ---
>>> .../bindings/sound/{pcm3060.yaml => ti,pcm3060.yaml} | 10 +++++-----
>> What v4 is that of? There is no such file.
>>
>> Do not attach (thread) your patchsets to some other threads (unrelated
>> or older versions). This buries them deep in the mailbox and might
>> interfere with applying entire sets. See also:
>> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>>
>> Best regards,
>> Krzysztof
>>
> Thanks for pointing this out.
>
> Since this is a DT binding patch for the same pcm3060 device, I linked
> it to the previous version. However, I realize the subject changed
> significantly, which made the threading confusing.
>
> I’m planning to resend it as a new patch in a separate thread. Please
> let me know if that works.
^ permalink raw reply
* Re: [PATCH v7 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Jonathan Cameron @ 2026-04-14 18:54 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio, devicetree, linux-kernel,
Andy Shevchenko
In-Reply-To: <20260410-dev_ad5706r-v7-2-af93a4caa186@analog.com>
On Fri, 10 Apr 2026 14:48:17 +0800
Alexis Czezar Torreno <alexisczezar.torreno@analog.com> wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
>
Hi Alexis,
A few little comments from me.
Thanks,
Jonathan
> diff --git a/drivers/iio/dac/ad5706r.c b/drivers/iio/dac/ad5706r.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..026f871ce121cd63331b2a34da8879491b2d0f3c
> --- /dev/null
> +++ b/drivers/iio/dac/ad5706r.c
> @@ -0,0 +1,253 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * AD5706R 16-bit Current Output Digital to Analog Converter
> + *
> + * Copyright 2026 Analog Devices Inc.
> + */
> +
> +#include <linux/array_size.h>
> +#include <linux/bits.h>
> +#include <linux/dev_printk.h>
> +#include <linux/err.h>
> +#include <linux/iio/iio.h>
> +#include <linux/minmax.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/spi/spi.h>
> +#include <linux/types.h>
> +#include <linux/unaligned.h>
> +
> +/* SPI frame layout */
> +#define AD5706R_RD_MASK BIT(15)
> +#define AD5706R_ADDR_MASK GENMASK(11, 0)
> +
> +/* Registers */
> +#define AD5706R_REG_DAC_INPUT_A_CH(x) (0x60 + ((x) * 2))
> +#define AD5706R_REG_DAC_DATA_READBACK_CH(x) (0x68 + ((x) * 2))
> +
> +#define AD5706R_DAC_RESOLUTION 16
> +#define AD5706R_DAC_MAX_CODE BIT(16)
Trivial but I'd expect something called MAX_CODE to be GENMASK(15, 0)
not BIT(16). E.g. inclusive limit.
> +#define AD5706R_MULTIBYTE_REG_START 0x14
> +#define AD5706R_MULTIBYTE_REG_END 0x71
> +#define AD5706R_MAX_REG 0x77
> +#define AD5706R_SINGLE_BYTE_LEN 1
> +#define AD5706R_DOUBLE_BYTE_LEN 2
See below. I'm not sure these two defines bring us anything.
> +
> +struct ad5706r_state {
> + struct spi_device *spi;
> + struct regmap *regmap;
> +
> + u8 tx_buf[4] __aligned(IIO_DMA_MINALIGN);
> + u8 rx_buf[4];
> +};
> +
> +static int ad5706r_reg_len(unsigned int reg)
> +{
> + if (reg >= AD5706R_MULTIBYTE_REG_START && reg <= AD5706R_MULTIBYTE_REG_END)
> + return AD5706R_DOUBLE_BYTE_LEN;
What do the defines for 2 == 2-bytes and 1 == 1-byte bring us over using numbers
directly? E.g.
if (reg >= AD5706R_MULTIBYTE_REG_START && reg <= AD5706R_MULTIBYTE_REG_END)
return 2;
return 1;
> +
> + return AD5706R_SINGLE_BYTE_LEN;
> +}
> +
> +static int ad5706r_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes, val;
> + u16 reg;
> +
> + if (count != 4)
> + return -EINVAL;
> +
> + reg = get_unaligned_be16(data);
> + num_bytes = ad5706r_reg_len(reg);
> +
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .len = num_bytes + 2,
> + };
> +
> + val = get_unaligned_be32(data);
> + put_unaligned_be32(val, &st->tx_buf[0]);
> +
> + /* For single byte, copy the data to the correct position */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + st->tx_buf[2] = st->tx_buf[3];
This does feel a bit odd vs using if / else if as you do in the read
case. Also, same as above wrt to single bytes having a length of
1 meaning that just using a 1 might be easier to read.
> +
> + return spi_sync_transfer(st->spi, &xfer, 1);
> +}
> +static int ad5706r_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val, int val2, long mask)
> +{
> + struct ad5706r_state *st = iio_priv(indio_dev);
> + unsigned int reg;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!in_range(val, 0, AD5706R_DAC_MAX_CODE))
I'm not seeing a strong reason to use in_range() here (hopefully
I didn't suggest it in an earlier review ;) It make sense when
we have a val >= base && val < base + length. With base as 0
and MAX_CODE not 'obviously' from it's name being the length
(it only is becauset he base is 0) this seems odd.
if (val < 0 || val >= AD5706R_DAC_MAX_CODE)
Though see above on MAX_CODE not being the maximum code...
> + return -EINVAL;
> +
> + reg = AD5706R_REG_DAC_INPUT_A_CH(chan->channel);
> + return regmap_write(st->regmap, reg, val);
> + default:
> + return -EINVAL;
> + }
> +}
^ permalink raw reply
* [PATCH 1/2] dt-bindings: qcom: Document panasonic,eluga-u2
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
In-Reply-To: <20260414184429.168612-1-linmengbo06890@proton.me>
Document the new panasonic,eluga-u2 device tree bindings used in
msm8916-panasonic-eluga-u2.
Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1335a7bee397..5b60145c80e7 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -183,6 +183,7 @@ properties:
- motorola,harpia
- motorola,osprey
- motorola,surnia
+ - panasonic,eluga-u2
- qcom,msm8916-mtp
- samsung,a3u-eur
- samsung,a5u-eur
--
2.47.3
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
In-Reply-To: <20260414184429.168612-1-linmengbo06890@proton.me>
Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
Add a device tree for with initial support for:
- GPIO keys
- GPIO LEDs
- pm8916-vibrator
- SDHCI (internal and external storage)
- USB Device Mode
- UART
- Regulators
Signed-off-by: "Lin, Meng-Bo" <linmengbo06890@proton.me>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/msm8916-panasonic-eluga-u2.dts | 149 ++++++++++++++++++
2 files changed, 150 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e7306419..4cbb4a079420 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -81,6 +81,7 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-harpia.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-osprey.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-motorola-surnia.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM) += msm8916-panasonic-eluga-u2.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-a3u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-a5u-eur.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-samsung-coreprimeltevzw.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts b/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
new file mode 100644
index 000000000000..8eff59119760
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-panasonic-eluga-u2.dts
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+/dts-v1/;
+
+#include "msm8916-pm8916.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "Panasonic ELUGA U2";
+ compatible = "panasonic,eluga-u2", "qcom,msm8916";
+ chassis-type = "handset";
+
+ aliases {
+ mmc0 = &sdhc_1; /* eMMC */
+ mmc1 = &sdhc_2; /* SD card */
+ serial0 = &blsp_uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&gpio_keys_default>;
+ pinctrl-names = "default";
+
+ label = "GPIO Buttons";
+
+ button-volume-up {
+ label = "Volume Up";
+ gpios = <&tlmm 107 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&pm8916_mpps_leds_default>;
+ pinctrl-names = "default";
+
+ led-green {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pm8916_mpps 2 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led-blue {
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pm8916_mpps 4 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ usb_id: usb-id {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&usb_id_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&blsp_uart2 {
+ status = "okay";
+};
+
+&pm8916_mpps {
+ pm8916_mpps_leds_default: pm8916-mpps-state {
+ pins = "mpp2", "mpp4";
+ function = "digital";
+ output-low;
+ };
+};
+
+&pm8916_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+ status = "okay";
+};
+
+&pm8916_rpm_regulators {
+ pm8916_l17: l17 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ };
+};
+
+&pm8916_vib {
+ status = "okay";
+};
+
+&sdhc_1 {
+ status = "okay";
+};
+
+&sdhc_2 {
+ pinctrl-0 = <&sdc2_default &sdc2_cd_default>;
+ pinctrl-1 = <&sdc2_sleep &sdc2_cd_default>;
+ pinctrl-names = "default", "sleep";
+
+ cd-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+&usb {
+ extcon = <&usb_id>, <&usb_id>;
+ status = "okay";
+};
+
+&usb_hs_phy {
+ extcon = <&usb_id>;
+};
+
+&tlmm {
+ gpio_keys_default: gpio-keys-default-state {
+ pins = "gpio107";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ sdc2_cd_default: sdc2-cd-default-state {
+ pins = "gpio38";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ usb_id_default: usb-id-default-state {
+ pins = "gpio110";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&venus {
+ status = "okay";
+};
+
+&venus_mem {
+ status = "okay";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: qcom: msm8916-panasonic-eluga-u2: add initial device tree
From: Lin, Meng-Bo @ 2026-04-14 18:44 UTC (permalink / raw)
To: linux-kernel
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, phone-devel,
~postmarketos/upstreaming, Lin, Meng-Bo
Panasonic ELUGA U2 is a phone using the MSM8916 SoC released in 2015.
Add a device tree for with initial support for:
- GPIO keys
- GPIO LEDs
- pm8916-vibrator
- SDHCI (internal and external storage)
- USB Device Mode
- UART
- Regulators
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-14 18:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <ad3paMbRXtq6BrCu@ashevche-desk.local>
On Tue, 14 Apr 2026 10:14:48 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> > On Mon, 30 Mar 2026 14:58:46 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
>
> ...
>
> > > + if (!conf->temp_en)
> > > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> >
> > Could make this
> > val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> > !conf->temp_en);
> > Not particularly important though if you prefer the if.
>
> Isn't this becomes FIELD_MODIFY()?
>
Yes, in this particular case as the bit has never been set before
this line, they end up the same. If the compiler fails to notice it
doesn't need to zero the bit if conf->temp_en is true might make it more
efficient to do it the way I had it but given this isn't a fast
path, FIELD_MODIFY() is fine.
Jonathan
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Bjorn Andersson @ 2026-04-14 18:11 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, cros-qcom-dts-watchers, linux-arm-msm,
linux-kernel, devicetree
In-Reply-To: <20260411062343.moksimqxjomts44a@hu-mojha-hyd.qualcomm.com>
On Sat, Apr 11, 2026 at 11:53:43AM +0530, Mukesh Ojha wrote:
> On Fri, Apr 10, 2026 at 09:43:10PM -0500, Bjorn Andersson wrote:
> > On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> > > Now that the two enable paths are separate functions, replace the
> > > pdc_version global with a __pdc_enable_intr function pointer. The
> > > pointer is assigned once at probe time based on the version register,
> > > moving the version comparison out of the interrupt enable/disable hot
> > > path entirely.
> >
> > That's what the patch does, but why?
>
> I thought, it was odd to compare against the version every time during
> enable/disable instead of clearing the path to take at probe time itself.
> however, I don't have data to prove how hot this path is ?
>
No immediate concerns about this hypothesis, but please start the commit
message with this problem description. Then if someone measures and find
that your assumption wasn't correct, they don't need to guess what you
where thinking when you wrote this.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: Enable CAN RX via GPIO expander
From: Dmitry Baryshkov @ 2026-04-14 18:09 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Anup Kulkarni, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-arm-msm, devicetree, linux-kernel, mukesh.savaliya,
viken.dadhaniya
In-Reply-To: <9cf3b035-79c0-4e9b-8ab6-a81f8d27728f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 06:20:14PM +0200, Konrad Dybcio wrote:
> On 4/14/26 6:08 PM, Dmitry Baryshkov wrote:
> > On Thu, Apr 02, 2026 at 04:22:53PM +0530, Anup Kulkarni wrote:
> >> Few CAN controllers, part of RTSS sub-system on LeMans, route
> >> their RX signal through a I2C GPIO expander at address 0x3b.
> >> RTSS subsystem is an MCU like sub-system on LeMans with independent
> >> booting capability through OSPI interface and supports peripherals like
> >> RGMII, CAN-FD, UART, I2C, SPI etc.
> >>
> >> Describe this hardware wiring by configuring the expander GPIO 4 pin as
> >> hog with output-high, asserting the selected line during boot.
> >
> > Missing platform name in the subject.
> >
> >>
> >> Signed-off-by: Anup Kulkarni <anup.kulkarni@oss.qualcomm.com>
> >> ---
> >> arch/arm64/boot/dts/qcom/lemans-evk.dts | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> index a1ef4eba2a20..b8371bdf9933 100644
> >> --- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> +++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
> >> @@ -615,6 +615,13 @@ expander3: gpio@3b {
> >> interrupts-extended = <&tlmm 39 IRQ_TYPE_LEVEL_LOW>;
> >> pinctrl-0 = <&expander3_int>;
> >> pinctrl-names = "default";
> >> +
> >> + rtss-can-sel-hog {
> >
> > Why is it being described as a hog rather than a pinctrl used by the
> > CAN device?
>
> My understanding is that the CAN bus is managed by SAIL ("RTSS")
So, Linux can affect what is being required for the safety island?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Mark Brown @ 2026-04-14 18:08 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <a0f50798-3293-4b2b-8d9c-7a85fce9e8e7@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Fri, Apr 10, 2026 at 12:56:47PM -0500, Sen Wang wrote:
> On 4/10/26 09:02, Mark Brown wrote:
> > This looks mostly good, but one issue I see is that AFAICT we only stop
> > fault_check_work during runtime suspsend - if runtime PM is disabled, or
> > if the driver is removed, the work will be left running.
> Regarding fault_check_work w/o runtime PM: the device has fault
> conditions that fire regardless of stream state, so the work runs for the
> duration of the active power state (runtime PM) rather than stream state.
> I could add a DAPM event fallback to gate the work when runtime PM is not
> defined, but that's more restrictive; it could miss faults outside of active
> playback, and adds complexity for what is a fairly niche configuration
> (optional check_work with runtime PM disabled).
> Do you think the DAPM fallback would suffice, or is the current approach
> (poll until removal) acceptable given the hardware behavior? Any other
> suggestions would be greatly appreciated!
It's fine to keep on checking for faults if there's faults that can be
generated, the only reason I mentioned runtime PM there was that it's
the only thing that stops the polling in the current version. So long
as everything is stopped when the device is removed it's fine. No need
for a DAPM fallback.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 06/35] irqchip/qcom-pdc: Use FIELD_GET() to extract bank index and bit position
From: Dmitry Baryshkov @ 2026-04-14 18:06 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-7-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:43AM +0530, Mukesh Ojha wrote:
> The IRQ_ENABLE_BANK register is a bank of 32-bit words where each bit
> represents one PDC pin. The bank index and bit position within the bank
> are encoded in the flat pin number as bits [31:5] and [4:0] respectively.
>
> Replace the open-coded division and modulo with FIELD_GET() and GENMASK()
> to make the bit extraction self-documenting and consistent with the
> FIELD_PREP() style already used in the PDC_VERSION() macro.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 5e1553334103..638b5d89a141 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -110,8 +110,8 @@ static void pdc_enable_intr_bank(int pin_out, bool on)
> unsigned long enable;
> u32 index, mask;
>
> - index = pin_out / 32;
> - mask = pin_out % 32;
> + index = FIELD_GET(GENMASK(31, 5), pin_out);
#define masks
> + mask = FIELD_GET(GENMASK(4, 0), pin_out);
>
> enable = pdc_reg_read(IRQ_ENABLE_BANK, index);
> __assign_bit(mask, &enable, on);
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 05/35] irqchip/qcom-pdc: Add PDC_VERSION() macro to describe version register fields
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-6-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:42AM +0530, Mukesh Ojha wrote:
> The PDC hardware version register encodes major, minor and step fields
> in byte-sized fields at bits [23:16], [15:8] and [7:0] respectively.
> The existing PDC_VERSION_3_2 constant was a bare magic number (0x30200)
> with no indication of this encoding.
>
> Add GENMASK-based field definitions for each sub-field and a
> PDC_VERSION(maj, min, step) constructor macro using FIELD_PREP, making
> the encoding self-documenting. Replace the magic constant with
> PDC_VERSION(3, 2, 0).
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 04/35] irqchip/qcom-pdc: Replace pdc_version global with a function pointer
From: Dmitry Baryshkov @ 2026-04-14 18:05 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-5-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:41AM +0530, Mukesh Ojha wrote:
> Now that the two enable paths are separate functions, replace the
> pdc_version global with a __pdc_enable_intr function pointer. The
> pointer is assigned once at probe time based on the version register,
> moving the version comparison out of the interrupt enable/disable hot
> path entirely.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 21e2b4b884ee..734576cdce0c 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -51,7 +51,7 @@ static void __iomem *pdc_base;
> static void __iomem *pdc_prev_base;
> static struct pdc_pin_region *pdc_region;
> static int pdc_region_cnt;
> -static unsigned int pdc_version;
> +static void (*__pdc_enable_intr)(int pin_out, bool on);
I'd say, it's more awkward than the current implementation.
> static bool pdc_x1e_quirk;
>
> static void pdc_base_reg_write(void __iomem *base, int reg, u32 i, u32 val)
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 03/35] irqchip/qcom-pdc: Tighten ioremap clamp to single DRV region size
From: Dmitry Baryshkov @ 2026-04-14 18:04 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-4-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:40AM +0530, Mukesh Ojha wrote:
> The QCOM_PDC_SIZE constant (0x30000) was introduced to work around old
> sm8150 DTs that described a too-small PDC register region, causing the
> driver to silently expand the ioremap to cover three DRV regions. Now
> that the preceding DT fixes have corrected all platforms to describe only
> the APSS DRV region (0x10000), the oversized clamp is no longer needed.
>
> Replace QCOM_PDC_SIZE with PDC_DRV_SIZE (0x10000) in the clamp so the
> minimum mapped size matches a single DRV region. The clamp and warning
> are intentionally kept to preserve backward compatibility with any old
> DTs that may still describe a smaller region.
>
> While at it, rename PDC_DRV_OFFSET to PDC_DRV_SIZE since the constant
> represents the size of a DRV region and is used as both the ioremap
> minimum size and the offset to the previous DRV region.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 02/35] irqchip/qcom-pdc: Split __pdc_enable_intr() into per-version helpers
From: Dmitry Baryshkov @ 2026-04-14 18:00 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260410184124.1068210-3-mukesh.ojha@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 12:10:39AM +0530, Mukesh Ojha wrote:
> The __pdc_enable_intr() function contains a version branch that selects
> between two distinct enable mechanisms: a bank-based IRQ_ENABLE_BANK
> register for HW < 3.2, and a per-pin enable bit in IRQ_i_CFG for
> HW >= 3.2. These two paths share no code and serve different hardware.
>
> Split them into two focused static functions: pdc_enable_intr_bank()
> for HW < 3.2 and pdc_enable_intr_cfg() for HW >= 3.2. No functional
> change.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> drivers/irqchip/qcom-pdc.c | 42 +++++++++++++++++++++++---------------
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur: Drop RPMh CXO clocks from QMP PHYs
From: Dmitry Baryshkov @ 2026-04-14 17:57 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wesley Cheng, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260414-dts-glymur-drop-rpmh-cxo-clk-from-qmpphys-v1-1-ab12d77c4aec@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 08:05:51PM +0300, Abel Vesa wrote:
> On Glymur, all QMP PHYs except the one used by USB SS0 take their
> reference clock from the TCSR clock controller. Since these TCSR clocks
> already derive from RPMH_CXO_CLK as their sole parent, there is no need
> to provide an extra `clkref` clock to the PHY nodes.
>
> Drop the extra RPMh CXO clock inputs and use the TCSR clocks as the PHY
> reference clocks instead.
>
> This also fixes the devicetree schema validation, as the bindings do not
> allow a separate `clkref` clock.
>
> Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
> Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Reported-by: Rob Herring <robh@kernel.org>
> Closes: https://lore.kernel.org/r/20260410145205.GA554754-robh@kernel.org/
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/glymur.dtsi | 20 ++++++--------------
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: sc7180: Add QSPI memory interconnect path
From: Dmitry Baryshkov @ 2026-04-14 17:56 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-7-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:25PM +0530, Viken Dadhaniya wrote:
> Add the missing QSPI-to-memory interconnect path alongside the existing
> configuration path. Without this path, the interconnect framework cannot
> correctly vote for the bandwidth required by QSPI DMA data transfers.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] remoteproc: add AMD MicroBlaze driver
From: Krzysztof Kozlowski @ 2026-04-14 17:56 UTC (permalink / raw)
To: Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah, michal.simek
In-Reply-To: <20260414161558.2579920-3-ben.levinsky@amd.com>
On 14/04/2026 18:15, Ben Levinsky wrote:
> Add an AMD MicroBlaze remoteproc driver.
>
> The driver parses the executable firmware memory window from
> the remoteproc device node's reg property, interprets that
> address and size in the MicroBlaze-local address space, and
> then uses standard devicetree address translation through the
> parent bus ranges property to obtain the corresponding
> Linux-visible system physical address.
>
> The resulting translated region is registered as the executable
> remoteproc carveout and coredump segment.
>
> The MicroBlaze is controlled through an active-low reset GPIO and kept in
> reset until firmware loading completes.
>
> The firmware-name property is optional, allowing firmware to be
> assigned later through the remoteproc framework.
>
Fix your commit msg so it uses sane style, not some indentation.
Look at how other commits are written, if you have doubts.
...
> +
> +static int mb_rproc_start(struct rproc *rproc)
> +{
> + struct mb_rproc *mb = rproc->priv;
> +
> + /* reset-gpios is declared active-low, so logical 0 releases reset */
If reset-gpios is declared active-high, then logical 0 also releases reset.
Drop comment, not correct.
> + gpiod_set_value_cansleep(mb->reset, 0);
> +
> + return 0;
> +}
> +
> +static int mb_rproc_stop(struct rproc *rproc)
> +{
> + struct mb_rproc *mb = rproc->priv;
> +
> + /* reset-gpios is declared active-low, so logical 1 asserts reset */
> + gpiod_set_value_cansleep(mb->reset, 1);
> +
> + return 0;
> +}
> +
> +static int mb_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
> +{
> + int ret;
> +
> + ret = rproc_elf_load_rsc_table(rproc, fw);
> + if (ret == -EINVAL) {
> + dev_dbg(&rproc->dev, "no resource table found\n");
> + return 0;
> + }
> +
> + return ret;
> +}
> +
> +static const struct rproc_ops mb_rproc_ops = {
> + .prepare = mb_rproc_prepare,
> + .start = mb_rproc_start,
> + .stop = mb_rproc_stop,
> + .load = rproc_elf_load_segments,
> + .sanity_check = rproc_elf_sanity_check,
> + .get_boot_addr = rproc_elf_get_boot_addr,
> + .parse_fw = mb_rproc_parse_fw,
> +};
> +
> +static int mb_rproc_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mb_rproc *mb;
> + struct rproc *rproc;
> + const char *fw_name = NULL;
> + int ret;
> +
> + ret = rproc_of_parse_firmware(dev, 0, &fw_name);
> + if (ret < 0 && ret != -EINVAL)
> + return dev_err_probe(dev, ret,
> + "failed to parse firmware-name property\n");
> +
> + rproc = devm_rproc_alloc(dev, dev_name(dev), &mb_rproc_ops, fw_name,
> + sizeof(*mb));
> + if (!rproc)
> + return -ENOMEM;
> +
> + mb = rproc->priv;
> + mb->dev = dev;
> +
> + /*
> + * Keep the MicroBlaze in reset until remoteproc has finished loading
> + * firmware into the executable memory window described by reg and
> + * translated through the parent bus ranges property.
> + */
> + mb->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(mb->reset))
> + return dev_err_probe(dev, PTR_ERR(mb->reset),
> + "failed to get reset gpio\n");
> +
> + rproc->auto_boot = false;
> +
> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to set DMA mask\n");
> +
> + platform_set_drvdata(pdev, rproc);
> +
> + ret = devm_rproc_add(dev, rproc);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register rproc\n");
> +
> + dev_dbg(dev, "MicroBlaze remoteproc registered\n");
Drop. This does not look like useful printk message. Drivers should be
silent on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79
Core already gives way to see probe success.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 6/7] arm64: dts: qcom: kodiak: Add QSPI memory interconnect path
From: Dmitry Baryshkov @ 2026-04-14 17:56 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-6-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:24PM +0530, Viken Dadhaniya wrote:
> Add the missing QSPI-to-memory interconnect path alongside the existing
> configuration path. Without it, the interconnect framework cannot vote for
> the bandwidth required by QSPI DMA data transfers.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Krzysztof Kozlowski @ 2026-04-14 17:53 UTC (permalink / raw)
To: Ben Levinsky, andersson, mathieu.poirier
Cc: robh, krzk+dt, conor+dt, linux-remoteproc, devicetree,
linux-kernel, tanmay.shah, michal.simek
In-Reply-To: <20260414161558.2579920-2-ben.levinsky@amd.com>
On 14/04/2026 18:15, Ben Levinsky wrote:
A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> +---
> +$id: http://devicetree.org/schemas/remoteproc/amd,microblaze.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD MicroBlaze remote processor
> +
> +maintainers:
> + - Ben Levinsky <ben.levinsky@amd.com>
> +
> +description:
> + MicroBlaze remote processor controlled by Linux through the remoteproc
> + framework.
Describe hardware, not Linux frameworks. IOW, Linux framework is here
irrelevant.
> +
> + The executable firmware memory window is described in the
> + MicroBlaze-local address space by the node's reg property and translated
> + to the system physical address space with standard devicetree address
> + translation provided by the parent bus node's ranges property.
> +
> +properties:
> + $nodename:
> + pattern: "^remoteproc@[0-9a-f]+$"
> +
> + compatible:
> + const: amd,microblaze
microblaze is architecture, so this feels way too generic. You need SoC
specific compatibles and I suggest do not reference architecture, but
name or the function of the processor, if there are such.
> +
> + reg:
> + maxItems: 1
> + description:
> + MicroBlaze-local address and size of the executable firmware memory
> + window.
> +
> + firmware-name:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + / {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + bus@b0000000 {
> + compatible = "simple-pm-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0xb0000000 0x40000>;
> +
Drop all above.
> + remoteproc@0 {
> + compatible = "amd,microblaze";
> + reg = <0x0 0x40000>;
> + reset-gpios = <&mbv_reset_gpio 0 GPIO_ACTIVE_LOW>;
> + };
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/7] arm64: dts: qcom: talos: Add QSPI support
From: Dmitry Baryshkov @ 2026-04-14 17:47 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-4-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:22PM +0530, Viken Dadhaniya wrote:
> The Talos (QCS615) platform includes a QSPI controller used for accessing
> external flash storage. Add the QSPI OPP table, TLMM pinmux entries, and
> the QSPI controller node to enable support for this hardware.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/talos.dtsi | 80 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 80 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/7] spi: qcom-qspi: Add interconnect support for memory path
From: Dmitry Baryshkov @ 2026-04-14 17:47 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-3-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:21PM +0530, Viken Dadhaniya wrote:
> The QSPI controller has two interconnect paths:
> 1. qspi-config: CPU to QSPI controller for register access
> 2. qspi-memory: QSPI controller to memory for DMA operations
>
> Currently, the driver only manages the qspi-config path. Add support for
> the qspi-memory path to ensure proper bandwidth allocation for QSPI data
> transfers to/from memory. Enable and disable both paths during runtime PM
> transitions.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> drivers/spi/spi-qcom-qspi.c | 41 +++++++++++++++++++++++++++++++++++------
> 1 file changed, 35 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/7] spi: qcom-qspi: Fix incomplete error handling in runtime PM
From: Dmitry Baryshkov @ 2026-04-14 17:46 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers,
linux-arm-msm, linux-spi, devicetree, linux-kernel
In-Reply-To: <20260414-spi-nor-v2-2-bcca40de4b5f@oss.qualcomm.com>
On Tue, Apr 14, 2026 at 10:38:20PM +0530, Viken Dadhaniya wrote:
> The runtime PM functions had incomplete error handling that could leave the
> system in an inconsistent state. If any operation failed midway through
> suspend or resume, some resources would be left in the wrong state while
> others were already changed, leading to potential clock/power imbalances.
>
> Fix by adding proper error checking for all operations and using goto-based
> cleanup to ensure all successfully acquired resources are properly released
> on any error.
>
> Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
> ---
> drivers/spi/spi-qcom-qspi.c | 40 +++++++++++++++++++++++++++++++++-------
> 1 file changed, 33 insertions(+), 7 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: add AMD MicroBlaze binding
From: Rob Herring (Arm) @ 2026-04-14 17:29 UTC (permalink / raw)
To: Ben Levinsky
Cc: tanmay.shah, linux-kernel, mathieu.poirier, conor+dt, devicetree,
andersson, michal.simek, krzk+dt, linux-remoteproc
In-Reply-To: <20260414161558.2579920-2-ben.levinsky@amd.com>
On Tue, 14 Apr 2026 09:15:57 -0700, Ben Levinsky wrote:
> Describe an AMD MicroBlaze remote processor controlled
> through the remoteproc framework.
>
> The binding models the MicroBlaze remoteproc device as a
> child node whose reg property describes the executable firmware
> memory window in the MicroBlaze-local address space. The parent bus
> node provides standard devicetree address translation through ranges
> so Linux can access the same memory through the system physical
> address space.
>
> An active-low reset GPIO holds the MicroBlaze in reset until
> firmware loading completes.
>
> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> ---
> .../bindings/remoteproc/amd,microblaze.yaml | 67 +++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/remoteproc/amd,microblaze.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/remoteproc/amd,microblaze.example.dtb: bus@b0000000 (simple-pm-bus): 'anyOf' conditional failed, one must be fixed:
'clocks' is a required property
'power-domains' is a required property
from schema $id: http://devicetree.org/schemas/bus/simple-pm-bus.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260414161558.2579920-2-ben.levinsky@amd.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH v2 7/7] arm64: dts: qcom: sc7180: Add QSPI memory interconnect path
From: Viken Dadhaniya @ 2026-04-14 17:08 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, cros-qcom-dts-watchers
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
Viken Dadhaniya
In-Reply-To: <20260414-spi-nor-v2-0-bcca40de4b5f@oss.qualcomm.com>
Add the missing QSPI-to-memory interconnect path alongside the existing
configuration path. Without this path, the interconnect framework cannot
correctly vote for the bandwidth required by QSPI DMA data transfers.
Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 45b9864e3304..0efcda80ac94 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2864,9 +2864,12 @@ qspi: spi@88dc000 {
clocks = <&gcc GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
<&gcc GCC_QSPI_CORE_CLK>;
clock-names = "iface", "core";
- interconnects = <&gem_noc MASTER_APPSS_PROC 0
- &config_noc SLAVE_QSPI_0 0>;
- interconnect-names = "qspi-config";
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_QSPI_0 QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&aggre1_noc MASTER_QSPI QCOM_ICC_TAG_ACTIVE_ONLY
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "qspi-config",
+ "qspi-memory";
power-domains = <&rpmhpd SC7180_CX>;
operating-points-v2 = <&qspi_opp_table>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox